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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Wed, May 06, 2015 at 02:43:54PM +0200, Johan Hovold wrote:
> On Wed, May 06, 2015 at 12:24:50PM +0100, Russell King - ARM Linux wrote:
> > On Mon, May 04, 2015 at 10:49:25AM +0200, Johan Hovold wrote:
> > > Firmware should describe pin directionality and function, and undefined
> > > pins should never be allowed to be accessed from userspace.
> > 
> > No, that's totally wrong if you consider one of the most common use
> > cases out there...
> > 
> > Think about something like a Raspberry Pi, where you have a header with
> > GPIOs on it, which can be used for multiple different purposes (and are
> > even multiplexed with some on-SoC functions.)
> > 
> > "Firmware" can't know about all possible configurations of those IO pins.
> > 
> > That's why Raspberry Pi uses a userspace helper and programs stuff up
> > appropriately for the users application.
> 
> I'm not familiar with exactly how the RPi handles its pin muxing, but
> even if it requires userspace interaction that should not prevent having
> firmware describe the pins.

How it handles this is... it doesn't.  Userspace does it.

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.

> In general, if the hardware configuration is static we use device trees.
> 
> If the configuration is dynamic we use device-tree overlays; either
> loaded manually or by some service (e.g. Beaglebone capes). Perhaps this
> could be handled by the RPi helper.

Yes, that _could_ work, but I bet asking millions of people to change
what they're doing is going to be extremely difficult.  Remember the
golden rule of the kernel: thou shalt not break userspace.

So, there is _no_ possibility of removing this GPIO exposure to userspace
because we _know_ that it will break people.

If you think differently on the "thou shalt not break userspace" please
don't discuss it with me, I'm not interested.  Linus isn't interested
either, and if you try and discuss it with him, he'll tell you to get
out of kernel programming. :)

This is a commonly used API.  You can't change it.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux