Hi,
Dependencies / Merging
======================
1. Depends on !GPIOLIB stub:
https://lore.kernel.org/all/[email protected]/
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/[email protected]/
2. https://lore.kernel.org/all/[email protected]/
3. https://lore.kernel.org/lkml/[email protected]/
4. https://lore.kernel.org/all/[email protected]/
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/[email protected]/
Best regards,
Krzysztof
Cc: Chris Packham <[email protected]>
Cc: Bartosz Golaszewski <[email protected]>
Cc: Sean Anderson <[email protected]>
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
--
2.34.1
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 <[email protected]>
Cc: Sean Anderson <[email protected]>
Acked-by: Rob Herring <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
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:
--
2.34.1
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 <[email protected]>
Cc: Chris Packham <[email protected]>
Cc: Sean Anderson <[email protected]>
Reviewed-by: Bartosz Golaszewski <[email protected]>
Reviewed-by: Philipp Zabel <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
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 <[email protected]>
+S: Maintained
+F: drivers/reset/reset-gpio.c
+
GENERIC HDLC (WAN) DRIVERS
M: Krzysztof Halasa <[email protected]>
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 <[email protected]>");
+MODULE_DESCRIPTION("Generic GPIO reset driver");
+MODULE_LICENSE("GPL");
--
2.34.1
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/[email protected]/ [1]
Cc: Bartosz Golaszewski <[email protected]>
Cc: Chris Packham <[email protected]>
Cc: Sean Anderson <[email protected]>
Reviewed-by: Philipp Zabel <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
Depends on:
1. Previous OF change.
2. !GPIOLIB stub:
https://lore.kernel.org/all/[email protected]/
---
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);
--
2.34.1
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 <[email protected]>
Cc: Sean Anderson <[email protected]>
Reviewed-by: Philipp Zabel <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
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;
--
2.34.1
Add a helper comparing two "struct of_phandle_args" to avoid
reinventing the wheel.
Reviewed-by: Philipp Zabel <[email protected]>
Acked-by: Rob Herring <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
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
*
--
2.34.1
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:
> 2. !GPIOLIB stub:
> https://lore.kernel.org/all/[email protected]/
On Mon, Jan 29, 2024 at 12:53 PM Krzysztof Kozlowski
<[email protected]> 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/[email protected]/ [1]
> Cc: Bartosz Golaszewski <[email protected]>
> Cc: Chris Packham <[email protected]>
> Cc: Sean Anderson <[email protected]>
> Reviewed-by: Philipp Zabel <[email protected]>
> Signed-off-by: Krzysztof Kozlowski <[email protected]>
(...)
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@linaroorg> 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:
> > 2. !GPIOLIB stub:
> > https://lore.kernel.org/all/[email protected]/
>
> On Mon, Jan 29, 2024 at 12:53 PM Krzysztof Kozlowski
> <[email protected]> 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/[email protected]/ [1]
> > Cc: Bartosz Golaszewski <[email protected]>
> > Cc: Chris Packham <[email protected]>
> > Cc: Sean Anderson <[email protected]>
> > Reviewed-by: Philipp Zabel <[email protected]>
> > Signed-off-by: Krzysztof Kozlowski <[email protected]>
> (...)
>
> 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 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:
>> 2. !GPIOLIB stub:
>> https://lore.kernel.org/all/[email protected]/
>
> On Mon, Jan 29, 2024 at 12:53 PM Krzysztof Kozlowski
> <[email protected]> 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/[email protected]/ [1]
>> Cc: Bartosz Golaszewski <[email protected]>
>> Cc: Chris Packham <[email protected]>
>> Cc: Sean Anderson <[email protected]>
>> Reviewed-by: Philipp Zabel <[email protected]>
>> Signed-off-by: Krzysztof Kozlowski <[email protected]>
> (...)
>
> 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/[email protected]/
https://lore.kernel.org/all/[email protected]/
https://lore.kernel.org/all/[email protected]/
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:
>>> 2. !GPIOLIB stub:
>>> https://lore.kernel.org/all/[email protected]/
>>
>> On Mon, Jan 29, 2024 at 12:53 PM Krzysztof Kozlowski
>> <[email protected]> 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/[email protected]/ [1]
>>> Cc: Bartosz Golaszewski <[email protected]>
>>> Cc: Chris Packham <[email protected]>
>>> Cc: Sean Anderson <[email protected]>
>>> Reviewed-by: Philipp Zabel <[email protected]>
>>> Signed-off-by: Krzysztof Kozlowski <[email protected]>
>> (...)
>>
>> 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/[email protected]/
> https://lore.kernel.org/all/[email protected]/
> https://lore.kernel.org/all/[email protected]/
> https://social.treehouse.systems/@marcan/111268780311634160
>
And here:
https://lore.kernel.org/all/CAL_JsqL3oZXJJ5_i4BRGpvWu1X8QFB7OGG=D+zLvvWb=UR1mWg@mail.gmail.com/
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
<[email protected]> 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/[email protected]/
> https://lore.kernel.org/all/[email protected]/
> https://lore.kernel.org/all/[email protected]/
> 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 Wed, Jan 31, 2024 at 02:17:54PM +0100, Linus Walleij wrote:
> On Wed, Jan 31, 2024 at 10:37 AM Bartosz Golaszewski <[email protected]> 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 <[email protected]> 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/[email protected]/
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
<[email protected]> 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 10:37 AM Bartosz Golaszewski <[email protected]> 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: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
<[email protected]> wrote:
>
> On 31/01/2024 14:17, Linus Walleij wrote:
> > On Wed, Jan 31, 2024 at 10:37 AM Bartosz Golaszewski <[email protected]> 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/[email protected]/
>
> 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 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/[email protected]/ [1]
> Cc: Bartosz Golaszewski <[email protected]>
> Cc: Chris Packham <[email protected]>
> Cc: Sean Anderson <[email protected]>
> Reviewed-by: Philipp Zabel <[email protected]>
> Signed-off-by: Krzysztof Kozlowski <[email protected]>
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
<[email protected]> 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/[email protected]/ [1]
> Cc: Bartosz Golaszewski <[email protected]>
> Cc: Chris Packham <[email protected]>
> Cc: Sean Anderson <[email protected]>
> Reviewed-by: Philipp Zabel <[email protected]>
> Signed-off-by: Krzysztof Kozlowski <[email protected]>
Acked-by: Linus Walleij <[email protected]>
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@linaroorg> wrote:
>
> On Mon, Jan 29, 2024 at 12:53 PM Krzysztof Kozlowski
> <[email protected]> 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/[email protected]/ [1]
> > Cc: Bartosz Golaszewski <[email protected]>
> > Cc: Chris Packham <[email protected]>
> > Cc: Sean Anderson <[email protected]>
> > Reviewed-by: Philipp Zabel <[email protected]>
> > Signed-off-by: Krzysztof Kozlowski <[email protected]>
>
> Acked-by: Linus Walleij <[email protected]>
>
> 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 <[email protected]>
I will pick up the stub patches tomorrow and send a tag for Philipp to pull.
Bartosz
On 29/01/2024 12:52, Krzysztof Kozlowski wrote:
> Hi,
>
> Dependencies / Merging
> ======================
> 1. Depends on !GPIOLIB stub:
> https://lore.kernel.org/all/[email protected]/
>
> 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).
Hi Philipp,
I got acks from GPIO folks. The also provided stable tag with dependency:
https://lore.kernel.org/all/[email protected]/
(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
On Mon, 29 Jan 2024 12:52:10 +0100, Krzysztof Kozlowski wrote:
> Dependencies / Merging
> ======================
> 1. Depends on !GPIOLIB stub:
> https://lore.kernel.org/all/[email protected]/
>
> 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).
>
> [...]
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
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
> > ======================
> > 1. Depends on !GPIOLIB stub:
> > https://lore.kernel.org/all/[email protected]/
> >
> > 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).
>
>
> Hi Philipp,
>
> I got acks from GPIO folks. The also provided stable tag with dependency:
> https://lore.kernel.org/all/[email protected]/
> (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
>>> ======================
>>> 1. Depends on !GPIOLIB stub:
>>> https://lore.kernel.org/all/[email protected]/
>>>
>>> 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).
>>
>>
>> Hi Philipp,
>>
>> I got acks from GPIO folks. The also provided stable tag with dependency:
>> https://lore.kernel.org/all/[email protected]/
>> (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
> ======================
> 1. Depends on !GPIOLIB stub:
> https://lore.kernel.org/all/[email protected]/
>
> 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).
>
> [...]
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