[PATCH 0/2] gpio: Allow userspace export from DT

On Thu, May 07, 2015 at 01:28:40PM +0100, Russell King - ARM Linux wrote:

On Wed, May 06, 2015 at 03:25:20PM +0200, Johan Hovold wrote:

quoted

On Wed, May 06, 2015 at 01:57:08PM +0100, Russell King - ARM Linux wrote:

quoted

There is *no* "firmware" on these devices.  The only thing you have is a
boot loader and a DT blob, and people will hate you if you tell them that
they have to change the DT blob and then reboot their systems to change
the functionality of a GPIO pin.

It's also entirely reasonable to assume that people are going to want to
change the configuration at runtime, given their diverse range of
applications.

DT can be changed at run-time using overlays.

Yes, I'm aware of that, but that code is really not nice.  There is no
notification system to drivers that something has changed, and with a
GPIO driver, you really don't want the driver to be unbound and
re-bound just because something changed.  That has the very real
possibility to disrupt users of other GPIOs.

Yes, you'd need to configure your gpio chip before you start using it.

And for your RPi use case, things need not change much if the default
mode if undefined, or the default DT, continue to allow for full
flexibility.

But I imagine that even for such use cases some people will want to
configure pin directionality and default modes in DT (blob or overlay)
to limit potential damage from bugs in userspace applications.

And everyone should benefit from persistent, predictable pin names.

quoted

You also cut out the part in my reply about continuing to allow
unrestricted access for such cases. That could still continue to be the
default (e.g. when there are no pin function names defined in DT).

Yes, that's standard Internet email etiquette - cut everything from
the message you're replying to which is not part of the context of the
immediate reply.  I'd include a URL to that, but unfortunately google
seems broken (it's inserting a refresh into the results page which causes
elinks to continually refetch the same page, eventually triggering a
violation of googles terms of use... yea, quite funny that google is
instructing browsers to violate their own terms of use.)

Yes, but in this case you argued using an example that I had already
discussed in the part of the email that you left out (i.e. how to not
break userspace by continuing to allow full flexibility if desired).

Johan