linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Device Tree Property for Setting of Labels
@ 2022-01-28 17:00 Matt Walker
  2022-01-31 14:13 ` Andy Shevchenko
  0 siblings, 1 reply; 2+ messages in thread
From: Matt Walker @ 2022-01-28 17:00 UTC (permalink / raw)
  To: linux-gpio

All;

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#.)

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`.

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.

Thanks,
Matt Walker

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Device Tree Property for Setting of Labels
  2022-01-28 17:00 Device Tree Property for Setting of Labels Matt Walker
@ 2022-01-31 14:13 ` Andy Shevchenko
  0 siblings, 0 replies; 2+ messages in thread
From: Andy Shevchenko @ 2022-01-31 14:13 UTC (permalink / raw)
  To: Matt Walker, Bartosz Golaszewski; +Cc: open list:GPIO SUBSYSTEM

On Mon, Jan 31, 2022 at 1:21 PM Matt Walker <m@allocor.tech> 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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-01-31 14:14 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-01-28 17:00 Device Tree Property for Setting of Labels Matt Walker
2022-01-31 14:13 ` Andy Shevchenko

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).