Re: [PATCH] gpio: search gpio-line-names property in dm_gpio_lookup_name

[Rasmus Villemoes <ravi@prevas.dk>]

On Wed, Oct 15 2025, Tom Rini <trini@konsulko.com> wrote:

> On Tue, Oct 07, 2025 at 12:26:37PM +0200, Rasmus Villemoes wrote:
>
>> In scripts as well as interactively, it's much nicer to be able to
>> refer to GPIOs via their names defined in the device tree property
>> "gpio-line-names", instead of the rather opaque names derived from the
>> bank name with a _xx suffix. E.g.
>> 
>>   gpio read factory_reset FACTORY_RESET
>>   if test $factory_reset = 1 ; then ...
>> 
>> versus
>> 
>>   gpio read factory_reset gpio@481ac000_16
>>   if test $factory_reset = 1 ; then ...
>> 
>> This is also consistent with the move on the linux/userspace side towards
>> using line names instead of legacy chip+offset or the even more legacy
>> global gpio numbering in sysfs.
>> 
>> As this seems to only add about ~50 bytes of code to U-Boot proper,
>> and dm_gpio_lookup_name() most often ends up being GC'ed for SPL, so
>> adds no overhead there, adding yet another config knob (or two, if it
>> also needed an SPL variant) for this does not seem warranted.
>> 
>> Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
>
> On a few platforms we now get a failure to build:
>        arm:  +   work_92105
> +(work_92105) arm-linux-gnueabi-ld: drivers/gpio/gpio-uclass.o: in function `dev_read_stringlist_search':
> +(work_92105) include/dm/read.h:1078:(.text.dm_gpio_lookup_name+0x8c): undefined reference to `ofnode_stringlist_search'
> +(work_92105) make[1]: *** [Makefile:2029: u-boot] Error 1
> +(work_92105) make: *** [Makefile:198: sub-make] Error 2

Hm, interesting. The same call is already being done in the same .c
file, and AFAICT not under any different #ifdef conditions.

But I suppose it's possible that gpio_request_by_line_name() always end
up being GC'ed on those platforms, but dm_gpio_lookup_name() (probably
via gpio_lookup_name) does not.

ofnode_stringlist_search is available whenever CONFIG_OF_CONTROL, which
probably explains why you say "a few". And I guess it kind of makes
sense to at least make this conditional on there _being_ a dt node
associated to the udevice. I'll send a v2 with the block wrapped in if
(CONFIG_IS_ENABLED(OF_CONTROL)).

Rasmus