Re: Getting legacy GPIO index by line name

[Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx>]

Hello Linus,

On 29.08.23 09:24, Linus Walleij wrote:
> On Mon, Aug 28, 2023 at 4:21 PM Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote:
> 
>> Much to my dismay, I've learnt that my script above doesn't work when the same device
>> registers multiple GPIO controllers. On my i.MX system with some PCA953x GPIO expanders,
>> it works ok, but on a STM32MP, were the pinctrl device registers all GPIO chips, the glob
>> will expand to more than once device.
>>
>> So my question is: What better way is there to get a legacy GPIO index from within
>> a shell script (or an alternative way to request a sysfs GPIO by label)?
> 
> Don't know if it answers your question, but when there are several GPIO
> chips of the same device/driver the way to determine topology ("which
> device is which") is to use the topology in sysfs, i.e. the directory path,
> where each device will have some unique bus ID (such as the USB
> instance number, the device tree address etc).

I don't want to hardcode device tree paths or I2C addresses into shell scripts.
I have added a GPIO line name in the DT and I want to use for looking up the
legacy GPIO index.

Let's take as an example, this GPIO that can be requested from an I2C expander:

  $ gpiofind HDMI_RESET
  gpiochip5 3
That's the node for the I2C expander:

  /sys/devices/platform/soc@0/30800000.bus/30a30000.i2c/i2c-1/1-003a

Looking into it for gpio*, I see:

/sys/devices/platform/soc@0/30800000.bus/30a30000.i2c/i2c-1/1-003a/gpio/gpiochip512
/sys/devices/platform/soc@0/30800000.bus/30a30000.i2c/i2c-1/1-003a/gpiochip5

gpio/gpiochip512/base is the file I need to read. gpiochip5 is the file I have.

What I do is:

  $ cat /sys/bus/gpio/devices/gpiochip5/../gpio/gpio*/base
  512

But that breaks down if gpio/ has multiple directories:

root@stm32mp157c-lxa-mc1:~ ls /sys/bus/gpio/devices/gpiochip8/../gpio/gpiochip* -d
/sys/bus/gpio/devices/gpiochip8/../gpio/gpiochip0    /sys/bus/gpio/devices/gpiochip8/../gpio/gpiochip48
/sys/bus/gpio/devices/gpiochip8/../gpio/gpiochip112  /sys/bus/gpio/devices/gpiochip8/../gpio/gpiochip64
/sys/bus/gpio/devices/gpiochip8/../gpio/gpiochip128  /sys/bus/gpio/devices/gpiochip8/../gpio/gpiochip80
/sys/bus/gpio/devices/gpiochip8/../gpio/gpiochip16   /sys/bus/gpio/devices/gpiochip8/../gpio/gpiochip96
/sys/bus/gpio/devices/gpiochip8/../gpio/gpiochip32


>> P.S: I know that most GPIO fiddling should've kernel driver consumers instead. That's under
>>      way too.
> 
> Thanks! :)
> 
>> [1]: I appreciate links to any WIP/planned systemd-gpiod or similar patches anyway. While new
>>      projects should do more fine grained control of GPIOs, migration of most users will
>>      likely benefit benefit from a single global consumer.
> 
> I think Bartosz was working at a GPIO daemon for central management at one
> point, but in a controlled embedded system, I think other (custom) solutions for
> a central entity are possible.
> 
> Yours,
> Linus Walleij
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |