summaryrefslogtreecommitdiff
path: root/drivers/reset/core.c
AgeCommit message (Collapse)AuthorFilesLines
2026-03-27reset: core: Drop unnecessary double quoteClaudiu Beznea1-1/+1
Drop unnecessary double quote. Reported-by: Pavel Machek <pavel@nabladev.com> Closes: https://lore.kernel.org/all/acJbYxKGAB4lxGQr@duo.ucw.cz Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-03-11reset: don't overwrite fwnode_reset_n_cellsBartosz Golaszewski1-6/+7
Fix a logic bug in reset_controller_register() where we set fwnode_reset_n_cells to 1 if fwnode is set and fwnode_xlate is not but we do it after assigning of_fwnode_handle(of_node) to fwnode. Modify the logic to: assign fwnode from of_node if applicable, if fwnode is still not set, try to get it from the device and only then check of_xlate and fwnode_xlate and either assign fwnode_reset_n_cells from OF or default to fwnode_reset_simple_xlate and fwnode_reset_n_cells = 1. Fixes: ba8dbbb14b7e ("reset: convert the core API to using firmware nodes") Reported-by: Mark Brown <broonie@kernel.org> Closes: https://lore.kernel.org/all/0b72286b-33dd-4bc9-8c0e-161c2f4baed8@sirena.org.uk/ Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Tested-by: Mark Brown <broonie@kernel.org> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-03-10reset: core: Fix indentationPhilipp Zabel1-1/+1
Correct an accidental whitespace change. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202603100730.J3pi4xqi-lkp@intel.com/ Fixes: 9035073d0ef1 ("reset: convert reset core to using firmware nodes") Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-03-09reset: convert reset core to using firmware nodesBartosz Golaszewski1-66/+100
With everything else now in place, we can convert the remaining parts of the reset subsystem to becoming fwnode-agnostic - meaning it will work with all kinds of firmware nodes, not only devicetree. To that end: extend struct reset_controller_dev with fields taking information relevant for using firmware nodes (which mirrors what we already do for OF-nodes) and limit using of_ APIs only to where it's absolutely necessary (mostly around the of_xlate callback). For backward compatibility of existing drivers we still support OF-nodes but firmware nodes become the preferred method. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-03-09reset: convert the core API to using firmware nodesBartosz Golaszewski1-15/+18
In order to simplify the commit converting the internals of reset core to using firmware nodes, first convert the user-facing API. Modify the signature of the core consumer functions but leave the specialized wrappers as is to avoid modifying users for now. No functional change intended. Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-03-09reset: convert of_reset_control_get_count() to using firmware nodesBartosz Golaszewski1-9/+27
Start the conversion of reset core to using firmware nodes by reworking of_reset_control_get_count(). Unfortunately there is no fwnode-based alternative to of_count_phandle_with_args() so we have to hand-code it. Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-03-09reset: protect struct reset_control with its own mutexBartosz Golaszewski1-32/+36
Currently we use a single, global mutex - misleadingly names reset_list_mutex - to protect the global list of reset devices, per-controller list of reset control handles and also internal fields of struct reset_control. Locking can be made a lot more fine-grained if we use a separate mutex for serializing operations on the list AND accessing the reset control handle. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-03-09reset: protect struct reset_controller_dev with its own mutexBartosz Golaszewski1-17/+27
Currently we use a single, global mutex - misleadingly names reset_list_mutex - to protect the global list of reset devices, per-controller list of reset control handles and also internal fields of struct reset_control. Locking can be made a lot more fine-grained if we use a separate mutex for serializing operations on the list AND accessing the reset controller device. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-03-09reset: handle removing supplier before consumersBartosz Golaszewski1-17/+91
Except for the reset-gpio, all reset drivers use device tree - and as such - benefit from the device links set up by driver core. This means, that no reset supplier will be unbound before all its consumers have been. For this reason, nobody bothered making the reset core resiliant to the object life-time issues that are plagueing the kernel. In this case: reset control handles referencing the reset provider device with no serialization or NULL-pointer checking. We now want to make the reset core fwnode-agnostic but before we do, we must make sure it can survive unbinding of suppliers with consumers still holding reset control handles. To that end: use SRCU to protect the rcdev pointer inside struct reset_control. We protect all sections using the pointer with SRCU read-only critical sections and synchronize SRCU after every modification of the pointer. This is in line with what the GPIO subsystem does and what the proposed revocable API tries to generalize. When and if the latter makes its way into the kernel, reset core could potentially also be generalized to use it. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-03-09reset: use lock guards in reset coreBartosz Golaszewski1-30/+25
Simplify the locking code in reset core by using lock guard from linux/cleanup.h. Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-03-09reset: fold ida_alloc() into reset_create_gpio_aux_device()Bartosz Golaszewski1-15/+14
We don't need to know the IDA value outside of the function that creates the auxiliary reset-gpio device. Simplify error handling by folding it into reset_create_gpio_aux_device(). Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-03-09reset: warn on reset-gpio releaseBartosz Golaszewski1-1/+1
While we implement an empty .release() callback for reset-gpio (driver core requires it), this function will never actually be called as nobody ever removes the device and the last reference is not dropped anywhere. This is by design - once created, the reset-gpio device stays in memory. Make the .release() callback emit a warning, should it ever be called due to a programming bug. Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-03-09reset: gpio: simplify fallback device matchingBartosz Golaszewski1-9/+6
The of_args field of struct reset_controller_dev was introduced to allow the reset-gpio driver to pass the phandle arguments back to reset core. The thing is: it doesn't even have to do it. The core sets the platform data of the auxiliary device *AND* has access to it later on during the lookup. This means the field is unneeded and all can happen entirely in reset core. Remove the field from the public header and don't set it in reset-gpio.c. Retrieve the platform data in reset core when needed instead. Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-03-09reset: gpio: add a devlink between reset-gpio and its consumerBartosz Golaszewski1-24/+55
The device that requests the reset control managed by the reset-gpio device is effectively its consumer but the devlink is only established between it and the GPIO controller exposing the reset pin. Add a devlink between the consumer of the reset control and its supplier. This will allow us to simplify the GPIOLIB code managing shared GPIOs when handling the corner case of reset-gpio and gpiolib-shared interacting. While at it and since we need to store the address of the auxiliary device: don't allocate memory for the device separately but fold it into struct reset_gpio_lookup instead. Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-02-22Convert 'alloc_flex' family to use the new default GFP_KERNEL argumentLinus Torvalds1-1/+1
This is the exact same thing as the 'alloc_obj()' version, only much smaller because there are a lot fewer users of the *alloc_flex() interface. As with alloc_obj() version, this was done entirely with mindless brute force, using the same script, except using 'flex' in the pattern rather than 'objs*'. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-22Convert 'alloc_obj' family to use the new default GFP_KERNEL argumentLinus Torvalds1-3/+3
This was done entirely with mindless brute force, using git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' | xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/' to convert the new alloc_obj() users that had a simple GFP_KERNEL argument to just drop that argument. Note that due to the extreme simplicity of the scripting, any slightly more complex cases spread over multiple lines would not be triggered: they definitely exist, but this covers the vast bulk of the cases, and the resulting diff is also then easier to check automatically. For the same reason the 'flex' versions will be done as a separate conversion. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21treewide: Replace kmalloc with kmalloc_obj for non-scalar typesKees Cook1-4/+4
This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook <kees@kernel.org>
2026-01-08reset: gpio: add the "compatible" propertyBartosz Golaszewski1-3/+4
In order to correctly handle the interaction between the reset-gpio devices and shared GPIOs managed by GPIOLIB, we need to be able to identify the former. Add the "compatible" property to allow us to use the device_is_compatible() helper. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2025-12-06Merge tag 'soc-drivers-6.19' of ↵Linus Torvalds1-121/+3
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC driver updates from Arnd Bergmann: "This is the first half of the driver changes: - A treewide interface change to the "syscore" operations for power management, as a preparation for future Tegra specific changes - Reset controller updates with added drivers for LAN969x, eic770 and RZ/G3S SoCs - Protection of system controller registers on Renesas and Google SoCs, to prevent trivially triggering a system crash from e.g. debugfs access - soc_device identification updates on Nvidia, Exynos and Mediatek - debugfs support in the ST STM32 firewall driver - Minor updates for SoC drivers on AMD/Xilinx, Renesas, Allwinner, TI - Cleanups for memory controller support on Nvidia and Renesas" * tag 'soc-drivers-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (114 commits) memory: tegra186-emc: Fix missing put_bpmp Documentation: reset: Remove reset_controller_add_lookup() reset: fix BIT macro reference reset: rzg2l-usbphy-ctrl: Fix a NULL vs IS_ERR() bug in probe reset: th1520: Support reset controllers in more subsystems reset: th1520: Prepare for supporting multiple controllers dt-bindings: reset: thead,th1520-reset: Add controllers for more subsys dt-bindings: reset: thead,th1520-reset: Remove non-VO-subsystem resets reset: remove legacy reset lookup code clk: davinci: psc: drop unused reset lookup reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S SoC reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3S support reset: eswin: Add eic7700 reset driver dt-bindings: reset: eswin: Documentation for eic7700 SoC reset: sparx5: add LAN969x support dt-bindings: reset: microchip: Add LAN969x support soc: rockchip: grf: Add select correct PWM implementation on RK3368 soc/tegra: pmc: Add USB wake events for Tegra234 amba: tegra-ahb: Fix device leak on SMMU enable ...
2025-11-20reset: gpio: use software nodes to setup the GPIO lookupBartosz Golaszewski1-49/+70
GPIO machine lookup is a nice mechanism for associating GPIOs with consumers if we don't know what kind of device the GPIO provider is or when it will become available. However in the case of the reset-gpio, we are already holding a reference to the device and so can reference its firmware node. Let's setup a software node that references the relevant GPIO and attach it to the auxiliary device we're creating. Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2025-11-20reset: gpio: convert the driver to using the auxiliary busBartosz Golaszewski1-8/+6
As the reset-gpio devices are purely virtual and never instantiated from real firmware nodes, let's convert the driver to using the - more fitting - auxiliary bus. Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2025-11-20reset: make the provider of reset-gpios the parent of the reset deviceBartosz Golaszewski1-8/+10
Auxiliary devices really do need a parent so ahead of converting the reset-gpios driver to registering on the auxiliary bus, make the GPIO device that provides the reset GPIO the parent of the reset-gpio device. To that end move the lookup of the GPIO device by fwnode to the beginning of __reset_add_reset_gpio_device() which has the added benefit of bailing out earlier, before allocating resources for the virtual device, if the chip is not up yet. Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2025-11-20reset: order includes alphabetically in reset/core.cBartosz Golaszewski1-3/+4
For better readability and easier maintenance order the includes alphabetically. Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2025-11-18reset: remove legacy reset lookup codeBartosz Golaszewski1-121/+3
There are no more users of this code. Let's remove the exported symbols and the implementation from reset core. Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> [p.zabel@pengutronix.de: folded in 8e6ec20e-8965-4b42-99fc-0462269ff2f1@paulmck-laptop] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2024-10-01reset: Add devres helpers to request pre-deasserted reset controlsPhilipp Zabel1-2/+46
Add devres helpers - devm_reset_control_bulk_get_exclusive_deasserted - devm_reset_control_bulk_get_optional_exclusive_deasserted - devm_reset_control_bulk_get_optional_shared_deasserted - devm_reset_control_bulk_get_shared_deasserted - devm_reset_control_get_exclusive_deasserted - devm_reset_control_get_optional_exclusive_deasserted - devm_reset_control_get_optional_shared_deasserted - devm_reset_control_get_shared_deasserted to request and immediately deassert reset controls. During cleanup, reset_control_assert() will be called automatically on the returned reset controls. Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20240925-reset-get-deasserted-v2-2-b3601bbd0458@pengutronix.de Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2024-10-01reset: replace boolean parameters with flags parameterPhilipp Zabel1-31/+40
Introduce enum reset_control_flags and replace the list of boolean parameters to the internal reset_control_get functions with a single flags parameter, before adding more boolean options. The separate boolean parameters have been shown to be error prone in the past. See for example commit a57f68ddc886 ("reset: Fix devm bulk optional exclusive control getter"). Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20240925-reset-get-deasserted-v2-1-b3601bbd0458@pengutronix.de Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2024-09-02reset: core: add get_device()/put_device on rcdevClément Léger1-0/+2
Since the rcdev structure is allocated by the reset controller drivers themselves, they need to exists as long as there is a consumer. A call to module_get() is already existing but that does not work when using device-tree overlays. In order to guarantee that the underlying reset controller device does not vanish while using it, add a get_device() call when retrieving a reset control from a reset controller device and a put_device() when releasing that control. Signed-off-by: Clément Léger <clement.leger@bootlin.com> Signed-off-by: Herve Codina <herve.codina@bootlin.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240808154658.247873-8-herve.codina@bootlin.com Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2024-09-02reset: simplify locking with guard()Krzysztof Kozlowski1-11/+4
Simplify error handling (less gotos) over locks with guard(). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Link: https://lore.kernel.org/r/20240825-reset-cleanup-scoped-v1-3-03f6d834f8c0@linaro.org Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2024-02-21reset: Instantiate reset GPIO controller for shared reset-gpiosKrzysztof Kozlowski1-13/+211
Devices sharing a reset GPIO could use the reset framework for coordinated handling of that shared GPIO line. We have several cases of such needs, at least for Devicetree-based platforms. If Devicetree-based device requests a reset line, while "resets" Devicetree property is missing but there is a "reset-gpios" one, instantiate a new "reset-gpio" platform device which will handle such reset line. This allows seamless handling of such shared reset-gpios without need of changing Devicetree binding [1]. To avoid creating multiple "reset-gpio" platform devices, store the Devicetree "reset-gpios" GPIO specifiers used for new devices on a linked list. Later such Devicetree GPIO specifier (phandle to GPIO controller, GPIO number and GPIO flags) is used to check if reset controller for given GPIO was already registered. If two devices have conflicting "reset-gpios" property, e.g. with different ACTIVE_xxx flags, this would allow to spawn two separate "reset-gpio" devices, where the second would fail probing on busy GPIO request. Link: https://lore.kernel.org/all/YXi5CUCEi7YmNxXM@robh.at.kernel.org/ [1] Cc: Bartosz Golaszewski <brgl@bgdev.pl> Cc: Chris Packham <chris.packham@alliedtelesis.co.nz> Cc: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240129115216.96479-5-krzysztof.kozlowski@linaro.org Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2023-11-30reset: Fix crash when freeing non-existent optional resetsGeert Uytterhoeven1-4/+4
When obtaining one or more optional resets, non-existent resets are stored as NULL pointers, and all related error and cleanup paths need to take this into account. Currently only reset_control_put() and reset_control_bulk_put() get this right. All of __reset_control_bulk_get(), of_reset_control_array_get(), and reset_control_array_put() lack the proper checking, causing NULL pointer dereferences on failure or release. Fix this by moving the existing check from reset_control_bulk_put() to __reset_control_put_internal(), so it applies to all callers. The double check in reset_control_put() doesn't hurt. Fixes: 17c82e206d2a3cd8 ("reset: Add APIs to manage array of resets") Fixes: 48d71395896d54ee ("reset: Add reset_control_bulk API") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/2440edae7ca8534628cdbaf559ded288f2998178.1701276806.git.geert+renesas@glider.be Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2023-10-25reset: Annotate struct reset_control_array with __counted_byKees Cook1-2/+2
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct reset_control_array. Additionally, since the element count member must be set before accessing the annotated flexible array member, move its initialization earlier. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: "Gustavo A. R. Silva" <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20230922175229.work.838-kees@kernel.org Signed-off-by: Kees Cook <keescook@chromium.org>
2022-05-03reset: ACPI reset supportKrishna Yarlagadda1-1/+14
Some of the IO devices like I2C or SPI require reset at runtime to recover from an error condition without changing the power state of the system. Added check for ACPI handle and a call to method '__RST' if supported. Devices using device tree method are unaffected by this. Signed-off-by: Krishna Yarlagadda <kyarlagadda@nvidia.com> [p.zabel@pengutronix.de: wrap in #ifdef CONFIG_ACPI due to missing stubs] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Link: https://lore.kernel.org/r/20220307135626.16673-1-kyarlagadda@nvidia.com
2021-06-07reset: bail if try_module_get() failsPhilipp Zabel1-1/+4
Abort instead of returning a new reset control for a reset controller device that is going to have its module unloaded. Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Fixes: 61fc41317666 ("reset: Add reset controller API") Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20210607082615.15160-1-p.zabel@pengutronix.de Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2021-05-10reset: whitespace fixesPhilipp Zabel1-10/+10
Fixes checkpatch issues: CHECK: Alignment should match open parenthesis #87: FILE: drivers/reset/core.c:87: +static int of_reset_simple_xlate(struct reset_controller_dev *rcdev, + const struct of_phandle_args *reset_spec) CHECK: Lines should not end with a '(' #540: FILE: drivers/reset/core.c:540: +static struct reset_control *__reset_control_get_internal( CHECK: Alignment should match open parenthesis #603: FILE: drivers/reset/core.c:603: +struct reset_control *__of_reset_control_get(struct device_node *node, + const char *id, int index, bool shared, CHECK: Alignment should match open parenthesis #781: FILE: drivers/reset/core.c:781: +struct reset_control *__devm_reset_control_get(struct device *dev, + const char *id, int index, bool shared, Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2021-03-18reset: Add reset_control_bulk APIPhilipp Zabel1-0/+215
Follow the clock and regulator subsystems' lead and add a bulk API for reset controls. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20210314154459.15375-5-digetx@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-14reset: core: fix a kernel-doc markupMauro Carvalho Chehab1-2/+2
A function has a different name between their prototype and its kernel-doc markup: ../drivers/reset/core.c:888: warning: expecting prototype for device_reset(). Prototype was for __device_reset() instead Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2020-11-16reset: make shared pulsed reset controls re-triggerableAmjad Ouled-Ameur1-0/+73
The current reset framework API does not allow to release what is done by reset_control_reset(), IOW decrement triggered_count. Add the new reset_control_rearm() call to do so. When reset_control_reset() has been called once, the counter triggered_count, in the reset framework, is incremented i.e the resource under the reset is in-use and the reset should not be done again. reset_control_rearm() would be the way to state that the resource is no longer used and, that from the caller's perspective, the reset can be fired again if necessary. Signed-off-by: Amjad Ouled-Ameur <aouledameur@baylibre.com> Reported-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2020-09-23reset: Fix and extend kerneldocKrzysztof Kozlowski1-1/+2
Fix W=1 compile warnings (invalid kerneldoc): drivers/reset/core.c:50: warning: Function parameter or member 'array' not described in 'reset_control' drivers/reset/core.c:50: warning: Function parameter or member 'deassert_count' not described in 'reset_control' Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2020-01-02reset: Align logic and flow in managed helpersGeert Uytterhoeven1-16/+17
__devm_reset_control_get() and devm_reset_control_array_get() are very similar, but they do not look similar, due to inverted logic. Make them more similar, following the "bail out early" paradigm. Adjust the logic and flow in devm_reset_controller_register() to match the two other functions. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-12-10reset: Do not register resource data for missing resetsGeert Uytterhoeven1-2/+2
When an optional reset is not present, __devm_reset_control_get() and devm_reset_control_array_get() still register resource data to release the non-existing reset on cleanup, which is futile. Fix this by skipping NULL reset control pointers. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-12-10reset: Fix {of,devm}_reset_control_array_get kerneldoc return typesGeert Uytterhoeven1-4/+2
of_reset_control_array_get() and devm_reset_control_array_get() return struct reset_control pointers, not internal struct reset_control_array pointers, just like all other reset control API calls. Correct the kerneldoc to match the code. Fixes: 17c82e206d2a3cd8 ("reset: Add APIs to manage array of resets") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-12-05Merge tag 'armsoc-drivers' of ↵Linus Torvalds1-4/+4
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC driver updates from Olof Johansson: "Various driver updates for platforms: - A larger set of work on Tegra 2/3 around memory controller and regulator features, some fuse cleanups, etc.. - MMP platform drivers, in particular for USB PHY, and other smaller additions. - Samsung Exynos 5422 driver for DMC (dynamic memory configuration), and ASV (adaptive voltage), allowing the platform to run at more optimal operating points. - Misc refactorings and support for RZ/G2N and R8A774B1 from Renesas - Clock/reset control driver for TI/OMAP - Meson-A1 reset controller support - Qualcomm sdm845 and sda845 SoC IDs for socinfo" * tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (150 commits) firmware: arm_scmi: Fix doorbell ring logic for !CONFIG_64BIT soc: fsl: add RCPM driver dt-bindings: fsl: rcpm: Add 'little-endian' and update Chassis definition memory: tegra: Consolidate registers definition into common header memory: tegra: Ensure timing control debug features are disabled memory: tegra: Introduce Tegra30 EMC driver memory: tegra: Do not handle error from wait_for_completion_timeout() memory: tegra: Increase handshake timeout on Tegra20 memory: tegra: Print a brief info message about EMC timings memory: tegra: Pre-configure debug register on Tegra20 memory: tegra: Include io.h instead of iopoll.h memory: tegra: Adapt for Tegra20 clock driver changes memory: tegra: Don't set EMC rate to maximum on probe for Tegra20 memory: tegra: Add gr2d and gr3d to DRM IOMMU group memory: tegra: Set DMA mask based on supported address bits soc: at91: Add Atmel SFR SN (Serial Number) support memory: atmel-ebi: switch to SPDX license identifiers memory: atmel-ebi: move NUM_CS definition inside EBI driver soc: mediatek: Refactor bus protection control soc: mediatek: Refactor sram control ...
2019-10-24reset: improve of_xlate documentationPhilipp Zabel1-2/+4
Mention of_reset_simple_xlate as the default if of_xlate is not set. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-10-24reset: fix of_reset_control_get_count kerneldoc commentPhilipp Zabel1-1/+2
Add a newline and remove a superfluous kerneldoc marker before the of_reset_control_get_count kerneldoc comment, to fix documentation build warnings: ./drivers/reset/core.c:832: warning: Incorrect use of kernel-doc format: * of_reset_control_get_count - Count number of resets available with a device ./drivers/reset/core.c:840: warning: Function parameter or member 'node' not described in 'of_reset_control_get_count' Fixes: 17c82e206d2a ("reset: Add APIs to manage array of resets") Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-10-24reset: fix of_reset_simple_xlate kerneldoc commentPhilipp Zabel1-1/+0
The flags parameter never made it into the API, but was erroneously included in the kerneldoc comment. Remove it to fix a documentation build warning: ./drivers/reset/core.c:86: warning: Excess function parameter 'flags' description in 'of_reset_simple_xlate' Fixes: 61fc41317666 ("reset: Add reset controller API") Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-10-22reset: Fix memory leak in reset_control_array_put()Kishon Vijay Abraham I1-0/+1
Memory allocated for 'struct reset_control_array' in of_reset_control_array_get() is never freed in reset_control_array_put() resulting in kmemleak showing the following backtrace. backtrace: [<00000000c5f17595>] __kmalloc+0x1b0/0x2b0 [<00000000bd499e13>] of_reset_control_array_get+0xa4/0x180 [<000000004cc02754>] 0xffff800008c669e4 [<0000000050a83b24>] platform_drv_probe+0x50/0xa0 [<00000000d3a0b0bc>] really_probe+0x108/0x348 [<000000005aa458ac>] driver_probe_device+0x58/0x100 [<000000008853626c>] device_driver_attach+0x6c/0x90 [<0000000085308d19>] __driver_attach+0x84/0xc8 [<00000000080d35f2>] bus_for_each_dev+0x74/0xc8 [<00000000dd7f015b>] driver_attach+0x20/0x28 [<00000000923ba6e6>] bus_add_driver+0x148/0x1f0 [<0000000061473b66>] driver_register+0x60/0x110 [<00000000c5bec167>] __platform_driver_register+0x40/0x48 [<000000007c764b4f>] 0xffff800008c6c020 [<0000000047ec2e8c>] do_one_initcall+0x5c/0x1b0 [<0000000093d4b50d>] do_init_module+0x54/0x1d0 Fixes: 17c82e206d2a ("reset: Add APIs to manage array of resets") Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-10-03reset: Remove copy'n'paste redundancy in the commentsAndy Shevchenko1-2/+0
It seems the commit bb475230b8e5 ("reset: make optional functions really optional") brought couple of redundant lines in the comments. Drop them here. Cc: Ramiro Oliveira <Ramiro.Oliveira@synopsys.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-07-04Merge tag 'reset-fixes-for-v5.2' of git://git.pengutronix.de/git/pza/linux ↵Olof Johansson1-3/+0
into arm/drivers Reset controller fix for v5.2 This tag removes a redundant device pointer NULL check from __reset_control_get_from_lookup to fix a static code checker warning. * tag 'reset-fixes-for-v5.2' of git://git.pengutronix.de/git/pza/linux: reset: remove redundant null check on pointer dev Link: https://lore.kernel.org/r/1562236626.6641.13.camel@pengutronix.de Signed-off-by: Olof Johansson <olof@lixom.net>
2019-07-04reset: remove redundant null check on pointer devColin Ian King1-3/+0
Pointer dev is being dereferenced when passed to the inlined functon dev_name, however, dev is later being null checked so at first this seems like a potential null pointer dereference. In fact, _reset_control_get_from_lookup is only ever called from __reset_control_get, right after checking dev->of_node hence dev can never be null. Clean this up by removing the redundant null check. Thanks to Philipp Zabel for spotting that dev can never be null. Addresses-Coverity: ("Dereference before null check") Fixes: 6691dffab0ab ("reset: add support for non-DT systems") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-05-30treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152Thomas Gleixner1-5/+1
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 3029 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-17 05:46:19 +0300