Re: sysfs: wait for GPIO interrupt

[Javier Martinez Canillas <javier@xxxxxxxxxxxx>]

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.

>> 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 :-)

> Yours,
> Linus Walleij

Best regards,
Javier
--
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