[PATCH V2] gpio: brcmstb: support gpio-line-names property

[PATCH V2] gpio: brcmstb: support gpio-line-names property

[Doug Berger]

The default handling of the gpio-line-names property by the
gpiolib-of implementation does not work with the multiple
gpiochip banks per device structure used by the gpio-brcmstb
driver.

This commit adds driver level support for the device tree
property so that GPIO lines can be assigned friendly names.

Signed-off-by: Doug Berger <opendmb@gmail.com>
---
 drivers/gpio/gpio-brcmstb.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/drivers/gpio/gpio-brcmstb.c b/drivers/gpio/gpio-brcmstb.c
index 05e3f99ae59c..fcfc1a1f1a5c 100644
--- a/drivers/gpio/gpio-brcmstb.c
+++ b/drivers/gpio/gpio-brcmstb.c
@@ -603,6 +603,49 @@ static const struct dev_pm_ops brcmstb_gpio_pm_ops = {
 	.resume_noirq = brcmstb_gpio_resume,
 };
 
+static void brcmstb_gpio_set_names(struct device *dev,
+				   struct brcmstb_gpio_bank *bank)
+{
+	struct device_node *np = dev->of_node;
+	const char **names;
+	int nstrings, base;
+	unsigned int i;
+
+	base = bank->id * MAX_GPIO_PER_BANK;
+
+	nstrings = of_property_count_strings(np, "gpio-line-names");
+	if (nstrings <= base)
+		/* Line names not present */
+		return;
+
+	names = devm_kcalloc(dev, MAX_GPIO_PER_BANK, sizeof(*names),
+			     GFP_KERNEL);
+	if (!names)
+		return;
+
+	/*
+	 * Make sure to not index beyond the end of the number of descriptors
+	 * of the GPIO device.
+	 */
+	for (i = 0; i < bank->width; i++) {
+		const char *name;
+		int ret;
+
+		ret = of_property_read_string_index(np, "gpio-line-names",
+						    base + i, &name);
+		if (ret) {
+			if (ret != -ENODATA)
+				dev_err(dev, "unable to name line %d: %d\n",
+					base + i, ret);
+			break;
+		}
+		if (*name)
+			names[i] = name;
+	}
+
+	bank->gc.names = names;
+}
+
 static int brcmstb_gpio_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -726,6 +769,7 @@ static int brcmstb_gpio_probe(struct platform_device *pdev)
 		need_wakeup_event |= !!__brcmstb_gpio_get_active_irqs(bank);
 		gc->write_reg(reg_base + GIO_MASK(bank->id), 0);
 
+		brcmstb_gpio_set_names(dev, bank);
 		err = gpiochip_add_data(gc, bank);
 		if (err) {
 			dev_err(dev, "Could not add gpiochip for bank %d\n",
-- 
2.7.4

Re: [PATCH V2] gpio: brcmstb: support gpio-line-names property

[Gregory Fong]

On Mon, Mar 9, 2020 at 12:02 PM Doug Berger <opendmb@gmail.com> wrote:
>
> The default handling of the gpio-line-names property by the
> gpiolib-of implementation does not work with the multiple
> gpiochip banks per device structure used by the gpio-brcmstb
> driver.
>
> This commit adds driver level support for the device tree
> property so that GPIO lines can be assigned friendly names.
>
> Signed-off-by: Doug Berger <opendmb@gmail.com>

Acked-by: Gregory Fong <gregory.0xf0@gmail.com>

Re: [PATCH V2] gpio: brcmstb: support gpio-line-names property

[Bartosz Golaszewski]

pon., 9 mar 2020 o 20:02 Doug Berger <opendmb@gmail.com> napisał(a):
>
> The default handling of the gpio-line-names property by the
> gpiolib-of implementation does not work with the multiple
> gpiochip banks per device structure used by the gpio-brcmstb
> driver.
>
> This commit adds driver level support for the device tree
> property so that GPIO lines can be assigned friendly names.
>
> Signed-off-by: Doug Berger <opendmb@gmail.com>
> ---
>  drivers/gpio/gpio-brcmstb.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 44 insertions(+)
>
> diff --git a/drivers/gpio/gpio-brcmstb.c b/drivers/gpio/gpio-brcmstb.c
> index 05e3f99ae59c..fcfc1a1f1a5c 100644
> --- a/drivers/gpio/gpio-brcmstb.c
> +++ b/drivers/gpio/gpio-brcmstb.c
> @@ -603,6 +603,49 @@ static const struct dev_pm_ops brcmstb_gpio_pm_ops = {
>         .resume_noirq = brcmstb_gpio_resume,
>  };
>
> +static void brcmstb_gpio_set_names(struct device *dev,
> +                                  struct brcmstb_gpio_bank *bank)
> +{
> +       struct device_node *np = dev->of_node;
> +       const char **names;
> +       int nstrings, base;
> +       unsigned int i;
> +
> +       base = bank->id * MAX_GPIO_PER_BANK;
> +
> +       nstrings = of_property_count_strings(np, "gpio-line-names");
> +       if (nstrings <= base)
> +               /* Line names not present */
> +               return;
> +
> +       names = devm_kcalloc(dev, MAX_GPIO_PER_BANK, sizeof(*names),
> +                            GFP_KERNEL);
> +       if (!names)
> +               return;
> +
> +       /*
> +        * Make sure to not index beyond the end of the number of descriptors
> +        * of the GPIO device.
> +        */
> +       for (i = 0; i < bank->width; i++) {
> +               const char *name;
> +               int ret;
> +
> +               ret = of_property_read_string_index(np, "gpio-line-names",
> +                                                   base + i, &name);
> +               if (ret) {
> +                       if (ret != -ENODATA)
> +                               dev_err(dev, "unable to name line %d: %d\n",
> +                                       base + i, ret);
> +                       break;
> +               }

This bit is confusing to me. If we can't read the property we break
the loop and leave the remaining line names null but at the same time
it isn't considered a probe failure? Would you mind at least
commenting on this in the code?

Bart

> +               if (*name)
> +                       names[i] = name;
> +       }
> +
> +       bank->gc.names = names;
> +}
> +
>  static int brcmstb_gpio_probe(struct platform_device *pdev)
>  {
>         struct device *dev = &pdev->dev;
> @@ -726,6 +769,7 @@ static int brcmstb_gpio_probe(struct platform_device *pdev)
>                 need_wakeup_event |= !!__brcmstb_gpio_get_active_irqs(bank);
>                 gc->write_reg(reg_base + GIO_MASK(bank->id), 0);
>
> +               brcmstb_gpio_set_names(dev, bank);
>                 err = gpiochip_add_data(gc, bank);
>                 if (err) {
>                         dev_err(dev, "Could not add gpiochip for bank %d\n",
> --
> 2.7.4
>

Re: [PATCH V2] gpio: brcmstb: support gpio-line-names property

[Linus Walleij]

On Mon, Mar 9, 2020 at 8:02 PM Doug Berger <opendmb@gmail.com> wrote:

> The default handling of the gpio-line-names property by the
> gpiolib-of implementation does not work with the multiple
> gpiochip banks per device structure used by the gpio-brcmstb
> driver.
>
> This commit adds driver level support for the device tree
> property so that GPIO lines can be assigned friendly names.
>


> Signed-off-by: Doug Berger <opendmb@gmail.com>
> +static void brcmstb_gpio_set_names(struct device *dev,
> +                                  struct brcmstb_gpio_bank *bank)
> +{
> +       struct device_node *np = dev->of_node;
> +       const char **names;
> +       int nstrings, base;

I don't understand why that thing is named "base".

> +       unsigned int i;
> +
> +       base = bank->id * MAX_GPIO_PER_BANK;

That would be ngpios or something.

But you alread have what you need in bank->gc.ngpio, right?

So why calculate it?

> +       nstrings = of_property_count_strings(np, "gpio-line-names");
> +       if (nstrings <= base)
> +               /* Line names not present */
> +               return;
> +
> +       names = devm_kcalloc(dev, MAX_GPIO_PER_BANK, sizeof(*names),
> +                            GFP_KERNEL);
> +       if (!names)
> +               return;
> +
> +       /*
> +        * Make sure to not index beyond the end of the number of descriptors
> +        * of the GPIO device.
> +        */
> +       for (i = 0; i < bank->width; i++) {
> +               const char *name;
> +               int ret;
> +
> +               ret = of_property_read_string_index(np, "gpio-line-names",
> +                                                   base + i, &name);
> +               if (ret) {
> +                       if (ret != -ENODATA)
> +                               dev_err(dev, "unable to name line %d: %d\n",
> +                                       base + i, ret);
> +                       break;
> +               }
> +               if (*name)
> +                       names[i] = name;
> +       }
> +
> +       bank->gc.names = names;
> +}

Why can't you just make the function
devprop_gpiochip_set_names() public, (line in <linux/gpio/driver.h>)
and convert your np to a fwnode and call that &bank->gc ?

Yours,
Linus Walleij

Re: [PATCH V2] gpio: brcmstb: support gpio-line-names property

[Doug Berger]

Thanks for taking the time to review this.

On 3/11/20 8:32 AM, Linus Walleij wrote:
> On Mon, Mar 9, 2020 at 8:02 PM Doug Berger <opendmb@gmail.com> wrote:
> 
>> The default handling of the gpio-line-names property by the
>> gpiolib-of implementation does not work with the multiple
>> gpiochip banks per device structure used by the gpio-brcmstb
>> driver.
To expand on this description, the crux of the issue is that the
gpio-brcmstb hardware has some nicely banked registers and some
not-so-nicely-banked common registers.

This lead to the decision to implement the driver to manage multiple
banks as a single GPIO device with a single device-tree node rather than
separate devices for each bank each with its own device-tree node.

In addition, most implementations include a hardware block within an
"Always On" power island and a second block that can be powered down.
Each of these blocks is represented as a separate device with their own
device-tree node and are managed by this driver.

The gpio_chip abstraction in the gpiolib provides a lot of useful
functionality for managing the banks of GPIO for the gpio-brcmstb
driver, but unfortunately it breaks down in a couple of places because
of the common device tree node that is shared by each bank.

One area is the IRQ chip helpers which were tried but needed to be reverted.

Another is labeling, which this commit attempts to address. The
device-tree node for each device can optionally contain a single
gpio-line-names property with a list of names to be applied to the GPIO
managed by the driver.

>>
>> This commit adds driver level support for the device tree
>> property so that GPIO lines can be assigned friendly names.
>>
> 
> 
>> Signed-off-by: Doug Berger <opendmb@gmail.com>
>> +static void brcmstb_gpio_set_names(struct device *dev,
>> +                                  struct brcmstb_gpio_bank *bank)
>> +{
>> +       struct device_node *np = dev->of_node;
>> +       const char **names;
>> +       int nstrings, base;
> 
> I don't understand why that thing is named "base".Since this function is applied to each bank, it is necessary to know
what the device relative index is for the first GPIO contained within
this bank. That is the purpose of this base variable. It is used to
index the device relative list of gpio labels.

GPIO0 of bank 0 would have a base of 0. GPIO0 of bank 1 would have a
base of MAX_GPIO_PER_BANK, and so on.

>> +       unsigned int i;
>> +
>> +       base = bank->id * MAX_GPIO_PER_BANK;
> 
> That would be ngpios or something.
> 
> But you alread have what you need in bank->gc.ngpio, right?
> 
> So why calculate it?
Almost. ngpios is the number of gpios in the bank which in this case is
always MAX_GPIO_PER_BANK.

bank->gc.base is almost the right value, but it is relative to the GPIO
subsystem which can include multiple devices rather than the specific
device that contains this bank.

bank->id is device relative so bank->id * MAX_GPIO_PER_BANK gives us the
desired device relative offset.

>> +       nstrings = of_property_count_strings(np, "gpio-line-names");
>> +       if (nstrings <= base)
>> +               /* Line names not present */
>> +               return;
>> +
>> +       names = devm_kcalloc(dev, MAX_GPIO_PER_BANK, sizeof(*names),
>> +                            GFP_KERNEL);
>> +       if (!names)
>> +               return;
>> +
>> +       /*
>> +        * Make sure to not index beyond the end of the number of descriptors
>> +        * of the GPIO device.
>> +        */
>> +       for (i = 0; i < bank->width; i++) {
>> +               const char *name;
>> +               int ret;
>> +
>> +               ret = of_property_read_string_index(np, "gpio-line-names",
>> +                                                   base + i, &name);
>> +               if (ret) {
>> +                       if (ret != -ENODATA)
>> +                               dev_err(dev, "unable to name line %d: %d\n",
>> +                                       base + i, ret);
>> +                       break;
>> +               }
>> +               if (*name)
>> +                       names[i] = name;
>> +       }
>> +
>> +       bank->gc.names = names;
>> +}
> 
> Why can't you just make the function
> devprop_gpiochip_set_names() public, (line in <linux/gpio/driver.h>)
> and convert your np to a fwnode and call that &bank->gc ?
This is basically the current functionality as provided by the call to
gpiochip_add_data() in probe that this commit attempts to correct.

Since the fwnode is the same for all banks of the same device each bank
repeats the first MAX_GPIO_PER_BANK label names in each bank.

This commit populates the gc.names member of each bank from the
device-tree node within the driver. This overrides the default behavior
since devprop_gpiochip_set_names() will only be called if names is NULL.

> 
> Yours,
> Linus Walleij
> 

I hope that explanation makes sense.

Thanks again,
    Doug

Re: [PATCH V2] gpio: brcmstb: support gpio-line-names property

[Doug Berger]

On 3/11/20 5:44 AM, Bartosz Golaszewski wrote:
> pon., 9 mar 2020 o 20:02 Doug Berger <opendmb@gmail.com> napisał(a):
>>
>> The default handling of the gpio-line-names property by the
>> gpiolib-of implementation does not work with the multiple
>> gpiochip banks per device structure used by the gpio-brcmstb
>> driver.
>>
>> This commit adds driver level support for the device tree
>> property so that GPIO lines can be assigned friendly names.
>>
>> Signed-off-by: Doug Berger <opendmb@gmail.com>
>> ---
>>  drivers/gpio/gpio-brcmstb.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 44 insertions(+)
>>
>> diff --git a/drivers/gpio/gpio-brcmstb.c b/drivers/gpio/gpio-brcmstb.c
>> index 05e3f99ae59c..fcfc1a1f1a5c 100644
>> --- a/drivers/gpio/gpio-brcmstb.c
>> +++ b/drivers/gpio/gpio-brcmstb.c
>> @@ -603,6 +603,49 @@ static const struct dev_pm_ops brcmstb_gpio_pm_ops = {
>>         .resume_noirq = brcmstb_gpio_resume,
>>  };
>>
>> +static void brcmstb_gpio_set_names(struct device *dev,
>> +                                  struct brcmstb_gpio_bank *bank)
>> +{
>> +       struct device_node *np = dev->of_node;
>> +       const char **names;
>> +       int nstrings, base;
>> +       unsigned int i;
>> +
>> +       base = bank->id * MAX_GPIO_PER_BANK;
>> +
>> +       nstrings = of_property_count_strings(np, "gpio-line-names");
>> +       if (nstrings <= base)
>> +               /* Line names not present */
>> +               return;
>> +
>> +       names = devm_kcalloc(dev, MAX_GPIO_PER_BANK, sizeof(*names),
>> +                            GFP_KERNEL);
>> +       if (!names)
>> +               return;
>> +
>> +       /*
>> +        * Make sure to not index beyond the end of the number of descriptors
>> +        * of the GPIO device.
>> +        */
>> +       for (i = 0; i < bank->width; i++) {
>> +               const char *name;
>> +               int ret;
>> +
>> +               ret = of_property_read_string_index(np, "gpio-line-names",
>> +                                                   base + i, &name);
>> +               if (ret) {
>> +                       if (ret != -ENODATA)
>> +                               dev_err(dev, "unable to name line %d: %d\n",
>> +                                       base + i, ret);
>> +                       break;
>> +               }
> 
> This bit is confusing to me. If we can't read the property we break
> the loop and leave the remaining line names null but at the same time
> it isn't considered a probe failure? Would you mind at least
> commenting on this in the code?
> 
> Bart
> 
The label names are viewed as a convenience for the user and are not
necessary for the proper functionality of the driver and device, so we
don't want to prevent the driver from succeeding at probe due to an
error in the gpio-line-names property. The bank->gc.names member is
still made non-NULL which is what we really care about to prevent the
misapplication of label names by devprop_gpiochip_set_names().

In fact, it is expected that the device-tree will only include label
strings up to the last GPIO of interest so the ENODATA error is
considered a valid result to terminate any further labeling so there is
no need for an error message in that case.

Other error results are unexpected so an error message indicating the
consequence of the error is appropriate here.

I'm not sure which aspect is confusing to you, so it's not clear to me
how best to comment the code. I can hazard a guess, but if you have a
suggestion I'm happy to submit a v3.

Thanks for taking the time to review this,
    Doug

Re: [PATCH V2] gpio: brcmstb: support gpio-line-names property

[Florian Fainelli]

On 3/9/20 12:02 PM, Doug Berger wrote:
> The default handling of the gpio-line-names property by the
> gpiolib-of implementation does not work with the multiple
> gpiochip banks per device structure used by the gpio-brcmstb
> driver.
> 
> This commit adds driver level support for the device tree
> property so that GPIO lines can be assigned friendly names.
> 
> Signed-off-by: Doug Berger <opendmb@gmail.com>

Acked-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian

Re: [PATCH V2] gpio: brcmstb: support gpio-line-names property

[Bartosz Golaszewski]

śr., 11 mar 2020 o 20:03 Doug Berger <opendmb@gmail.com> napisał(a):
>
> The label names are viewed as a convenience for the user and are not
> necessary for the proper functionality of the driver and device, so we
> don't want to prevent the driver from succeeding at probe due to an
> error in the gpio-line-names property. The bank->gc.names member is
> still made non-NULL which is what we really care about to prevent the
> misapplication of label names by devprop_gpiochip_set_names().
>
> In fact, it is expected that the device-tree will only include label
> strings up to the last GPIO of interest so the ENODATA error is
> considered a valid result to terminate any further labeling so there is
> no need for an error message in that case.
>
> Other error results are unexpected so an error message indicating the
> consequence of the error is appropriate here.
>
> I'm not sure which aspect is confusing to you, so it's not clear to me
> how best to comment the code. I can hazard a guess, but if you have a
> suggestion I'm happy to submit a v3.
>
> Thanks for taking the time to review this,
>     Doug

No it's fine, thank you for the explanation.

Bartosz

Re: [PATCH V2] gpio: brcmstb: support gpio-line-names property

[Linus Walleij]

On Mon, Mar 9, 2020 at 8:02 PM Doug Berger <opendmb@gmail.com> wrote:

> The default handling of the gpio-line-names property by the
> gpiolib-of implementation does not work with the multiple
> gpiochip banks per device structure used by the gpio-brcmstb
> driver.
>
> This commit adds driver level support for the device tree
> property so that GPIO lines can be assigned friendly names.
>
> Signed-off-by: Doug Berger <opendmb@gmail.com>

Patch applied with the ACKs!

Yours,
Linus Walleij