Re: [PATCH] gpio: omap: make gpio numbering deterministical by using of aliases

Re: [PATCH] gpio: omap: make gpio numbering deterministical by using of aliases

[Uwe Kleine-König]

Hello Linus,

On Sat, Jun 18, 2016 at 10:25:45AM +0200, Linus Walleij wrote:
> On Wed, Jun 15, 2016 at 9:24 AM, Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> > On Wed, Jun 15, 2016 at 08:56:58AM +0200, Linus Walleij wrote:
> 
> >> The GPIO numbering scheme is a matter of Linux internals and
> >> not about hardware description IMO.
> >
> > Not sure if I should agree here or not. It's very usual that the
> > "internal" gpio numbers match the hardware reference manual. I know this
> > from imx, at91, all pre-dt platforms, I'm sure there are more, and I bet
> > I'm not the only one relying on this for omap.
> 
> I think it will still match nicely against the chip-local offsets of the
> primary gpiochip so it'll be fine with a chardev too. The same was/is

I cannot follow. What is the primary gpiochip? The first one? What is a
"chip-local offset". Just 3 for the fourth gpio of a given gpio bank?
I guess the problem is that I didn't follow development of the gpio
chardev.

> the case of the first interrupts on x86 I think, but with the plethora of
> irqchips and dependency on probe order etc the assumption is
> nowadays to dangerous.
> 
> >
> > And this is very usual in the dt world, too:
> >
> > $ git grep -El 'gpio. = \&gpio' arch/arm/boot/dts | wc -l
> > 37
> 
> Aha I didn't even know. Well I guess I could allow it for OMAP too
> then, but I want an ACK from one of the DT binding maintainers.

I added Rob, Frank, Mark and the device tree list to the recipients of
this mail. Can you please comment? There is already a v2 that you can
find at http://thread.gmane.org/gmane.linux.kernel.gpio/17399/ in case
it didn't hit your mailbox. If you tell me that you want it, I can also
bounce you the series.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gpio: omap: make gpio numbering deterministical by using of aliases

[Mark Rutland]

On Sun, Jun 19, 2016 at 03:08:23AM +0200, Uwe Kleine-König wrote:
> Hello Linus,
> 
> On Sat, Jun 18, 2016 at 10:25:45AM +0200, Linus Walleij wrote:
> > On Wed, Jun 15, 2016 at 9:24 AM, Uwe Kleine-König
> > <u.kleine-koenig@pengutronix.de> wrote:
> > > On Wed, Jun 15, 2016 at 08:56:58AM +0200, Linus Walleij wrote:
> > 
> > >> The GPIO numbering scheme is a matter of Linux internals and
> > >> not about hardware description IMO.
> > >
> > > Not sure if I should agree here or not. It's very usual that the
> > > "internal" gpio numbers match the hardware reference manual. I know this
> > > from imx, at91, all pre-dt platforms, I'm sure there are more, and I bet
> > > I'm not the only one relying on this for omap.
> > 
> > I think it will still match nicely against the chip-local offsets of the
> > primary gpiochip so it'll be fine with a chardev too. The same was/is
> 
> I cannot follow. What is the primary gpiochip? The first one? What is a
> "chip-local offset". Just 3 for the fourth gpio of a given gpio bank?
> I guess the problem is that I didn't follow development of the gpio
> chardev.

If I've understood correctly, Linus was on about the id space for GPIOs
under a particular gpiochip. If I've understand correctly, you're trying
to ensure consistent numbering the the *global* ID space shared by all
GPIO chips present in a system?

> > the case of the first interrupts on x86 I think, but with the plethora of
> > irqchips and dependency on probe order etc the assumption is
> > nowadays to dangerous.
> > 
> > > And this is very usual in the dt world, too:
> > >
> > > $ git grep -El 'gpio. = \&gpio' arch/arm/boot/dts | wc -l
> > > 37
> > 
> > Aha I didn't even know. Well I guess I could allow it for OMAP too
> > then, but I want an ACK from one of the DT binding maintainers.

In general, our use of aliases is rather ill-defined. It would be nicer
if we could address devices in a similar manner to disks or partitions,
e.g. by path or uuid, but I don't think we have anything sensible we can
use there.

Given that, I can see the use of an alias to provide a consistent way of
referring to a particular gpiochip (and maybe we need to expose the
alises information somehow to userspace), but IMO that's independent of
any global ID space, probe ordering, etc.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gpio: omap: make gpio numbering deterministical by using of aliases

[Linus Walleij]

On Wed, Jun 22, 2016 at 6:16 PM, Mark Rutland <mark.rutland@arm.com> wrote:

> In general, our use of aliases is rather ill-defined. It would be nicer
> if we could address devices in a similar manner to disks or partitions,
> e.g. by path or uuid, but I don't think we have anything sensible we can
> use there.
>
> Given that, I can see the use of an alias to provide a consistent way of
> referring to a particular gpiochip (and maybe we need to expose the
> alises information somehow to userspace), but IMO that's independent of
> any global ID space, probe ordering, etc.

>From the kernel point of view the way forward to identify and refer to
a particular gpiochip is using /dev/gpiochipN the character device.

If complete topology of the bus placement etc is needed, userspace
can traverse /sys/bus/gpio/*

This solves the big problem with the current global numbering system
in /sys/class/gpio/*

So what this alias should address would be two things:

- Solve the immediate issue of the global number space for the
  legacy sysfs ABI, but also:

- Determine which chip is gpiochip0, gpiochip1, .. etc in the
  new ABI, so the devices get consistent numbering.

The latter is lightly frowned upon by the udev people: they think it
is more proper to traverse /sys to get topological information about
the devices.

I would appreciate if a patch to add alias handling would take care
of both these things if we apply it.

Yours,
Linus Walleij

Re: [PATCH] gpio: omap: make gpio numbering deterministical by using of aliases

[Grygorii Strashko]

On 06/23/2016 12:04 PM, Linus Walleij wrote:
> On Wed, Jun 22, 2016 at 6:16 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> 
>> In general, our use of aliases is rather ill-defined. It would be nicer
>> if we could address devices in a similar manner to disks or partitions,
>> e.g. by path or uuid, but I don't think we have anything sensible we can
>> use there.
>>
>> Given that, I can see the use of an alias to provide a consistent way of
>> referring to a particular gpiochip (and maybe we need to expose the
>> alises information somehow to userspace), but IMO that's independent of
>> any global ID space, probe ordering, etc.
> 
>  From the kernel point of view the way forward to identify and refer to
> a particular gpiochip is using /dev/gpiochipN the character device.
> 
> If complete topology of the bus placement etc is needed, userspace
> can traverse /sys/bus/gpio/*
> 
> This solves the big problem with the current global numbering system
> in /sys/class/gpio/*

Hm. May be i misunderstood samthing (and sry, if my following question
is dummy as I've not followed closely new GPIO ABI development), but..

- from above description it seems that  global numbering system is not really
solved :( instead it's been moved one level up and now the same happens with
gpiocipX devices :( Wouldn't it be reasonable to add possibility to create named/labeled
gpiocipX devices from the very beginning, like: "/dev/gpiocipX[_name|label], or "/dev/gpiocip[_name|label]", or ..

Actually, struct gpio_chip has label field already.

PS. From my experience, the worst case with dev numbering usually happens after 
few insmod/rmmod (or sometimes after suspend/resume) iterations - ttyX ;..(.

> 
> So what this alias should address would be two things:
> 
> - Solve the immediate issue of the global number space for the
>    legacy sysfs ABI, but also:
> 
> - Determine which chip is gpiochip0, gpiochip1, .. etc in the
>    new ABI, so the devices get consistent numbering.
> 
> The latter is lightly frowned upon by the udev people: they think it
> is more proper to traverse /sys to get topological information about
> the devices.
> 
> I would appreciate if a patch to add alias handling would take care
> of both these things if we apply it.
> 

-- 
regards,
-grygorii

Re: [PATCH] gpio: omap: make gpio numbering deterministical by using of aliases

[Linus Walleij]

On Thu, Jun 23, 2016 at 11:38 AM, Grygorii Strashko
<grygorii.strashko@ti.com> wrote:

>> This solves the big problem with the current global numbering system
>> in /sys/class/gpio/*
>
> Hm. May be i misunderstood samthing (and sry, if my following question
> is dummy as I've not followed closely new GPIO ABI development), but..
>
> - from above description it seems that  global numbering system is not really
> solved :( instead it's been moved one level up and now the same happens with
> gpiocipX devices :(

Yes that is true, but also the discovery mechanism is changed so it should
not be a problem: by traversing /sys/bus/gpio/* you know from the topology
information which GPIO chip is which. This is the same method that e.g. USB,
IIO or disks use: you have to complement the device name with bus information
from sysfs.

/sys/class/gpio/* on the other hand has no such information: it is flat.

But as I wrote in the other mail in response to Mark Rutland: if it is desired
to have predictable numbering of the GPIO chips the exact same alias
method can be used for that, and a patch utilizing aliases should fix also
this for the character device usecase.

My own position on these aliases is "eating popcorn", I'm happy with it,
happy without it, the people who care need to argue for it with the DT
maintainers.

> Wouldn't it be reasonable to add possibility to create named/labeled
> gpiocipX devices from the very beginning, like: "/dev/gpiocipX[_name|label], or "/dev/gpiocip[_name|label]", or ..
>
> Actually, struct gpio_chip has label field already.

I don't think that would be nice. There is an ioctl() to get that information
(amongst other stuff) from the device. Check tools/gpio/lsgpio.c

> PS. From my experience, the worst case with dev numbering usually happens after
> few insmod/rmmod (or sometimes after suspend/resume) iterations - ttyX ;..(.

In the GPIO case I think the numbers will be reused as we're using
<linux/idr.h> infrastructure (same method as IIO).

Yours,
Linus Walleij