Re: sysfs: wait for GPIO interrupt

[Javier Martinez Canillas <javier@xxxxxxxxxxxx>]

On Wed, May 14, 2014 at 9:47 AM, Yegor Yefremov
<yegorslists@xxxxxxxxxxxxxx> wrote:
> 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,
>

I was wondering the same. Unfortunately writing a small device driver
that uses gpiolib from the kernel is sometimes not possible for many
companies. Even though writing kernel code is not too different than
user-space C code there are some things to take into account so you
need some special training. Thus having an easy to use interface to
control GPIO from user-space is very handy.

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

If Linus agrees that a better GPIO interface that model the GPIO
operations can be developed using a set of ioctl commands or netlink
sockets I'll be very glad to help with the implementation.

On a related note I see that people are asking how they can mux a SoC
pin in GPIO mode in order to use the GPIO sysfs interface. For example
take a look to this thread [0].

When OMAP was not using pinctrl-single but a custom driver for pin
configuration there was a debugfs interface
(/sys/kernel/debug/omap_mux) that allowed to change the pin mux setup.

I agree that this was not pretty since a user-space program could step
into other drivers toes and make devices to stop working. But I wonder
if we can have a similar interface under
/sys/kernel/debug/pinctrl/<pinctrl_dev> where a subset of the pins can
be changed from user-space. Probably not in a secure way...

And after all, users can still modify their DT to mux the needed pins
in GPIO mode which is not that bad either.

Best regards,
Javier

[0]: http://comments.gmane.org/gmane.linux.redhat.fedora.arm/7644
--
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