On Fri, Jun 07, 2013 at 01:36:16PM +0200, Linus Walleij wrote:

On Mon, Jun 3, 2013 at 11:42 AM, Christian Ruppert
[off-list ref] wrote:

quoted

Ease of use is also the reason why I added the gpio-base property to the
original driver: Finding out the global GPIO number to use in
/sys/class/gpio for a given GPIO of a given bank seems to be a recurring
headache for our customers and the definition of the bank's base number
in the device tree is an attempt to improve this situation.

What you need to do in that case is to find a way to name the pins
in sysfs (creating symbolic links with the GPIO pin name) so they
can use these names in sysfs instead.

There is no ambition from my side to try to correlate the
GPIO sysfs interface and device trees. This is because the GPIO
sysfs is not universally liked. And when you say you want to make the
sysfs ABI easy to use that lights a big red light on my panel. I will
explain why.

What is very important is that your customers understand that
the GPIO sysfs shall not be used for things like:

- LEDs
- Switches
- Regulators
- Camera muxes
- etc

From the kernel community we have tried (or atleast I have tried)
that this kind of hardware shall be handled by the apropriate linux
subsystems, and not by obscure userspace code.

I totally agree with that and we already declare the LEDs etc. on our
PCBs in the device trees. However, we have at least one customer who has
a user space driver for some peripheral on i2c which needs to be reset
through GPIO. I'm not sure which framework to use for this sort of
applications.

Greetings,
  Christian

-- 
  Christian Ruppert              ,          [off-list ref]
                                /|
  Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pré-Fleuri
                             _// | bilis Systems   CH-1228 Plan-les-Ouates