On Fri, Jun 07, 2013 at 01:36:16PM +0200, Linus Walleij wrote:
> On Mon, Jun 3, 2013 at 11:42 AM, Christian Ruppert
> <christian.ruppert@xxxxxxxxxx> wrote:
>
> > 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 , <christian.ruppert@xxxxxxxxxx>
/|
Tel: +41/(0)22 816 19-42 //| 3, Chemin du Pré-Fleuri
_// | bilis Systems CH-1228 Plan-les-Ouates
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
