Re: Userspace and Device-Tree

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

 




On Fri, Aug 28, 2015 at 10:24:54AM -0700, Chris Read wrote:
> On Fri, Aug 28, 2015 at 3:12 AM, Mark Rutland <mark.rutland@xxxxxxx> wrote:

> > So long as the DT describes the HW, the subsystem can then choose to
> > expose the devices as it wishes, and any policy atop of that can then be
> > applied in the usual manner (e.g. udev for access control, naming, etc).

> The issue I see is that drivers may want to expose something in one case,
> but not in another, in a very board-specific way.  For example an I2C GPIO
> expander has a driver that allows reading and writing the GPIOs that it
> provides.  In one system the GPIOs control power switches and the DT
> is used to connect them to regulators, and they are activated as device
> files are opened.  There is no need to expose any GPIOs to userspace.
> On another board the GPIOs are attached to a connector that is intended
> for customization by an end user.  The same driver will want to expose
> the GPIOs to userspace in one case, but not in another.  Thus I see a
> need for some kind of board-specific configuration mechanism--without
> a "board file". It doesn't need to be DT.

What's the issue you see here?  The GPIO subsystem isn't really for
exposing things to userspace, it's for exposing GPIOs to the rest of the
kernel.  The DT should just describe how the GPIOs are used and then the
bindings for whatever the GPIOs are connected to will work out what to
do with them, including exporting them to userspace if that's how
they're handled.

> > I don't see this as strictly a policy issue, because it's so
> board-specific.

> A policy would need to allow for features like GPIOs to be both exposed or
> to not be exposed, but in a board-specific way.

You're trying to handle this at the wrong level, it's not an issue for
the GPIOs themselves.

> I see a strong need for board-specific configuration of drivers as they
> apply
> to exposure to userspace, but that need does not yet seem well addressed.
> There are some kernel modules (such as userspace-consumer.c) that are
> specifically designed to assist with this, but without some way to specify
> how to hook them up to other devices, they aren't available.

A driver can instantiate a userspace consummer if it finds that useful.

Attachment: signature.asc
Description: Digital signature


[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