Re: sysfs: wait for GPIO interrupt

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Wed, May 14, 2014 at 9:47 AM, Yegor Yefremov
<yegorslists@xxxxxxxxxxxxxx> wrote:
> On Tue, May 13, 2014 at 11:48 AM, Linus Walleij

>> The basic rule is that the kernel shall handle hardware, and I just
>> get the feeling you are doing some userspace driver that should be
>> in the kernel instead.
>
> But what do you suggest to use for a system, that has a connector with
> for example 8 I/Os made via i2c I/O expander?

Depends on what they want to do with them. The GPIO expander
itself is a GPIO driver, then if there are LEDs on it, then it should
use drivers/leds/leds-gpio.c, if it's handling keys it should use
drivers/input/keyboard/gpio_keys.c (or the polled variant if the expander
does not support IRQs) etc.

> The system just provides
> a general Linux BSP, so that the customer is then responsible for the
> final software. The customer is not a kernel hacker and it is very
> simple to program via sysfs especially, when you have a wrapper
> library,

Trying to simplify the act of driving hardware is the opposite of
empowering users. They should be able to get to the guts
of what they actually want to do. If they can do such advanced stuff
as electronics and sysfs manipulation I think kernel drivers are
not much harder.

> Is it planned to provide a GPIO interface via IOCTLs for userspace or
> something like this?

That is atleast better than using sysfs, but we need someone to drive
that to make it happen.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html