kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-08 18:57:22 +00:00
Code Issues Releases Packages Activity
linux/drivers/reset/core.c

1606 lines
40 KiB
Raw Normal View History

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152 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>
2019-05-27 08:55:01 +02:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: order includes alphabetically in reset/core.c 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-20 14:24:01 +01:00
reset: Add support for shared reset controls 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-02-23 18:46:26 +01:00
reset: gpio: convert the driver to using the auxiliary bus 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-20 14:24:03 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: convert of_reset_control_get_count() to using firmware nodes 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-06 18:22:55 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: order includes alphabetically in reset/core.c 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-20 14:24:01 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: convert of_reset_control_get_count() to using firmware nodes 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-06 18:22:55 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Share struct reset_control between reset_control_get calls Now that struct reset_control no longer stores the device pointer for the device calling reset_control_get we can share a single struct reset_control when multiple calls to reset_control_get are made for the same reset line (same id / index). This is a preparation patch for adding support for shared reset lines. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-02-23 18:46:25 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: Share struct reset_control between reset_control_get calls Now that struct reset_control no longer stores the device pointer for the device calling reset_control_get we can share a single struct reset_control when multiple calls to reset_control_get are made for the same reset line (same id / index). This is a preparation patch for adding support for shared reset lines. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-02-23 18:46:25 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Share struct reset_control between reset_control_get calls Now that struct reset_control no longer stores the device pointer for the device calling reset_control_get we can share a single struct reset_control when multiple calls to reset_control_get are made for the same reset line (same id / index). This is a preparation patch for adding support for shared reset lines. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-02-23 18:46:25 +01:00
reset: add acquired/released state for exclusive reset controls 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-02-21 16:25:53 +01:00
reset: Add support for shared reset controls 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-02-23 18:46:26 +01:00
reset: Fix and extend kerneldoc 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-07-28 19:10:11 +02:00
reset: allow using reset_control_reset with shared reset Some SoCs (for example Amlogic GXBB) implement a reset controller which only supports a reset pulse (triggered via reset_control_reset). At the same time multiple devices (in case of the Amlogic GXBB SoC both USB PHYs) are sharing the same reset line. This patch allows using reset_control_reset also for shared resets. There are limitations though: reset_control_reset can only be used if reset_control_assert was not used yet. reset_control_assert can only be used if reset_control_reset was not used yet. For shared resets the reset is only triggered once for the lifetime of the reset_control instance (the reset can be triggered again if all consumers of that specific reset_control are gone, as the reset framework will free the reset_control instance in that case). Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-11-12 14:13:03 +01:00
reset: protect struct reset_control with its own mutex 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-06 18:22:54 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: Share struct reset_control between reset_control_get calls Now that struct reset_control no longer stores the device pointer for the device calling reset_control_get we can share a single struct reset_control when multiple calls to reset_control_get are made for the same reset line (same id / index). This is a preparation patch for adding support for shared reset lines. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-02-23 18:46:25 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: use kref for reference counting Use kref for reference counting and enjoy the advantages of refcount_t. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-05-31 17:42:29 +02:00
reset: add acquired/released state for exclusive reset controls 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-02-21 16:25:53 +01:00
reset: Change shared flag from int to bool 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>
2017-01-13 17:57:40 +00:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: Add support for shared reset controls 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-02-23 18:46:26 +01:00
reset: allow using reset_control_reset with shared reset Some SoCs (for example Amlogic GXBB) implement a reset controller which only supports a reset pulse (triggered via reset_control_reset). At the same time multiple devices (in case of the Amlogic GXBB SoC both USB PHYs) are sharing the same reset line. This patch allows using reset_control_reset also for shared resets. There are limitations though: reset_control_reset can only be used if reset_control_assert was not used yet. reset_control_assert can only be used if reset_control_reset was not used yet. For shared resets the reset is only triggered once for the lifetime of the reset_control instance (the reset can be triggered again if all consumers of that specific reset_control are gone, as the reset framework will free the reset_control instance in that case). Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-11-12 14:13:03 +01:00
reset: protect struct reset_control with its own mutex 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-06 18:22:54 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: Annotate struct reset_control_array with __counted_by 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>
2023-09-22 10:52:29 -07:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: gpio: add a devlink between reset-gpio and its consumer 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-03-06 18:22:46 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: gpio: add a devlink between reset-gpio and its consumer 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-03-06 18:22:46 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: add acquired/released state for exclusive reset controls 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-02-21 16:25:53 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: add acquired/released state for exclusive reset controls 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-02-21 16:25:53 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: don't overwrite fwnode_reset_n_cells 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-10 16:15:15 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: don't overwrite fwnode_reset_n_cells 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-10 16:15:15 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: don't overwrite fwnode_reset_n_cells 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-10 16:15:15 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: don't overwrite fwnode_reset_n_cells 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-10 16:15:15 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Share struct reset_control between reset_control_get calls Now that struct reset_control no longer stores the device pointer for the device calling reset_control_get we can share a single struct reset_control when multiple calls to reset_control_get are made for the same reset line (same id / index). This is a preparation patch for adding support for shared reset lines. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-02-23 18:46:25 +01:00
reset: protect struct reset_controller_dev with its own mutex 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-06 18:22:53 +01:00
reset: Share struct reset_control between reset_control_get calls Now that struct reset_control no longer stores the device pointer for the device calling reset_control_get we can share a single struct reset_control when multiple calls to reset_control_get are made for the same reset line (same id / index). This is a preparation patch for adding support for shared reset lines. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-02-23 18:46:25 +01:00
reset: use lock guards in reset core 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-06 18:22:51 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: protect struct reset_controller_dev with its own mutex 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-06 18:22:53 +01:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: protect struct reset_controller_dev with its own mutex 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-06 18:22:53 +01:00
reset: use lock guards in reset core 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-06 18:22:51 +01:00
reset: protect struct reset_controller_dev with its own mutex 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-06 18:22:53 +01:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: protect struct reset_controller_dev with its own mutex 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-06 18:22:53 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: add devm_reset_controller_register API Add a device managed API for reset_controller_register(). This helps in reducing code in .remove callbacks and sometimes dropping .remove callbacks entirely. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-05-01 19:36:57 +09:00
reset: Align logic and flow in managed helpers __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-11-20 15:59:27 +01:00
reset: add devm_reset_controller_register API Add a device managed API for reset_controller_register(). This helps in reducing code in .remove callbacks and sometimes dropping .remove callbacks entirely. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-05-01 19:36:57 +09:00
reset: Align logic and flow in managed helpers __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-11-20 15:59:27 +01:00
reset: add devm_reset_controller_register API Add a device managed API for reset_controller_register(). This helps in reducing code in .remove callbacks and sometimes dropping .remove callbacks entirely. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-05-01 19:36:57 +09:00
reset: Align logic and flow in managed helpers __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-11-20 15:59:27 +01:00
reset: add devm_reset_controller_register API Add a device managed API for reset_controller_register(). This helps in reducing code in .remove callbacks and sometimes dropping .remove callbacks entirely. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-05-01 19:36:57 +09:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: make shared pulsed reset controls re-triggerable 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-11-13 00:00:43 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: Add acquire/release support for arrays 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-02-21 16:25:55 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Add support for shared reset controls 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-02-23 18:46:26 +01:00
reset: allow using reset_control_reset with shared reset Some SoCs (for example Amlogic GXBB) implement a reset controller which only supports a reset pulse (triggered via reset_control_reset). At the same time multiple devices (in case of the Amlogic GXBB SoC both USB PHYs) are sharing the same reset line. This patch allows using reset_control_reset also for shared resets. There are limitations though: reset_control_reset can only be used if reset_control_assert was not used yet. reset_control_assert can only be used if reset_control_reset was not used yet. For shared resets the reset is only triggered once for the lifetime of the reset_control instance (the reset can be triggered again if all consumers of that specific reset_control are gone, as the reset framework will free the reset_control instance in that case). Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-11-12 14:13:03 +01:00
reset: make optional functions really optional 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-13 17:57:41 +00:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: allow using reset_control_reset with shared reset Some SoCs (for example Amlogic GXBB) implement a reset controller which only supports a reset pulse (triggered via reset_control_reset). At the same time multiple devices (in case of the Amlogic GXBB SoC both USB PHYs) are sharing the same reset line. This patch allows using reset_control_reset also for shared resets. There are limitations though: reset_control_reset can only be used if reset_control_assert was not used yet. reset_control_assert can only be used if reset_control_reset was not used yet. For shared resets the reset is only triggered once for the lifetime of the reset_control instance (the reset can be triggered again if all consumers of that specific reset_control are gone, as the reset framework will free the reset_control instance in that case). Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-11-12 14:13:03 +01:00
reset: make optional functions really optional 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-13 17:57:41 +00:00
reset: Add support for shared reset controls 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-02-23 18:46:26 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: allow using reset_control_reset with shared reset Some SoCs (for example Amlogic GXBB) implement a reset controller which only supports a reset pulse (triggered via reset_control_reset). At the same time multiple devices (in case of the Amlogic GXBB SoC both USB PHYs) are sharing the same reset line. This patch allows using reset_control_reset also for shared resets. There are limitations though: reset_control_reset can only be used if reset_control_assert was not used yet. reset_control_assert can only be used if reset_control_reset was not used yet. For shared resets the reset is only triggered once for the lifetime of the reset_control instance (the reset can be triggered again if all consumers of that specific reset_control are gone, as the reset framework will free the reset_control instance in that case). Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-11-12 14:13:03 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: allow using reset_control_reset with shared reset Some SoCs (for example Amlogic GXBB) implement a reset controller which only supports a reset pulse (triggered via reset_control_reset). At the same time multiple devices (in case of the Amlogic GXBB SoC both USB PHYs) are sharing the same reset line. This patch allows using reset_control_reset also for shared resets. There are limitations though: reset_control_reset can only be used if reset_control_assert was not used yet. reset_control_assert can only be used if reset_control_reset was not used yet. For shared resets the reset is only triggered once for the lifetime of the reset_control instance (the reset can be triggered again if all consumers of that specific reset_control are gone, as the reset framework will free the reset_control instance in that case). Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-11-12 14:13:03 +01:00
reset: add acquired/released state for exclusive reset controls 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-02-21 16:25:53 +01:00
reset: allow using reset_control_reset with shared reset Some SoCs (for example Amlogic GXBB) implement a reset controller which only supports a reset pulse (triggered via reset_control_reset). At the same time multiple devices (in case of the Amlogic GXBB SoC both USB PHYs) are sharing the same reset line. This patch allows using reset_control_reset also for shared resets. There are limitations though: reset_control_reset can only be used if reset_control_assert was not used yet. reset_control_assert can only be used if reset_control_reset was not used yet. For shared resets the reset is only triggered once for the lifetime of the reset_control instance (the reset can be triggered again if all consumers of that specific reset_control are gone, as the reset framework will free the reset_control instance in that case). Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-11-12 14:13:03 +01:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: fix shared reset triggered_count decrement on error For a shared reset, when the reset is successful, the triggered_count is incremented when trying to call the reset callback, so that another device sharing the same reset line won't trigger it again. If the reset has not been triggered successfully, the trigger_count should be decremented. The code does the opposite, and decrements the trigger_count on success. As a consequence, another device sharing the reset will be able to trigger it again. Fixed be removing negation in from of the error code of the reset function. Fixes: 7da33a37b48f ("reset: allow using reset_control_reset with shared reset") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-02-15 19:15:51 +01:00
reset: allow using reset_control_reset with shared reset Some SoCs (for example Amlogic GXBB) implement a reset controller which only supports a reset pulse (triggered via reset_control_reset). At the same time multiple devices (in case of the Amlogic GXBB SoC both USB PHYs) are sharing the same reset line. This patch allows using reset_control_reset also for shared resets. There are limitations though: reset_control_reset can only be used if reset_control_assert was not used yet. reset_control_assert can only be used if reset_control_reset was not used yet. For shared resets the reset is only triggered once for the lifetime of the reset_control instance (the reset can be triggered again if all consumers of that specific reset_control are gone, as the reset framework will free the reset_control instance in that case). Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-11-12 14:13:03 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Add reset_control_bulk API 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-03-14 18:44:46 +03:00
reset: make shared pulsed reset controls re-triggerable 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-11-13 00:00:43 +01:00
reset: core: Drop unnecessary double quote 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-26 21:29:24 +02:00
reset: make shared pulsed reset controls re-triggerable 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-11-13 00:00:43 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Add support for shared reset controls 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-02-23 18:46:26 +01:00
reset: allow using reset_control_reset with shared reset Some SoCs (for example Amlogic GXBB) implement a reset controller which only supports a reset pulse (triggered via reset_control_reset). At the same time multiple devices (in case of the Amlogic GXBB SoC both USB PHYs) are sharing the same reset line. This patch allows using reset_control_reset also for shared resets. There are limitations though: reset_control_reset can only be used if reset_control_assert was not used yet. reset_control_assert can only be used if reset_control_reset was not used yet. For shared resets the reset is only triggered once for the lifetime of the reset_control instance (the reset can be triggered again if all consumers of that specific reset_control are gone, as the reset framework will free the reset_control instance in that case). Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-11-12 14:13:03 +01:00
reset: make optional functions really optional 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-13 17:57:41 +00:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: make optional functions really optional 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-13 17:57:41 +00:00
reset: warn on invalid input to reset_control_reset/assert/deassert/status Instead of potentially crashing, dump a backtrace and return -EINVAL if rstc is NULL or an error code. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-06-20 13:05:14 +02:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: Add support for shared reset controls 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-02-23 18:46:26 +01:00
reset: allow using reset_control_reset with shared reset Some SoCs (for example Amlogic GXBB) implement a reset controller which only supports a reset pulse (triggered via reset_control_reset). At the same time multiple devices (in case of the Amlogic GXBB SoC both USB PHYs) are sharing the same reset line. This patch allows using reset_control_reset also for shared resets. There are limitations though: reset_control_reset can only be used if reset_control_assert was not used yet. reset_control_assert can only be used if reset_control_reset was not used yet. For shared resets the reset is only triggered once for the lifetime of the reset_control instance (the reset can be triggered again if all consumers of that specific reset_control are gone, as the reset framework will free the reset_control instance in that case). Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-11-12 14:13:03 +01:00
reset: Add support for shared reset controls 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-02-23 18:46:26 +01:00
reset: make (de)assert report success for self-deasserting reset drivers By now there are drivers using shared reset controls and (de)assert calls on platforms with self-deasserting reset lines and thus reset drivers that do not implement .assert() and .deassert(). As long as the initial state of the reset line is deasserted, there is no reason for a reset_control_assert call to return an error for shared reset controls, or for a reset_control_deassert call to return an error for either shared or exclusive reset controls: after a call to reset_control_deassert the reset line is guaranteed to be deasserted, and after a call to reset_control_assert it is valid for the reset line to stay deasserted for shared reset controls. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2017-07-12 17:51:22 +02:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: make (de)assert report success for self-deasserting reset drivers By now there are drivers using shared reset controls and (de)assert calls on platforms with self-deasserting reset lines and thus reset drivers that do not implement .assert() and .deassert(). As long as the initial state of the reset line is deasserted, there is no reason for a reset_control_assert call to return an error for shared reset controls, or for a reset_control_deassert call to return an error for either shared or exclusive reset controls: after a call to reset_control_deassert the reset line is guaranteed to be deasserted, and after a call to reset_control_assert it is valid for the reset line to stay deasserted for shared reset controls. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2017-07-12 17:51:22 +02:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: make (de)assert report success for self-deasserting reset drivers By now there are drivers using shared reset controls and (de)assert calls on platforms with self-deasserting reset lines and thus reset drivers that do not implement .assert() and .deassert(). As long as the initial state of the reset line is deasserted, there is no reason for a reset_control_assert call to return an error for shared reset controls, or for a reset_control_deassert call to return an error for either shared or exclusive reset controls: after a call to reset_control_deassert the reset line is guaranteed to be deasserted, and after a call to reset_control_assert it is valid for the reset line to stay deasserted for shared reset controls. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2017-07-12 17:51:22 +02:00
reset: add acquired/released state for exclusive reset controls 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-02-21 16:25:53 +01:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: add acquired/released state for exclusive reset controls 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-02-21 16:25:53 +01:00
reset: Add support for shared reset controls 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-02-23 18:46:26 +01:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Add reset_control_bulk API 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-03-14 18:44:46 +03:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Add support for shared reset controls 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-02-23 18:46:26 +01:00
reset: allow using reset_control_reset with shared reset Some SoCs (for example Amlogic GXBB) implement a reset controller which only supports a reset pulse (triggered via reset_control_reset). At the same time multiple devices (in case of the Amlogic GXBB SoC both USB PHYs) are sharing the same reset line. This patch allows using reset_control_reset also for shared resets. There are limitations though: reset_control_reset can only be used if reset_control_assert was not used yet. reset_control_assert can only be used if reset_control_reset was not used yet. For shared resets the reset is only triggered once for the lifetime of the reset_control instance (the reset can be triggered again if all consumers of that specific reset_control are gone, as the reset framework will free the reset_control instance in that case). Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-11-12 14:13:03 +01:00
reset: make optional functions really optional 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-13 17:57:41 +00:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: make optional functions really optional 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-13 17:57:41 +00:00
reset: warn on invalid input to reset_control_reset/assert/deassert/status Instead of potentially crashing, dump a backtrace and return -EINVAL if rstc is NULL or an error code. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-06-20 13:05:14 +02:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: Add support for shared reset controls 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-02-23 18:46:26 +01:00
reset: allow using reset_control_reset with shared reset Some SoCs (for example Amlogic GXBB) implement a reset controller which only supports a reset pulse (triggered via reset_control_reset). At the same time multiple devices (in case of the Amlogic GXBB SoC both USB PHYs) are sharing the same reset line. This patch allows using reset_control_reset also for shared resets. There are limitations though: reset_control_reset can only be used if reset_control_assert was not used yet. reset_control_assert can only be used if reset_control_reset was not used yet. For shared resets the reset is only triggered once for the lifetime of the reset_control instance (the reset can be triggered again if all consumers of that specific reset_control are gone, as the reset framework will free the reset_control instance in that case). Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-11-12 14:13:03 +01:00
reset: Add support for shared reset controls 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-02-23 18:46:26 +01:00
reset: add acquired/released state for exclusive reset controls 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-02-21 16:25:53 +01:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: add acquired/released state for exclusive reset controls 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-02-21 16:25:53 +01:00
reset: Add support for shared reset controls 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-02-23 18:46:26 +01:00
reset: make (de)assert report success for self-deasserting reset drivers By now there are drivers using shared reset controls and (de)assert calls on platforms with self-deasserting reset lines and thus reset drivers that do not implement .assert() and .deassert(). As long as the initial state of the reset line is deasserted, there is no reason for a reset_control_assert call to return an error for shared reset controls, or for a reset_control_deassert call to return an error for either shared or exclusive reset controls: after a call to reset_control_deassert the reset line is guaranteed to be deasserted, and after a call to reset_control_assert it is valid for the reset line to stay deasserted for shared reset controls. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2017-07-12 17:51:22 +02:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: make (de)assert report success for self-deasserting reset drivers By now there are drivers using shared reset controls and (de)assert calls on platforms with self-deasserting reset lines and thus reset drivers that do not implement .assert() and .deassert(). As long as the initial state of the reset line is deasserted, there is no reason for a reset_control_assert call to return an error for shared reset controls, or for a reset_control_deassert call to return an error for either shared or exclusive reset controls: after a call to reset_control_deassert the reset line is guaranteed to be deasserted, and after a call to reset_control_assert it is valid for the reset line to stay deasserted for shared reset controls. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2017-07-12 17:51:22 +02:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Add reset_control_bulk API 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-03-14 18:44:46 +03:00
reset: add reset_control_status helper function 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-10-10 10:21:14 -05:00
reset: make optional functions really optional 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-13 17:57:41 +00:00
reset: add reset_control_status helper function 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-10-10 10:21:14 -05:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: make optional functions really optional 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-13 17:57:41 +00:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: warn on invalid input to reset_control_reset/assert/deassert/status Instead of potentially crashing, dump a backtrace and return -EINVAL if rstc is NULL or an error code. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-06-20 13:05:14 +02:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: add reset_control_status helper function 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-10-10 10:21:14 -05:00
reset: use ENOTSUPP instead of ENOSYS 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-10-29 09:55:00 +01:00
reset: add reset_control_status helper function 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-10-10 10:21:14 -05:00
reset: add acquired/released state for exclusive reset controls 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-02-21 16:25:53 +01:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: add acquired/released state for exclusive reset controls 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-02-21 16:25:53 +01:00
reset: Add acquire/release support for arrays 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-02-21 16:25:55 +01:00
reset: protect struct reset_control with its own mutex 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-06 18:22:54 +01:00
reset: add acquired/released state for exclusive reset controls 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-02-21 16:25:53 +01:00
reset: use lock guards in reset core 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-06 18:22:51 +01:00
reset: add acquired/released state for exclusive reset controls 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-02-21 16:25:53 +01:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: protect struct reset_controller_dev with its own mutex 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-06 18:22:53 +01:00
reset: add acquired/released state for exclusive reset controls 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-02-21 16:25:53 +01:00
reset: Add reset_control_bulk API 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-03-14 18:44:46 +03:00
reset: add acquired/released state for exclusive reset controls 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-02-21 16:25:53 +01:00
reset: Add acquire/release support for arrays 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-02-21 16:25:55 +01:00
reset: add acquired/released state for exclusive reset controls 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-02-21 16:25:53 +01:00
reset: Add reset_control_bulk API 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-03-14 18:44:46 +03:00
reset: whitespace fixes 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-04 16:56:56 +01:00
reset: replace boolean parameters with flags parameter 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-25 18:40:09 +02:00
reset: Share struct reset_control between reset_control_get calls Now that struct reset_control no longer stores the device pointer for the device calling reset_control_get we can share a single struct reset_control when multiple calls to reset_control_get are made for the same reset line (same id / index). This is a preparation patch for adding support for shared reset lines. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-02-23 18:46:25 +01:00
reset: replace boolean parameters with flags parameter 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-25 18:40:09 +02:00
reset: Share struct reset_control between reset_control_get calls Now that struct reset_control no longer stores the device pointer for the device calling reset_control_get we can share a single struct reset_control when multiple calls to reset_control_get are made for the same reset line (same id / index). This is a preparation patch for adding support for shared reset lines. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-02-23 18:46:25 +01:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: Share struct reset_control between reset_control_get calls Now that struct reset_control no longer stores the device pointer for the device calling reset_control_get we can share a single struct reset_control when multiple calls to reset_control_get are made for the same reset line (same id / index). This is a preparation patch for adding support for shared reset lines. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-02-23 18:46:25 +01:00
reset: protect struct reset_controller_dev with its own mutex 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-06 18:22:53 +01:00
reset: Share struct reset_control between reset_control_get calls Now that struct reset_control no longer stores the device pointer for the device calling reset_control_get we can share a single struct reset_control when multiple calls to reset_control_get are made for the same reset line (same id / index). This is a preparation patch for adding support for shared reset lines. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-02-23 18:46:25 +01:00
reset: replace boolean parameters with flags parameter 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-25 18:40:09 +02:00
reset: Share struct reset_control between reset_control_get calls Now that struct reset_control no longer stores the device pointer for the device calling reset_control_get we can share a single struct reset_control when multiple calls to reset_control_get are made for the same reset line (same id / index). This is a preparation patch for adding support for shared reset lines. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-02-23 18:46:25 +01:00
reset: add acquired/released state for exclusive reset controls 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-02-21 16:25:53 +01:00
reset: Add support for shared reset controls 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-02-23 18:46:26 +01:00
reset: use kref for reference counting Use kref for reference counting and enjoy the advantages of refcount_t. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-05-31 17:42:29 +02:00
reset: Share struct reset_control between reset_control_get calls Now that struct reset_control no longer stores the device pointer for the device calling reset_control_get we can share a single struct reset_control when multiple calls to reset_control_get are made for the same reset line (same id / index). This is a preparation patch for adding support for shared reset lines. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-02-23 18:46:25 +01:00
Convert 'alloc_obj' family to use the new default GFP_KERNEL argument 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-21 16:37:42 -08:00
reset: Share struct reset_control between reset_control_get calls Now that struct reset_control no longer stores the device pointer for the device calling reset_control_get we can share a single struct reset_control when multiple calls to reset_control_get are made for the same reset line (same id / index). This is a preparation patch for adding support for shared reset lines. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-02-23 18:46:25 +01:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: bail if try_module_get() fails 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-06-07 10:26:15 +02:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: bail if try_module_get() fails 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-06-07 10:26:15 +02:00
reset: Share struct reset_control between reset_control_get calls Now that struct reset_control no longer stores the device pointer for the device calling reset_control_get we can share a single struct reset_control when multiple calls to reset_control_get are made for the same reset line (same id / index). This is a preparation patch for adding support for shared reset lines. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-02-23 18:46:25 +01:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: Share struct reset_control between reset_control_get calls Now that struct reset_control no longer stores the device pointer for the device calling reset_control_get we can share a single struct reset_control when multiple calls to reset_control_get are made for the same reset line (same id / index). This is a preparation patch for adding support for shared reset lines. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-02-23 18:46:25 +01:00
reset: use kref for reference counting Use kref for reference counting and enjoy the advantages of refcount_t. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-05-31 17:42:29 +02:00
reset: protect struct reset_control with its own mutex 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-06 18:22:54 +01:00
reset: add acquired/released state for exclusive reset controls 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-02-21 16:25:53 +01:00
reset: Add support for shared reset controls 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-02-23 18:46:26 +01:00
reset: core: add get_device()/put_device on rcdev 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-08-08 17:46:56 +02:00
reset: Share struct reset_control between reset_control_get calls Now that struct reset_control no longer stores the device pointer for the device calling reset_control_get we can share a single struct reset_control when multiple calls to reset_control_get are made for the same reset line (same id / index). This is a preparation patch for adding support for shared reset lines. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-02-23 18:46:25 +01:00
reset: use kref for reference counting Use kref for reference counting and enjoy the advantages of refcount_t. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-05-31 17:42:29 +02:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: use kref for reference counting Use kref for reference counting and enjoy the advantages of refcount_t. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-05-31 17:42:29 +02:00
reset: protect struct reset_control with its own mutex 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-06 18:22:54 +01:00
reset: use kref for reference counting Use kref for reference counting and enjoy the advantages of refcount_t. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-05-31 17:42:29 +02:00
reset: protect struct reset_control with its own mutex 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-06 18:22:54 +01:00
reset: handle removing supplier before consumers 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-06 18:22:52 +01:00
reset: use kref for reference counting Use kref for reference counting and enjoy the advantages of refcount_t. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-05-31 17:42:29 +02:00
reset: protect struct reset_control with its own mutex 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-06 18:22:54 +01:00
reset: use kref for reference counting Use kref for reference counting and enjoy the advantages of refcount_t. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-05-31 17:42:29 +02:00
reset: protect struct reset_control with its own mutex 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-06 18:22:54 +01:00
reset: Share struct reset_control between reset_control_get calls Now that struct reset_control no longer stores the device pointer for the device calling reset_control_get we can share a single struct reset_control when multiple calls to reset_control_get are made for the same reset line (same id / index). This is a preparation patch for adding support for shared reset lines. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-02-23 18:46:25 +01:00
reset: protect struct reset_control with its own mutex 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-06 18:22:54 +01:00
reset: Share struct reset_control between reset_control_get calls Now that struct reset_control no longer stores the device pointer for the device calling reset_control_get we can share a single struct reset_control when multiple calls to reset_control_get are made for the same reset line (same id / index). This is a preparation patch for adding support for shared reset lines. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-02-23 18:46:25 +01:00
reset: Fix crash when freeing non-existent optional resets 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-11-29 17:55:33 +01:00
reset: protect struct reset_control with its own mutex 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-06 18:22:54 +01:00
reset: Share struct reset_control between reset_control_get calls Now that struct reset_control no longer stores the device pointer for the device calling reset_control_get we can share a single struct reset_control when multiple calls to reset_control_get are made for the same reset line (same id / index). This is a preparation patch for adding support for shared reset lines. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-02-23 18:46:25 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: warn on reset-gpio release 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-06 18:22:49 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: gpio: add a devlink between reset-gpio and its consumer 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-03-06 18:22:46 +01:00
reset: fold ida_alloc() into reset_create_gpio_aux_device() 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-06 18:22:50 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: gpio: add a devlink between reset-gpio and its consumer 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-03-06 18:22:46 +01:00
reset: fold ida_alloc() into reset_create_gpio_aux_device() 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-06 18:22:50 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: gpio: add a devlink between reset-gpio and its consumer 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-03-06 18:22:46 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: fold ida_alloc() into reset_create_gpio_aux_device() 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-06 18:22:50 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: fold ida_alloc() into reset_create_gpio_aux_device() 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-06 18:22:50 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: fold ida_alloc() into reset_create_gpio_aux_device() 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-06 18:22:50 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: gpio: add a devlink between reset-gpio and its consumer 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-03-06 18:22:46 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: gpio: add a devlink between reset-gpio and its consumer 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-03-06 18:22:46 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: gpio: add a devlink between reset-gpio and its consumer 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-03-06 18:22:46 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: gpio: add a devlink between reset-gpio and its consumer 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-03-06 18:22:46 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: gpio: add a devlink between reset-gpio and its consumer 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-03-06 18:22:46 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: gpio: add the "compatible" property 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-11-21 14:57:39 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: fold ida_alloc() into reset_create_gpio_aux_device() 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-06 18:22:50 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: make the provider of reset-gpios the parent of the reset device 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-20 14:24:02 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: make the provider of reset-gpios the parent of the reset device 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-20 14:24:02 +01:00
reset: simplify locking with guard() 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-08-25 16:14:26 +02:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: gpio: add the "compatible" property 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-11-21 14:57:39 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
Convert 'alloc_obj' family to use the new default GFP_KERNEL argument 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-21 16:37:42 -08:00
reset: fold ida_alloc() into reset_create_gpio_aux_device() 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-06 18:22:50 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: fold ida_alloc() into reset_create_gpio_aux_device() 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-06 18:22:50 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: gpio: use software nodes to setup the GPIO lookup 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-20 14:24:04 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: gpio: simplify fallback device matching 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-06 18:22:47 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: whitespace fixes 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-04 16:56:56 +01:00
reset: convert the core API to using firmware nodes 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-06 18:22:56 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: replace boolean parameters with flags parameter 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-25 18:40:09 +02:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: protect struct reset_control with its own mutex 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-06 18:22:54 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: convert the core API to using firmware nodes 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-06 18:22:56 +01:00
reset: Make [of_]reset_control_get[_foo] functions wrappers 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>
2016-02-23 18:46:24 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: make optional functions really optional 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-13 17:57:41 +00:00
reset: Make [of_]reset_control_get[_foo] functions wrappers 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>
2016-02-23 18:46:24 +01:00
reset: make optional functions really optional 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-13 17:57:41 +00:00
reset: Make [of_]reset_control_get[_foo] functions wrappers 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>
2016-02-23 18:46:24 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: make optional functions really optional 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-13 17:57:41 +00:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: use lock guards in reset core 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-06 18:22:51 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: use lock guards in reset core 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-06 18:22:51 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Fix potential use-after-free in __of_reset_control_get() Calling of_node_put() decreases the reference count of a device tree object, and may free some data. However, the of_phandle_args structure embedding it is passed to reset_controller_dev.of_xlate() after that, so it may still be accessed. Move the call to of_node_put() down to fix this. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> [p.zabel@pengutronix.de: moved of_node_put after mutex_unlock] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2018-10-08 13:14:35 +02:00
reset: use lock guards in reset core 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-06 18:22:51 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Fix potential use-after-free in __of_reset_control_get() Calling of_node_put() decreases the reference count of a device tree object, and may free some data. However, the of_phandle_args structure embedding it is passed to reset_controller_dev.of_xlate() after that, so it may still be accessed. Move the call to of_node_put() down to fix this. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> [p.zabel@pengutronix.de: moved of_node_put after mutex_unlock] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2018-10-08 13:14:35 +02:00
reset: use lock guards in reset core 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-06 18:22:51 +01:00
reset: Move DT cell size check to the core The core currently doesn't check that the DT cell size matches what the driver declares, which means that every xlate function needs to duplicate that check. Make sure that of_reset_control_get checks for this to avoid duplication and errors. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-01-14 16:24:44 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Fix potential use-after-free in __of_reset_control_get() Calling of_node_put() decreases the reference count of a device tree object, and may free some data. However, the of_phandle_args structure embedding it is passed to reset_controller_dev.of_xlate() after that, so it may still be accessed. Move the call to of_node_put() down to fix this. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> [p.zabel@pengutronix.de: moved of_node_put after mutex_unlock] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2018-10-08 13:14:35 +02:00
reset: core: Fix indentation 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-10 10:00:05 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: replace boolean parameters with flags parameter 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-25 18:40:09 +02:00
reset: protect struct reset_control with its own mutex 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-06 18:22:54 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Instantiate reset GPIO controller for shared reset-gpios 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>
2024-01-29 12:52:14 +01:00
reset: convert reset core to using firmware nodes 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-06 18:22:57 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: convert the core API to using firmware nodes 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-06 18:22:56 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: add exported __reset_control_get, return NULL if optional 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>
2016-02-05 13:41:39 +01:00
reset: replace boolean parameters with flags parameter 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-25 18:40:09 +02:00
reset: add exported __reset_control_get, return NULL if optional 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>
2016-02-05 13:41:39 +01:00
reset: replace boolean parameters with flags parameter 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-25 18:40:09 +02:00
reset: remove legacy reset lookup code 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>
2025-10-22 15:51:32 +02:00
reset: convert the core API to using firmware nodes 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-06 18:22:56 +01:00
reset: replace boolean parameters with flags parameter 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-25 18:40:09 +02:00
reset: add acquired/released state for exclusive reset controls 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-02-21 16:25:53 +01:00
reset: convert the core API to using firmware nodes 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-06 18:22:56 +01:00
reset: add exported __reset_control_get, return NULL if optional 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>
2016-02-05 13:41:39 +01:00
reset: remove legacy reset lookup code 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>
2025-10-22 15:51:32 +02:00
reset: add exported __reset_control_get, return NULL if optional 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>
2016-02-05 13:41:39 +01:00
reset: Add reset_control_bulk API 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-03-14 18:44:46 +03:00
reset: replace boolean parameters with flags parameter 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-25 18:40:09 +02:00
reset: Add reset_control_bulk API 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-03-14 18:44:46 +03:00
reset: replace boolean parameters with flags parameter 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-25 18:40:09 +02:00
reset: Add reset_control_bulk API 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-03-14 18:44:46 +03:00
reset: protect struct reset_control with its own mutex 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-06 18:22:54 +01:00
reset: use lock guards in reset core 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-06 18:22:51 +01:00
reset: Add reset_control_bulk API 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-03-14 18:44:46 +03:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: protect struct reset_control with its own mutex 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-06 18:22:54 +01:00
reset: Fix memory leak in reset_control_array_put() 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-22 14:06:23 +05:30
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: core: fix reset_control_put Commit "reset: make optional functions really optional" missed to adjust one check in reset_control_put, causing a NULL pointer access for optional resets. Fixes: bb475230b8e5 "reset: make optional functions really optional" Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-02-01 08:05:22 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: protect struct reset_control with its own mutex 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-06 18:22:54 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Add reset_control_bulk API 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-03-14 18:44:46 +03:00
reset: Fix crash when freeing non-existent optional resets 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-11-29 17:55:33 +01:00
reset: protect struct reset_control with its own mutex 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-06 18:22:54 +01:00
reset: Add reset_control_bulk API 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-03-14 18:44:46 +03:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Add devres helpers to request pre-deasserted reset controls 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-09-25 18:40:10 +02:00
reset: whitespace fixes 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-04 16:56:56 +01:00
reset: replace boolean parameters with flags parameter 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-25 18:40:09 +02:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Add devres helpers to request pre-deasserted reset controls 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-09-25 18:40:10 +02:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Add devres helpers to request pre-deasserted reset controls 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-09-25 18:40:10 +02:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Add devres helpers to request pre-deasserted reset controls 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-09-25 18:40:10 +02:00
reset: replace boolean parameters with flags parameter 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-25 18:40:09 +02:00
reset: Align logic and flow in managed helpers __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-11-20 15:59:27 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Align logic and flow in managed helpers __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-11-20 15:59:27 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Add devres helpers to request pre-deasserted reset controls 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-09-25 18:40:10 +02:00
reset: Align logic and flow in managed helpers __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-11-20 15:59:27 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Make [of_]reset_control_get[_foo] functions wrappers 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>
2016-02-23 18:46:24 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: Add reset_control_bulk API 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-03-14 18:44:46 +03:00
reset: Add devres helpers to request pre-deasserted reset controls 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-09-25 18:40:10 +02:00
reset: Add reset_control_bulk API 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-03-14 18:44:46 +03:00
reset: replace boolean parameters with flags parameter 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-25 18:40:09 +02:00
reset: Add reset_control_bulk API 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-03-14 18:44:46 +03:00
reset: Add devres helpers to request pre-deasserted reset controls 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-09-25 18:40:10 +02:00
reset: Add reset_control_bulk API 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-03-14 18:44:46 +03:00
reset: Add devres helpers to request pre-deasserted reset controls 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-09-25 18:40:10 +02:00
reset: Add reset_control_bulk API 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-03-14 18:44:46 +03:00
reset: Add devres helpers to request pre-deasserted reset controls 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-09-25 18:40:10 +02:00
reset: replace boolean parameters with flags parameter 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-25 18:40:09 +02:00
reset: Add reset_control_bulk API 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-03-14 18:44:46 +03:00
reset: Add devres helpers to request pre-deasserted reset controls 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-09-25 18:40:10 +02:00
reset: Add reset_control_bulk API 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-03-14 18:44:46 +03:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: core: fix a kernel-doc markup 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>
2021-01-14 09:04:50 +01:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: make device_reset_optional() really optional 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-10-29 01:50:06 +09:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: make device_reset_optional() really optional 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-10-29 01:50:06 +09:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: ACPI reset support 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
2022-03-07 19:26:26 +05:30
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: make device_reset_optional() really optional 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-10-29 01:50:06 +09:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: replace boolean parameters with flags parameter 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-25 18:40:09 +02:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: ACPI reset support 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
2022-03-07 19:26:26 +05:30
reset: replace boolean parameters with flags parameter 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-25 18:40:09 +02:00
reset: Add reset controller API 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>
2012-11-19 17:23:13 +01:00
reset: make device_reset_optional() really optional 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-10-29 01:50:06 +09:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: fix of_reset_control_get_count kerneldoc comment 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-22 16:09:50 +02:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: fix of_reset_control_get_count kerneldoc comment 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-22 16:09:50 +02:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: convert of_reset_control_get_count() to using firmware nodes 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-06 18:22:55 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: convert of_reset_control_get_count() to using firmware nodes 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-06 18:22:55 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: convert of_reset_control_get_count() to using firmware nodes 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-06 18:22:55 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: convert of_reset_control_get_count() to using firmware nodes 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-06 18:22:55 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: convert of_reset_control_get_count() to using firmware nodes 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-06 18:22:55 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: convert of_reset_control_get_count() to using firmware nodes 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-06 18:22:55 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: convert the core API to using firmware nodes 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-06 18:22:56 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: convert the core API to using firmware nodes 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-06 18:22:56 +01:00
reset: replace boolean parameters with flags parameter 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-25 18:40:09 +02:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: Fix {of,devm}_reset_control_array_get kerneldoc return types 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-11-20 15:26:13 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: convert the core API to using firmware nodes 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-06 18:22:56 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: replace boolean parameters with flags parameter 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-25 18:40:09 +02:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: convert the core API to using firmware nodes 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-06 18:22:56 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
Convert 'alloc_flex' family to use the new default GFP_KERNEL argument 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-21 17:06:51 -08:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: Annotate struct reset_control_array with __counted_by 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>
2023-09-22 10:52:29 -07:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: convert the core API to using firmware nodes 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-06 18:22:56 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: protect struct reset_control with its own mutex 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-06 18:22:54 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: convert the core API to using firmware nodes 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-06 18:22:56 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: replace boolean parameters with flags parameter 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-25 18:40:09 +02:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: Fix {of,devm}_reset_control_array_get kerneldoc return types 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-11-20 15:26:13 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: replace boolean parameters with flags parameter 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-25 18:40:09 +02:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: Align logic and flow in managed helpers __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-11-20 15:59:27 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: Align logic and flow in managed helpers __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-11-20 15:59:27 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: convert the core API to using firmware nodes 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-06 18:22:56 +01:00
reset: Do not register resource data for missing resets 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-11-20 15:59:26 +01:00
reset: Align logic and flow in managed helpers __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-11-20 15:59:27 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: Align logic and flow in managed helpers __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-11-20 15:59:27 +01:00
reset: Add APIs to manage array of resets 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-05-22 16:53:25 +05:30
reset: Add reset_control_get_count() 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>
2018-11-13 13:47:44 +01:00
reset: convert of_reset_control_get_count() to using firmware nodes 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-06 18:22:55 +01:00
reset: Add reset_control_get_count() 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>
2018-11-13 13:47:44 +01:00
reset: remove legacy reset lookup code 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>
2025-10-22 15:51:32 +02:00
reset: Add reset_control_get_count() 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>
2018-11-13 13:47:44 +01:00