gpiolib: Allow name duplicates of "" and "NC"

Message ID 20201215170308.2037624-1-bjorn.andersson@linaro.org
State New
Headers show
Series
  • gpiolib: Allow name duplicates of "" and "NC"
Related show

Commit Message

Bjorn Andersson Dec. 15, 2020, 5:03 p.m.
Not all GPIO pins are exposed to the world and this is typically
described by not giving these lines particular names, commonly "" or
"NC".

With the recent introduction of '2cd64ae98f35 ("gpiolib: Disallow
identical line names in the same chip")' any gpiochip with multiple such
pins will refuse to probe.

Fix this by treating "" and "NC" as "no name specified" in
gpio_name_to_desc()

Fixes: 2cd64ae98f35 ("gpiolib: Disallow identical line names in the same chip")
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

The introduction of 2cd64ae98f35 breaks pretty much all Qualcomm boards and
grepping the DT tree indicates that other vendors will have the same problem.

In addition to this the am335x-* boards will also needs "[NC]", "[ethernet]",
"[emmc"], "[i2c0]", "[SYSBOOT]" and "[JTAG]" added to this list to allow
booting v5.11 with the past and present dtb/dts files.

 drivers/gpio/gpiolib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Bartosz Golaszewski Dec. 15, 2020, 5:42 p.m. | #1
On Tue, Dec 15, 2020 at 6:02 PM Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> Not all GPIO pins are exposed to the world and this is typically
> described by not giving these lines particular names, commonly "" or
> "NC".
>
> With the recent introduction of '2cd64ae98f35 ("gpiolib: Disallow
> identical line names in the same chip")' any gpiochip with multiple such
> pins will refuse to probe.
>
> Fix this by treating "" and "NC" as "no name specified" in
> gpio_name_to_desc()
>
> Fixes: 2cd64ae98f35 ("gpiolib: Disallow identical line names in the same chip")
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>
> The introduction of 2cd64ae98f35 breaks pretty much all Qualcomm boards and
> grepping the DT tree indicates that other vendors will have the same problem.
>
> In addition to this the am335x-* boards will also needs "[NC]", "[ethernet]",
> "[emmc"], "[i2c0]", "[SYSBOOT]" and "[JTAG]" added to this list to allow
> booting v5.11 with the past and present dtb/dts files.
>
>  drivers/gpio/gpiolib.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index b3340ba68471..407ba79ae571 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -302,7 +302,7 @@ static struct gpio_desc *gpio_name_to_desc(const char * const name)
>         struct gpio_device *gdev;
>         unsigned long flags;
>
> -       if (!name)
> +       if (!name || !strcmp(name, "") || !strcmp(name, "NC"))
>                 return NULL;
>
>         spin_lock_irqsave(&gpio_lock, flags);
> --
> 2.29.2
>

I have a bad feeling about this. This opens the door for all kinds of
exceptions: "N/A", "none" etc. Depending on whose boards are getting
broken.

If non-uniqueness of names is needed then let's better revert 2cd64ae98f35.

Bartosz
Linus Walleij Dec. 16, 2020, 12:46 p.m. | #2
On Tue, Dec 15, 2020 at 6:02 PM Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:

> Not all GPIO pins are exposed to the world and this is typically

> described by not giving these lines particular names, commonly "" or

> "NC".

>

> With the recent introduction of '2cd64ae98f35 ("gpiolib: Disallow

> identical line names in the same chip")' any gpiochip with multiple such

> pins will refuse to probe.

>

> Fix this by treating "" and "NC" as "no name specified" in

> gpio_name_to_desc()

>

> Fixes: 2cd64ae98f35 ("gpiolib: Disallow identical line names in the same chip")

> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

> ---

>

> The introduction of 2cd64ae98f35 breaks pretty much all Qualcomm boards and

> grepping the DT tree indicates that other vendors will have the same problem.

>

> In addition to this the am335x-* boards will also needs "[NC]", "[ethernet]",

> "[emmc"], "[i2c0]", "[SYSBOOT]" and "[JTAG]" added to this list to allow

> booting v5.11 with the past and present dtb/dts files.


I pushed this patch yesterday that fixes the obvious "(empty string)" problem:
https://lore.kernel.org/linux-gpio/20201215123755.438369-1-linus.walleij@linaro.org/T/#u

But I see this is for device tree line naming only, right?

I think I will conjure a patch allowing identical naming only for
device property naming (like from device tree) but emitting a
warning so that people fix it to something unique moving
forward.

Yours,
Linus Walleij
Bjorn Andersson Dec. 16, 2020, 6:40 p.m. | #3
On Wed 16 Dec 06:46 CST 2020, Linus Walleij wrote:

> On Tue, Dec 15, 2020 at 6:02 PM Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
> 
> > Not all GPIO pins are exposed to the world and this is typically
> > described by not giving these lines particular names, commonly "" or
> > "NC".
> >
> > With the recent introduction of '2cd64ae98f35 ("gpiolib: Disallow
> > identical line names in the same chip")' any gpiochip with multiple such
> > pins will refuse to probe.
> >
> > Fix this by treating "" and "NC" as "no name specified" in
> > gpio_name_to_desc()
> >
> > Fixes: 2cd64ae98f35 ("gpiolib: Disallow identical line names in the same chip")
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > ---
> >
> > The introduction of 2cd64ae98f35 breaks pretty much all Qualcomm boards and
> > grepping the DT tree indicates that other vendors will have the same problem.
> >
> > In addition to this the am335x-* boards will also needs "[NC]", "[ethernet]",
> > "[emmc"], "[i2c0]", "[SYSBOOT]" and "[JTAG]" added to this list to allow
> > booting v5.11 with the past and present dtb/dts files.
> 
> I pushed this patch yesterday that fixes the obvious "(empty string)" problem:
> https://lore.kernel.org/linux-gpio/20201215123755.438369-1-linus.walleij@linaro.org/T/#u
> 

Unfortunately we've almost consistently used "NC" for the Qualcomm
platforms, so that seems to fix only a single platform :(

> But I see this is for device tree line naming only, right?
> 

Yes.

> I think I will conjure a patch allowing identical naming only for
> device property naming (like from device tree) but emitting a
> warning so that people fix it to something unique moving
> forward.
> 

I'm not against emitting a dev_err() when we hit duplicates, remove the
return and then update the various dts files to use "" for things that
doesn't have a name.

Regarding special handling of the DT case, I think (beyond making all
these boards boot again) it would be nice to make
gpiochip_set_desc_names() take the list of names and a length and use
the same function in both code paths...


PS. strlen(names[i]) is O(N), strcmp(names[i], "") is O(1).

Regards,
Bjorn
Drew Fustini Dec. 16, 2020, 7:53 p.m. | #4
On Tue, Dec 15, 2020 at 09:03:08AM -0800, Bjorn Andersson wrote:
> Not all GPIO pins are exposed to the world and this is typically
> described by not giving these lines particular names, commonly "" or
> "NC".
> 
> With the recent introduction of '2cd64ae98f35 ("gpiolib: Disallow
> identical line names in the same chip")' any gpiochip with multiple such
> pins will refuse to probe.
> 
> Fix this by treating "" and "NC" as "no name specified" in
> gpio_name_to_desc()
> 
> Fixes: 2cd64ae98f35 ("gpiolib: Disallow identical line names in the same chip")
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> 
> The introduction of 2cd64ae98f35 breaks pretty much all Qualcomm boards and
> grepping the DT tree indicates that other vendors will have the same problem.
> 
> In addition to this the am335x-* boards will also needs "[NC]", "[ethernet]",
> "[emmc"], "[i2c0]", "[SYSBOOT]" and "[JTAG]" added to this list to allow
> booting v5.11 with the past and present dtb/dts files.

I am the one who added the gpio line names to the am335x dts board
files, and I am happy to change them if it will make unique line name
logic simpler.

I used the notation of "[<non-gpio-functionality>]" to make it easy for
the user to realize that the corresponding gpiolines could not be used
on these boards (BeagleBone and PocketBeagle) for actual GPIO.  I used
generic names like "[ethernet]" because I didn't think it made sense
to confuse the user by using the precise name of the non-gpio function
(such as "[gmii1_rxd0]").  I could post a patch for the dts files that
restores unique names for "[ethernet]", "[emmc"], "[i2c0]",
"[SYSBOOT]" and "[JTAG]".

As for "[NC]", the BGA balls corresponding to these gpio lines are
simply not connected to any circuits on the board.  I happy to change
that to whatever name people prefer for a non-connected pin ("", "NC",
etc).

Thanks,
Drew
Bjorn Andersson Dec. 16, 2020, 8:38 p.m. | #5
On Wed 16 Dec 13:53 CST 2020, Drew Fustini wrote:

> On Tue, Dec 15, 2020 at 09:03:08AM -0800, Bjorn Andersson wrote:
> > Not all GPIO pins are exposed to the world and this is typically
> > described by not giving these lines particular names, commonly "" or
> > "NC".
> > 
> > With the recent introduction of '2cd64ae98f35 ("gpiolib: Disallow
> > identical line names in the same chip")' any gpiochip with multiple such
> > pins will refuse to probe.
> > 
> > Fix this by treating "" and "NC" as "no name specified" in
> > gpio_name_to_desc()
> > 
> > Fixes: 2cd64ae98f35 ("gpiolib: Disallow identical line names in the same chip")
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > ---
> > 
> > The introduction of 2cd64ae98f35 breaks pretty much all Qualcomm boards and
> > grepping the DT tree indicates that other vendors will have the same problem.
> > 
> > In addition to this the am335x-* boards will also needs "[NC]", "[ethernet]",
> > "[emmc"], "[i2c0]", "[SYSBOOT]" and "[JTAG]" added to this list to allow
> > booting v5.11 with the past and present dtb/dts files.
> 
> I am the one who added the gpio line names to the am335x dts board
> files, and I am happy to change them if it will make unique line name
> logic simpler.
> 
> I used the notation of "[<non-gpio-functionality>]" to make it easy for
> the user to realize that the corresponding gpiolines could not be used
> on these boards (BeagleBone and PocketBeagle) for actual GPIO.  I used
> generic names like "[ethernet]" because I didn't think it made sense
> to confuse the user by using the precise name of the non-gpio function
> (such as "[gmii1_rxd0]").  I could post a patch for the dts files that
> restores unique names for "[ethernet]", "[emmc"], "[i2c0]",
> "[SYSBOOT]" and "[JTAG]".
> 
> As for "[NC]", the BGA balls corresponding to these gpio lines are
> simply not connected to any circuits on the board.  I happy to change
> that to whatever name people prefer for a non-connected pin ("", "NC",
> etc).
> 

I think this is the right thing to do, but we can't have gpiolib refuse
to probe existing DTBs - at least not until some grace period has
expired.

Regards,
Bjorn
Linus Walleij Dec. 16, 2020, 8:50 p.m. | #6
On Wed, Dec 16, 2020 at 7:40 PM Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:

> > I think I will conjure a patch allowing identical naming only for

> > device property naming (like from device tree) but emitting a

> > warning so that people fix it to something unique moving

> > forward.

> >

>

> I'm not against emitting a dev_err() when we hit duplicates, remove the

> return and then update the various dts files to use "" for things that

> doesn't have a name.

>

> Regarding special handling of the DT case, I think (beyond making all

> these boards boot again) it would be nice to make

> gpiochip_set_desc_names() take the list of names and a length and use

> the same function in both code paths...

>

> PS. strlen(names[i]) is O(N), strcmp(names[i], "") is O(1).


OK I'll think of something. I'm pulling these patches out of the stuff
for this merge window because they are clearly immature,
nobody else is telling me so I have to realize it myself, it takes
like three days for me to do that...

Yours,
Linus Walleij

Patch

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index b3340ba68471..407ba79ae571 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -302,7 +302,7 @@  static struct gpio_desc *gpio_name_to_desc(const char * const name)
 	struct gpio_device *gdev;
 	unsigned long flags;
 
-	if (!name)
+	if (!name || !strcmp(name, "") || !strcmp(name, "NC"))
 		return NULL;
 
 	spin_lock_irqsave(&gpio_lock, flags);