On Fri, Oct 18, 2013 at 08:04:02AM +0100, Jiří Prchal wrote: > Hi all, Hi Jiří, > > Dne 17.10.2013 20:03, Alexandre Courbot napsal(a): > > On Thu, Oct 17, 2013 at 8:04 AM, Mark Rutland <mark.rutland@xxxxxxx> wrote: > >> Hello Jiri, > >> > >> On Thu, Oct 17, 2013 at 01:08:02PM +0100, Jiri Prchal wrote: > >>> Add export possibility to sysfs with given name in device tree. It is nice for > >>> users to have board specific gpios exported at boot-time and with their names. > >>> It renames some functions in gpiolib and adds name as parameter. If it is passed > >>> NULL as name everything works like before, export by chip name. > >>> It can be done by extra function export_with_name without changing original > >>> export function but I think there would not to be twice almost the same. > >>> Even if gpio sysfs interface is almost to be deprecated, I would like to add > >>> this, cause new chardev interface is in farness future. > >>> Rebased from older unapplyed patch: [PATCH] owrt: GPIO: add gpio_export_with_name. > >>> v3: > >>> change to "linux,gpio-export" > >>> removed arrays of gpios, just one child node -> one GPIO line > >>> simplified node properties like as it's in gpio-leds > >>> if not label -> uses child node name > >>> > >>> Signed-off-by: Jiri Prchal <jiri.prchal@xxxxxxxxxxx> > >>> --- > >>> Documentation/devicetree/bindings/gpio/gpio.txt | 44 ++++++++++++++++++ > >>> drivers/gpio/gpiolib-of.c | 56 +++++++++++++++++++++++ > >>> drivers/gpio/gpiolib.c | 27 +++++++---- > >>> include/asm-generic/gpio.h | 6 ++- > >>> include/linux/gpio.h | 23 +++++++++- > >>> 5 files changed, 144 insertions(+), 12 deletions(-) > >> > >> As I mentioned on v1 of this patch [1], I do not think that this is the > >> right way to go about exporting GPIOs to userspace. Why do we need a > >> binding for a non-device to tell Linux (specifically Linux) whether or > >> not to represent a device to userspace, and how to do so? > >> > >> Why can this policy not be handled within the GPIO framework, or within > >> GPIO drivers? > > > > Pretty much agree with Mark here. There is no reason to limit this > > naming feature (which I'm not opposed to fundamentally) to the device > > tree. Besides gpio_export_with_link() does something suspisciously > > similar, and better-suited in my opinion: the GPIO keeps its > > hard-coded, predictable name but is also accessible through a link > > under the device that uses it. Since GPIOs are typically used as > > functions for devices this seems to make the most sense. > > > > But maybe I'm missing your point - could you describe a concrete > > use-case for this feature that can *not* be achieved using > > gpio_export_with_link()? > > The concrete use-case is that I have two boards with same I/O on them, but they use > two different SoC. And I like to shadow it to users. On one board is some I/O on > pioC16 and on the other it is on pioA30 for example. > I'd like to prepare I/O just with right board names for example in11. > I'm trying to do something like GPIOs LEDs, I like that interface, but I need it > for both direction. > So where else give the name then in DT. And why not to export it there. Just like > LEDs. The LED bindings represent devices attached to GPIO pins. This binding appears to describe the GPIO pins themselves. There are already bindings for the GPIO pins. If there is information associated with the GPIO pins themselves, that should be described in the GPIO bindings. If we want to export named pins in sysfs, that is the duty of the GPIO framework and GPIO drivers. I do not believe having a binding for a non-device that exists solely to express a naming preference makes any sense. We have a similar issue with assigning names to serial devices, and the approach taken there was to use an /aliases node. The same approach might be applicable here, but I see no reason to have this binding. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
