aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/reset.h (follow)
AgeCommit message (Collapse)AuthorFilesLines
2019-04-02reset: fix linux/reset.h errorsRandy Dunlap1-0/+2
The header file <linux/reset.h> uses errno constant(s) and the ERR_PTR() macro but does not #include the appropriate header files that provide those facilities, so add 2 header files to fix build errors. CC [M] drivers/gpu/drm/lima/lima_device.o In file included from ../drivers/gpu/drm/lima/lima_device.c:5:0: ../include/linux/reset.h: In function ‘__device_reset’: ../include/linux/reset.h:77:25: error: ‘ENOTSUPP’ undeclared (first use in this function) return optional ? 0 : -ENOTSUPP; ../include/linux/reset.h:77:25: note: each undeclared identifier is reported only once for each function it appears in ../include/linux/reset.h: In function ‘__of_reset_control_get’: ../include/linux/reset.h:85:36: error: ‘ENOTSUPP’ undeclared (first use in this function) return optional ? NULL : ERR_PTR(-ENOTSUPP); ../include/linux/reset.h: In function ‘__reset_control_get’: ../include/linux/reset.h:93:36: error: ‘ENOTSUPP’ undeclared (first use in this function) return optional ? NULL : ERR_PTR(-ENOTSUPP); ../include/linux/reset.h: In function ‘__devm_reset_control_get’: ../include/linux/reset.h:101:36: error: ‘ENOTSUPP’ undeclared (first use in this function) return optional ? NULL : ERR_PTR(-ENOTSUPP); ../include/linux/reset.h: In function ‘devm_reset_control_array_get’: ../include/linux/reset.h:107:36: error: ‘ENOTSUPP’ undeclared (first use in this function) return optional ? NULL : ERR_PTR(-ENOTSUPP); ../include/linux/reset.h: In function ‘of_reset_control_array_get’: ../include/linux/reset.h:114:36: error: ‘ENOTSUPP’ undeclared (first use in this function) return optional ? NULL : ERR_PTR(-ENOTSUPP); In file included from ../drivers/gpu/drm/lima/lima_device.c:5:0: ../include/linux/reset.h: In function ‘__devm_reset_control_get’: ../include/linux/reset.h:102:1: warning: control reaches end of non-void function [-Wreturn-type] } Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-03-20reset: Add acquire/release support for arraysThierry Reding1-0/+6
Add implementations that apply acquire and release operations to all reset controls part of a reset control array. Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-03-20reset: Add acquired flag to of_reset_control_array_get()Thierry Reding1-6/+8
In order to be able to request an array of reset controls in acquired or released mode, add the acquired flag to of_reset_control_array_get() and pass the flag to subsequent calls of __of_reset_control_get(). Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-03-20reset: add acquired/released state for exclusive reset controlsPhilipp Zabel1-20/+73
There are cases where a driver needs explicit control over a reset line that is exclusively conneted to its device, but this control has to be temporarily handed over to the power domain controller to handle reset requirements during power transitions. Allow multiple exclusive reset controls to be requested in 'released' state for the same physical reset line, only one of which can be acquired at the same time. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-01-07reset: Add reset_control_get_count()Geert Uytterhoeven1-0/+7
Currently the reset core has internal support for counting the number of resets for a device described in DT. Generalize this to devices using lookup resets, and export it for public use. This will be used by generic drivers that need to be sure a device is controlled by a single, dedicated reset line (e.g. vfio-platform). Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> [p.zabel@pengutronix.de: fixed a typo in reset_control_get_count comment] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-01-07reset: Improve reset controller kernel docsGeert Uytterhoeven1-4/+4
Grammar and indentation fixes. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> [p.zabel@pengutronix.de: dropped "shared among" -> "shared between"] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2018-10-04reset: Grammar s/more then once/more than once/Geert Uytterhoeven1-1/+1
Fix grammar in reset_control_get_exclusive() documentation comment. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-11-27reset: remove reset_control_get(_optional)Masahiro Yamada1-12/+0
No more users of these two. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-11-27reset: minimize the number of headers included from <linux/reset.h>Masahiro Yamada1-1/+3
Commit 62e24c5775ec ("reset: add exported __reset_control_get, return NULL if optional") moved the dev->of_node reference to core.c, so <linux/reset.h> does not need to know the members of struct device. Declaring device and device_node as structure is enough. <linux/types.h> is necessary for bool, true, and false. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-11-27reset: remove remaining WARN_ON() in <linux/reset.h>Masahiro Yamada1-6/+0
Commit bb475230b8e5 ("reset: make optional functions really optional") gave a new meaning to _get_optional variants. The differentiation by WARN_ON() is not needed any more. We already have inconsistency about this; (devm_)reset_control_get_exclusive() has WARN_ON() check, but of_reset_control_get_exclusive() does not. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-11-27reset: make device_reset_optional() really optionalMasahiro Yamada1-15/+13
Commit bb475230b8e5 ("reset: make optional functions really optional") converted *_get_optional* functions, but device_reset_optional() was left behind. Convert it in the same way. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman1-0/+1
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-07-19reset: Add APIs to manage array of resetsVivek Gautam1-0/+68
Many devices may want to request a bunch of resets and control them. So it's better to manage them as an array. Add APIs to _get() an array of reset_control, reusing the _assert(), _deassert(), and _reset() APIs for single reset controls. Since reset controls already may control multiple reset lines with a single hardware bit, from the user perspective, reset control arrays are not at all different from single reset controls. Note that these APIs don't guarantee that the reset lines managed in the array are handled in any particular order. Cc: Felipe Balbi <balbi@kernel.org> Cc: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> [p.zabel@pengutronix.de: changed API to hide reset control arrays behind struct reset_control] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-04-04reset: add exported __reset_control_get, return NULL if optionalPhilipp Zabel1-8/+14
Rename the internal __reset_control_get/put functions to __reset_control_get/put_internal and add an exported __reset_control_get equivalent to __of_reset_control_get that takes a struct device parameter. This avoids the confusing call to __of_reset_control_get in the non-DT case and fixes the devm_reset_control_get_optional function to return NULL if RESET_CONTROLLER is enabled but dev->of_node == NULL. Fixes: bb475230b8e5 ("reset: make optional functions really optional") Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Ramiro Oliveira <Ramiro.Oliveira@synopsys.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-03-21reset: fix optional reset_control_get stubs to return NULLPhilipp Zabel1-7/+2
When RESET_CONTROLLER is not enabled, the optional reset_control_get stubs should now also return NULL. Since it is now valid for reset_control_assert/deassert/reset/status/put to be called unconditionally, with NULL as an argument for optional resets, the stubs are not allowed to warn anymore. Fixes: bb475230b8e5 ("reset: make optional functions really optional") Reported-by: Andrzej Hajda <a.hajda@samsung.com> Tested-by: Andrzej Hajda <a.hajda@samsung.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Cc: Ramiro Oliveira <Ramiro.Oliveira@synopsys.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-01-20reset: make optional functions really optionalRamiro Oliveira1-19/+26
The *_get_optional_* functions weren't really optional so this patch makes them really optional. These *_get_optional_* functions will now return NULL instead of an error if no matching reset phandle is found in the DT, and all the reset_control_* functions now accept NULL rstc pointers. Signed-off-by: Ramiro Oliveira <Ramiro.Oliveira@synopsys.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-01-20reset: Change shared flag from int to boolRamiro Oliveira1-16/+16
Since the new parameter being added is going to be a bool this patch changes the shared flag from int to bool to match the new parameter. Signed-off-by: Ramiro Oliveira <Ramiro.Oliveira@synopsys.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-06-29Merge branch 'reset/explicit-api' into reset/nextPhilipp Zabel1-44/+167
2016-06-29reset: TRIVIAL: Add line break at same place for similar APIsLee Jones1-2/+2
Standardise the way inline functions: devm_reset_control_get_shared_by_index devm_reset_control_get_exclusive_by_index ... are formatted. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-06-29reset: Supply *_shared variant calls when using *_optional APIsLee Jones1-0/+12
Consumers need to be able to specify whether they are requesting an 'exclusive' or 'shared' reset line no matter which API (of_*, devm_*, etc) they are using. This change allows users of the optional_* API in particular to specify that their request is for a 'shared' line. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-06-29reset: Supply *_shared variant calls when using of_* APILee Jones1-0/+53
Consumers need to be able to specify whether they are requesting an 'exclusive' or 'shared' reset line no matter which API (of_*, devm_*, etc) they are using. This change allows users of the of_* API in particular to specify that their request is for a 'shared' line. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-06-29reset: Ensure drivers are explicit when requesting reset linesLee Jones1-24/+82
Phasing out generic reset line requests enables us to make some better decisions on when and how to (de)assert said lines. If an 'exclusive' line is requested, we know a device *requires* a reset and that it's preferable to act upon a request right away. However, if a 'shared' reset line is requested, we can reasonably assume sure that placing a device into reset isn't a hard requirement, but probably a measure to save power and is thus able to cope with not being asserted if another device is still in use. In order allow gentle adoption and not to forcing all consumers to move to the API immediately, causing administration headache between subsystems, this patch adds some temporary stand-in shim-calls. This will ease the burden at merge time and allow subsystems to migrate over to the new API in a more realistic time-frame. Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-06-29reset: Reorder inline reset_control_get*() wrappersLee Jones1-21/+21
We're about to split the current API into two, where consumers will be forced to be explicit when requesting reset lines. The choice will be to either the call the *_exclusive or *_shared variant depending on whether they can actually tolorate not being asserted when that request is made. The new API will look like this once reorded and complete: reset_control_get_exclusive() reset_control_get_shared() reset_control_get_optional_exclusive() reset_control_get_optional_shared() of_reset_control_get_exclusive() of_reset_control_get_shared() of_reset_control_get_exclusive_by_index() of_reset_control_get_shared_by_index() devm_reset_control_get_exclusive() devm_reset_control_get_shared() devm_reset_control_get_optional_exclusive() devm_reset_control_get_optional_shared() devm_reset_control_get_exclusive_by_index() devm_reset_control_get_shared_by_index() Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-06-01reset: Return -ENOTSUPP when not configuredJohn Youn1-2/+2
Prior to commit 6c96f05c8bb8 ("reset: Make [of_]reset_control_get[_foo] functions wrappers"), the "optional" functions returned -ENOTSUPP when CONFIG_RESET_CONTROLLER was not set. Revert back to the old behavior by changing the new __devm_reset_control_get() and __of_reset_control_get() functions to return ERR_PTR(-ENOTSUPP) when compiled without CONFIG_RESET_CONTROLLER. Otherwise they will return -EINVAL causing users to think that an error occurred when CONFIG_RESET_CONTROLLER is not set. Fixes: 6c96f05c8bb8 ("reset: Make [of_]reset_control_get[_foo] functions wrappers") Signed-off-by: John Youn <johnyoun@synopsys.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-04-04reset: Add missing function stub for device_resetDaniel Lezcano1-0/+6
The Mediatek's thermal driver fails to compile when the RESET_CONTROLLER option is not set. Logically, as the driver depends on this option to compile, the Kconfig should select it but actually that is not correct because the Kconfig provides also the COMPILE_TEST to increase the compile test coverage. By providing the missing 'device_reset' stub for the driver in reset.h, that let the kernel to compile on different platforms with the Mediatek thermal driver enabled with the COMPILE_TEST option. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-03-30reset: Add support for shared reset controlsHans de Goede1-15/+81
In some SoCs some hw-blocks share a reset control. Add support for this setup by adding new: reset_control_get_shared() devm_reset_control_get_shared() devm_reset_control_get_shared_by_index() methods to get a reset_control. Note that this patch omits adding of_ variants, if these are needed later they can be easily added. This patch also changes the behavior of the existing exclusive reset_control_get() variants, if these are now called more then once for the same reset_control they will return -EBUSY. To catch existing drivers triggering this error (there should not be any) a WARN_ON(1) is added in this path. When a reset_control is shared, the behavior of reset_control_assert / deassert is changed, for shared reset_controls these will work like the clock-enable/disable and regulator-on/off functions. They will keep a deassert_count, and only (re-)assert the reset after reset_control_assert has been called as many times as reset_control_deassert was called. Calling reset_control_assert without first calling reset_control_deassert is not allowed on a shared reset control. Calling reset_control_reset is also not allowed on a shared reset control. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-03-30reset: Make [of_]reset_control_get[_foo] functions wrappersHans de Goede1-36/+90
With both the regular, _by_index and _optional variants we already have quite a few variants of [of_]reset_control_get[_foo], the upcoming addition of shared reset lines support makes this worse. This commit changes all the variants into wrappers around common core functions. For completeness sake this commit also adds a new devm_get_reset_control_by_index wrapper. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2015-11-16reset: use ENOTSUPP instead of ENOSYSPhilipp Zabel1-4/+4
ENOSYS is reserved to report invalid syscalls to userspace. Consistently return ENOTSUPP to indicate that the driver doesn't support the functionality or the reset framework is not enabled at all. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2015-11-16reset: add of_reset_control_get_by_index()Vince Hsu1-0/+9
Add of_reset_control_get_by_index() to allow the drivers to get reset device without knowing its name. Signed-off-by: Vince Hsu <vinceh@nvidia.com> [jonathanh@nvidia.com: Updated stub function to return -ENOTSUPP instead of -ENOSYS which should only be used for system calls.] Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2015-09-01reset: Add (devm_)reset_control_get stub functionsAxel Lin1-0/+14
So the drivers can be compiled with CONFIG_RESET_CONTROLLER disabled. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2014-10-20reset: add reset_control_status helper functionDinh Nguyen1-0/+7
There are cases where a system will want to read a reset status bit before doing any other toggling. Add a reset_control_status helper function to the reset controller API. Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2014-04-14reset: Add of_reset_control_get to reset.hHans de Goede1-0/+10
of_reset_control_get is not declared static in drivers/reset/core.c, which is correct as we want to use it elsewhere too. But it does not have a protype declared anywhere under include/linux. Add a prototype / stub for it to linux/reset.h to fix this. Reviewed-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2014-03-09reset: Add optional resets and stubsPhilipp Zabel1-5/+64
This patch adds device_reset_optional and (devm_)reset_control_get_optional variants that drivers can use to indicate they can function without control over the reset line. For those functions, stubs are added so the drivers can be compiled with CONFIG_RESET_CONTROLLER disabled. Also, device_reset is annotated with __must_check. Drivers ignoring the return value should use device_reset_optional instead. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Marek Vasut <marex@denx.de> Acked-by: Wolfram Sang <wsa@the-dreams.de>
2014-02-03reset: Add of_reset_control_getMaxime Ripard1-0/+4
In some cases, you might need to deassert from reset an hardware block that doesn't associated to a struct device (CPUs, timers, etc.). Add a small helper to retrieve the reset controller from the device tree without the need to pass a struct device. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2013-04-12reset: Add reset controller APIPhilipp Zabel1-0/+17
This adds a simple API for devices to request being reset by separate reset controller hardware and implements the reset signal device tree binding. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Shawn Guo <shawn.guo@linaro.org> Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Pavel Machek <pavel@ucw.cz>