gpiolib: add support for having symlinks under gpio class directory
in [Kernel]
|
Prev: timeriomem-rng.c: use resource_size()
Next: [60/90] ext4: fix lock order problem in ext4_move_extents()
From: David Brownell on 10 Dec 2009 22:40 On Thursday 10 December 2009, Jani Nikula wrote: > GPIOs can be exported to gpiolib sysfs at /sys/class/gpio/ like this: > > # ls -l /sys/class/gpio/ > --w------- � �1 root � � 0 � � � � � �4096 Jan �1 00:00 export > lrwxrwxrwx � �1 root � � 0 � � � � � � � 0 Jan �1 00:00 gpio25 -> ../../devices/virtual/gpio/gpio25 > lrwxrwxrwx � �1 root � � 0 � � � � � � � 0 Jan �1 00:00 gpio38 -> ../../devices/virtual/gpio/gpio38 > ... Hmm, ISTR they don't always appear as "virtual" ... though that's pretty much irrelevant to the larger point you're making. Even when there are real device nodes for the gpio chips parenting any given GPIOs, they end up in fairly un-useful parts of the device tree (in terms of being related to something more significant than the random wires that were handy to the hardware designer). > The GPIO lines may and do change from board revision to another. For > example a power button's GPIO number might be 25 in board rev 1.0 but 66 > in board rev 1.1. > > We want to assign symbolic names to GPIO lines and hide the numbering > changes from userspace, because it is very painful to amend userspace > for every board revision. Related: these are part of what one might call "composite devices", which are crafted using a component from this subsystem, one from that, a few from over there, and so on. They don't properly belong in any single location in the device tree. Some level of symlinking seems inevitable. And no, a full fledged chardev node is inappropriate so I don't see udev as able to help out. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |