Re: sysfs: wait for GPIO interrupt

[Yegor Yefremov <yegorslists@xxxxxxxxxxxxxx>]

Hello Linus,

On Tue, May 13, 2014 at 11:48 AM, Linus Walleij
<linus.walleij@xxxxxxxxxx> wrote:
> On Tue, May 13, 2014 at 1:45 AM, Javier Martinez Canillas
> <javier@xxxxxxxxxxxx> wrote:
>> Hello Yegor,
>> On Thu, May 8, 2014 at 10:19 AM, Yegor Yefremov
>> <yegorslists@xxxxxxxxxxxxxx> wrote:
>>> I've stumbled upon following issue. When waiting for interrupt with
>>> poll() like described in this example [1], the program returns from
>>> poll() immediately. This thread [2] describes a workaround for this
>>> issue via making read() before invoking poll().
>>>
>>> My system is am335x, kernel 3.15-rc4
>>>
>>> I experience this behavior by both SoC's own GPIO and i2c expander tca6416.
>>>
>>
>> I tested with an OMAP3 board which uses the same GPIO driver than the
>> am335x and I was able to reproduce your issue.
>
> At times like this I always want to warn you for using the GPIO sysfs
> interface which is a scary piece of code.
>
> And also to know what you are doing in userspace. Just hammering
> GPIOs is already a bad idea, reading *interrupts* from GPIOs in
> userspace is an even worse idea.
>
> 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? 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,

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

Yegor
--
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