| Message ID | 1467355333-8813-1-git-send-email-u.kleine-koenig@pengutronix.de |
|---|---|
| State | New |
| Headers | show |
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
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
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
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
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
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
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
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
On Wed, Jul 6, 2016 at 4:12 PM, Jan Lübbe <jlu@pengutronix.de> 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
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
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
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
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 -----------------------------------------
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(+)