gpio: Allow userspace export from DT
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 2 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 2 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/2] 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