kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-10-28 20:03:05 +00:00
Code Issues Releases Packages Activity
linux/drivers/reset/core.c

1487 lines
37 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: 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: 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: 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: 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: 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: 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: 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: add support for non-DT systems The reset framework only supports device-tree. There are some platforms however, which need to use it even in legacy, board-file based mode. An example of such architecture is the DaVinci family of SoCs which supports both device tree and legacy boot modes and we don't want to introduce any regressions. We're currently working on converting the platform from its hand-crafted clock API to using the common clock framework. Part of the overhaul will be representing the chip's power sleep controller's reset lines using the reset framework. This changeset extends the core reset code with a new reset lookup entry structure. It contains data allowing the reset core to associate reset lines with devices by comparing the dev_id and con_id strings. It also provides a function allowing drivers to register lookup entries with the framework. The new lookup function is only called as a fallback in case the of_node field is NULL and doesn't change anything for current users. Tested with a dummy reset driver with several lookup entries. An example lookup table registration from a driver can be found below: static struct reset_control_lookup foobar_reset_lookup[] = { RESET_LOOKUP("foo.0", "foo", 15), RESET_LOOKUP("bar.0", NULL, 5), }; foobar_probe() { ... reset_controller_add_lookup(&rcdev, foobar_reset_lookup, ARRAY_SIZE(foobar_reset_lookup)); ... } Cc: Sekhar Nori <nsekhar@ti.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: David Lechner <david@lechnology.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2018-02-28 14:08: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: 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: 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: 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: 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: 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: 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: 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: 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: improve of_xlate documentation Mention of_reset_simple_xlate as the default if of_xlate is not set. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-10-22 16:51:37 +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: Mark function as static and remove unused function in core.c Mark function of_reset_simple_xlate() as static in core.c because it is not used outside this file. Also, remove functions devm_reset_control_put() and devm_reset_control_match() because they are unused. This eliminates the following warnings in core.c: drivers/reset/core.c:46:5: warning: no previous prototype for ‘of_reset_simple_xlate’ [-Wmissing-prototypes] drivers/reset/core.c:262:6: warning: no previous prototype for ‘devm_reset_control_put’ [-Wmissing-prototypes] Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2013-12-19 14:11:10 +05:30
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: 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: 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 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: 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: 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 support for non-DT systems The reset framework only supports device-tree. There are some platforms however, which need to use it even in legacy, board-file based mode. An example of such architecture is the DaVinci family of SoCs which supports both device tree and legacy boot modes and we don't want to introduce any regressions. We're currently working on converting the platform from its hand-crafted clock API to using the common clock framework. Part of the overhaul will be representing the chip's power sleep controller's reset lines using the reset framework. This changeset extends the core reset code with a new reset lookup entry structure. It contains data allowing the reset core to associate reset lines with devices by comparing the dev_id and con_id strings. It also provides a function allowing drivers to register lookup entries with the framework. The new lookup function is only called as a fallback in case the of_node field is NULL and doesn't change anything for current users. Tested with a dummy reset driver with several lookup entries. An example lookup table registration from a driver can be found below: static struct reset_control_lookup foobar_reset_lookup[] = { RESET_LOOKUP("foo.0", "foo", 15), RESET_LOOKUP("bar.0", NULL, 5), }; foobar_probe() { ... reset_controller_add_lookup(&rcdev, foobar_reset_lookup, ARRAY_SIZE(foobar_reset_lookup)); ... } Cc: Sekhar Nori <nsekhar@ti.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: David Lechner <david@lechnology.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2018-02-28 14:08:57 +01:00
reset: modify the way reset lookup works for board files Commit 7af1bb19f1d7 ("reset: add support for non-DT systems") introduced reset control lookup mechanism for boards that still use board files. The routine used to register lookup entries takes the corresponding reset_controlled_dev structure as argument. It's been determined however that for the first user of this new interface - davinci psc driver - it will be easier to register the lookup entries using the reset controller device name. This patch changes the way lookup entries are added. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> [p.zabel@pengutronix.de: added missing ERR_PTR] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2018-03-23 14:04:48 +01:00
reset: add support for non-DT systems The reset framework only supports device-tree. There are some platforms however, which need to use it even in legacy, board-file based mode. An example of such architecture is the DaVinci family of SoCs which supports both device tree and legacy boot modes and we don't want to introduce any regressions. We're currently working on converting the platform from its hand-crafted clock API to using the common clock framework. Part of the overhaul will be representing the chip's power sleep controller's reset lines using the reset framework. This changeset extends the core reset code with a new reset lookup entry structure. It contains data allowing the reset core to associate reset lines with devices by comparing the dev_id and con_id strings. It also provides a function allowing drivers to register lookup entries with the framework. The new lookup function is only called as a fallback in case the of_node field is NULL and doesn't change anything for current users. Tested with a dummy reset driver with several lookup entries. An example lookup table registration from a driver can be found below: static struct reset_control_lookup foobar_reset_lookup[] = { RESET_LOOKUP("foo.0", "foo", 15), RESET_LOOKUP("bar.0", NULL, 5), }; foobar_probe() { ... reset_controller_add_lookup(&rcdev, foobar_reset_lookup, ARRAY_SIZE(foobar_reset_lookup)); ... } Cc: Sekhar Nori <nsekhar@ti.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: David Lechner <david@lechnology.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2018-02-28 14:08:57 +01:00
reset: modify the way reset lookup works for board files Commit 7af1bb19f1d7 ("reset: add support for non-DT systems") introduced reset control lookup mechanism for boards that still use board files. The routine used to register lookup entries takes the corresponding reset_controlled_dev structure as argument. It's been determined however that for the first user of this new interface - davinci psc driver - it will be easier to register the lookup entries using the reset controller device name. This patch changes the way lookup entries are added. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> [p.zabel@pengutronix.de: added missing ERR_PTR] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2018-03-23 14:04:48 +01:00
reset: add support for non-DT systems The reset framework only supports device-tree. There are some platforms however, which need to use it even in legacy, board-file based mode. An example of such architecture is the DaVinci family of SoCs which supports both device tree and legacy boot modes and we don't want to introduce any regressions. We're currently working on converting the platform from its hand-crafted clock API to using the common clock framework. Part of the overhaul will be representing the chip's power sleep controller's reset lines using the reset framework. This changeset extends the core reset code with a new reset lookup entry structure. It contains data allowing the reset core to associate reset lines with devices by comparing the dev_id and con_id strings. It also provides a function allowing drivers to register lookup entries with the framework. The new lookup function is only called as a fallback in case the of_node field is NULL and doesn't change anything for current users. Tested with a dummy reset driver with several lookup entries. An example lookup table registration from a driver can be found below: static struct reset_control_lookup foobar_reset_lookup[] = { RESET_LOOKUP("foo.0", "foo", 15), RESET_LOOKUP("bar.0", NULL, 5), }; foobar_probe() { ... reset_controller_add_lookup(&rcdev, foobar_reset_lookup, ARRAY_SIZE(foobar_reset_lookup)); ... } Cc: Sekhar Nori <nsekhar@ti.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: David Lechner <david@lechnology.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2018-02-28 14:08:57 +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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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: 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: 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: 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: 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: 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
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: remove unnecessary local variable initialization from of_reset_control_get_by_index There is no need to initialize rstc, as it is unconditionally assigned the return value of a kzalloc call before use. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2015-12-08 18:49:53 +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: 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: 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: Add of_reset_control_get In some cases, you might need to deassert from reset an hardware block that doesn't associated to a struct device (CPUs, timers, etc.). Add a small helper to retrieve the reset controller from the device tree without the need to pass a struct device. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2013-12-20 22:41:07 +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 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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: 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: 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: 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: 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: modify the way reset lookup works for board files Commit 7af1bb19f1d7 ("reset: add support for non-DT systems") introduced reset control lookup mechanism for boards that still use board files. The routine used to register lookup entries takes the corresponding reset_controlled_dev structure as argument. It's been determined however that for the first user of this new interface - davinci psc driver - it will be easier to register the lookup entries using the reset controller device name. This patch changes the way lookup entries are added. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> [p.zabel@pengutronix.de: added missing ERR_PTR] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2018-03-23 14:04:48 +01:00
reset: add support for non-DT systems The reset framework only supports device-tree. There are some platforms however, which need to use it even in legacy, board-file based mode. An example of such architecture is the DaVinci family of SoCs which supports both device tree and legacy boot modes and we don't want to introduce any regressions. We're currently working on converting the platform from its hand-crafted clock API to using the common clock framework. Part of the overhaul will be representing the chip's power sleep controller's reset lines using the reset framework. This changeset extends the core reset code with a new reset lookup entry structure. It contains data allowing the reset core to associate reset lines with devices by comparing the dev_id and con_id strings. It also provides a function allowing drivers to register lookup entries with the framework. The new lookup function is only called as a fallback in case the of_node field is NULL and doesn't change anything for current users. Tested with a dummy reset driver with several lookup entries. An example lookup table registration from a driver can be found below: static struct reset_control_lookup foobar_reset_lookup[] = { RESET_LOOKUP("foo.0", "foo", 15), RESET_LOOKUP("bar.0", NULL, 5), }; foobar_probe() { ... reset_controller_add_lookup(&rcdev, foobar_reset_lookup, ARRAY_SIZE(foobar_reset_lookup)); ... } Cc: Sekhar Nori <nsekhar@ti.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: David Lechner <david@lechnology.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2018-02-28 14:08: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 support for non-DT systems The reset framework only supports device-tree. There are some platforms however, which need to use it even in legacy, board-file based mode. An example of such architecture is the DaVinci family of SoCs which supports both device tree and legacy boot modes and we don't want to introduce any regressions. We're currently working on converting the platform from its hand-crafted clock API to using the common clock framework. Part of the overhaul will be representing the chip's power sleep controller's reset lines using the reset framework. This changeset extends the core reset code with a new reset lookup entry structure. It contains data allowing the reset core to associate reset lines with devices by comparing the dev_id and con_id strings. It also provides a function allowing drivers to register lookup entries with the framework. The new lookup function is only called as a fallback in case the of_node field is NULL and doesn't change anything for current users. Tested with a dummy reset driver with several lookup entries. An example lookup table registration from a driver can be found below: static struct reset_control_lookup foobar_reset_lookup[] = { RESET_LOOKUP("foo.0", "foo", 15), RESET_LOOKUP("bar.0", NULL, 5), }; foobar_probe() { ... reset_controller_add_lookup(&rcdev, foobar_reset_lookup, ARRAY_SIZE(foobar_reset_lookup)); ... } Cc: Sekhar Nori <nsekhar@ti.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: David Lechner <david@lechnology.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2018-02-28 14:08:57 +01:00
reset: modify the way reset lookup works for board files Commit 7af1bb19f1d7 ("reset: add support for non-DT systems") introduced reset control lookup mechanism for boards that still use board files. The routine used to register lookup entries takes the corresponding reset_controlled_dev structure as argument. It's been determined however that for the first user of this new interface - davinci psc driver - it will be easier to register the lookup entries using the reset controller device name. This patch changes the way lookup entries are added. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> [p.zabel@pengutronix.de: added missing ERR_PTR] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2018-03-23 14:04:48 +01:00
reset: add support for non-DT systems The reset framework only supports device-tree. There are some platforms however, which need to use it even in legacy, board-file based mode. An example of such architecture is the DaVinci family of SoCs which supports both device tree and legacy boot modes and we don't want to introduce any regressions. We're currently working on converting the platform from its hand-crafted clock API to using the common clock framework. Part of the overhaul will be representing the chip's power sleep controller's reset lines using the reset framework. This changeset extends the core reset code with a new reset lookup entry structure. It contains data allowing the reset core to associate reset lines with devices by comparing the dev_id and con_id strings. It also provides a function allowing drivers to register lookup entries with the framework. The new lookup function is only called as a fallback in case the of_node field is NULL and doesn't change anything for current users. Tested with a dummy reset driver with several lookup entries. An example lookup table registration from a driver can be found below: static struct reset_control_lookup foobar_reset_lookup[] = { RESET_LOOKUP("foo.0", "foo", 15), RESET_LOOKUP("bar.0", NULL, 5), }; foobar_probe() { ... reset_controller_add_lookup(&rcdev, foobar_reset_lookup, ARRAY_SIZE(foobar_reset_lookup)); ... } Cc: Sekhar Nori <nsekhar@ti.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: David Lechner <david@lechnology.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2018-02-28 14:08:57 +01:00
reset: modify the way reset lookup works for board files Commit 7af1bb19f1d7 ("reset: add support for non-DT systems") introduced reset control lookup mechanism for boards that still use board files. The routine used to register lookup entries takes the corresponding reset_controlled_dev structure as argument. It's been determined however that for the first user of this new interface - davinci psc driver - it will be easier to register the lookup entries using the reset controller device name. This patch changes the way lookup entries are added. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> [p.zabel@pengutronix.de: added missing ERR_PTR] Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2018-03-23 14:04:48 +01:00
reset: add support for non-DT systems The reset framework only supports device-tree. There are some platforms however, which need to use it even in legacy, board-file based mode. An example of such architecture is the DaVinci family of SoCs which supports both device tree and legacy boot modes and we don't want to introduce any regressions. We're currently working on converting the platform from its hand-crafted clock API to using the common clock framework. Part of the overhaul will be representing the chip's power sleep controller's reset lines using the reset framework. This changeset extends the core reset code with a new reset lookup entry structure. It contains data allowing the reset core to associate reset lines with devices by comparing the dev_id and con_id strings. It also provides a function allowing drivers to register lookup entries with the framework. The new lookup function is only called as a fallback in case the of_node field is NULL and doesn't change anything for current users. Tested with a dummy reset driver with several lookup entries. An example lookup table registration from a driver can be found below: static struct reset_control_lookup foobar_reset_lookup[] = { RESET_LOOKUP("foo.0", "foo", 15), RESET_LOOKUP("bar.0", NULL, 5), }; foobar_probe() { ... reset_controller_add_lookup(&rcdev, foobar_reset_lookup, ARRAY_SIZE(foobar_reset_lookup)); ... } Cc: Sekhar Nori <nsekhar@ti.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: David Lechner <david@lechnology.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2018-02-28 14:08: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 support for non-DT systems The reset framework only supports device-tree. There are some platforms however, which need to use it even in legacy, board-file based mode. An example of such architecture is the DaVinci family of SoCs which supports both device tree and legacy boot modes and we don't want to introduce any regressions. We're currently working on converting the platform from its hand-crafted clock API to using the common clock framework. Part of the overhaul will be representing the chip's power sleep controller's reset lines using the reset framework. This changeset extends the core reset code with a new reset lookup entry structure. It contains data allowing the reset core to associate reset lines with devices by comparing the dev_id and con_id strings. It also provides a function allowing drivers to register lookup entries with the framework. The new lookup function is only called as a fallback in case the of_node field is NULL and doesn't change anything for current users. Tested with a dummy reset driver with several lookup entries. An example lookup table registration from a driver can be found below: static struct reset_control_lookup foobar_reset_lookup[] = { RESET_LOOKUP("foo.0", "foo", 15), RESET_LOOKUP("bar.0", NULL, 5), }; foobar_probe() { ... reset_controller_add_lookup(&rcdev, foobar_reset_lookup, ARRAY_SIZE(foobar_reset_lookup)); ... } Cc: Sekhar Nori <nsekhar@ti.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: David Lechner <david@lechnology.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2018-02-28 14:08:57 +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: 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 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 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 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 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 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 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 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: 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 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: 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 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: 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: 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: 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: 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: 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 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: 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: 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 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: 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 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: 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: Add acquired flag to of_reset_control_array_get() In order to be able to request an array of reset controls in acquired or released mode, add the acquired flag to of_reset_control_array_get() and pass the flag to subsequent calls of __of_reset_control_get(). Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-02-21 16:25: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: 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: Add acquired flag to of_reset_control_array_get() In order to be able to request an array of reset controls in acquired or released mode, add the acquired flag to of_reset_control_array_get() and pass the flag to subsequent calls of __of_reset_control_get(). Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-02-21 16:25: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
treewide: Use struct_size() for kmalloc()-family One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; void *entry[]; }; instance = kmalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL); This patch makes the changes for kmalloc()-family (and kvmalloc()-family) uses. It was done via automatic conversion with manual review for the "CHECKME" non-standard cases noted below, using the following Coccinelle script: // pkey_cache = kmalloc(sizeof *pkey_cache + tprops->pkey_tbl_len * // sizeof *pkey_cache->table, GFP_KERNEL); @@ identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc"; expression GFP; identifier VAR, ELEMENT; expression COUNT; @@ - alloc(sizeof(*VAR) + COUNT * sizeof(*VAR->ELEMENT), GFP) + alloc(struct_size(VAR, ELEMENT, COUNT), GFP) // mr = kzalloc(sizeof(*mr) + m * sizeof(mr->map[0]), GFP_KERNEL); @@ identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc"; expression GFP; identifier VAR, ELEMENT; expression COUNT; @@ - alloc(sizeof(*VAR) + COUNT * sizeof(VAR->ELEMENT[0]), GFP) + alloc(struct_size(VAR, ELEMENT, COUNT), GFP) // Same pattern, but can't trivially locate the trailing element name, // or variable name. @@ identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc"; expression GFP; expression SOMETHING, COUNT, ELEMENT; @@ - alloc(sizeof(SOMETHING) + COUNT * sizeof(ELEMENT), GFP) + alloc(CHECKME_struct_size(&SOMETHING, ELEMENT, COUNT), GFP) Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-08 13:45:50 -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: 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: 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 acquired flag to of_reset_control_array_get() In order to be able to request an array of reset controls in acquired or released mode, add the acquired flag to of_reset_control_array_get() and pass the flag to subsequent calls of __of_reset_control_get(). Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-02-21 16:25: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: 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: 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 acquired flag to of_reset_control_array_get() In order to be able to request an array of reset controls in acquired or released mode, add the acquired flag to of_reset_control_array_get() and pass the flag to subsequent calls of __of_reset_control_get(). Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2019-02-21 16:25:54 +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: fix null pointer dereference on dev by dev_name The call to dev_name will dereference dev, however, dev is later being null checked, so there is a possibility of a null pointer dereference on dev by the call to dev_name. Fix this by null checking dev first before the call to dev_name Detected by CoverityScan, CID#1475475 ("Dereference before null check") Fixes: 2a6cb2b1d83b ("reset: Add reset_control_get_count()") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2018-11-14 21:49:35 +00: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: fix null pointer dereference on dev by dev_name The call to dev_name will dereference dev, however, dev is later being null checked, so there is a possibility of a null pointer dereference on dev by the call to dev_name. Fix this by null checking dev first before the call to dev_name Detected by CoverityScan, CID#1475475 ("Dereference before null check") Fixes: 2a6cb2b1d83b ("reset: Add reset_control_get_count()") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2018-11-14 21:49:35 +00: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