[PATCH] gpio: document how to order GPIO controllers

[PATCH] gpio: document how to order GPIO controllers

[Uwe Kleine-König]

This uses the same approach that is already used for spi, i2c and
several other controllers to ensure a consistent numbering independent
of probe order. This is in use for several gpio drivers that already now
use of_alias_get_id(np, "gpio").

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Hello,

Linus requested such a patch as part of a change that introduces
this mechanism to the gpio-omap driver[1]. IMHO this is better done in a
separate patch, so here it comes.

Best regards
Uwe

[1] http://thread.gmane.org/gmane.linux.kernel.gpio/17399/focus=17629

 Documentation/devicetree/bindings/gpio/gpio.txt | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt
index 68d28f62a6f4..5dbacc8f094a 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
@@ -227,6 +227,24 @@ Example of two SOC GPIO banks defined as gpio-controller nodes:
 		#gpio-cells = <2>;
 	};
 
+Usually the GPIO banks in SoCs are ordered, that is there is a dedicated "first
+gpio bank". To fix this ordering in the device tree use aliases starting at 0
+(even if the first bank is called "GPIO1" in the hardware reference).
+This is necessary/handy to ensure deterministical numbering of GPIOs and GPIO
+controllers.
+
+Example of a machine having 4 GPIO banks.
+
+	/ {
+		aliases {
+			...
+			gpio0 = &gpio1;
+			gpio1 = &gpio2;
+			gpio2 = &gpio3;
+			gpio3 = &gpio4;
+		};
+	};
+
 2.1) gpio- and pin-controller interaction
 -----------------------------------------
 
-- 
2.8.1

--
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: document how to order GPIO controllers

[Rob Herring]

On Fri, Jul 01, 2016 at 08:42:13AM +0200, Uwe Kleine-König wrote:
> This uses the same approach that is already used for spi, i2c and
> several other controllers to ensure a consistent numbering independent
> of probe order. This is in use for several gpio drivers that already now
> use of_alias_get_id(np, "gpio").

Like SPI and I2C, I'm against further abuse of aliases for this purpose 
[1].

> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Hello,
> 
> Linus requested such a patch as part of a change that introduces
> this mechanism to the gpio-omap driver[1]. IMHO this is better done in a
> separate patch, so here it comes.
> 
> Best regards
> Uwe
> 
> [1] http://thread.gmane.org/gmane.linux.kernel.gpio/17399/focus=17629
> 
>  Documentation/devicetree/bindings/gpio/gpio.txt | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt
> index 68d28f62a6f4..5dbacc8f094a 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio.txt
> @@ -227,6 +227,24 @@ Example of two SOC GPIO banks defined as gpio-controller nodes:
>  		#gpio-cells = <2>;
>  	};
>  
> +Usually the GPIO banks in SoCs are ordered, that is there is a dedicated "first
> +gpio bank". To fix this ordering in the device tree use aliases starting at 0
> +(even if the first bank is called "GPIO1" in the hardware reference).
> +This is necessary/handy to ensure deterministical numbering of GPIOs and GPIO
> +controllers.

Why is deterministic numbering needed?

Rob

[1] https://lkml.org/lkml/2016/5/24/470
--
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: document how to order GPIO controllers

[Uwe Kleine-König]

On Tue, Jul 05, 2016 at 09:05:46AM -0500, Rob Herring wrote:
> On Fri, Jul 01, 2016 at 08:42:13AM +0200, Uwe Kleine-König wrote:
> > This uses the same approach that is already used for spi, i2c and
> > several other controllers to ensure a consistent numbering independent
> > of probe order. This is in use for several gpio drivers that already now
> > use of_alias_get_id(np, "gpio").
> 
> Like SPI and I2C, I'm against further abuse of aliases for this purpose 
> [1].

I considered spi and i2c the good examples here :-|

> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > ---
> > Hello,
> > 
> > Linus requested such a patch as part of a change that introduces
> > this mechanism to the gpio-omap driver[1]. IMHO this is better done in a
> > separate patch, so here it comes.
> > 
> > Best regards
> > Uwe
> > 
> > [1] http://thread.gmane.org/gmane.linux.kernel.gpio/17399/focus=17629
> > 
> >  Documentation/devicetree/bindings/gpio/gpio.txt | 18 ++++++++++++++++++
> >  1 file changed, 18 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt
> > index 68d28f62a6f4..5dbacc8f094a 100644
> > --- a/Documentation/devicetree/bindings/gpio/gpio.txt
> > +++ b/Documentation/devicetree/bindings/gpio/gpio.txt
> > @@ -227,6 +227,24 @@ Example of two SOC GPIO banks defined as gpio-controller nodes:
> >  		#gpio-cells = <2>;
> >  	};
> >  
> > +Usually the GPIO banks in SoCs are ordered, that is there is a dedicated "first
> > +gpio bank". To fix this ordering in the device tree use aliases starting at 0
> > +(even if the first bank is called "GPIO1" in the hardware reference).
> > +This is necessary/handy to ensure deterministical numbering of GPIOs and GPIO
> > +controllers.
> 
> Why is deterministic numbering needed?

in my case (with a pre 4.8 kernel) it's to control GPIO48 with
/sys/class/gpio/gpio48. But also when using the gpio chardev device
(that will hit 4.8-rc1 AFAIK) there is one device file per gpio chip.

Now consider a user who wants to control/debug direction and value of
GPIO48 (or GPIO2.16 for the chardev case). The strait forward approach
is to use /sys/class/gpio/gpio48 (or /dev/dontknowthename2 with offset
16). I doubt there is a platform where it didn't work like this up to
now and I'd consider it a userspace breakage to force the user to know
that the 2nd gpio bank is located at address 0x53fd0000 and so to lookup
the gpio bank below /sys/bus/platform/devices/53fd0000.gpio/.

On an i.MX25 device I currently see:

root@hostname:/sys/bus/gpio/devices ls -l
lrwxrwxrwx    1 root     root             0 Jul  5 20:52 gpiochip0 -> ../../../devices/platform/soc/53f00000.aips/53f9c000.gpio/gpiochip0
lrwxrwxrwx    1 root     root             0 Jul  5 20:52 gpiochip1 -> ../../../devices/platform/soc/53f00000.aips/53fa4000.gpio/gpiochip1
lrwxrwxrwx    1 root     root             0 Jul  5 20:52 gpiochip2 -> ../../../devices/platform/soc/53f00000.aips/53fcc000.gpio/gpiochip2
lrwxrwxrwx    1 root     root             0 Jul  5 20:52 gpiochip3 -> ../../../devices/platform/soc/53f00000.aips/53fd0000.gpio/gpiochip3

That is we have:

	Hardware name | software gpiochip
	    GPIO4     |      gpiochip0
	    GPIO3     |      gpiochip1
	    GPIO1     |      gpiochip2
	    GPIO2     |	     gpiochip3

I bet that's the probe order because when sorted by address (and so
by order in the device tree) we have exactly this ordering. (Compare
with $(grep gpio@ arch/arm/boot/dts/imx25.dtsi).)

For a new interface this is OK, still I predict users will complain if
the numbers used don't match naturally the hardware names. And IMHO they
are right.

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: document how to order GPIO controllers

[Lothar Waßmann]

Hi,

On Tue, 5 Jul 2016 20:04:47 +0200 Uwe Kleine-König wrote:
> On Tue, Jul 05, 2016 at 09:05:46AM -0500, Rob Herring wrote:
> > On Fri, Jul 01, 2016 at 08:42:13AM +0200, Uwe Kleine-König wrote:
> > > This uses the same approach that is already used for spi, i2c and
> > > several other controllers to ensure a consistent numbering independent
> > > of probe order. This is in use for several gpio drivers that already now
> > > use of_alias_get_id(np, "gpio").
> > 
> > Like SPI and I2C, I'm against further abuse of aliases for this purpose 
> > [1].
> 
> I considered spi and i2c the good examples here :-|
> 
+1

> > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > > ---
> > > Hello,
> > > 
> > > Linus requested such a patch as part of a change that introduces
> > > this mechanism to the gpio-omap driver[1]. IMHO this is better done in a
> > > separate patch, so here it comes.
> > > 
> > > Best regards
> > > Uwe
> > > 
> > > [1] http://thread.gmane.org/gmane.linux.kernel.gpio/17399/focus=17629
> > > 
> > >  Documentation/devicetree/bindings/gpio/gpio.txt | 18 ++++++++++++++++++
> > >  1 file changed, 18 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt
> > > index 68d28f62a6f4..5dbacc8f094a 100644
> > > --- a/Documentation/devicetree/bindings/gpio/gpio.txt
> > > +++ b/Documentation/devicetree/bindings/gpio/gpio.txt
> > > @@ -227,6 +227,24 @@ Example of two SOC GPIO banks defined as gpio-controller nodes:
> > >  		#gpio-cells = <2>;
> > >  	};
> > >  
> > > +Usually the GPIO banks in SoCs are ordered, that is there is a dedicated "first
> > > +gpio bank". To fix this ordering in the device tree use aliases starting at 0
> > > +(even if the first bank is called "GPIO1" in the hardware reference).
> > > +This is necessary/handy to ensure deterministical numbering of GPIOs and GPIO
> > > +controllers.
> > 
> > Why is deterministic numbering needed?
> 
> in my case (with a pre 4.8 kernel) it's to control GPIO48 with
> /sys/class/gpio/gpio48. But also when using the gpio chardev device
> (that will hit 4.8-rc1 AFAIK) there is one device file per gpio chip.
> 
> Now consider a user who wants to control/debug direction and value of
> GPIO48 (or GPIO2.16 for the chardev case). The strait forward approach
> is to use /sys/class/gpio/gpio48 (or /dev/dontknowthename2 with offset
> 16). I doubt there is a platform where it didn't work like this up to
> now and I'd consider it a userspace breakage to force the user to know
> that the 2nd gpio bank is located at address 0x53fd0000 and so to lookup
> the gpio bank below /sys/bus/platform/devices/53fd0000.gpio/.
> 
> On an i.MX25 device I currently see:
> 
> root@hostname:/sys/bus/gpio/devices ls -l
> lrwxrwxrwx    1 root     root             0 Jul  5 20:52 gpiochip0 -> ../../../devices/platform/soc/53f00000.aips/53f9c000.gpio/gpiochip0
> lrwxrwxrwx    1 root     root             0 Jul  5 20:52 gpiochip1 -> ../../../devices/platform/soc/53f00000.aips/53fa4000.gpio/gpiochip1
> lrwxrwxrwx    1 root     root             0 Jul  5 20:52 gpiochip2 -> ../../../devices/platform/soc/53f00000.aips/53fcc000.gpio/gpiochip2
> lrwxrwxrwx    1 root     root             0 Jul  5 20:52 gpiochip3 -> ../../../devices/platform/soc/53f00000.aips/53fd0000.gpio/gpiochip3
> 
> That is we have:
> 
> 	Hardware name | software gpiochip
> 	    GPIO4     |      gpiochip0
> 	    GPIO3     |      gpiochip1
> 	    GPIO1     |      gpiochip2
> 	    GPIO2     |	     gpiochip3
> 
> I bet that's the probe order because when sorted by address (and so
> by order in the device tree) we have exactly this ordering. (Compare
> with $(grep gpio@ arch/arm/boot/dts/imx25.dtsi).)
> 
> For a new interface this is OK, still I predict users will complain if
> the numbers used don't match naturally the hardware names. And IMHO they
> are right.
> 
IMO the burden of doing such lookups should be put on the computer, not
the human who is using it. That's what computers are good at.
If aliases in DT are the wrong way to a straightforward numbering
scheme for use by humans, we should introduce a different way to achieve
this.


Lothar Waßmann
--
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: document how to order GPIO controllers

[Alexander Stein]

On Tuesday 05 July 2016 20:04:47, Uwe Kleine-König wrote:
> That is we have:
> 
> 	Hardware name | software gpiochip
> 	    GPIO4     |      gpiochip0
> 	    GPIO3     |      gpiochip1
> 	    GPIO1     |      gpiochip2
> 	    GPIO2     |	     gpiochip3
> 
> I bet that's the probe order because when sorted by address (and so
> by order in the device tree) we have exactly this ordering. (Compare
> with $(grep gpio@ arch/arm/boot/dts/imx25.dtsi).)

This is rather straight forward and rather simple for controller internal GPIO 
controllers but when using GPIO expanders both on SPI and I2C thing will get 
much more volatile especially on SMP systems. What would be the correct 
"order" here? Unless they are cascaded they are independent and there is no 
such thing as an order. Probe order _is_ unpredictable so they will vary on 
different boots. Having 4 internal GPIO controllers which creates 4 gpiochips 
with more or less fixed names is rather a special case. Dunno if they might 
change on a SMP system. Can a driver probe be called multiple times 
simultaneously? Well, when drivers are used as modules I think things are even 
more unpredictable.

> For a new interface this is OK, still I predict users will complain if
> the numbers used don't match naturally the hardware names. And IMHO they
> are right.

Given the fact that hardware names and gpiochip number relation is not fixed 
IMHO the simplest way to identify them is using the DT label. You need them 
anyway to identify them in DT itself at other places why not using this on 
Linux userspace too? So gpiochip[0-9]* should still be created but using udev 
you can create appropriate symlinks with more recognizable names.

Best regards,
Alexander

--
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: document how to order GPIO controllers

[Linus Walleij]

On Tue, Jul 5, 2016 at 8:04 PM, Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> [Rob]:

>> Like SPI and I2C, I'm against further abuse of aliases for this purpose
>> [1].

So what about the usecase for serial ports, where we use this
to make sure the console come out where we want it? Is that
also considered abuse or legitimate use? Note: I'm not trying to be
snarky, I'm trying to understand what is the right and wrong use
of alias. I'm confused about it right now :(

>> Why is deterministic numbering needed?

This is the big question, we all agree on that.

> in my case (with a pre 4.8 kernel) it's to control GPIO48 with
> /sys/class/gpio/gpio48.

That is understandable. However as many people have pointed
out, if this is inherently broken since the introduction of
off-chip devices and even more by deferred probing. For some
odd silicon state making one GPIO's clock or something randomly
defer the probe, this would happen to become unpredictable
also on SoC-embedded GPIO chips. It's just that we don't see
it very much because it is deterministic in practice.

We need to face it: relying on fixed GPIO numbering is just a
big fragile mess that we're trying to duct-tape.

> But also when using the gpio chardev device
> (that will hit 4.8-rc1 AFAIK) there is one device file per gpio chip.

Yeah and the argument is that the numbering also of the chip
instance should be made more deterministic, so gpiochip0,
gpiochip1 ... gpiochipN are intuitive to a human user.

> root@hostname:/sys/bus/gpio/devices ls -l
> lrwxrwxrwx    1 root     root             0 Jul  5 20:52 gpiochip0 -> ../../../devices/platform/soc/53f00000.aips/53f9c000.gpio/gpiochip0
> lrwxrwxrwx    1 root     root             0 Jul  5 20:52 gpiochip1 -> ../../../devices/platform/soc/53f00000.aips/53fa4000.gpio/gpiochip1
> lrwxrwxrwx    1 root     root             0 Jul  5 20:52 gpiochip2 -> ../../../devices/platform/soc/53f00000.aips/53fcc000.gpio/gpiochip2
> lrwxrwxrwx    1 root     root             0 Jul  5 20:52 gpiochip3 -> ../../../devices/platform/soc/53f00000.aips/53fd0000.gpio/gpiochip3
>
> That is we have:
>
>         Hardware name | software gpiochip
>             GPIO4     |      gpiochip0
>             GPIO3     |      gpiochip1
>             GPIO1     |      gpiochip2
>             GPIO2     |      gpiochip3
>
> I bet that's the probe order because when sorted by address (and so
> by order in the device tree) we have exactly this ordering. (Compare
> with $(grep gpio@ arch/arm/boot/dts/imx25.dtsi).)

That is super-unintuitive for a human user, I agree 100%.

> For a new interface this is OK, still I predict users will complain if
> the numbers used don't match naturally the hardware names. And IMHO they
> are right.

I agree, and I think that if aliases can alleviate the situation we should
allow them and encourage them. They are the best duct-tape we can
find for the DT systems.

Unfortunately it is not my call, because DT bindings and alias use
is not under my jurisdiction.

I *THINK* the view of the device core maintainers is that udev
and sysfs hierarchies should be used to uniquely identify a certain
device, and that relying on device numbering is too fragile.

The network and disks people faced this problem before us, and
their solution was things like using sysfs/udev to make sure
the device get presented the right way to userspace and
handled the way it should.

Yours,
Linus Walleij
--
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: document how to order GPIO controllers

[Johan Hovold]

On Wed, Jul 06, 2016 at 11:34:37AM +0200, Linus Walleij wrote:
> On Tue, Jul 5, 2016 at 8:04 PM, Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:

> > root@hostname:/sys/bus/gpio/devices ls -l
> > lrwxrwxrwx    1 root     root             0 Jul  5 20:52 gpiochip0 -> ../../../devices/platform/soc/53f00000.aips/53f9c000.gpio/gpiochip0
> > lrwxrwxrwx    1 root     root             0 Jul  5 20:52 gpiochip1 -> ../../../devices/platform/soc/53f00000.aips/53fa4000.gpio/gpiochip1
> > lrwxrwxrwx    1 root     root             0 Jul  5 20:52 gpiochip2 -> ../../../devices/platform/soc/53f00000.aips/53fcc000.gpio/gpiochip2
> > lrwxrwxrwx    1 root     root             0 Jul  5 20:52 gpiochip3 -> ../../../devices/platform/soc/53f00000.aips/53fd0000.gpio/gpiochip3
> >
> > That is we have:
> >
> >         Hardware name | software gpiochip
> >             GPIO4     |      gpiochip0
> >             GPIO3     |      gpiochip1
> >             GPIO1     |      gpiochip2
> >             GPIO2     |      gpiochip3
> >
> > I bet that's the probe order because when sorted by address (and so
> > by order in the device tree) we have exactly this ordering. (Compare
> > with $(grep gpio@ arch/arm/boot/dts/imx25.dtsi).)
> 
> That is super-unintuitive for a human user, I agree 100%.
> 
> > For a new interface this is OK, still I predict users will complain if
> > the numbers used don't match naturally the hardware names. And IMHO they
> > are right.
> 
> I agree, and I think that if aliases can alleviate the situation we should
> allow them and encourage them. They are the best duct-tape we can
> find for the DT systems.
> 
> Unfortunately it is not my call, because DT bindings and alias use
> is not under my jurisdiction.
> 
> I *THINK* the view of the device core maintainers is that udev
> and sysfs hierarchies should be used to uniquely identify a certain
> device, and that relying on device numbering is too fragile.

I thought the whole idea (or at least a large part of) the new
user-space interface was to allow lookups by line names precisely in
order not to have to rely on gpio numbers, which may not only change
between boots, but also between hardware revisions, etc.

What's wrong with naming the pins in DT and use that for lookups?

I've been too busy with other stuff this spring to follow the new
user-space interface development, but I assume that this had been taken
into account in the design?

Thanks,
Johan
--
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: document how to order GPIO controllers

[Linus Walleij]

On Wed, Jul 6, 2016 at 12:27 PM, Johan Hovold <johan@kernel.org> wrote:
> On Wed, Jul 06, 2016 at 11:34:37AM +0200, Linus Walleij wrote:

>> I *THINK* the view of the device core maintainers is that udev
>> and sysfs hierarchies should be used to uniquely identify a certain
>> device, and that relying on device numbering is too fragile.
>
> I thought the whole idea (or at least a large part of) the new
> user-space interface was to allow lookups by line names precisely in
> order not to have to rely on gpio numbers, which may not only change
> between boots, but also between hardware revisions, etc.

That is true for the individual pins, but not the device names.
Devices are just names gpiochipN where N is the instance
number. Topological info on the device can be found in sysfs.

The discussion here pertaining to the new chardev is just about
the intuitiveness of the number N, whether it should be
"whatever" or something predictable.

For the purpose of picking a certain named GPIO line (see below)
knowing this number is unnecessary. To that mechanism all gpio
chips are equal and the instance number does not matter.

> What's wrong with naming the pins in DT and use that for lookups?

That works. It relies on the developers using sane naming conventions
though. (This problem is prevalent everywhere I guess, a human problem,
not a technical one.) I made this patch:
http://marc.info/?l=linux-arm-kernel&m=146672328215354&w=2

There is a standard document for these boards (96board) specifying
the names of the GPIO lines to be "GPIO-A" thru "GPIO-L".

So a user can iterate across the gpiochips (as is done in lsgpio)
and pick the lines with the right names.

This works fine, given you have such conventions or equal.

I.e. the person writing the DTS file naming the lines must not
be a complete lunatic.

I can think of scenarios where bad use can make things problematic:
i.e. name two lines the same thing, albeit on different GPIO chips.
That is currently allowed, and if that happens, the user must
use topological information about the gpiochip (from sysfs) to
uniquely identify the GPIO line.

I wouldn't recommend that since it is essentially inventing a
problem for oneself to solve, but I don't know what reasons
people may have to do something like that. There is no technical
problem with it.

> I've been too busy with other stuff this spring to follow the new
> user-space interface development, but I assume that this had been taken
> into account in the design?

I think so...

Yours,
Linus Walleij

Permissions for GPIOs [Was: [PATCH] gpio: document how to order GPIO controllers]

[Jan Lübbe]

On Mi, 2016-07-06 at 14:34 +0200, Linus Walleij wrote:
> On Wed, Jul 6, 2016 at 12:27 PM, Johan Hovold <johan@kernel.org> wrote:
> > What's wrong with naming the pins in DT and use that for lookups?
> 
> That works. It relies on the developers using sane naming conventions
> though. (This problem is prevalent everywhere I guess, a human problem,
> not a technical one.) I made this patch:
> http://marc.info/?l=linux-arm-kernel&m=146672328215354&w=2
> 
> There is a standard document for these boards (96board) specifying
> the names of the GPIO lines to be "GPIO-A" thru "GPIO-L".
> 
> So a user can iterate across the gpiochips (as is done in lsgpio)
> and pick the lines with the right names.

This discussion caused me remember a concern regarding the chardev
interface: Is it still be possible to give specific users/groups access
to individual GPIOs? This is currently possible in the sysfs interface
with chown/chmod. I don't see how per-GPIO permissions would translate
to a per-gpiochip device.

Am I overlooking some better way to give non-root users granular access
to GPIOs? Or is that intentionally out of scope for the chardev
interface?

Yours,
Jan
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Permissions for GPIOs [Was: [PATCH] gpio: document how to order GPIO controllers]

[Linus Walleij]

On Wed, Jul 6, 2016 at 4:12 PM, Jan Lübbe <jlu-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:

> This discussion caused me remember a concern regarding the chardev
> interface: Is it still be possible to give specific users/groups access
> to individual GPIOs? This is currently possible in the sysfs interface
> with chown/chmod. I don't see how per-GPIO permissions would translate
> to a per-gpiochip device.

It is not possible because it is a different model. The /dev/gpiochipN
is similar to /dev/sda for example, either you access the whole device
file not parts of it.

I think the old sysfs wrongly gives people the impression that this is
needed just because it happens to have one value per file, I can't think
of a usecase for it.

It's a bit like if we had a sysfs or similar that could give you write
permissions to just certain blocks of a disk or something using chmod.
I don't see anyone needing that other than in theory.

> Am I overlooking some better way to give non-root users granular access
> to GPIOs? Or is that intentionally out of scope for the chardev
> interface?

Intentionally out of scope I don't know, nobody raised it during review,
and I have never seen a real-world usecase.

Are there any distributions out there that ship with something like udev
files that actually go to the trouble of setting up different permissions
on GPIO sysfs files, or are we talking about hacks in a lab or even
just theoretical issues?

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gpio: document how to order GPIO controllers

[Johan Hovold]

On Wed, Jul 06, 2016 at 02:34:39PM +0200, Linus Walleij wrote:
> On Wed, Jul 6, 2016 at 12:27 PM, Johan Hovold <johan@kernel.org> wrote:
> > On Wed, Jul 06, 2016 at 11:34:37AM +0200, Linus Walleij wrote:
> 
> >> I *THINK* the view of the device core maintainers is that udev
> >> and sysfs hierarchies should be used to uniquely identify a certain
> >> device, and that relying on device numbering is too fragile.
> >
> > I thought the whole idea (or at least a large part of) the new
> > user-space interface was to allow lookups by line names precisely in
> > order not to have to rely on gpio numbers, which may not only change
> > between boots, but also between hardware revisions, etc.
> 
> That is true for the individual pins, but not the device names.
> Devices are just names gpiochipN where N is the instance
> number. Topological info on the device can be found in sysfs.
> 
> The discussion here pertaining to the new chardev is just about
> the intuitiveness of the number N, whether it should be
> "whatever" or something predictable.
> 
> For the purpose of picking a certain named GPIO line (see below)
> knowing this number is unnecessary. To that mechanism all gpio
> chips are equal and the instance number does not matter.

My point was that with gpio line names (and possibly topological
information to resolve duplicates), the N number should not matter
anymore.

[ It was also a comment to a comment made earlier in the thread were the
use case was said to be to "control GPIO48 with /sys/class/gpio/gpio48".
And it seems we are in agreement there. ]

If one needs to look up a particular gpiochip based on some hardware
naming convention, why not associate a name with the chip instead of
trying to shoehorn the dynamic gpiochip range in there?

> > What's wrong with naming the pins in DT and use that for lookups?
> 
> That works. It relies on the developers using sane naming conventions
> though. (This problem is prevalent everywhere I guess, a human problem,
> not a technical one.) I made this patch:
> http://marc.info/?l=linux-arm-kernel&m=146672328215354&w=2
> 
> There is a standard document for these boards (96board) specifying
> the names of the GPIO lines to be "GPIO-A" thru "GPIO-L".
> 
> So a user can iterate across the gpiochips (as is done in lsgpio)
> and pick the lines with the right names.
> 
> This works fine, given you have such conventions or equal.
> 
> I.e. the person writing the DTS file naming the lines must not
> be a complete lunatic.

Again, it seems we're on the same page here.

> I can think of scenarios where bad use can make things problematic:
> i.e. name two lines the same thing, albeit on different GPIO chips.
> That is currently allowed, and if that happens, the user must
> use topological information about the gpiochip (from sysfs) to
> uniquely identify the GPIO line.
> 
> I wouldn't recommend that since it is essentially inventing a
> problem for oneself to solve, but I don't know what reasons
> people may have to do something like that. There is no technical
> problem with it.

And this may even be unavoidable with dynamic buses such as USB or
greybus, where you can have multiple devices associating the same name
with a pin. That's fine as long as the user-space interface allows for a
way to distinguish them (e.g. through topological information).

Thanks,
Johan

Re: [PATCH] gpio: document how to order GPIO controllers

[Linus Walleij]

On Wed, Jul 13, 2016 at 3:14 PM, Johan Hovold <johan@kernel.org> wrote:
> On Wed, Jul 06, 2016 at 02:34:39PM +0200, Linus Walleij wrote:

>> For the purpose of picking a certain named GPIO line (see below)
>> knowing this number is unnecessary. To that mechanism all gpio
>> chips are equal and the instance number does not matter.
>
> My point was that with gpio line names (and possibly topological
> information to resolve duplicates), the N number should not matter
> anymore.

Agreed. It doesn't, with the new ABI. Not for technical reasons, at all.

> If one needs to look up a particular gpiochip based on some hardware
> naming convention, why not associate a name with the chip instead of
> trying to shoehorn the dynamic gpiochip range in there?

With the new ABI it is possible to set a "label" for the gpiochip, currently
described as "a functional name for this GPIO chip, such as a product
number" and it's certainly possible to manage this name carefully for
a system to look up a certain chip.

[About obtaining topological  information from sysfs]
> And this may even be unavoidable with dynamic buses such as USB or
> greybus, where you can have multiple devices associating the same name
> with a pin. That's fine as long as the user-space interface allows for a
> way to distinguish them (e.g. through topological information).

This should work fine AFAICT. All the ABI and information is in place
to deal with this.

Yours,
Linus Walleij

Re: [PATCH] gpio: document how to order GPIO controllers

[Rob Herring]

On Wed, Jul 06, 2016 at 11:34:37AM +0200, Linus Walleij wrote:
> On Tue, Jul 5, 2016 at 8:04 PM, Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> > [Rob]:
> 
> >> Like SPI and I2C, I'm against further abuse of aliases for this purpose
> >> [1].
> 
> So what about the usecase for serial ports, where we use this
> to make sure the console come out where we want it? Is that
> also considered abuse or legitimate use? Note: I'm not trying to be
> snarky, I'm trying to understand what is the right and wrong use
> of alias. I'm confused about it right now :(

I guess it comes down to how ingrained the usage of any numbering is. 
For consoles, it was pretty important to maintain numbering and no 
alternative. But now with stdout-path that is less important. Perhaps if 
you have inittab with tty devices, then it is still needed.

So I guess I would summarize the requirement to be only cases needing to 
maintain numbering for existing userspace. The only users really caring 
about this have been on N900.

Rob
--
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