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

[Johan Hovold]

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:
> > On Wed, May 06, 2015 at 01:57:08PM +0100, Russell King - ARM Linux wrote:
> > > 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.

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