gpio: Allow userspace export from DT
Subsystems (2)
cover gpio: Allow userspace export from DT
Currently the gpio sysfs interface allows userspace to access simple hardware where no kernel driver exists or would be useful.
However it requires userspace to know the gpio number that has been assigned by the kernel.
That number, in the case of gpio drviers using dynamic allocation, is not fixed, and may change when:
* The kernel version changes and ARCH_NR_GPIOS is changed (happened in 3.17)
* The kernel version changes and probe order changes for gpio chips.
* The kernel configuration is changed if CONFIG_ARCH_NR_GPIO is used
* The board is redesigned (eg switching an externally visible signal from a SoC provided GPIO to an I2C expander chip or vice versa).
* Other GPIO chips are added to the system.
The above means that, in order to export the GPIO to userspace via /sys/class/gpio/export the userspace code must know the exact hardware and kernel version information.
Furthermore, in many cases, it makes no sense to allow userspace to change the signal direction; even if the GPIO itself allows it the circuitry connected to the pin often does not (eg a signal dedicated to an output function driving a transistor).
This patch series solves both problems by performing the external signal => GPIO mapping in the device tree.
PATCH 1/2 Doc: DT: Add binding document for GPIO exporter
--- .../devicetree/bindings/gpio/gpio-exporter.txt | 40 ++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-exporter.txt
Documentation/devicetree/bindings/gpio/gpio-exporter.txt new file +40 -0
@@ -0,0 +1,40 @@ +Bindings to export some GPIOs to userspace. + +This is useful when some signals are made externally available by a piece +of hardware (eg terminal blocks to connect sensors, actuators) but no +special purpose kernel driver exists. + +Use of this binding allows userspace to have a stable name and input +/ output mode across hardware and software versions. + +Required properties: +- compatible: "linux,gpio-exporter" + + +Each GPIO to be exported is represented as a child node with: + +Required child properties: +- gpios : Reference to the GPIO to export (standard gpio binding) + +Optional child properties: +- output : if present GPIO is output, otherwise input +- initial-state : Initial state (0=low, 1=high) for output +- allow-direction-change : Present if GPIO direction may be modified + +The name of the child node is that exposed to userspace. + +Example: + gpio_exporter:gpio-exporter { + compatible = "linux,gpio-exporter"; + + terminalblock_1_out1 { + gpios = <&gpio2 12 0>; + output; + initial-state = <0>; + }; + + terminalblock_1_in1 { + gpios = <&gpio2 15 0>; + }; + + };
PATCH 2/2 gpio: add driver to export DT configured GPIOs to userspace
In reply to Martin FuzzeySelected GPIOs (defined as child nodes in DT) may be exported as symlinks to user space (using gpiod_export_link())
The advantages of this are:
* Userspace no longer needs to know the GPIO number (which may vary with other hardware and with kernel version due to dynamic allocation)
* Userspace can be prevented from changing the direction if that does not make sense from a hardware perspective.
--- drivers/gpio/Kconfig | 9 ++ drivers/gpio/Makefile | 1 drivers/gpio/gpio-exporter.c | 171 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 181 insertions(+) create mode 100644 drivers/gpio/gpio-exporter.c
drivers/gpio/Kconfig +9 -0
@@ -110,6 +110,15 @@ config GPIO_DA9055 config GPIO_MAX730X tristate +config GPIO_EXPORTER + tristate "Userspace exporter driver" + depends on OF_GPIO && GPIO_SYSFS + help + This enables a GPIO consumer which exports some GPIOs to userspace. + The GPIOs to be exported are defined in the device tree. + The exported GPIOs are represented as symbolic links in sysfs, + relieving usespace of the burden of knowing the GPIO number to export + comment "Memory mapped GPIO drivers:" config GPIO_74XX_MMIO
drivers/gpio/Makefile +1 -0
@@ -10,6 +10,7 @@ obj-$(CONFIG_GPIO_SYSFS) += gpiolib-sysfs.o obj-$(CONFIG_GPIO_ACPI) += gpiolib-acpi.o # Device drivers. Generally keep list sorted alphabetically +obj-$(CONFIG_GPIO_EXPORTER) += gpio-exporter.o obj-$(CONFIG_GPIO_GENERIC) += gpio-generic.o obj-$(CONFIG_GPIO_74X164) += gpio-74x164.o
drivers/gpio/gpio-exporter.c new file +171 -0
171 lines not on this page · raw message
cover gpio: Allow userspace export from DT
In reply to Martin FuzzeyQuoted 2 lines · Martin Fuzzey
Currently the gpio sysfs interface allows userspace to access simple hardware where no kernel driver exists or would be useful.
Whether or not a kernel driver exists can vary by kernel version. The dtb needs to work either way. The way you have done it would require dtb changes.
It would be useful to describe the function of gpios in a way that either subsystems can bind to them (e.g. leds, rf-kill, keys, etc.) or that information can be exported to userspace.
Quoted 11 lines
However it requires userspace to know the gpio number that has been assigned by the kernel.
That number, in the case of gpio drviers using dynamic allocation, is not fixed, and may change when:
* The kernel version changes andARCH_NR_GPIOSis changed (happened in 3.17)
* The kernel version changes and probe order changes for gpio chips.
* The kernel configuration is changed ifCONFIG_ARCH_NR_GPIOis used
* The board is redesigned (eg switching an externally visible signal from a SoC provided GPIO to an I2C expander chip or vice versa).
* Other GPIO chips are added to the system.
Isn't there some plan/desire to fix the GPIO sysfs interface?
Quoted 16 lines
The above means that, in order to export the GPIO to userspace via
/sys/class/gpio/exportthe userspace code must know the exact hardware and kernel version information.Furthermore, in many cases, it makes no sense to allow userspace to change the signal direction; even if the GPIO itself allows it the circuitry connected to the pin often does not (eg a signal dedicated to an output function driving a transistor).
This patch series solves both problems by performing the external signal => GPIO mapping in the device tree.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
cover gpio: Allow userspace export from DT
Quoted 11 lines · Rob Herring
Quoted 8 lines · Martin Fuzzey
That number, in the case of gpio drviers using dynamic allocation, is not fixed, and may change when:
* The kernel version changes andARCH_NR_GPIOSis changed (happened in 3.17)
* The kernel version changes and probe order changes for gpio chips.
* The kernel configuration is changed ifCONFIG_ARCH_NR_GPIOis used
* The board is redesigned (eg switching an externally visible signal from a SoC provided GPIO to an I2C expander chip or vice versa).
* Other GPIO chips are added to the system.
Quoted 1 line
Isn't there some plan/desire to fix the GPIO sysfs interface?
Desire yes. But well noone seems to do it...
There is also the perpetual abuse of sysfs to do things that should be done in the kernel, like driving LEDs or reading switches. But that's another problem I guess.
Yours,
Linus Walleij
cover gpio: Allow userspace export from DT
In reply to Martin FuzzeyQuoted 15 lines · Martin Fuzzey
Currently the gpio sysfs interface allows userspace to access simple hardware where no kernel driver exists or would be useful.
However it requires userspace to know the gpio number that has been assigned by the kernel.
That number, in the case of gpio drviers using dynamic allocation, is not fixed, and may change when:
* The kernel version changes andARCH_NR_GPIOSis changed (happened in 3.17)
* The kernel version changes and probe order changes for gpio chips.
* The kernel configuration is changed ifCONFIG_ARCH_NR_GPIOis used
* The board is redesigned (eg switching an externally visible signal from a SoC provided GPIO to an I2C expander chip or vice versa).
* Other GPIO chips are added to the system.
Quoted 3 lines
The above means that, in order to export the GPIO to userspace via
/sys/class/gpio/exportthe userspace code must know the exact hardware and kernel version information.
Not quite. You can still determine the gpio number in the above cases by walking the sysfs tree to find the chip and it's base. This is the only way to do this for dynamic buses such as USB.
The only case for which this fails is if a pin function is moved (e.g. your i2c-expander case above).
Quoted 4 lines
Furthermore, in many cases, it makes no sense to allow userspace to change the signal direction; even if the GPIO itself allows it the circuitry connected to the pin often does not (eg a signal dedicated to an output function driving a transistor).
Indeed. The current sysfs-interface is a hack (which I personally think never should have been merged).
Firmware should describe pin directionality and function, and undefined pins should never be allowed to be accessed from userspace.
Sure, the current GPIO-sysfs-interface is useful during development and for one-off hacks, but I'm convinced it's detrimental in the long run as it removes the incentives to fix the driver code that it's used to work around (e.g. custom init script to toggle enable lines of some radio chips).
Quoted 2 lines
This patch series solves both problems by performing the external signal => GPIO mapping in the device tree.
As Rob already mentioned, what we want is some way to declare pin functions. These could then be requested from userspace (or used in DT, something which should allow for further refactoring there as well) unless a driver has already claimed them.
We don't want to add more dependencies on the current sysfs-based interface, which I hope we'll one day will be able to retire in favour of a more sane one.
Johan
cover gpio: Allow userspace export from DT
Quoted 9 lines · Johan Hovold
Quoted 3 lines · Martin Fuzzey
The above means that, in order to export the GPIO to userspace via
/sys/class/gpio/exportthe userspace code must know the exact hardware and kernel version information.Not quite. You can still determine the gpio number in the above cases by walking the sysfs tree to find the chip and it's base. This is the only way to do this for dynamic buses such as USB.
Maybe we should start providing something like an "lsgpio" utility in tools/gpio to do this, just as a hint to userspace people on how things should be done.
Quoted 7 lines
Quoted 2 lines
This patch series solves both problems by performing the external signal => GPIO mapping in the device tree.
As Rob already mentioned, what we want is some way to declare pin functions. These could then be requested from userspace (or used in DT, something which should allow for further refactoring there as well) unless a driver has already claimed them.
We have the ability to name the GPIO lines (I usually refer to lines rather than pins, as pins are physical and not all GPIOs are, actually) using the array "names" in struct gpio_chip, however this has no DT binding, so maybe people should work on that. These names appear as named line files in sysfs IIRC. Or maybe you're thinking of something else?
Quoted 3 lines
We don't want to add more dependencies on the current sysfs-based interface, which I hope we'll one day will be able to retire in favour of a more sane one.
Agree.
Yours,
Linus Walleij
cover gpio: Allow userspace export from DT
Quoted 7 lines · Linus Walleij
Quoted 6 lines · Johan Hovold
Quoted 3 lines · Martin Fuzzey
The above means that, in order to export the GPIO to userspace via
/sys/class/gpio/exportthe userspace code must know the exact hardware and kernel version information.
Quoted 7 lines
Quoted 3 lines
Not quite. You can still determine the gpio number in the above cases by walking the sysfs tree to find the chip and it's base. This is the only way to do this for dynamic buses such as USB.
Maybe we should start providing something like an "lsgpio" utility in
tools/gpioto do this, just as a hint to userspace people on how things should be done.
I think we should focus on defining a new user-space interface rather than make it easier to use the current one (it should really only be used for development or one-off hacks IMO).
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
This patch series solves both problems by performing the external signal => GPIO mapping in the device tree.
As Rob already mentioned, what we want is some way to declare pin functions. These could then be requested from userspace (or used in DT, something which should allow for further refactoring there as well) unless a driver has already claimed them.
Quoted 6 lines
We have the ability to name the GPIO lines (I usually refer to lines rather than pins, as pins are physical and not all GPIOs are, actually) using the array "names" in struct
gpio_chip, however this has no DT binding, so maybe people should work on that. These names appear as named line files in sysfs IIRC. Or maybe you're thinking of something else?
Yes, something like that. As you mention above, if it was possibly to define those names in firmware, even the current sysfs interface would expose the pins as
/sys/class/gpio/<function>
rather than say /sys/class/gpio/gpio279, thereby solving the gpio-number look-up issue. Well, to actually make the pin available *from* userspace you'd currently still need the number...
Johan
cover gpio: Allow userspace export from DT
Quoted 5 lines · Johan Hovold
Quoted 3 lines · Linus Walleij
Quoted 1 line · Johan Hovold
On Mon, Apr 13, 2015 at 01:05:15PM +0200, Martin Fuzzey wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 3 lines
The above means that, in order to export the GPIO to userspace via
/sys/class/gpio/exportthe userspace code must know the exact hardware and kernel version information.Not quite. You can still determine the gpio number in the above cases by walking the sysfs tree to find the chip and it's base. This is the only way to do this for dynamic buses such as USB.
A problem with that is that the "label" sysfs attribute is not necessarilly unique (and is even documented as being non unique). Many drivers just use the chip name as the label so if you have more than one of them...
Of course if you know the bus and bus address it is possible to find the associated GPIO base but why should userspace have to know that? Isn't the whole point of the DT to describe such hardware details?
Quoted 8 lines
Quoted 3 lines
Maybe we should start providing something like an "lsgpio" utility in
tools/gpioto do this, just as a hint to userspace people on how things should be done.I think we should focus on defining a new user-space interface rather than make it easier to use the current one (it should really only be used for development or one-off hacks IMO).
Doesn't the ability to name GPIOs, fix their direction, and "pre export" them in the device tree remove most of the warts of the current interface? (for GPIOs for which it is used in any case)
While I agree that the sysfs GPIO interface is sometimes abused (such as for LEDs and switches which already have proper kernel drivers) there are still cases where a full kernel driver doesn't really make sense (eg a signal to open a parking barrier) - is anyone suggesting this needs a custom driver or that the LED one should be used - setting the heartbeat trigger on that would be interesting .... :)
Quoted 21 lines
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
This patch series solves both problems by performing the external signal => GPIO mapping in the device tree.
As Rob already mentioned, what we want is some way to declare pin functions. These could then be requested from userspace (or used in DT, something which should allow for further refactoring there as well) unless a driver has already claimed them.
Quoted 6 lines
We have the ability to name the GPIO lines (I usually refer to lines rather than pins, as pins are physical and not all GPIOs are, actually) using the array "names" in struct
gpio_chip, however this has no DT binding, so maybe people should work on that. These names appear as named line files in sysfs IIRC. Or maybe you're thinking of something else?Yes, something like that. As you mention above, if it was possibly to define those names in firmware, even the current sysfs interface would expose the pins as
Quoted 6 lines
/sys/class/gpio/<function>
rather than say
/sys/class/gpio/gpio279, thereby solving the gpio-number look-up issue. Well, to actually make the pin available *from* userspace you'd currently still need the number...
Indeed that doesn't solve the how to export it problem. AFAICT nothing is visible in sysfs until the export has been done.
Martin
Signature · 5 lines
-- Martin Fuzzey | Software Expertise Parc La Fayette - 6 rue Isaac Newton - 25075 Besan?on - FR +33381546880 | +33677158582 mfuzzey at parkeon.com | www.parkeon.com
cover gpio: Allow userspace export from DT
Quoted 14 lines · Martin
Quoted 4 lines · Johan Hovold
Quoted 3 lines · Linus Walleij
Quoted 1 line · Johan Hovold
On Mon, Apr 13, 2015 at 01:05:15PM +0200, Martin Fuzzey wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 3 lines
The above means that, in order to export the GPIO to userspace via
/sys/class/gpio/exportthe userspace code must know the exact hardware and kernel version information.Not quite. You can still determine the gpio number in the above cases by walking the sysfs tree to find the chip and it's base. This is the only way to do this for dynamic buses such as USB.
Quoted 8 lines
A problem with that is that the "label" sysfs attribute is not necessarilly unique (and is even documented as being non unique). Many drivers just use the chip name as the label so if you have more than one of them...
Of course if you know the bus and bus address it is possible to find the associated GPIO base but why should userspace have to know that? Isn't the whole point of the DT to describe such hardware details?
Yes, eventually, but the current gpio sysfs-interface does not allow for that information to be confined to DT. It has always required knowledge of the hardware (e.g. the pin numbers), but people eventually discovered that those numbers may actually change.
I'm only pointing out that *that* particular quirk can be worked around by providing different information about the hardware (e.g. the bus topology).
IMO, the current interface should remain to be a pain to use so that people either fix the drivers or start working on a replacement user-space interface.
Quoted 11 lines
Quoted 8 lines
Quoted 3 lines
Maybe we should start providing something like an "lsgpio" utility in
tools/gpioto do this, just as a hint to userspace people on how things should be done.I think we should focus on defining a new user-space interface rather than make it easier to use the current one (it should really only be used for development or one-off hacks IMO).
Doesn't the ability to name GPIOs, fix their direction, and "pre export" them in the device tree remove most of the warts of the current interface? (for GPIOs for which it is used in any case)
I agree with you that such properties (e.g. direction and function) should be defined in DT. A gpio should not be exported until requested by userspace though. This allow for the case where a userspace driver can be used as a fall back if a kernel driver isn't available or loaded.
Quoted 19 lines
Quoted 19 lines
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
This patch series solves both problems by performing the external signal => GPIO mapping in the device tree.
As Rob already mentioned, what we want is some way to declare pin functions. These could then be requested from userspace (or used in DT, something which should allow for further refactoring there as well) unless a driver has already claimed them.
Quoted 6 lines
We have the ability to name the GPIO lines (I usually refer to lines rather than pins, as pins are physical and not all GPIOs are, actually) using the array "names" in struct
gpio_chip, however this has no DT binding, so maybe people should work on that. These names appear as named line files in sysfs IIRC. Or maybe you're thinking of something else?Yes, something like that. As you mention above, if it was possibly to define those names in firmware, even the current sysfs interface would expose the pins as
Quoted 8 lines
Quoted 6 lines
/sys/class/gpio/<function>
rather than say
/sys/class/gpio/gpio279, thereby solving the gpio-number look-up issue. Well, to actually make the pin available *from* userspace you'd currently still need the number...Indeed that doesn't solve the how to export it problem. AFAICT nothing is visible in sysfs until the export has been done.
That will be solved by the new userspace interface. ;)
Johan
Quoted 23 lines · Linus Walleij
Quoted 9 lines · Johan Hovold
Quoted 3 lines · Martin Fuzzey
The above means that, in order to export the GPIO to userspace via
/sys/class/gpio/exportthe userspace code must know the exact hardware and kernel version information.Not quite. You can still determine the gpio number in the above cases by walking the sysfs tree to find the chip and it's base. This is the only way to do this for dynamic buses such as USB.
Maybe we should start providing something like an "lsgpio" utility in
tools/gpioto do this, just as a hint to userspace people on how things should be done.Quoted 7 lines
Quoted 2 lines
This patch series solves both problems by performing the external signal => GPIO mapping in the device tree.
As Rob already mentioned, what we want is some way to declare pin functions. These could then be requested from userspace (or used in DT, something which should allow for further refactoring there as well) unless a driver has already claimed them.
Quoted 6 lines
We have the ability to name the GPIO lines (I usually refer to lines rather than pins, as pins are physical and not all GPIOs are, actually) using the array "names" in struct
gpio_chip, however this has no DT binding, so maybe people should work on that. These names appear as named line files in sysfs IIRC. Or maybe you're thinking of something else?
This problem is in many ways the similar to LEDs.
cover gpio: Allow userspace export from DT
In reply to Johan HovoldQuoted 2 lines · Johan Hovold
Firmware should describe pin directionality and function, and undefined pins should never be allowed to be accessed from userspace.
No, that's totally wrong if you consider one of the most common use cases out there...
Think about something like a Raspberry Pi, where you have a header with GPIOs on it, which can be used for multiple different purposes (and are even multiplexed with some on-SoC functions.)
"Firmware" can't know about all possible configurations of those IO pins.
That's why Raspberry Pi uses a userspace helper and programs stuff up appropriately for the users application.
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
cover gpio: Allow userspace export from DT
Quoted 7 lines · Russell King - ARM Linux
Quoted 2 lines · Johan Hovold
Firmware should describe pin directionality and function, and undefined pins should never be allowed to be accessed from userspace.
No, that's totally wrong if you consider one of the most common use cases out there...
Quoted 8 lines
Think about something like a Raspberry Pi, where you have a header with GPIOs on it, which can be used for multiple different purposes (and are even multiplexed with some on-SoC functions.)
"Firmware" can't know about all possible configurations of those IO pins.
That's why Raspberry Pi uses a userspace helper and programs stuff up appropriately for the users application.
I'm not familiar with exactly how the RPi handles its pin muxing, but even if it requires userspace interaction that should not prevent having firmware describe the pins.
In general, if the hardware configuration is static we use device trees.
If the configuration is dynamic we use device-tree overlays; either loaded manually or by some service (e.g. Beaglebone capes). Perhaps this could be handled by the RPi helper.
And for experimentation / development, firmware could even be totally non-restrictive by simply declaring generic pin "functions" like "expansion-pin-4" and even allow for the direction to be changed.
Johan
cover gpio: Allow userspace export from DT
Quoted 12 lines · Johan Hovold
Quoted 11 lines · Russell King - ARM Linux
Quoted 2 lines · Johan Hovold
Firmware should describe pin directionality and function, and undefined pins should never be allowed to be accessed from userspace.
No, that's totally wrong if you consider one of the most common use cases out there...
Think about something like a Raspberry Pi, where you have a header with GPIOs on it, which can be used for multiple different purposes (and are even multiplexed with some on-SoC functions.)
Quoted 8 lines
Quoted 4 lines
"Firmware" can't know about all possible configurations of those IO pins.
That's why Raspberry Pi uses a userspace helper and programs stuff up appropriately for the users application.
I'm not familiar with exactly how the RPi handles its pin muxing, but even if it requires userspace interaction that should not prevent having firmware describe the pins.
How it handles this is... it doesn't. Userspace does it.
There is *no* "firmware" on these devices. The only thing you have is a boot loader and a DT blob, and people will hate you if you tell them that they have to change the DT blob and then reboot their systems to change the functionality of a GPIO pin.
It's also entirely reasonable to assume that people are going to want to change the configuration at runtime, given their diverse range of applications.
Quoted 5 lines
In general, if the hardware configuration is static we use device trees.
If the configuration is dynamic we use device-tree overlays; either loaded manually or by some service (e.g. Beaglebone capes). Perhaps this could be handled by the RPi helper.
Yes, that _could_ work, but I bet asking millions of people to change what they're doing is going to be extremely difficult. Remember the golden rule of the kernel: thou shalt not break userspace.
So, there is _no_ possibility of removing this GPIO exposure to userspace because we _know_ that it will break people.
If you think differently on the "thou shalt not break userspace" please don't discuss it with me, I'm not interested. Linus isn't interested either, and if you try and discuss it with him, he'll tell you to get out of kernel programming. :)
This is a commonly used API. You can't change it.
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
cover gpio: Allow userspace export from DT
Quoted 24 lines · Russell King - ARM Linux
Quoted 12 lines · Johan Hovold
Quoted 11 lines · Russell King - ARM Linux
Quoted 2 lines · Johan Hovold
Firmware should describe pin directionality and function, and undefined pins should never be allowed to be accessed from userspace.
No, that's totally wrong if you consider one of the most common use cases out there...
Think about something like a Raspberry Pi, where you have a header with GPIOs on it, which can be used for multiple different purposes (and are even multiplexed with some on-SoC functions.)
Quoted 8 lines
Quoted 4 lines
"Firmware" can't know about all possible configurations of those IO pins.
That's why Raspberry Pi uses a userspace helper and programs stuff up appropriately for the users application.
I'm not familiar with exactly how the RPi handles its pin muxing, but even if it requires userspace interaction that should not prevent having firmware describe the pins.
How it handles this is... it doesn't. Userspace does it.
Quoted 8 lines
There is *no* "firmware" on these devices. The only thing you have is a boot loader and a DT blob, and people will hate you if you tell them that they have to change the DT blob and then reboot their systems to change the functionality of a GPIO pin.
It's also entirely reasonable to assume that people are going to want to change the configuration at runtime, given their diverse range of applications.
DT can be changed at run-time using overlays.
This way the RPi users could define their i2c-clients, or whatever buses they choose to expose on those pins as well.
Quoted 13 lines
Quoted 5 lines
In general, if the hardware configuration is static we use device trees.
If the configuration is dynamic we use device-tree overlays; either loaded manually or by some service (e.g. Beaglebone capes). Perhaps this could be handled by the RPi helper.
Yes, that _could_ work, but I bet asking millions of people to change what they're doing is going to be extremely difficult. Remember the golden rule of the kernel: thou shalt not break userspace.
So, there is _no_ possibility of removing this GPIO exposure to userspace because we _know_ that it will break people.
Quoted 6 lines
If you think differently on the "thou shalt not break userspace" please don't discuss it with me, I'm not interested. Linus isn't interested either, and if you try and discuss it with him, he'll tell you to get out of kernel programming. :)
This is a commonly used API. You can't change it.
I've never suggested that we remove the current API, but *only* exposing a totally non-restrictive interface for systems not used by school children and hardware hackers is not sane.
You also cut out the part in my reply about continuing to allow unrestricted access for such cases. That could still continue to be the default (e.g. when there are no pin function names defined in DT).
And if those people ever update their DTs they could benefit from the deterministic pin naming without loosing any flexibility too.
Johan
cover gpio: Allow userspace export from DT
Quoted 63 lines · Johan Hovold
Quoted 24 lines · Russell King - ARM Linux
Quoted 12 lines · Johan Hovold
Quoted 11 lines · Russell King - ARM Linux
Quoted 2 lines · Johan Hovold
Firmware should describe pin directionality and function, and undefined pins should never be allowed to be accessed from userspace.
No, that's totally wrong if you consider one of the most common use cases out there...
Think about something like a Raspberry Pi, where you have a header with GPIOs on it, which can be used for multiple different purposes (and are even multiplexed with some on-SoC functions.)
Quoted 8 lines
Quoted 4 lines
"Firmware" can't know about all possible configurations of those IO pins.
That's why Raspberry Pi uses a userspace helper and programs stuff up appropriately for the users application.
I'm not familiar with exactly how the RPi handles its pin muxing, but even if it requires userspace interaction that should not prevent having firmware describe the pins.
How it handles this is... it doesn't. Userspace does it.
Quoted 8 lines
There is *no* "firmware" on these devices. The only thing you have is a boot loader and a DT blob, and people will hate you if you tell them that they have to change the DT blob and then reboot their systems to change the functionality of a GPIO pin.
It's also entirely reasonable to assume that people are going to want to change the configuration at runtime, given their diverse range of applications.
DT can be changed at run-time using overlays.
This way the RPi users could define their i2c-clients, or whatever buses they choose to expose on those pins as well.
Quoted 13 lines
Quoted 5 lines
In general, if the hardware configuration is static we use device trees.
If the configuration is dynamic we use device-tree overlays; either loaded manually or by some service (e.g. Beaglebone capes). Perhaps this could be handled by the RPi helper.
Yes, that _could_ work, but I bet asking millions of people to change what they're doing is going to be extremely difficult. Remember the golden rule of the kernel: thou shalt not break userspace.
So, there is _no_ possibility of removing this GPIO exposure to userspace because we _know_ that it will break people.
Quoted 6 lines
If you think differently on the "thou shalt not break userspace" please don't discuss it with me, I'm not interested. Linus isn't interested either, and if you try and discuss it with him, he'll tell you to get out of kernel programming. :)
This is a commonly used API. You can't change it.
I've never suggested that we remove the current API, but *only* exposing a totally non-restrictive interface for systems not used by school children and hardware hackers is not sane.
Quoted 6 lines
You also cut out the part in my reply about continuing to allow unrestricted access for such cases. That could still continue to be the default (e.g. when there are no pin function names defined in DT).
And if those people ever update their DTs they could benefit from the deterministic pin naming without loosing any flexibility too.
Just to not let Johan alone:
I totally agree with Johan and looking for this export for at least 2 years. Jiri
Quoted 7 lines
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cover gpio: Allow userspace export from DT
In reply to Johan HovoldQuoted 11 lines · Johan Hovold
Quoted 8 lines · Russell King - ARM Linux
There is *no* "firmware" on these devices. The only thing you have is a boot loader and a DT blob, and people will hate you if you tell them that they have to change the DT blob and then reboot their systems to change the functionality of a GPIO pin.
It's also entirely reasonable to assume that people are going to want to change the configuration at runtime, given their diverse range of applications.
DT can be changed at run-time using overlays.
Yes, I'm aware of that, but that code is really not nice. There is no notification system to drivers that something has changed, and with a GPIO driver, you really don't want the driver to be unbound and re-bound just because something changed. That has the very real possibility to disrupt users of other GPIOs.
I'm not sure what kind of driver you'd attach userspace GPIO pinctrl settings to other than the GPIO driver.
Sure, if you're wanting to configure a couple of GPIOs as I2C, then yes, you certainly should put the binding in the I2C device block in DT, but you don't always have a device to do that with.
Quoted 3 lines
You also cut out the part in my reply about continuing to allow unrestricted access for such cases. That could still continue to be the default (e.g. when there are no pin function names defined in DT).
Yes, that's standard Internet email etiquette - cut everything from the message you're replying to which is not part of the context of the immediate reply. I'd include a URL to that, but unfortunately google seems broken (it's inserting a refresh into the results page which causes elinks to continually refetch the same page, eventually triggering a violation of googles terms of use... yea, quite funny that google is instructing browsers to violate their own terms of use.)
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
cover gpio: Allow userspace export from DT
Quoted 11 lines · Russell King - ARM Linux
Quoted 10 lines · Johan Hovold
Quoted 8 lines · Russell King - ARM Linux
There is *no* "firmware" on these devices. The only thing you have is a boot loader and a DT blob, and people will hate you if you tell them that they have to change the DT blob and then reboot their systems to change the functionality of a GPIO pin.
It's also entirely reasonable to assume that people are going to want to change the configuration at runtime, given their diverse range of applications.
Quoted 7 lines
Quoted 1 line
DT can be changed at run-time using overlays.
Yes, I'm aware of that, but that code is really not nice. There is no notification system to drivers that something has changed, and with a GPIO driver, you really don't want the driver to be unbound and re-bound just because something changed. That has the very real possibility to disrupt users of other GPIOs.
Yes, you'd need to configure your gpio chip before you start using it.
And for your RPi use case, things need not change much if the default mode if undefined, or the default DT, continue to allow for full flexibility.
But I imagine that even for such use cases some people will want to configure pin directionality and default modes in DT (blob or overlay) to limit potential damage from bugs in userspace applications.
And everyone should benefit from persistent, predictable pin names.
Quoted 11 lines
Quoted 3 lines
You also cut out the part in my reply about continuing to allow unrestricted access for such cases. That could still continue to be the default (e.g. when there are no pin function names defined in DT).
Yes, that's standard Internet email etiquette - cut everything from the message you're replying to which is not part of the context of the immediate reply. I'd include a URL to that, but unfortunately google seems broken (it's inserting a refresh into the results page which causes elinks to continually refetch the same page, eventually triggering a violation of googles terms of use... yea, quite funny that google is instructing browsers to violate their own terms of use.)
Yes, but in this case you argued using an example that I had already discussed in the part of the email that you left out (i.e. how to not break userspace by continuing to allow full flexibility if desired).
Johan