Re: Userspace and Device-Tree

On Mon, Aug 31, 2015 at 12:20:20PM -0700, Chris Read wrote:

Yes.  That is what we do.  We make custom boards for our main Arm
CPU board.  However, rather than create a new kernel driver for every
variant of hardware, we have the application software act like drivers in
cases where high speed isn't required (such as GPIOs and switching
on/off power supplies).

Yeah, so the power supplies bit is not something we want to encourage.

quoted

We really need people working on these maker devices to recognise that
Linux is a general purpose OS used on a wide ranging systems and that as
a result we need to explicitly describe things like expansion ports in
the DT rather than just hacking the system.  We don't want people making
routers and similar devices to form the impression that the simple and
idiomatic way to extend Linux is to just hack things from userspace.

I want to follow the standard paradigms and elegance of the mainline
kernel.  I don't want to create a set of hacks to do what we require, just
use standard kernel mechanisms and drivers.  I also don't want to have
to create custom drivers for every single board we create.  Nor do I want
to have a "board file" to initialize every board.

From what I see the standard kernel allows exposing GPIOs to userspace.
There are kernel calls to do so.  It seems to be recognized as an important
feature.  The standard kernel also has a regulator-consumer whose whole
purpose is to expose control of a regulator to userspace.  So it looks like
such userspace control is intended.

At least in the case of regulators those are specifically for use in
board file cases, they should never have direct DT bindings.

My concern is that, while these features are appropriate to expose in
userspace, I can't expose them using what are now the standard ways
(i.e. without a board file or customized driver for each board).  I'd like
to have a way to use the same kernel for all our boards, and have a
configuration that can be provided that will expose the required ones.

So one thing you could do here is have your connector have a driver that
handles what it knows about for the cases where that's useful and just
punts everything else to userspace.  That way you don't need to actually
write the kernel code for every last thing and can still punt to
userspace but don't need to have a DT that represents the actual
hardware.

I don't know if other people think that makes sense though.