On Mon, Jul 19, 2021 at 1:31 AM Sergio Paracuellos
[off-list ref] wrote:

On Mon, Jul 19, 2021 at 9:57 AM Gregory Fong [off-list ref] wrote:

quoted

On Thu, Jul 08, 2021 at 09:04:27AM +0200, Sergio Paracuellos wrote:

[snip]

quoted

quoted

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 27c07108496d..f3f45b804542 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c

@@ -382,11 +382,16 @@ static int devprop_gpiochip_set_names(struct gpio_chip *chip)
      if (count < 0)
              return 0;

-     if (count > gdev->ngpio) {
-             dev_warn(&gdev->dev, "gpio-line-names is length %d but should be at most length %d",
-                      count, gdev->ngpio);
-             count = gdev->ngpio;
-     }
+     /*
+      * When offset is set in the driver side we assume the driver internally
+      * is using more than one gpiochip per the same device. We have to stop
+      * setting friendly names if the specified ones with 'gpio-line-names'
+      * are less than the offset in the device itself. This means all the
+      * lines are not present for every single pin within all the internal
+      * gpiochips.
+      */
+     if (count <= chip->offset)
+             return 0;

This case needs a descriptive warning message.  Silent failure to assign
names here will leave someone confused about what they're doing wrong.

Ok, I will add something like "All line names are not defined for bank
X.". Or any other suggestion would be also ok :).

I'd like this to name the gpio-line-names property like the other
warning does.  Not sure there's a good way to generically determine
what the bank number is, since some driver might not populate at
regular offsets.

We do have the count and offset available, so maybe something like
"gpio-line-names too short (length <count>), cannot map names for the
gpiochip at offset <offset>"?

quoted

quoted

      names = kcalloc(count, sizeof(*names), GFP_KERNEL);
      if (!names)

@@ -400,8 +405,25 @@ static int devprop_gpiochip_set_names(struct gpio_chip *chip)
              return ret;
      }

+     /*
+      * When more that one gpiochip per device is used, 'count' can
+      * contain at most number gpiochips x chip->ngpio. We have to
+      * correctly distribute all defined lines taking into account
+      * chip->offset as starting point from where we will assign
+      * the names to pins from the 'names' array. Since property
+      * 'gpio-line-names' cannot contains gaps, we have to be sure
+      * we only assign those pins that really exists since chip->ngpio
+      * can be different of the chip->offset.
+      */
+     count = (count > chip->offset) ? count - chip->offset : count;
+     if (count > chip->ngpio) {

In the multiple gpiochip case, if there are 3+ gpiochips this seems like
it will yield an invalid warning. For example, if there are 3 gpiochips
(banks 0, 1, and 2), and all gpios are given names in gpio-line-names,
isn't this condition going to always evaluate to true for bank 1,
resulting in an invalid warning?  In that case I would think setting
count to chip->ngpio is the *expected* behavior.

Since that's a "normal" behavior in the multiple gpiochip case, I'm not
sure there's a simple way to detect an over-long gpio-line-names here
in this function anymore.

Yes, in case of multiple chips with all lines names defined this
warning will be displayed but I wanted to maintain the warning for
normal cases and I was not able to find an easy way of distinc that
cases with those having multiple gpiochips internally. So I ended up
in "ok, will be displayed for those special cases and interpreted as
we are just assigning names within an offset along the gpiochips in
the device.". Any other suggestion of course is always welcome :)

There are millions of parts with this gpio hardware in the wild; I'd
much prefer we didn't issue a warning for every chip using it.

If there is a good way to detect the multiple gpiochip case, then that
could be used to determine whether to issue the warning.  Otherwise,
it seems like it would be better to remove the warning altogether.

Best regards,
Gregory