[PATCH v6 0/6] reset: gpio: ASoC: shared GPIO resets
Hi,
Dependencies / Merging ====================== 1. Depends on !GPIOLIB stub: https://lore.kernel.org/all/20240125081601.118051-3-krzysztof.kozlowski@lina...
2. Patch #2 (cpufreq: do not open-code of_phandle_args_equal()) and patch #4 (reset: Instantiate reset GPIO controller for shared reset-gpios) depend on OF change (patch #1).
Changes in v6 ============= 1. reset/core.c: Add check for number of GPIO cells==2 (Neil). 2. Add Rb/Ack tags.
Changes in v5 ============= 1. Minor comments from Philipp: missing cleanup.h, correct indentation of pr_err(), shorten gpio_device_find_by_fwnode() line. 2. Acks/Rbs.
Changes in v4 ============= 1. New patches: of: add of_phandle_args_equal() helper cpufreq: do not open-code of_phandle_args_equal()
2. reset-gpio.c: - Drop unneeded comment (Bartosz), add Rb tag. - Do not assign of_node.
3. reset/core.c: - Implement most of Bartosz feedback (I responded to one which I did not implement) and comments from Philipp. - Expect either rcdev->of_args or rcdev->of_node. - Drop __reset_gpios_args_match() and use common helper (Philipp). - Move declarations of automatic-cleanup variables in __reset_add_reset_gpio_lookup() to place of use (Bartosz). - Separate gpio_device_get_label() and kstrdup() (Philipp). - Correct doc for __reset_add_reset_gpio_device(), rewrite few comments. - Drop unneeded "r" variable in __reset_find_rcdev() (Philipp). - Drop of_phandle_args initialization in __of_reset_control_get (Philipp). - Check if CONFIG_RESET_GPIO is enabled before trying to look up reset-gpios.
4. Drop Chris' patch: "i2c: muxes: pca954x: Allow sharing reset GPIO", because discussion is on going.
Changes in v3 ============= 1. reset-gpio.c: - Add reset_gpio_of_xlate (Philipp). - reset_gpio_of_args_put->reset_gpio_of_node_put (Philipp). - Expect via platdata of_phandle_args. - Do not call device_set_node() to attach itself to reset consumer (the final device). This was questionable idea in the first place. Bartosz suggested to use GPIO_LOOKUP to solve this.
2. reset/core.c, implement Philipp's feedback. That was a lot: - Commit msg fixes. - Add new platform_device earlier, when reset core found "reset-gpios" but not "resets". - Do not overwrite of_phandle_args. - Expect matching .of_reset_n_cells. - Pass of_phandle_args as platdata to reset-gpio. - Rename reset_gpio_device->reset_gpio_lookup and others. Fix few comments and code cleanup pointed on review. - From Bartosz: Use GPIO_LOOKUP and a lot of cleanup.h in __reset_add_reset_gpio_lookup().
3. Include here Chris' patch: "i2c: muxes: pca954x: Allow sharing reset GPIO".
Changes in v2 ============= 1. wsa884x.c: add missing return in wsa884x_get_reset(), correct comment. 2. qcom,wsa8840.yaml: fix oneOf syntax. 3. reset-gpio.c: - Fix smatch warning on platdata evaluation. - Parse GPIO args and store them in rc.of_args. 4. reset/core.c: - Revise approach based on Bartosz comments: parse the reset-gpios phandle with arguments, do not use deprecated API and do not rely on gpio_desc pointer. - Create a list of instantiated platform devices to avoid any duplicates. - After creating reset-gpio platform device, try to get new reset controller or return EPROBE_DEFER. - Drop the "cookie" member and add new "of_args" to "struct reset_controller_dev".
Description ===========
We have at least few cases where hardware engineers decided to use one powerdown/shutdown/reset GPIO line for multiple devices:
1. WSA884x (this and previous patch): https://lore.kernel.org/all/b7aeda24-d638-45b7-8e30-80d287f498f8@sirena.org.... 2. https://lore.kernel.org/all/20231027033104.1348921-1-chris.packham@alliedtel... 3. https://lore.kernel.org/lkml/20191030120440.3699-1-peter.ujfalusi@ti.com/ 4. https://lore.kernel.org/all/20211018234923.1769028-1-sean.anderson@seco.com/ 5. https://social.treehouse.systems/@marcan/111268780311634160
I try to solve my case, hopefuly Chris' (2), partially Sean's (4) and maybe Hectors (5), using Rob's suggestion:
https://lore.kernel.org/all/YXi5CUCEi7YmNxXM@robh.at.kernel.org/
Best regards, Krzysztof
Cc: Chris Packham chris.packham@alliedtelesis.co.nz Cc: Bartosz Golaszewski brgl@bgdev.pl Cc: Sean Anderson sean.anderson@seco.com
Krzysztof Kozlowski (6): of: Add of_phandle_args_equal() helper cpufreq: do not open-code of_phandle_args_equal() reset: gpio: Add GPIO-based reset controller reset: Instantiate reset GPIO controller for shared reset-gpios ASoC: dt-bindings: qcom,wsa8840: Add reset-gpios for shared line ASoC: codecs: wsa884x: Allow sharing reset GPIO
.../bindings/sound/qcom,wsa8840.yaml | 11 +- MAINTAINERS | 5 + drivers/reset/Kconfig | 9 + drivers/reset/Makefile | 1 + drivers/reset/core.c | 224 +++++++++++++++++- drivers/reset/reset-gpio.c | 119 ++++++++++ include/linux/cpufreq.h | 3 +- include/linux/of.h | 16 ++ include/linux/reset-controller.h | 4 + sound/soc/codecs/wsa884x.c | 53 ++++- 10 files changed, 419 insertions(+), 26 deletions(-) create mode 100644 drivers/reset/reset-gpio.c
Add a helper comparing two "struct of_phandle_args" to avoid reinventing the wheel.
Reviewed-by: Philipp Zabel p.zabel@pengutronix.de Acked-by: Rob Herring robh@kernel.org Signed-off-by: Krzysztof Kozlowski krzysztof.kozlowski@linaro.org ---
Dependency of cpufreq and reset change. --- include/linux/of.h | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
diff --git a/include/linux/of.h b/include/linux/of.h index 6a9ddf20e79a..85bcc05b278d 100644 --- a/include/linux/of.h +++ b/include/linux/of.h @@ -1065,6 +1065,22 @@ static inline int of_parse_phandle_with_optional_args(const struct device_node * 0, index, out_args); }
+/** + * of_phandle_args_equal() - Compare two of_phandle_args + * @a1: First of_phandle_args to compare + * @a2: Second of_phandle_args to compare + * + * Return: True if a1 and a2 are the same (same node pointer, same phandle + * args), false otherwise. + */ +static inline bool of_phandle_args_equal(const struct of_phandle_args *a1, + const struct of_phandle_args *a2) +{ + return a1->np == a2->np && + a1->args_count == a2->args_count && + !memcmp(a1->args, a2->args, sizeof(a1->args[0]) * a1->args_count); +} + /** * of_property_count_u8_elems - Count the number of u8 elements in a property *
Use newly added of_phandle_args_equal() helper to compare two of_phandle_args.
Acked-by: Viresh Kumar viresh.kumar@linaro.org Reviewed-by: Philipp Zabel p.zabel@pengutronix.de Signed-off-by: Krzysztof Kozlowski krzysztof.kozlowski@linaro.org ---
Depends on previous OF change. --- include/linux/cpufreq.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index afda5f24d3dd..3cd06dafb04b 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -1149,8 +1149,7 @@ static inline int of_perf_domain_get_sharing_cpumask(int pcpu, const char *list_ if (ret < 0) continue;
- if (pargs->np == args.np && pargs->args_count == args.args_count && - !memcmp(pargs->args, args.args, sizeof(args.args[0]) * args.args_count)) + if (of_phandle_args_equal(pargs, &args)) cpumask_set_cpu(cpu, cpumask);
of_node_put(args.np);
Add a simple driver to control GPIO-based resets using the reset controller API for the cases when the GPIOs are shared and reset should be coordinated. The driver is expected to be used by reset core framework for ad-hoc reset controllers.
Cc: Bartosz Golaszewski brgl@bgdev.pl Cc: Chris Packham chris.packham@alliedtelesis.co.nz Cc: Sean Anderson sean.anderson@seco.com Reviewed-by: Bartosz Golaszewski bartosz.golaszewski@linaro.org Reviewed-by: Philipp Zabel p.zabel@pengutronix.de Signed-off-by: Krzysztof Kozlowski krzysztof.kozlowski@linaro.org --- MAINTAINERS | 5 ++ drivers/reset/Kconfig | 9 +++ drivers/reset/Makefile | 1 + drivers/reset/reset-gpio.c | 119 +++++++++++++++++++++++++++++++++++++ 4 files changed, 134 insertions(+) create mode 100644 drivers/reset/reset-gpio.c
diff --git a/MAINTAINERS b/MAINTAINERS index ddc5e1049921..91d45c6bade7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8905,6 +8905,11 @@ F: Documentation/i2c/muxes/i2c-mux-gpio.rst F: drivers/i2c/muxes/i2c-mux-gpio.c F: include/linux/platform_data/i2c-mux-gpio.h
+GENERIC GPIO RESET DRIVER +M: Krzysztof Kozlowski krzysztof.kozlowski@linaro.org +S: Maintained +F: drivers/reset/reset-gpio.c + GENERIC HDLC (WAN) DRIVERS M: Krzysztof Halasa khc@pm.waw.pl S: Maintained diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index ccd59ddd7610..bb1b5a326eb7 100644 --- a/drivers/reset/Kconfig +++ b/drivers/reset/Kconfig @@ -66,6 +66,15 @@ config RESET_BRCMSTB_RESCAL This enables the RESCAL reset controller for SATA, PCIe0, or PCIe1 on BCM7216.
+config RESET_GPIO + tristate "GPIO reset controller" + help + This enables a generic reset controller for resets attached via + GPIOs. Typically for OF platforms this driver expects "reset-gpios" + property. + + If compiled as module, it will be called reset-gpio. + config RESET_HSDK bool "Synopsys HSDK Reset Driver" depends on HAS_IOMEM diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile index 8270da8a4baa..fd8b49fa46fc 100644 --- a/drivers/reset/Makefile +++ b/drivers/reset/Makefile @@ -11,6 +11,7 @@ obj-$(CONFIG_RESET_BCM6345) += reset-bcm6345.o obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o obj-$(CONFIG_RESET_BRCMSTB) += reset-brcmstb.o obj-$(CONFIG_RESET_BRCMSTB_RESCAL) += reset-brcmstb-rescal.o +obj-$(CONFIG_RESET_GPIO) += reset-gpio.o obj-$(CONFIG_RESET_HSDK) += reset-hsdk.o obj-$(CONFIG_RESET_IMX7) += reset-imx7.o obj-$(CONFIG_RESET_INTEL_GW) += reset-intel-gw.o diff --git a/drivers/reset/reset-gpio.c b/drivers/reset/reset-gpio.c new file mode 100644 index 000000000000..2290b25b6703 --- /dev/null +++ b/drivers/reset/reset-gpio.c @@ -0,0 +1,119 @@ +// SPDX-License-Identifier: GPL-2.0 + +#include <linux/gpio/consumer.h> +#include <linux/mod_devicetable.h> +#include <linux/module.h> +#include <linux/of.h> +#include <linux/platform_device.h> +#include <linux/reset-controller.h> + +struct reset_gpio_priv { + struct reset_controller_dev rc; + struct gpio_desc *reset; +}; + +static inline struct reset_gpio_priv +*rc_to_reset_gpio(struct reset_controller_dev *rc) +{ + return container_of(rc, struct reset_gpio_priv, rc); +} + +static int reset_gpio_assert(struct reset_controller_dev *rc, unsigned long id) +{ + struct reset_gpio_priv *priv = rc_to_reset_gpio(rc); + + gpiod_set_value_cansleep(priv->reset, 1); + + return 0; +} + +static int reset_gpio_deassert(struct reset_controller_dev *rc, + unsigned long id) +{ + struct reset_gpio_priv *priv = rc_to_reset_gpio(rc); + + gpiod_set_value_cansleep(priv->reset, 0); + + return 0; +} + +static int reset_gpio_status(struct reset_controller_dev *rc, unsigned long id) +{ + struct reset_gpio_priv *priv = rc_to_reset_gpio(rc); + + return gpiod_get_value_cansleep(priv->reset); +} + +static const struct reset_control_ops reset_gpio_ops = { + .assert = reset_gpio_assert, + .deassert = reset_gpio_deassert, + .status = reset_gpio_status, +}; + +static int reset_gpio_of_xlate(struct reset_controller_dev *rcdev, + const struct of_phandle_args *reset_spec) +{ + return reset_spec->args[0]; +} + +static void reset_gpio_of_node_put(void *data) +{ + of_node_put(data); +} + +static int reset_gpio_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct of_phandle_args *platdata = dev_get_platdata(dev); + struct reset_gpio_priv *priv; + int ret; + + if (!platdata) + return -EINVAL; + + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); + if (!priv) + return -ENOMEM; + + platform_set_drvdata(pdev, &priv->rc); + + priv->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH); + if (IS_ERR(priv->reset)) + return dev_err_probe(dev, PTR_ERR(priv->reset), + "Could not get reset gpios\n"); + + priv->rc.ops = &reset_gpio_ops; + priv->rc.owner = THIS_MODULE; + priv->rc.dev = dev; + priv->rc.of_args = platdata; + ret = devm_add_action_or_reset(dev, reset_gpio_of_node_put, + priv->rc.of_node); + if (ret) + return ret; + + /* Cells to match GPIO specifier, but it's not really used */ + priv->rc.of_reset_n_cells = 2; + priv->rc.of_xlate = reset_gpio_of_xlate; + priv->rc.nr_resets = 1; + + return devm_reset_controller_register(dev, &priv->rc); +} + +static const struct platform_device_id reset_gpio_ids[] = { + { .name = "reset-gpio", }, + {} +}; +MODULE_DEVICE_TABLE(platform, reset_gpio_ids); + +static struct platform_driver reset_gpio_driver = { + .probe = reset_gpio_probe, + .id_table = reset_gpio_ids, + .driver = { + .name = "reset-gpio", + }, +}; +module_platform_driver(reset_gpio_driver); + +MODULE_AUTHOR("Krzysztof Kozlowski krzysztof.kozlowski@linaro.org"); +MODULE_DESCRIPTION("Generic GPIO reset driver"); +MODULE_LICENSE("GPL");
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
---
Depends on: 1. Previous OF change. 2. !GPIOLIB stub: https://lore.kernel.org/all/20240125081601.118051-3-krzysztof.kozlowski@lina... --- drivers/reset/core.c | 224 +++++++++++++++++++++++++++++-- include/linux/reset-controller.h | 4 + 2 files changed, 215 insertions(+), 13 deletions(-)
diff --git a/drivers/reset/core.c b/drivers/reset/core.c index 4d5a78d3c085..dba74e857be6 100644 --- a/drivers/reset/core.c +++ b/drivers/reset/core.c @@ -5,14 +5,19 @@ * Copyright 2013 Philipp Zabel, Pengutronix */ #include <linux/atomic.h> +#include <linux/cleanup.h> #include <linux/device.h> #include <linux/err.h> #include <linux/export.h> #include <linux/kernel.h> #include <linux/kref.h> +#include <linux/gpio/driver.h> +#include <linux/gpio/machine.h> +#include <linux/idr.h> #include <linux/module.h> #include <linux/of.h> #include <linux/acpi.h> +#include <linux/platform_device.h> #include <linux/reset.h> #include <linux/reset-controller.h> #include <linux/slab.h> @@ -23,6 +28,11 @@ static LIST_HEAD(reset_controller_list); static DEFINE_MUTEX(reset_lookup_mutex); static LIST_HEAD(reset_lookup_list);
+/* Protects reset_gpio_lookup_list */ +static DEFINE_MUTEX(reset_gpio_lookup_mutex); +static LIST_HEAD(reset_gpio_lookup_list); +static DEFINE_IDA(reset_gpio_ida); + /** * struct reset_control - a reset control * @rcdev: a pointer to the reset controller device @@ -63,6 +73,16 @@ struct reset_control_array { struct reset_control *rstc[] __counted_by(num_rstcs); };
+/** + * struct reset_gpio_lookup - lookup key for ad-hoc created reset-gpio devices + * @of_args: phandle to the reset controller with all the args like GPIO number + * @list: list entry for the reset_gpio_lookup_list + */ +struct reset_gpio_lookup { + struct of_phandle_args of_args; + struct list_head list; +}; + static const char *rcdev_name(struct reset_controller_dev *rcdev) { if (rcdev->dev) @@ -71,6 +91,9 @@ static const char *rcdev_name(struct reset_controller_dev *rcdev) if (rcdev->of_node) return rcdev->of_node->full_name;
+ if (rcdev->of_args) + return rcdev->of_args->np->full_name; + return NULL; }
@@ -99,6 +122,9 @@ static int of_reset_simple_xlate(struct reset_controller_dev *rcdev, */ int reset_controller_register(struct reset_controller_dev *rcdev) { + if (rcdev->of_node && rcdev->of_args) + return -EINVAL; + if (!rcdev->of_xlate) { rcdev->of_reset_n_cells = 1; rcdev->of_xlate = of_reset_simple_xlate; @@ -813,12 +839,171 @@ static void __reset_control_put_internal(struct reset_control *rstc) kref_put(&rstc->refcnt, __reset_control_release); }
+static int __reset_add_reset_gpio_lookup(int id, struct device_node *np, + unsigned int gpio, + unsigned int of_flags) +{ + const struct fwnode_handle *fwnode = of_fwnode_handle(np); + unsigned int lookup_flags; + const char *label_tmp; + + /* + * Later we map GPIO flags between OF and Linux, however not all + * constants from include/dt-bindings/gpio/gpio.h and + * include/linux/gpio/machine.h match each other. + */ + if (of_flags > GPIO_ACTIVE_LOW) { + pr_err("reset-gpio code does not support GPIO flags %u for GPIO %u\n", + of_flags, gpio); + return -EINVAL; + } + + struct gpio_device *gdev __free(gpio_device_put) = gpio_device_find_by_fwnode(fwnode); + if (!gdev) + return -EPROBE_DEFER; + + label_tmp = gpio_device_get_label(gdev); + if (!label_tmp) + return -EINVAL; + + char *label __free(kfree) = kstrdup(label_tmp, GFP_KERNEL); + if (!label) + return -ENOMEM; + + /* Size: one lookup entry plus sentinel */ + struct gpiod_lookup_table *lookup __free(kfree) = kzalloc(struct_size(lookup, table, 2), + GFP_KERNEL); + if (!lookup) + return -ENOMEM; + + lookup->dev_id = kasprintf(GFP_KERNEL, "reset-gpio.%d", id); + if (!lookup->dev_id) + return -ENOMEM; + + lookup_flags = GPIO_PERSISTENT; + lookup_flags |= of_flags & GPIO_ACTIVE_LOW; + lookup->table[0] = GPIO_LOOKUP(no_free_ptr(label), gpio, "reset", + lookup_flags); + + /* Not freed on success, because it is persisent subsystem data. */ + gpiod_add_lookup_table(no_free_ptr(lookup)); + + return 0; +} + +/* + * @args: phandle to the GPIO provider with all the args like GPIO number + */ +static int __reset_add_reset_gpio_device(const struct of_phandle_args *args) +{ + struct reset_gpio_lookup *rgpio_dev; + struct platform_device *pdev; + int id, ret; + + /* + * Currently only #gpio-cells=2 is supported with the meaning of: + * args[0]: GPIO number + * args[1]: GPIO flags + * TODO: Handle other cases. + */ + if (args->args_count != 2) + return -ENOENT; + + /* + * Registering reset-gpio device might cause immediate + * bind, resulting in its probe() registering new reset controller thus + * taking reset_list_mutex lock via reset_controller_register(). + */ + lockdep_assert_not_held(&reset_list_mutex); + + mutex_lock(&reset_gpio_lookup_mutex); + + list_for_each_entry(rgpio_dev, &reset_gpio_lookup_list, list) { + if (args->np == rgpio_dev->of_args.np) { + if (of_phandle_args_equal(args, &rgpio_dev->of_args)) + goto out; /* Already on the list, done */ + } + } + + id = ida_alloc(&reset_gpio_ida, GFP_KERNEL); + if (id < 0) { + ret = id; + goto err_unlock; + } + + /* Not freed on success, because it is persisent subsystem data. */ + rgpio_dev = kzalloc(sizeof(*rgpio_dev), GFP_KERNEL); + if (!rgpio_dev) { + ret = -ENOMEM; + goto err_ida_free; + } + + ret = __reset_add_reset_gpio_lookup(id, args->np, args->args[0], + args->args[1]); + if (ret < 0) + goto err_kfree; + + rgpio_dev->of_args = *args; + /* + * We keep the device_node reference, but of_args.np is put at the end + * of __of_reset_control_get(), so get it one more time. + * Hold reference as long as rgpio_dev memory is valid. + */ + of_node_get(rgpio_dev->of_args.np); + pdev = platform_device_register_data(NULL, "reset-gpio", id, + &rgpio_dev->of_args, + sizeof(rgpio_dev->of_args)); + ret = PTR_ERR_OR_ZERO(pdev); + if (ret) + goto err_put; + + list_add(&rgpio_dev->list, &reset_gpio_lookup_list); + +out: + mutex_unlock(&reset_gpio_lookup_mutex); + + return 0; + +err_put: + of_node_put(rgpio_dev->of_args.np); +err_kfree: + kfree(rgpio_dev); +err_ida_free: + ida_free(&reset_gpio_ida, id); +err_unlock: + mutex_unlock(&reset_gpio_lookup_mutex); + + return ret; +} + +static struct reset_controller_dev *__reset_find_rcdev(const struct of_phandle_args *args, + bool gpio_fallback) +{ + struct reset_controller_dev *rcdev; + + lockdep_assert_held(&reset_list_mutex); + + list_for_each_entry(rcdev, &reset_controller_list, list) { + if (gpio_fallback) { + if (rcdev->of_args && of_phandle_args_equal(args, + rcdev->of_args)) + return rcdev; + } else { + if (args->np == rcdev->of_node) + return rcdev; + } + } + + return NULL; +} + struct reset_control * __of_reset_control_get(struct device_node *node, const char *id, int index, bool shared, bool optional, bool acquired) { + bool gpio_fallback = false; struct reset_control *rstc; - struct reset_controller_dev *r, *rcdev; + struct reset_controller_dev *rcdev; struct of_phandle_args args; int rstc_id; int ret; @@ -839,39 +1024,52 @@ __of_reset_control_get(struct device_node *node, const char *id, int index, index, &args); if (ret == -EINVAL) return ERR_PTR(ret); - if (ret) - return optional ? NULL : ERR_PTR(ret); + if (ret) { + if (!IS_ENABLED(CONFIG_RESET_GPIO)) + return optional ? NULL : ERR_PTR(ret);
- mutex_lock(&reset_list_mutex); - rcdev = NULL; - list_for_each_entry(r, &reset_controller_list, list) { - if (args.np == r->of_node) { - rcdev = r; - break; + /* + * There can be only one reset-gpio for regular devices, so + * don't bother with the "reset-gpios" phandle index. + */ + ret = of_parse_phandle_with_args(node, "reset-gpios", "#gpio-cells", + 0, &args); + if (ret) + return optional ? NULL : ERR_PTR(ret); + + gpio_fallback = true; + + ret = __reset_add_reset_gpio_device(&args); + if (ret) { + rstc = ERR_PTR(ret); + goto out_put; } }
+ mutex_lock(&reset_list_mutex); + rcdev = __reset_find_rcdev(&args, gpio_fallback); if (!rcdev) { rstc = ERR_PTR(-EPROBE_DEFER); - goto out; + goto out_unlock; }
if (WARN_ON(args.args_count != rcdev->of_reset_n_cells)) { rstc = ERR_PTR(-EINVAL); - goto out; + goto out_unlock; }
rstc_id = rcdev->of_xlate(rcdev, &args); if (rstc_id < 0) { rstc = ERR_PTR(rstc_id); - goto out; + goto out_unlock; }
/* reset_list_mutex also protects the rcdev's reset_control list */ rstc = __reset_control_get_internal(rcdev, rstc_id, shared, acquired);
-out: +out_unlock: mutex_unlock(&reset_list_mutex); +out_put: of_node_put(args.np);
return rstc; diff --git a/include/linux/reset-controller.h b/include/linux/reset-controller.h index 0fa4f60e1186..357df16ede32 100644 --- a/include/linux/reset-controller.h +++ b/include/linux/reset-controller.h @@ -60,6 +60,9 @@ struct reset_control_lookup { * @reset_control_head: head of internal list of requested reset controls * @dev: corresponding driver model device struct * @of_node: corresponding device tree node as phandle target + * @of_args: for reset-gpios controllers: corresponding phandle args with + * of_node and GPIO number complementing of_node; either this or + * of_node should be present * @of_reset_n_cells: number of cells in reset line specifiers * @of_xlate: translation function to translate from specifier as found in the * device tree to id as given to the reset control ops, defaults @@ -73,6 +76,7 @@ struct reset_controller_dev { struct list_head reset_control_head; struct device *dev; struct device_node *of_node; + const struct of_phandle_args *of_args; int of_reset_n_cells; int (*of_xlate)(struct reset_controller_dev *rcdev, const struct of_phandle_args *reset_spec);
Hi Krzysztof,
something is odd with the addresses on this patch, because neither GPIO maintainer is on CC nor linux-gpio@vger, and it's such a GPIO-related patch. We only saw it through side effects making <linux/gpio/driver.h> optional, as required by this patch.
Please also CC Geert Uytterhoeven, the author of the GPIO aggregator.
i.e. this:
On Mon, Jan 29, 2024 at 12:53 PM Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
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
(...)
In my naive view, this implements the following:
reset -> virtual "gpio" -> many physical gpios[0..n]
So if there was already a way in the kernel to map one GPIO to many GPIOs, the framework could just use that with a simple single GPIO?
See the bindings in: Documentation/devicetree/bindings/gpio/gpio-delay.yaml
This is handled by drivers/gpio/gpio-aggregator.c.
This supports a 1-to-1 map: one GPIO in, one GPIO out, same offset. So if that is extended to support 1-to-many, this problem is solved.
Proposed solution: add a single boolean property such as aggregate-all-gpios; to the gpio-delay node, making it provide one single gpio at offset 0 on the consumer side, and refuse any more consumers.
This will also solve the problem with induced delays on some GPIO lines as I can see was discussed in the bindings, the gpio aggregator already supports that, but it would work fine with a delay being zero as well.
This avoids all the hackery with driver stubs etc as well.
Yours, Linus Walleij
On Wed, Jan 31, 2024 at 9:57 AM Linus Walleij linus.walleij@linaro.org wrote:
Hi Krzysztof,
something is odd with the addresses on this patch, because neither GPIO maintainer is on CC nor linux-gpio@vger, and it's such a GPIO-related patch. We only saw it through side effects making <linux/gpio/driver.h> optional, as required by this patch.
Please also CC Geert Uytterhoeven, the author of the GPIO aggregator.
i.e. this:
On Mon, Jan 29, 2024 at 12:53 PM Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
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
(...)
In my naive view, this implements the following:
reset -> virtual "gpio" -> many physical gpios[0..n]
This is a different problem: it supports many users enabling the same GPIO (in Krzysztof's patch it's one but could be more if needed) but - unlike the broken NONEXCLUSIVE GPIOs in GPIOLIB - it counts the number of users and doesn't disable the GPIO for as long as there's at least one.
Bart
So if there was already a way in the kernel to map one GPIO to many GPIOs, the framework could just use that with a simple single GPIO?
See the bindings in: Documentation/devicetree/bindings/gpio/gpio-delay.yaml
This is handled by drivers/gpio/gpio-aggregator.c.
This supports a 1-to-1 map: one GPIO in, one GPIO out, same offset. So if that is extended to support 1-to-many, this problem is solved.
Proposed solution: add a single boolean property such as aggregate-all-gpios; to the gpio-delay node, making it provide one single gpio at offset 0 on the consumer side, and refuse any more consumers.
This will also solve the problem with induced delays on some GPIO lines as I can see was discussed in the bindings, the gpio aggregator already supports that, but it would work fine with a delay being zero as well.
This avoids all the hackery with driver stubs etc as well.
Yours, Linus Walleij
On Wed, Jan 31, 2024 at 10:37 AM Bartosz Golaszewski brgl@bgdev.pl wrote:
[Me]
reset -> virtual "gpio" -> many physical gpios[0..n]
This is a different problem: it supports many users enabling the same GPIO (in Krzysztof's patch it's one but could be more if needed) but - unlike the broken NONEXCLUSIVE GPIOs in GPIOLIB - it counts the number of users and doesn't disable the GPIO for as long as there's at least one.
I don't know if the NONEXCLUSIVE stuff is broken, if you mean reference counting isn't working on them, then that is by design because they were invented for regulators and such use cases that do their own reference counting. It's also used for hacks where people need to look up a desc in a second spot, (perhaps we can fix those better).
As I say in commit b0ce7b29bfcd090ddba476f45a75ec0a797b048a "This solution with a special flag is not entirely elegant and should ideally be replaced by something more careful as this makes it possible for several consumers to enable/disable the same GPIO line to the left and right without any consistency."
I think for regulators (which is the vast majority using it) it isn't broken because the regulator reference counting is working.
So if we solve that problem for reset, we probably should put it in drivers/gpio/* somewhere so we can reuse the same solution for regulators and get rid of NONEXCLUSIVE altogether I think?
The NONEXCLUSIVE stuff was prompted by converting regulators to gpio descriptors, so it was for the greater good one can say. Or the lesser evil :( my judgement can be questioned here.
Yours, Linus Walleij
On Wed, Jan 31, 2024 at 02:17:54PM +0100, Linus Walleij wrote:
On Wed, Jan 31, 2024 at 10:37 AM Bartosz Golaszewski brgl@bgdev.pl wrote:
This is a different problem: it supports many users enabling the same GPIO (in Krzysztof's patch it's one but could be more if needed) but - unlike the broken NONEXCLUSIVE GPIOs in GPIOLIB - it counts the number of users and doesn't disable the GPIO for as long as there's at least one.
I don't know if the NONEXCLUSIVE stuff is broken, if you mean reference counting isn't working on them, then that is by design because they were invented for regulators and such use cases that do their own reference counting. It's also used for hacks where people need to look up a desc in a second spot, (perhaps we can fix those better).
Their own reference counting or whatever other coordination they want - the deal is that users are responsible for their own coordination whatever that might be.
The NONEXCLUSIVE stuff was prompted by converting regulators to gpio descriptors, so it was for the greater good one can say. Or the lesser evil :( my judgement can be questioned here.
Right, previously we were working out if a GPIO was shared by looking at the GPIO number but with descriptors we need to get the GPIO before we can do anything with it, including figure out if it's shared.
On 31/01/2024 14:17, Linus Walleij wrote:
On Wed, Jan 31, 2024 at 10:37 AM Bartosz Golaszewski brgl@bgdev.pl wrote:
[Me]
reset -> virtual "gpio" -> many physical gpios[0..n]
This is a different problem: it supports many users enabling the same GPIO (in Krzysztof's patch it's one but could be more if needed) but - unlike the broken NONEXCLUSIVE GPIOs in GPIOLIB - it counts the number of users and doesn't disable the GPIO for as long as there's at least one.
I don't know if the NONEXCLUSIVE stuff is broken, if you mean reference counting isn't working on them, then that is by design because they were invented for regulators and such use cases that do their own reference counting. It's also used for hacks where people need to look up a desc in a second spot, (perhaps we can fix those better).
As I say in commit b0ce7b29bfcd090ddba476f45a75ec0a797b048a "This solution with a special flag is not entirely elegant and should ideally be replaced by something more careful as this makes it possible for several consumers to enable/disable the same GPIO line to the left and right without any consistency."
I think for regulators (which is the vast majority using it) it isn't broken because the regulator reference counting is working.
So if we solve that problem for reset, we probably should put it in drivers/gpio/* somewhere so we can reuse the same solution for regulators and get rid of NONEXCLUSIVE altogether I think?
The NONEXCLUSIVE stuff was prompted by converting regulators to gpio descriptors, so it was for the greater good one can say. Or the lesser evil :( my judgement can be questioned here.
I discussed the non-exclusive GPIOs with Bartosz quite a lot, who was Cced since beginning of this patchset, because that was my first approach, which was rejected:
https://lore.kernel.org/all/b7aeda24-d638-45b7-8e30-80d287f498f8@sirena.org....
The non-exclusive GPIO was made explicitly for regulators, so it is working fine there, but it is broken everywhere else, where the drivers do not handle it in sane way as regulator core does.
To make it working, either GPIO should be enable-count-aware, to which Bartosz was opposing with talks with me, or the subsystem should mimic regulators approach. In some way, my patchset is the second way here - reset framework subsystem being aware of shared GPIO and handles the enable-count, even though it is not using non-exclusive flag.
Best regards, Krzysztof
On Wed, Jan 31, 2024 at 2:32 PM Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
The non-exclusive GPIO was made explicitly for regulators, so it is working fine there, but it is broken everywhere else, where the drivers do not handle it in sane way as regulator core does.
I looked at it, it's 8 users in the entire kernel that aren't regulators, so let's put it on the TODO to get rid of those.
To make it working, either GPIO should be enable-count-aware, to which Bartosz was opposing with talks with me, or the subsystem should mimic regulators approach. In some way, my patchset is the second way here - reset framework subsystem being aware of shared GPIO and handles the enable-count, even though it is not using non-exclusive flag.
That's nice, I was thinking if it could be abstracted so the regulator core can move away from this too?
I guess it may be an issue that regulators are not using Device Tree exclusively, but also has to deal with a slew of platform_devices:s :/ IIRC that was one of the reasons why it looks as it does.
Maybe reset can only solve this in an elegant way if the solution is tightly coupled with DT and you have the advantage that you can require it from day one? (It looks a bit like that to me.)
Yours, Linus Walleij
On Wed, Jan 31, 2024 at 02:42:17PM +0100, Linus Walleij wrote:
I guess it may be an issue that regulators are not using Device Tree exclusively, but also has to deal with a slew of platform_devices:s :/ IIRC that was one of the reasons why it looks as it does.
Also ACPI, and this is a long standing binding so we can't change the ABI for DT. We could potentially use a refcounting mechanism provided by the GPIO core but we'd need to know when the refcount changes from 0 to 1 and back, we need to take other actions (inserting delays and generating notifications) when it does so I'm not sure how exciting it is to factor out the refcount. I think part of the decision making with the current design was that there was likely going to need to be some higher level stuff like that in the users so it wasn't clear that trying to abstract the reference count away in gpiolib was buying us much.
On Wed, Jan 31, 2024 at 2:32 PM Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
On 31/01/2024 14:17, Linus Walleij wrote:
On Wed, Jan 31, 2024 at 10:37 AM Bartosz Golaszewski brgl@bgdev.pl wrote:
[Me]
reset -> virtual "gpio" -> many physical gpios[0..n]
This is a different problem: it supports many users enabling the same GPIO (in Krzysztof's patch it's one but could be more if needed) but - unlike the broken NONEXCLUSIVE GPIOs in GPIOLIB - it counts the number of users and doesn't disable the GPIO for as long as there's at least one.
I don't know if the NONEXCLUSIVE stuff is broken, if you mean reference counting isn't working on them, then that is by design because they were invented for regulators and such use cases that do their own reference counting. It's also used for hacks where people need to look up a desc in a second spot, (perhaps we can fix those better).
As I say in commit b0ce7b29bfcd090ddba476f45a75ec0a797b048a "This solution with a special flag is not entirely elegant and should ideally be replaced by something more careful as this makes it possible for several consumers to enable/disable the same GPIO line to the left and right without any consistency."
I think for regulators (which is the vast majority using it) it isn't broken because the regulator reference counting is working.
So if we solve that problem for reset, we probably should put it in drivers/gpio/* somewhere so we can reuse the same solution for regulators and get rid of NONEXCLUSIVE altogether I think?
The NONEXCLUSIVE stuff was prompted by converting regulators to gpio descriptors, so it was for the greater good one can say. Or the lesser evil :( my judgement can be questioned here.
I discussed the non-exclusive GPIOs with Bartosz quite a lot, who was Cced since beginning of this patchset, because that was my first approach, which was rejected:
https://lore.kernel.org/all/b7aeda24-d638-45b7-8e30-80d287f498f8@sirena.org....
The non-exclusive GPIO was made explicitly for regulators, so it is working fine there, but it is broken everywhere else, where the drivers do not handle it in sane way as regulator core does.
To make it working, either GPIO should be enable-count-aware, to which Bartosz was opposing with talks with me, or the subsystem should mimic
For the record: I'm not 100% opposed to the enable-count-awarness of GPIOs but don't want it to be the standard. I'm open for introducing a wrapper built around the core, low-level GPIO API but I've just dropped a big patchset addressing the access control and serialization issues for the GPIO consumer API and I would rather work towards making it at least more-or-less correct in the first place before we start overcomplicating it again.
Bartosz
regulators approach. In some way, my patchset is the second way here - reset framework subsystem being aware of shared GPIO and handles the enable-count, even though it is not using non-exclusive flag.
Best regards, Krzysztof
On 31/01/2024 09:57, Linus Walleij wrote:
Hi Krzysztof,
something is odd with the addresses on this patch, because neither GPIO
Nothing is odd - I use get_maintainers.pl which just don't print your names. I can add your addresses manually, no problem, but don't blame the contributor that get_maintainers.pl has a missing content-regex. If you want to be Cced on usage of GPIOs, you need to be sure that MAINTAINERS file has appropriate pattern.
maintainer is on CC nor linux-gpio@vger, and it's such a GPIO-related patch. We only saw it through side effects making <linux/gpio/driver.h> optional, as required by this patch.
Please also CC Geert Uytterhoeven, the author of the GPIO aggregator.
i.e. this:
On Mon, Jan 29, 2024 at 12:53 PM Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
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
(...)
In my naive view, this implements the following:
reset -> virtual "gpio" -> many physical gpios[0..n]
It does not, there is no single GPIO here. There is a single reset controller, though, but still multiple GPIOs in DTS.
So if there was already a way in the kernel to map one GPIO to many GPIOs, the framework could just use that with a simple single GPIO?
See the bindings in: Documentation/devicetree/bindings/gpio/gpio-delay.yaml
This is handled by drivers/gpio/gpio-aggregator.c.
This supports a 1-to-1 map: one GPIO in, one GPIO out, same offset. So if that is extended to support 1-to-many, this problem is solved.
It does not match the hardware thus I don't know how to implement it in DTS while keeping the requirement that we are describing hardware, not OS abstractions.
Proposed solution: add a single boolean property such as aggregate-all-gpios; to the gpio-delay node, making it provide one single gpio at offset 0 on the consumer side, and refuse any more consumers.
And how do you solve the reset requirements? The problem is not just to share GPIO. The problem is to share in a way that devices operate properly when they assert/deassert reset.
This will also solve the problem with induced delays on some GPIO lines as I can see was discussed in the bindings, the gpio aggregator already supports that, but it would work fine with a delay being zero as well.
This avoids all the hackery with driver stubs etc as well.
So none of these ideas were posted in previous threads, just because you were not CCed (except one thread)?
https://lore.kernel.org/lkml/20191030120440.3699-1-peter.ujfalusi@ti.com/ https://lore.kernel.org/all/9eebec9b-e6fd-4a22-89ea-b434f446e061@linaro.org/ https://lore.kernel.org/all/20231018100055.140847-1-krzysztof.kozlowski@lina... https://social.treehouse.systems/@marcan/111268780311634160
Please implement some custom lei filter, so you will get such notifications earlier. We keep discussing this for many months on various attempts and this specific attempt already reached v6.
Best regards, Krzysztof
On 31/01/2024 10:50, Krzysztof Kozlowski wrote:
On 31/01/2024 09:57, Linus Walleij wrote:
Hi Krzysztof,
something is odd with the addresses on this patch, because neither GPIO
Nothing is odd - I use get_maintainers.pl which just don't print your names. I can add your addresses manually, no problem, but don't blame the contributor that get_maintainers.pl has a missing content-regex. If you want to be Cced on usage of GPIOs, you need to be sure that MAINTAINERS file has appropriate pattern.
maintainer is on CC nor linux-gpio@vger, and it's such a GPIO-related patch. We only saw it through side effects making <linux/gpio/driver.h> optional, as required by this patch.
Please also CC Geert Uytterhoeven, the author of the GPIO aggregator.
i.e. this:
On Mon, Jan 29, 2024 at 12:53 PM Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
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
(...)
In my naive view, this implements the following:
reset -> virtual "gpio" -> many physical gpios[0..n]
It does not, there is no single GPIO here. There is a single reset controller, though, but still multiple GPIOs in DTS.
So if there was already a way in the kernel to map one GPIO to many GPIOs, the framework could just use that with a simple single GPIO?
See the bindings in: Documentation/devicetree/bindings/gpio/gpio-delay.yaml
This is handled by drivers/gpio/gpio-aggregator.c.
This supports a 1-to-1 map: one GPIO in, one GPIO out, same offset. So if that is extended to support 1-to-many, this problem is solved.
It does not match the hardware thus I don't know how to implement it in DTS while keeping the requirement that we are describing hardware, not OS abstractions.
Proposed solution: add a single boolean property such as aggregate-all-gpios; to the gpio-delay node, making it provide one single gpio at offset 0 on the consumer side, and refuse any more consumers.
And how do you solve the reset requirements? The problem is not just to share GPIO. The problem is to share in a way that devices operate properly when they assert/deassert reset.
This will also solve the problem with induced delays on some GPIO lines as I can see was discussed in the bindings, the gpio aggregator already supports that, but it would work fine with a delay being zero as well.
This avoids all the hackery with driver stubs etc as well.
So none of these ideas were posted in previous threads, just because you were not CCed (except one thread)?
https://lore.kernel.org/lkml/20191030120440.3699-1-peter.ujfalusi@ti.com/ https://lore.kernel.org/all/9eebec9b-e6fd-4a22-89ea-b434f446e061@linaro.org/ https://lore.kernel.org/all/20231018100055.140847-1-krzysztof.kozlowski@lina... https://social.treehouse.systems/@marcan/111268780311634160
And here:
https://lore.kernel.org/all/CAL_JsqL3oZXJJ5_i4BRGpvWu1X8QFB7OGG=D+zLvvWb=UR1... which the place where this idea of using resets appeared. I agree that you were not CCed there, but that only means you miss lei filters or pattern in MAINTAINERS.
Best regards, Krzysztof
On Wed, Jan 31, 2024 at 10:50 AM Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
Nothing is odd - I use get_maintainers.pl which just don't print your names. I can add your addresses manually, no problem, but don't blame the contributor that get_maintainers.pl has a missing content-regex. If you want to be Cced on usage of GPIOs, you need to be sure that MAINTAINERS file has appropriate pattern.
I think that is over-reliance on tooling, I think if I author a patch creating a struct gpio_chip it's natural to CC the GPIO maintainers, just by intuition. Maybe that's just me.
I guess if one wants to automate maybe get_maintainers should CC GPIO maintainers on patches that has a + #include <linux/gpio/driver.h> in the patch body but it seems like stretching it to me, it's just too much process.
reset -> virtual "gpio" -> many physical gpios[0..n]
It does not, there is no single GPIO here. There is a single reset controller, though, but still multiple GPIOs in DTS.
Aha so this is problem similar to what regulators are doing, where they had this problem that a single GPIO can contain a regulator used by many devices?
There the solution is something along the line that the first consumer turns on the light when it arrives and the last consumer turns it off when it leaves, at least that is the idea.
That solution isn't the pretties either :/
But if we find a solution for the reset controller, it appears to me that the pattern should be re-usable for regulators too?
I think Bartosz says in another reply that *_NONEXCLUSIVE that the regulators are using is broken so if we are to invent something new we should make it available for everyone.
This supports a 1-to-1 map: one GPIO in, one GPIO out, same offset. So if that is extended to support 1-to-many, this problem is solved.
It does not match the hardware thus I don't know how to implement it in DTS while keeping the requirement that we are describing hardware, not OS abstractions.
OK fair enough I got it wrong.
(the rest of comments are probably fallouts from the misunderstanding).
So none of these ideas were posted in previous threads, just because you were not CCed (except one thread)?
https://lore.kernel.org/lkml/20191030120440.3699-1-peter.ujfalusi@ti.com/ https://lore.kernel.org/all/9eebec9b-e6fd-4a22-89ea-b434f446e061@linaro.org/ https://lore.kernel.org/all/20231018100055.140847-1-krzysztof.kozlowski@lina... https://social.treehouse.systems/@marcan/111268780311634160
Please implement some custom lei filter, so you will get such notifications earlier. We keep discussing this for many months on various attempts and this specific attempt already reached v6.
Yeah I should really look at lei!
I just haven't had time to get into it, because it appears it appeals most to people who use local clients like mutt. And I use gmail (yeah ...) I guess I would have to change my whole workflow to accomodate for lei, but it may very well be the right thing to do, I did change everything for b4 already.
Yours, Linus Walleij
On 29/01/2024 12:52, Krzysztof Kozlowski wrote:
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
Are any reviewers comments unresolved or unsatisfied with the discussion? I have impression that discussion bikeschedded a bit towards NONEXCLUSIVE, which was later clarified that NONEXCLUSIVE is not the solution for this problem, but maybe we miss some final Ack?
Anyone is here unhappy with this solution?
To remind: this is a generic solution solving at least two people's problems, probably more. It does not solve all people's problem, but I doubt anyone has enough of time to satisfy all people...
Best regards, Krzysztof
On Mon, Jan 29, 2024 at 12:53 PM Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
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: Linus Walleij linus.walleij@linaro.org
I can't think of anything better, that is reasonable to ask for.
I feel slightly icky about the way the code reaches into gpiolib, and I think regulators should be able to reuse the code, but unfortunately only the day they have no board files left :/
I do feel the core code handling "reset-gpios" could as well have been used to handle "enable-gpios" in regulators, just that the regulator code has more requirements, and would be really hard to rewrite, and deals with descriptors passed in from drivers instead of centralizing it.
Like regulators, reset grows core support for handling GPIO for resets which is *long due*, given how common it must be. We really need something like this, and this is certainly elegant enough to do the job.
Yours, Linus Walleij
On Mon, Feb 12, 2024 at 9:48 PM Linus Walleij linus.walleij@linaro.org wrote:
On Mon, Jan 29, 2024 at 12:53 PM Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
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: Linus Walleij linus.walleij@linaro.org
I can't think of anything better, that is reasonable to ask for.
I feel slightly icky about the way the code reaches into gpiolib, and I think
As long as it doesn't include gpiolib.h, I'm fine with it.
regulators should be able to reuse the code, but unfortunately only the day they have no board files left :/
I do feel the core code handling "reset-gpios" could as well have been used to handle "enable-gpios" in regulators, just that the regulator code has more requirements, and would be really hard to rewrite, and deals with descriptors passed in from drivers instead of centralizing it.
Like regulators, reset grows core support for handling GPIO for resets which is *long due*, given how common it must be. We really need something like this, and this is certainly elegant enough to do the job.
Yours, Linus Walleij
Agreed.
Acked-by: Bartosz Golaszewski bartosz.golaszewski@linaro.org
I will pick up the stub patches tomorrow and send a tag for Philipp to pull.
Bartosz
On newer Qualcomm platforms, like X1E80100-CRD, the WSA884x speakers share SD_N GPIOs between two speakers, thus a coordinated assertion is needed. Linux supports handling shared GPIO lines through "reset-gpios" property, thus allow specifying either powerdown or reset GPIOs (these are the same).
Cc: Bartosz Golaszewski brgl@bgdev.pl Cc: Sean Anderson sean.anderson@seco.com Acked-by: Rob Herring robh@kernel.org Signed-off-by: Krzysztof Kozlowski krzysztof.kozlowski@linaro.org ---
If previous patches are fine, then this commit is independent and could be taken via ASoC. --- .../devicetree/bindings/sound/qcom,wsa8840.yaml | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/sound/qcom,wsa8840.yaml b/Documentation/devicetree/bindings/sound/qcom,wsa8840.yaml index d717017b0fdb..22798d22d981 100644 --- a/Documentation/devicetree/bindings/sound/qcom,wsa8840.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,wsa8840.yaml @@ -28,6 +28,10 @@ properties: description: Powerdown/Shutdown line to use (pin SD_N) maxItems: 1
+ reset-gpios: + description: Powerdown/Shutdown line to use (pin SD_N) + maxItems: 1 + '#sound-dai-cells': const: 0
@@ -37,11 +41,16 @@ properties: required: - compatible - reg - - powerdown-gpios - '#sound-dai-cells' - vdd-1p8-supply - vdd-io-supply
+oneOf: + - required: + - powerdown-gpios + - required: + - reset-gpios + unevaluatedProperties: false
examples:
On some boards with multiple WSA8840/WSA8845 speakers, the reset (shutdown) GPIO is shared between two speakers. Use the reset controller framework and its "reset-gpio" driver to handle this case. This allows bring-up and proper handling of all WSA884x speakers on X1E80100-CRD board.
Cc: Bartosz Golaszewski brgl@bgdev.pl Cc: Sean Anderson sean.anderson@seco.com Reviewed-by: Philipp Zabel p.zabel@pengutronix.de Signed-off-by: Krzysztof Kozlowski krzysztof.kozlowski@linaro.org ---
If previous patches are fine, then this commit is independent and could be taken via ASoC. --- sound/soc/codecs/wsa884x.c | 53 +++++++++++++++++++++++++++++++------- 1 file changed, 43 insertions(+), 10 deletions(-)
diff --git a/sound/soc/codecs/wsa884x.c b/sound/soc/codecs/wsa884x.c index f2653df84e4a..a9767ef0e39d 100644 --- a/sound/soc/codecs/wsa884x.c +++ b/sound/soc/codecs/wsa884x.c @@ -13,6 +13,7 @@ #include <linux/pm_runtime.h> #include <linux/regmap.h> #include <linux/regulator/consumer.h> +#include <linux/reset.h> #include <linux/slab.h> #include <linux/soundwire/sdw.h> #include <linux/soundwire/sdw_registers.h> @@ -699,6 +700,7 @@ struct wsa884x_priv { struct sdw_stream_runtime *sruntime; struct sdw_port_config port_config[WSA884X_MAX_SWR_PORTS]; struct gpio_desc *sd_n; + struct reset_control *sd_reset; bool port_prepared[WSA884X_MAX_SWR_PORTS]; bool port_enable[WSA884X_MAX_SWR_PORTS]; unsigned int variant; @@ -1799,9 +1801,22 @@ static struct snd_soc_dai_driver wsa884x_dais[] = { }, };
-static void wsa884x_gpio_powerdown(void *data) +static void wsa884x_reset_powerdown(void *data) { - gpiod_direction_output(data, 1); + struct wsa884x_priv *wsa884x = data; + + if (wsa884x->sd_reset) + reset_control_assert(wsa884x->sd_reset); + else + gpiod_direction_output(wsa884x->sd_n, 1); +} + +static void wsa884x_reset_deassert(struct wsa884x_priv *wsa884x) +{ + if (wsa884x->sd_reset) + reset_control_deassert(wsa884x->sd_reset); + else + gpiod_direction_output(wsa884x->sd_n, 0); }
static void wsa884x_regulator_disable(void *data) @@ -1809,6 +1824,27 @@ static void wsa884x_regulator_disable(void *data) regulator_bulk_disable(WSA884X_SUPPLIES_NUM, data); }
+static int wsa884x_get_reset(struct device *dev, struct wsa884x_priv *wsa884x) +{ + wsa884x->sd_reset = devm_reset_control_get_optional_shared(dev, NULL); + if (IS_ERR(wsa884x->sd_reset)) + return dev_err_probe(dev, PTR_ERR(wsa884x->sd_reset), + "Failed to get reset\n"); + else if (wsa884x->sd_reset) + return 0; + /* + * else: NULL, so use the backwards compatible way for powerdown-gpios, + * which does not handle sharing GPIO properly. + */ + wsa884x->sd_n = devm_gpiod_get_optional(dev, "powerdown", + GPIOD_OUT_HIGH); + if (IS_ERR(wsa884x->sd_n)) + return dev_err_probe(dev, PTR_ERR(wsa884x->sd_n), + "Shutdown Control GPIO not found\n"); + + return 0; +} + static int wsa884x_probe(struct sdw_slave *pdev, const struct sdw_device_id *id) { @@ -1838,11 +1874,9 @@ static int wsa884x_probe(struct sdw_slave *pdev, if (ret) return ret;
- wsa884x->sd_n = devm_gpiod_get_optional(dev, "powerdown", - GPIOD_OUT_HIGH); - if (IS_ERR(wsa884x->sd_n)) - return dev_err_probe(dev, PTR_ERR(wsa884x->sd_n), - "Shutdown Control GPIO not found\n"); + ret = wsa884x_get_reset(dev, wsa884x); + if (ret) + return ret;
dev_set_drvdata(dev, wsa884x); wsa884x->slave = pdev; @@ -1858,9 +1892,8 @@ static int wsa884x_probe(struct sdw_slave *pdev, pdev->prop.sink_dpn_prop = wsa884x_sink_dpn_prop; pdev->prop.scp_int1_mask = SDW_SCP_INT1_BUS_CLASH | SDW_SCP_INT1_PARITY;
- /* Bring out of reset */ - gpiod_direction_output(wsa884x->sd_n, 0); - ret = devm_add_action_or_reset(dev, wsa884x_gpio_powerdown, wsa884x->sd_n); + wsa884x_reset_deassert(wsa884x); + ret = devm_add_action_or_reset(dev, wsa884x_reset_powerdown, wsa884x); if (ret) return ret;
On 29/01/2024 12:52, Krzysztof Kozlowski wrote:
Hi,
Dependencies / Merging
Depends on !GPIOLIB stub: https://lore.kernel.org/all/20240125081601.118051-3-krzysztof.kozlowski@lina...
Patch #2 (cpufreq: do not open-code of_phandle_args_equal()) and patch #4 (reset: Instantiate reset GPIO controller for shared reset-gpios) depend on OF change (patch #1).
Hi Philipp,
I got acks from GPIO folks. The also provided stable tag with dependency: https://lore.kernel.org/all/20240213101000.16700-1-brgl@bgdev.pl/ (which BTW already is in mainline, so you could just merge Linus' tree into your next branch)
Can you take entire patchset?
Best regards, Krzysztof
Hi Krzysztof,
On Mi, 2024-02-21 at 10:44 +0100, Krzysztof Kozlowski wrote:
On 29/01/2024 12:52, Krzysztof Kozlowski wrote:
Hi,
Dependencies / Merging
Depends on !GPIOLIB stub: https://lore.kernel.org/all/20240125081601.118051-3-krzysztof.kozlowski@lina...
Patch #2 (cpufreq: do not open-code of_phandle_args_equal()) and patch #4 (reset: Instantiate reset GPIO controller for shared reset-gpios) depend on OF change (patch #1).
Hi Philipp,
I got acks from GPIO folks. The also provided stable tag with dependency: https://lore.kernel.org/all/20240213101000.16700-1-brgl@bgdev.pl/ (which BTW already is in mainline, so you could just merge Linus' tree into your next branch)
Thanks.
Can you take entire patchset?
I've picked up 1-4. Patches 5-6 can go independently via ASoC, right?
regards Philipp
On 21/02/2024 12:26, Philipp Zabel wrote:
Hi Krzysztof,
On Mi, 2024-02-21 at 10:44 +0100, Krzysztof Kozlowski wrote:
On 29/01/2024 12:52, Krzysztof Kozlowski wrote:
Hi,
Dependencies / Merging
Depends on !GPIOLIB stub: https://lore.kernel.org/all/20240125081601.118051-3-krzysztof.kozlowski@lina...
Patch #2 (cpufreq: do not open-code of_phandle_args_equal()) and patch #4 (reset: Instantiate reset GPIO controller for shared reset-gpios) depend on OF change (patch #1).
Hi Philipp,
I got acks from GPIO folks. The also provided stable tag with dependency: https://lore.kernel.org/all/20240213101000.16700-1-brgl@bgdev.pl/ (which BTW already is in mainline, so you could just merge Linus' tree into your next branch)
Thanks.
Can you take entire patchset?
I've picked up 1-4. Patches 5-6 can go independently via ASoC, right?
Yes, thanks.
Best regards, Krzysztof
On Mon, 29 Jan 2024 12:52:10 +0100, Krzysztof Kozlowski wrote:
Dependencies / Merging
Depends on !GPIOLIB stub: https://lore.kernel.org/all/20240125081601.118051-3-krzysztof.kozlowski@lina...
Patch #2 (cpufreq: do not open-code of_phandle_args_equal()) and patch #4 (reset: Instantiate reset GPIO controller for shared reset-gpios) depend on OF change (patch #1).
[...]
Applied patches 1-4 to reset/next, thanks!
[1/6] of: Add of_phandle_args_equal() helper https://git.pengutronix.de/cgit/pza/linux/commit/?id=26ea8511c849 [2/6] cpufreq: do not open-code of_phandle_args_equal() https://git.pengutronix.de/cgit/pza/linux/commit/?id=0f28982835c2 [3/6] reset: gpio: Add GPIO-based reset controller https://git.pengutronix.de/cgit/pza/linux/commit/?id=cee544a40e44 [4/6] reset: Instantiate reset GPIO controller for shared reset-gpios https://git.pengutronix.de/cgit/pza/linux/commit/?id=c721f189e89c
regards Philipp
On Mon, 29 Jan 2024 12:52:10 +0100, Krzysztof Kozlowski wrote:
Dependencies / Merging
Depends on !GPIOLIB stub: https://lore.kernel.org/all/20240125081601.118051-3-krzysztof.kozlowski@lina...
Patch #2 (cpufreq: do not open-code of_phandle_args_equal()) and patch #4 (reset: Instantiate reset GPIO controller for shared reset-gpios) depend on OF change (patch #1).
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[5/6] ASoC: dt-bindings: qcom,wsa8840: Add reset-gpios for shared line commit: 26c8a435fce6ef8d1dea39cc52b15cf36c7e986b [6/6] ASoC: codecs: wsa884x: Allow sharing reset GPIO commit: 0dae534c48239be0a99092e46e1baade0cf3e04a
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
participants (5)
-
Bartosz Golaszewski -
Krzysztof Kozlowski -
Linus Walleij -
Mark Brown -
Philipp Zabel