Re: [PATCH v3] gpio: add export with name from dts

["Jiří Prchal" <jiri.prchal@aksignal.cz>]

Hi all,

Dne 17.10.2013 20:03, Alexandre Courbot napsal(a):
> On Thu, Oct 17, 2013 at 8:04 AM, Mark Rutland <mark.rutland@arm.com> 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@aksignal.cz>
>>> ---
>>>   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.
Of course I can use gpio_export_with_link() to not change gpio_export().
But what I don't like on gpio_export_with_link() is that there will be twice more
dirs in sysfs and it would be less transparent and users confusing "What is the pioA30?"

Jiri