[1/4] reset: instantiate reset GPIO controller for shared reset-gpios

Devices sharing a reset GPIO could use the reset framework for
coordinated handling of that shared GPIO line.  We have several cases of
such needs, at least for Devicetree-based platforms.

If Devicetree-based device requests a reset line 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(-)

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
>