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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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()?

Alex.
--
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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux