Re: Userspace and Device-Tree

[Alexandre Courbot <gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Tue, Sep 22, 2015 at 10:54 PM, Chris Read <chrisrfq-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Mon, Sep 21, 2015 at 4:55 PM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> On Wed, Sep 2, 2015 at 6:35 AM, Chris Read <chrisrfq-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> There are some hardware aspects/parameters
>>> of exporting that aren't controllable from userspace, such as whether or not
>>> reversing the direction of a GPIO is safe.
>>
>> The original argument as to why kernel should handle hardware
>> is to keep things safe and under control.
>>
>> I don't understand this argument really, should the kernel give you
>> a gun but stop you from shooting yourself in the foot with it or
>> what do you mean? Then the stance of kernel not to give out guns
>> is better.
>
> From my embedded perspective a board designer wants to keep
> hardware safe and under control too.  He may want or need to expose
> controls or status to userspace applications, though, and what he
> wants to have exposed may vary from board to board.  I just feel that
> exposing them via the DT could be OK, whereas others do not.

It is really not a matter of feeling. The DT's job is to describe what
the hardware is and how it is connected together - not the way in
which it may be used.

In your case, the DT describes a given range of pins as not being used
(typically, any unclaimed GPIO) and the sysfs kernel option allows
these GPIOs to be exposed to user-space. It is then up to the
priviledged userspace (via init scripts and/or udev rules) to export
and configure these GPIOs in the way they are supposed to be by
regular users.

This basically covers what you wanted to do exclusively by DT, but
with a stronger role separation. IIUC a good old init script could
just do what you want, using chmod to restrict write access to a GPIO
value or the ability to change direction. I also suspect the same
could be achieved with udev (especially since this series has just
been merged: http://www.spinics.net/lists/linux-gpio/msg07844.html ,
see the link for an example of a rule).

Board differenciation can also be handled at boot time, with init
doing different things depending on the board model. Again, similarly
to what you would do with DT, but without the it being involved in
describing the system semantics.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html