Thread (8 messages) 8 messages, 5 authors, 25d ago

Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper

From: "Arnd Bergmann" <arnd@arndb.de>
Date: 2026-07-01 08:32:22
Also in: dri-devel, linux-arm-kernel, linux-bluetooth, linux-gpio, linux-i2c, linux-iio, linux-mmc, linux-pm, linux-usb, lkml

On Tue, Jun 30, 2026, at 18:01, Geert Uytterhoeven wrote:
On Mon, 29 Jun 2026 at 19:54, Arnd Bergmann [off-list ref] wrote:
quoted
On Mon, Jun 29, 2026, at 17:29, Geert Uytterhoeven wrote:
quoted
quoted
Same results for instantiation using sysfs or configfs[1], although
the latter does have optional support for specifying the name.
I wonder how many of the other instances have the same problem
then. Would it be appropriate for gpiochip_fwd_desc_add() to set
a name itself to address this one?
I don't think it would be appropriate for the GPIO aggregator to set
that name.  What we want to print here (for debugging) is the physical
GPIO that an aggregator's GPIO is mapped to, not some consumer or line
name (which is not guaranteed to be unique).
Ok.
E.g. "<chip-name>.<offset>" would be fine.  As gpiod_name() can only
return a fixed string or an existing string, it can't return such a
formatted string, though. And consumers don't have access to chip info?
The gpiod_hwgpio() function is exported to consumers, so they can
already print that instead of desc_to_gpio() if the local number
is sufficient. If we really care about the <chip-name> portion for
any of the debug prints, we could export another function that
returns maybe gpiod_to_chip(gpiod)->label or
dev_name(&gpiod_to_gpio_device(gpiod)->dev), which are both
constant strings we can print.

It looks like we can also replace most of the remaining callers
of desc_to_gpio() with gpiod_hwgpio().

       Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help