On Mon, Jan 31, 2022 at 1:21 PM Matt Walker <m@xxxxxxxxxxxx> wrote: > I have a need to reliably identify GPIO pins in userspace, > specifically I would like the method I use to be invariant to > declaration order in the device tree (so not based on gpiochip#.) Not sure I understand the goal. We are trying hard to drop any global namespace for GPIOs so each of the pins is addressed by [chip, relative pin #]. > There doesn't seem to be any existing method to accomplish this; and > there's no existing device tree property in pinctrl that I can see, or > in any driver that I looked at, that would persistently set a label, > name, or other queryable property. (Although some devices like the > stm32pinctrl add a sysfs node like st,bank-name.) > > I propose that a new optional property `label` or `names` is added to > the base pinctrl schema that drivers would then use to set the `label` > property in `struct gpio_chip` which can be queried from userspace via > `GPIO_GET_CHIPINFO_IOCTL`. Names of the lines are visible if you supply gpio-line-names DT property. > Two things come to mind to consider in this scheme > 1) I think I've seen other solutions like this where the device tree > node name is used instead of some additional property, but that seems > like it would be a breaking change if accepted because then all the > labels would change as the drivers are updated. > > 2) Some pinctrl devices (I'm dealing with an mcp23sxx) register > multiple chips under the same node. Right now the label is assigned by > <mcp23sxx>.<address> and it could be something similar such as <label > | mcp23sxx>.<address> but if we had a property that accepted a list of > strings then each one could have a unique label if desired. > > If this is an acceptable proposal then I'll put together some patches. > Or if someone else has a method I could use instead that already > exists I'd love to hear about it. -- With Best Regards, Andy Shevchenko