| Message ID | 20231222150133.732662-1-krzysztof.kozlowski@linaro.org |
|---|---|
| Headers | show |
| Series | reset: gpio: ASoC: shared GPIO resets | expand |
On 22/12/2023 16:01, Krzysztof Kozlowski wrote: > Add 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. ... > + > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); > + if (!priv) > + return -ENOMEM; > + > + platform_set_drvdata(pdev, &priv->rc); > + device_set_node(dev, of_fwnode_handle(*platdata)); > + > + /* > + * Need to get non-exclusive because it is used in reset core as cookie > + * to find existing controllers. However the actual use is exclusive. > + */ This comment is a left-over of my work-in-progress and it is not accurate anymore. Exclusive GPIOs are not used, which should make Bartosz happy! I will remove it in v2. Best regards, Krzysztof
On 22/12/2023 16:01, Krzysztof Kozlowski wrote: > @@ -37,11 +41,14 @@ properties: > required: > - compatible > - reg > - - powerdown-gpios > - '#sound-dai-cells' > - vdd-1p8-supply > - vdd-io-supply > > +oneOf: > + - powerdown-gpios > + - reset-gpios And this obviously was not tested, so Krzysztof: It does not look like you tested the bindings, at least after quick look. Please run `make dt_binding_check` (see Documentation/devicetree/bindings/writing-schema.rst for instructions). Maybe you need to update your dtschema and yamllint. Best regards, Krzysztof
On Fri, Dec 22, 2023 at 4:01 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 which is missing but > there is a reset-gpios property, 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]. > > The "reset-gpio" driver follows shortly. > > Link: https://lore.kernel.org/all/YXi5CUCEi7YmNxXM@robh.at.kernel.org/ > Cc: Bartosz Golaszewski <brgl@bgdev.pl> > Cc: Sean Anderson <sean.anderson@seco.com> > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > --- > drivers/reset/core.c | 70 +++++++++++++++++++++++++++----- > include/linux/reset-controller.h | 2 + > 2 files changed, 61 insertions(+), 11 deletions(-) > > diff --git a/drivers/reset/core.c b/drivers/reset/core.c > index 4d5a78d3c085..a1f0f515a7e0 100644 > --- a/drivers/reset/core.c > +++ b/drivers/reset/core.c > @@ -10,9 +10,12 @@ > #include <linux/export.h> > #include <linux/kernel.h> > #include <linux/kref.h> > +#include <linux/gpio/consumer.h> > #include <linux/module.h> > #include <linux/of.h> > +#include <linux/of_gpio.h> > #include <linux/acpi.h> > +#include <linux/platform_device.h> > #include <linux/reset.h> > #include <linux/reset-controller.h> > #include <linux/slab.h> > @@ -813,13 +816,59 @@ static void __reset_control_put_internal(struct reset_control *rstc) > kref_put(&rstc->refcnt, __reset_control_release); > } > > +static int __reset_add_reset_gpio_device(struct device_node *node, > + const struct gpio_desc **out) > +{ > + struct platform_device *pdev; > + int gpio; > + > + /* Don't care about deprecated '-gpio' suffix. */ > + gpio = of_get_named_gpio(node, "reset-gpios", 0); Sorry but NAK. This is a legacy API, we've managed to remove all of_ GPIO interfaces but this one. Please don't use it. Any function that deals with the global GPIO numberspace is deprecated. See below how I would approach it. Side note: do we have any formal way of deprecating interfaces in the kernel? > + if (!gpio_is_valid(gpio)) > + return gpio; > + > + pdev = platform_device_register_data(NULL, "reset-gpio", > + PLATFORM_DEVID_AUTO, &node, > + sizeof(node)); You seem to make an assumption (in __reset_find_rcdev()) that this device will get bound to its driver before this function returns. There is no such guarantee. There are many situations where this may not happen immediately (think loading the reset-gpio driver as a module from the filesystem). You should set up a notifier callback on the platform bus that will get invoked on bus events and wait for this device's BUS_NOTIFY_BOUND_DRIVER event. > + if (!IS_ERR(pdev)) > + *out = gpio_to_desc(gpio); > + > + return PTR_ERR_OR_ZERO(pdev); > +} > + > +static struct reset_controller_dev *__reset_find_rcdev(const struct of_phandle_args *args, > + const void *cookie) > +{ > + struct reset_controller_dev *r, *rcdev; > + > + lockdep_assert_held(&reset_list_mutex); > + > + rcdev = NULL; > + list_for_each_entry(r, &reset_controller_list, list) { > + if (args && args->np) { > + if (args->np == r->of_node) { > + rcdev = r; > + break; > + } > + } else if (cookie) { > + if (cookie == r->cookie) { As I said in private: there's no guarantee that the same GPIO descriptor will always reference the same GPIO line. It happens to be the case currently but it's an implementation detail. > + rcdev = r; > + break; > + } > + } > + } > + > + return rcdev; > +} > + > struct reset_control * > __of_reset_control_get(struct device_node *node, const char *id, int index, > bool shared, bool optional, bool acquired) > { > + const struct gpio_desc *gpio = NULL; > + struct of_phandle_args args = {0}; > struct reset_control *rstc; > - struct reset_controller_dev *r, *rcdev; > - struct of_phandle_args args; > + struct reset_controller_dev *rcdev; > int rstc_id; > int ret; > > @@ -839,17 +888,16 @@ __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) { > + ret = __reset_add_reset_gpio_device(node, &gpio); > + if (ret) > + return optional ? NULL : ERR_PTR(ret); > + > + args.args_count = 1; /* reset-gpio has only one reset line */ > + } > > 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; > - } > - } > + rcdev = __reset_find_rcdev(&args, gpio); > > if (!rcdev) { > rstc = ERR_PTR(-EPROBE_DEFER); > diff --git a/include/linux/reset-controller.h b/include/linux/reset-controller.h > index 0fa4f60e1186..c0a99a8ea29e 100644 > --- a/include/linux/reset-controller.h > +++ b/include/linux/reset-controller.h > @@ -61,6 +61,7 @@ struct reset_control_lookup { > * @dev: corresponding driver model device struct > * @of_node: corresponding device tree node as phandle target > * @of_reset_n_cells: number of cells in reset line specifiers > + * @cookie: for reset-gpios controllers: corresponding GPIO instead of of_node > * @of_xlate: translation function to translate from specifier as found in the > * device tree to id as given to the reset control ops, defaults > * to :c:func:`of_reset_simple_xlate`. > @@ -74,6 +75,7 @@ struct reset_controller_dev { > struct device *dev; > struct device_node *of_node; > int of_reset_n_cells; > + const void *cookie; > int (*of_xlate)(struct reset_controller_dev *rcdev, > const struct of_phandle_args *reset_spec); > unsigned int nr_resets; > -- > 2.34.1 > I dislike this approach entirely. Here's what I would do: In the reset core: parse the phandle of the reset-gpios property. Use the resulting node with gpio_device_find_by_fwnode(). If the device is not up yet, defer probe. You'll now have the GPIO device object. Retrieve its label using gpio_device_get_label(). Now you should have everything you need (the offset and flags of the GPIO you'll get from __of_parse_phandle_with_args()) to set up the lookup tables. See include/linux/gpio/machine.h. An example of that would be in: bcm2835_spi_setup() in drivers/spi/spi-bcm2835.c. Then with a lookup table in place, you instantiate your device and it'll get its GPIO as it should. This is not ideal but much better than the above. Bartosz
On 22/12/2023 18:31, Bartosz Golaszewski wrote: >> >> +static int __reset_add_reset_gpio_device(struct device_node *node, >> + const struct gpio_desc **out) >> +{ >> + struct platform_device *pdev; >> + int gpio; >> + >> + /* Don't care about deprecated '-gpio' suffix. */ >> + gpio = of_get_named_gpio(node, "reset-gpios", 0); > > Sorry but NAK. This is a legacy API, we've managed to remove all of_ No worries, I expected problems with this patchset. I should have title it RFC. > GPIO interfaces but this one. Please don't use it. Any function that > deals with the global GPIO numberspace is deprecated. See below how I > would approach it. > > Side note: do we have any formal way of deprecating interfaces in the kernel? "DEPRECATED" message in kerneldoc would be enough for me. This could be later used by tooling like checkpatch/sparse/toolchains. > >> + if (!gpio_is_valid(gpio)) >> + return gpio; >> + >> + pdev = platform_device_register_data(NULL, "reset-gpio", >> + PLATFORM_DEVID_AUTO, &node, >> + sizeof(node)); > > You seem to make an assumption (in __reset_find_rcdev()) that this > device will get bound to its driver before this function returns. > There is no such guarantee. There are many situations where this may > not happen immediately (think loading the reset-gpio driver as a > module from the filesystem). You should set up a notifier callback on Yeah, this code is poor. In the case you mentioned, requesting a reset line would spawn multiple platform devices of which none would bind. > the platform bus that will get invoked on bus events and wait for this > device's BUS_NOTIFY_BOUND_DRIVER event. Hm, good point. Thanks. > >> + if (!IS_ERR(pdev)) >> + *out = gpio_to_desc(gpio); >> + >> + return PTR_ERR_OR_ZERO(pdev); >> +} >> + >> +static struct reset_controller_dev *__reset_find_rcdev(const struct of_phandle_args *args, >> + const void *cookie) >> +{ >> + struct reset_controller_dev *r, *rcdev; >> + >> + lockdep_assert_held(&reset_list_mutex); >> + >> + rcdev = NULL; >> + list_for_each_entry(r, &reset_controller_list, list) { >> + if (args && args->np) { >> + if (args->np == r->of_node) { >> + rcdev = r; >> + break; >> + } >> + } else if (cookie) { >> + if (cookie == r->cookie) { > > As I said in private: there's no guarantee that the same GPIO > descriptor will always reference the same GPIO line. It happens to be > the case currently but it's an implementation detail. I guess you commented on this further, so I will reply there. > >> + rcdev = r; >> + break; >> + } >> + } >> + } >> + >> + return rcdev; >> +} >> + >> struct reset_control * >> __of_reset_control_get(struct device_node *node, const char *id, int index, >> bool shared, bool optional, bool acquired) >> { >> + const struct gpio_desc *gpio = NULL; >> + struct of_phandle_args args = {0}; >> struct reset_control *rstc; >> - struct reset_controller_dev *r, *rcdev; >> - struct of_phandle_args args; >> + struct reset_controller_dev *rcdev; >> int rstc_id; >> int ret; >> >> @@ -839,17 +888,16 @@ __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) { >> + ret = __reset_add_reset_gpio_device(node, &gpio); >> + if (ret) >> + return optional ? NULL : ERR_PTR(ret); >> + >> + args.args_count = 1; /* reset-gpio has only one reset line */ >> + } >> >> 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; >> - } >> - } >> + rcdev = __reset_find_rcdev(&args, gpio); >> >> if (!rcdev) { >> rstc = ERR_PTR(-EPROBE_DEFER); >> diff --git a/include/linux/reset-controller.h b/include/linux/reset-controller.h >> index 0fa4f60e1186..c0a99a8ea29e 100644 >> --- a/include/linux/reset-controller.h >> +++ b/include/linux/reset-controller.h >> @@ -61,6 +61,7 @@ struct reset_control_lookup { >> * @dev: corresponding driver model device struct >> * @of_node: corresponding device tree node as phandle target >> * @of_reset_n_cells: number of cells in reset line specifiers >> + * @cookie: for reset-gpios controllers: corresponding GPIO instead of of_node >> * @of_xlate: translation function to translate from specifier as found in the >> * device tree to id as given to the reset control ops, defaults >> * to :c:func:`of_reset_simple_xlate`. >> @@ -74,6 +75,7 @@ struct reset_controller_dev { >> struct device *dev; >> struct device_node *of_node; >> int of_reset_n_cells; >> + const void *cookie; >> int (*of_xlate)(struct reset_controller_dev *rcdev, >> const struct of_phandle_args *reset_spec); >> unsigned int nr_resets; >> -- >> 2.34.1 >> > > I dislike this approach entirely. Here's what I would do: > > In the reset core: parse the phandle of the reset-gpios property. Use > the resulting node with gpio_device_find_by_fwnode(). If the device is > not up yet, defer probe. You'll now have the GPIO device object. > Retrieve its label using gpio_device_get_label(). Now you should have > everything you need (the offset and flags of the GPIO you'll get from > __of_parse_phandle_with_args()) to set up the lookup tables. See I don't get exactly what do you want to use as the cookie for lookup reset controller? 1. GPIO controller node? No way, not enough 2. GPIO label? 3. Or some combination of above? This would work, I guess, a bit more complicated cookie than just one pointer/unsigned long. > include/linux/gpio/machine.h. An example of that would be in: > bcm2835_spi_setup() in drivers/spi/spi-bcm2835.c. > > Then with a lookup table in place, you instantiate your device and > it'll get its GPIO as it should. This is not ideal but much better > than the above. Best regards, Krzysztof
On Wed, Dec 27, 2023 at 1:35 PM Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > [snip] > > > > I dislike this approach entirely. Here's what I would do: > > > > In the reset core: parse the phandle of the reset-gpios property. Use > > the resulting node with gpio_device_find_by_fwnode(). If the device is > > not up yet, defer probe. You'll now have the GPIO device object. > > Retrieve its label using gpio_device_get_label(). Now you should have > > everything you need (the offset and flags of the GPIO you'll get from > > __of_parse_phandle_with_args()) to set up the lookup tables. See > > I don't get exactly what do you want to use as the cookie for lookup > reset controller? I'm not sure what you refer to as "cookie". :( > 1. GPIO controller node? No way, not enough > 2. GPIO label? > 3. Or some combination of above? This would work, I guess, a bit more > complicated cookie than just one pointer/unsigned long. > For a GPIO lookup you need: 1. The name of the target device (in your case "reset-gpio.X", you can either keep track of device IDs yourself or live with the fact that you may have one deferred probe between when the device is registered and bound and when you are able to read its final name for the lookup). 2. The label of the GPIO chip (whatever gpio_device_get_label() returns). 3. The hardware offset of the pin (which you can get by parsing the phandle). You may need additional lookup flags but the above allows you to correctly assign a GPIO to a device. No need for cookies. Bart > > include/linux/gpio/machine.h. An example of that would be in: > > bcm2835_spi_setup() in drivers/spi/spi-bcm2835.c. > > > > Then with a lookup table in place, you instantiate your device and > > it'll get its GPIO as it should. This is not ideal but much better > > than the above. > > > Best regards, > Krzysztof >