Re: sysfs: wait for GPIO interrupt

[Yegor Yefremov <yegorslists@xxxxxxxxxxxxxx>]

On Fri, May 16, 2014 at 7:28 PM, Javier Martinez Canillas
<javier@xxxxxxxxxxxx> wrote:
> Hello Linus,
>
> Thanks a lot for your explanations.
>
> On Fri, May 16, 2014 at 6:43 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>> On Wed, May 14, 2014 at 11:32 AM, Javier Martinez Canillas
>> <javier@xxxxxxxxxxxx> wrote:
>>
>>> 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.
>>
>> That needs to be discussed with the wider kernel community and will
>> be a quite daunting task. But if you have the geist, do go ahead. Involved
>> people would include Grant Likely and Greg Kroah-Hartmann.
>>
>
> If the correct approach is to drive the hardware using the GPIO from
> the kernel then I think that is better to not add another interface
> that can be (ab)used from user-space.
>
> It would be nice if Yegor can give more details about the device that
> are using those GPIO and what he wants to achieve from user-space to
> see if an existing device driver can be used or in any case if a
> generic driver can be written like is done for GPIO leds, keys, etc.

Let's take VScom Alekto 2 (http://www.visionsystems.de/produkte/6820.html).

It has a combi RS232/422/485 driver IC, that has 4 configuration
inputs to set one of the desired modes. These pins are connected via
GPIOs (SoC GPIOs or i2c GPIO expander doesn't matter). The user can
configure these option at run-time. Now he can make it via sysfs by
exporting these GPIOs, setting them to output and changing their
values. What would be the proper kernel driver/interface for this
purpose.

It also has an IO connector with configurable inputs and outputs. The
problem here it has somewhat complicated structure, because you can
switch direction of the IO pins but this involves enabling/disabling
some hardware ICs. The whole mechanism is  hidden from user through a
library, but the library itself is still using sysfs.

As for simple designs where the direction of the pins is fixed the
keys driver can be used for inputs, what were the proper driver for
outputs (relays etc.)?

>>> 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].
>>
>> Pin control shall be handled in the kernel.
>>
>>> 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.
>>
>> If people want to do crazy stuff from userspace and they use
>> debugfs for that, they should be aware what the rules of debugfs
>> is: it is *NOT* an ABI! We may break that just because we feel
>> like it.
>>
>
> Yeah, that interface was not secure either since iirc you could change
> any padconf setup hence making devices that relied on a certain pin
> mux mode to not work anymore.
>
>> There are no plans for a proper userspace interface for pin control,
>> if that is desired an even bigger undertaking than moving GPIOs to
>> ioctl():s etc will be needed.
>>
>> But here, too, I think the real answer is: edit device tree files.
>>
>
> Perfect, as I said on a previous email it can be done by editing the
> device tree file, I just wanted to double check with you if that was
> the suggested approach for doing this.
>
> Yegor, it seems you got your answer :-)

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