gpio: document how to order GPIO controllers
Subsystems (2)
PATCH 1/1 gpio: document how to order GPIO controllers
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").
---
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(+)
Documentation/devicetree/bindings/gpio/gpio.txt +18 -0
@@ -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 -----------------------------------------
Signature · 1 line
2.8.1
Rob Herring
maintainerPATCH 1/1 gpio: document how to order GPIO controllers
Quoted 4 lines · 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").
Like SPI and I2C, I'm against further abuse of aliases for this purpose [1].
Quoted 22 lines
Signed-off-by Uwe Kleine-K?nig <[email protected]>---
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(+)Documentation/devicetree/bindings/gpio/gpio.txt +0
-0
Documentation/devicetree/bindings/gpio/gpio.txt Example of two SOC GPIO banks defined as gpio-controller nodes: · line 234
Quoted 8 lines
Documentation/devicetree/bindings/gpio/gpio.txt +5
-0@@ -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
PATCH 1/1 gpio: document how to order GPIO controllers
Quoted 8 lines · Rob Herring
Quoted 4 lines · 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").Like SPI and I2C, I'm against further abuse of aliases for this purpose [1].
I considered spi and i2c the good examples here :-|
Quoted 24 lines
Quoted 24 lines
Signed-off-by Uwe Kleine-K?nig <[email protected]>---
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(+)Documentation/devicetree/bindings/gpio/gpio.txt +0
-0@@ -227,6 +227,24 @@ Example of two SOC GPIO banks defined as gpio-controller nodes: #gpio-cells = <2>; };
Quoted 7 lines
Documentation/devicetree/bindings/gpio/gpio.txt Example of two SOC GPIO banks defined as gpio-controller nodes: · line 234
Quoted 5 lines
Documentation/devicetree/bindings/gpio/gpio.txt +5
-0+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 at 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
Signature · 2 lines
Pengutronix e.K. | Uwe Kleine-K?nig | Industrial Linux Solutions | http://www.pengutronix.de/ |
PATCH 1/1 gpio: document how to order GPIO controllers
Hi,
Quoted 7 lines · On Tue, 5 Jul 2016 20:04:47 +0200 Uwe Kleine-K?nig wrote:
Quoted 6 lines · Rob Herring
Quoted 4 lines · 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").
Quoted 5 lines
Quoted 2 lines
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
Quoted 60 lines
Quoted 24 lines
Quoted 24 lines
Signed-off-by Uwe Kleine-K?nig <[email protected]>---
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(+)Documentation/devicetree/bindings/gpio/gpio.txt +0
-0@@ -227,6 +227,24 @@ Example of two SOC GPIO banks defined as gpio-controller nodes: #gpio-cells = <2>; };Quoted 7 lines
Documentation/devicetree/bindings/gpio/gpio.txt Example of two SOC GPIO banks defined as gpio-controller nodes: · line 234
Quoted 5 lines
Documentation/devicetree/bindings/gpio/gpio.txt +5
-0+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/dontknowthename2with 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 address0x53fd0000and so to lookup the gpio bank below/sys/bus/platform/devices/53fd0000.gpio/.On an i.MX25 device I currently see:
root at 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/gpiochip3That is we have:
Hardware name | software gpiochip GPIO4 | gpiochip0 GPIO3 | gpiochip1 GPIO1 | gpiochip2 GPIO2 | gpiochip3
Quoted 8 lines
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
PATCH 1/1 gpio: document how to order GPIO controllers
In reply to Uwe Kleine-KönigQuoted 11 lines · Uwe Kleine-K?nig
That is we have:
Hardware name | software gpiochip GPIO4 | gpiochip0 GPIO3 | gpiochip1 GPIO1 | gpiochip2 GPIO2 | gpiochip3I 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.
Quoted 3 lines
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
PATCH 1/1 gpio: document how to order GPIO controllers
In reply to Uwe Kleine-KönigQuoted 4 lines · Uwe Kleine-K?nig
[Rob]:
Quoted 2 lines
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 :(
Quoted 1 line
Quoted 1 line
Why is deterministic numbering needed?
This is the big question, we all agree on that.
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 14 lines
root at 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/gpiochip3That is we have:
Hardware name | software gpiochip GPIO4 | gpiochip0 GPIO3 | gpiochip1 GPIO1 | gpiochip2 GPIO2 | gpiochip3
Quoted 3 lines
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%.
Quoted 3 lines
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
PATCH 1/1 gpio: document how to order GPIO controllers
Quoted 31 lines · Linus Walleij
Quoted 14 lines · Uwe Kleine-König
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/gpiochip3That is we have:
Hardware name | software gpiochip GPIO4 | gpiochip0 GPIO3 | gpiochip1 GPIO1 | gpiochip2 GPIO2 | gpiochip3Quoted 3 lines
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%.
Quoted 3 lines
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.
Quoted 6 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH 1/1 gpio: document how to order GPIO controllers
Quoted 10 lines · Johan Hovold
Quoted 3 lines · Linus Walleij
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.
Quoted 1 line
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.
Quoted 3 lines
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]
Quoted 8 lines · Linus Walleij
Quoted 1 line · Johan Hovold
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
Quoted 5 lines
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
Signature · 4 lines
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 |
Permissions for GPIOs [Was: [PATCH] gpio: document how to order GPIO controllers]
Quoted 5 lines · Jan L?bbe
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.
Quoted 3 lines
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
PATCH 1/1 gpio: document how to order GPIO controllers
In reply to Linus WalleijQuoted 16 lines · Linus Walleij
Quoted 10 lines · Johan Hovold
Quoted 3 lines · Linus Walleij
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.
Quoted 7 lines
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?
Quoted 10 lines
Quoted 1 line
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=2There is a standard document for these boards (96board) specifying the names of the GPIO lines to be "GPIO-A" thru "GPIO-L".
Quoted 7 lines
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.
Quoted 10 lines
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
PATCH 1/1 gpio: document how to order GPIO controllers
Quoted 9 lines · Johan Hovold
Quoted 3 lines · Linus Walleij
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.
Quoted 3 lines
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]
Quoted 4 lines
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
Rob Herring
maintainerPATCH 1/1 gpio: document how to order GPIO controllers
In reply to Linus WalleijQuoted 4 lines · Linus Walleij
Quoted 1 line · Uwe Kleine-K?nig
[Rob]:
Quoted 8 lines
Quoted 2 lines
Quoted 2 lines
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