Hi Mark,
Dne 18.10.2013 12:36, Mark Rutland napsal(a):
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 I understand it, sould I make some GPIO device?
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.
I realy don't understan it, isn't it done in GPIO framework? Please, coul'd
you explain it more.
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.
I try to find something about /aliases, but without success.
In fact, I have that problem with serial too, this is my /aliases:
aliases {
serial0 = &dbgu;
serial2 = &usart0; /* SBUS */
serial3 = &usart1; /* RS1 */
serial5 = &usart2; /* EBUS */
serial4 = &usart3; /* RS2 */
};
and this is my ttyS:
ttyS0
ttyS1
ttyS3
ttyS4
ttyS5
Thank a lot
Jiri
--
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
