gpio: Allow userspace export from DT
Get series with b4
b4 am 20150504084925.GB4047@localhostVersions 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 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