| Message ID | 20201215170308.2037624-1-bjorn.andersson@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | gpiolib: Allow name duplicates of "" and "NC" | expand |
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
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
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
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
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
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
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);
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(-)