Re: Userspace and Device-Tree

Re: Userspace and Device-Tree

[Mark Rutland]

On Thu, Aug 27, 2015 at 07:51:26PM +0100, Chris R wrote:
> Hi Mark,

Hi,

I've added the devicetree mailing list and a few maintainers, since this
is a recurring class of query.

> Sorry to write you out-of-the-blue, but I have a question/concern that I
> think has bearing on Linux kernel and device tree future, and your name is
> on some posts regarding DT & userspace.
> 
> In this one, http://www.spinics.net/lists/devicetree/msg43917.html, you
> state that you 'never expect to see "userspace" in a DT binding string', as
> DT is supposed to deal strictly with the interaction of HW components.
> 
> If I understand things correctly (and I'm relatively new to DT having been
> stuck with older kernels), we in the ARM/Linux world are using DT to do
> three things:
>     1.  Specify the hardware interactions
>     2.  Remove the need for board files for each board variant
>     3.  Allow the Linux kernel to plumb drivers together using the
> 'compatible = "<whatever>"' syntax
> My concerns lie in number 2 and number 3, with respect to userspace.
> 
> In my experience (primarily embedded OMAP3, but moving on now) one of the
> various purposes of the board file was to expose things to userspace
> (GPIO's, power supplies, ADC's etc.) so that they could be observed and even
> controlled from userspace.  So, I'm looking for how best to control hardware
> from userspace but without the customized board files I'm familiar with.
> 
> The above cited posting refers to the power regulator driver
> userspace-consumer.c, which is a regulator driver specifically designed to
> allow control of a hardware component from userspace.  I believe that this
> is a useful function to provide, and want to make use of it in my version of
> the kernel.  Is it possible to do so without a board file and without DT?
> If so, can you point me at some help?

I'm not specifically aware of how to achieve this, but this is really
down to the various subsystems to handle, rather than DT.

If you want to control regulators from userspace, then the regulator
subsystem needs to understand and expose regulators, rather than this
being left to arbitrary drivers to expose in arbitrary ways. If drivers
aren't exposing everything that they can, that is a driver issue.
Likewise for GPIOs, ADCs, etc.

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 only thing which may need to be in the DT are constraints on those
resources, to make it harder for a user to accidentally destroy their
board by over-volting a device, and so on. The same would apply to ACPI
or any other hardware description provided to the kernel.

> In this stackoverflow posting,
> http://stackoverflow.com/questions/30008189/linux-kernel-regulator-consumer-
> usage-from-userspace, which wanted to control a power supply from userspace,

As far as I can tell from that posting, the regulator was exposed to
userspace, but the subsystem had locked it to some particular state. I
don't understand the precise details behind that, but the best people to
talk to would be the maintainers of the regulator framework (Liam
Girdwood and Mark Brown according to MAINTAINERS).

> the solution they came up with was to create their own driver that exported
> it, and then bind it in with the DT.  That doesn't really solve the
> keeping-userspace-out-of-the-DT issue.  I think it would have been much more
> efficient to have a standardized way to control a regulator from userspace
> (e.g. userspace-consumer.c) and have a standardized way to have the kernel
> bind it to the regulator.  My understanding, though, is that the new
> standard way to get such bindings is with DT.

As above, this has nothing to do with DT. I agree that the subsystems
should expose standard interfaces for the resources they expose, but I
don't think that it makes sense for an external file provided to the
kernel to tell the kernel what and what not to expose to userspace --
that's pure policy and/or implementation details.

> Similarly, I'd like to be able to signal the export of a GPIO to userspace
> (/sys/class/gpio/gpioWXY) without a customized board file.  Since we're
> using DT to specify the hardware in a system, it would be a convenient place
> to specify exporting GPIOs to userspace.

I believe that the GPIO subsystem maintainers (Linus Walleij and
Alexandre Courbot) were trying to make GPIO control from userspace more
consistent (independent of DT) for a while. However I am not all that
familiar with the GPIO subsystem and may have misunderstood some of the
work that's going on there.

> I've searched for ways to expose things to userspace for several days,
> especially GPIOs, but the device tree still looks like an obvious place to
> this naive person.  If there's a good way to do this without DT, I'm happy
> to do so.  I'm also happy to have DT remain purely hardware oriented, but I
> wonder if it would make sense to put an umbrella over DT that included other
> things than DT, such as userspace.
> 
> In summary, I'd like to see ways to specify the exposure of GPIOs, power
> supplies, etc. to userspace, specified using device-tree like bindings.  If
> the device-tree is not the place to do so, then could there be a
> "system-tree" or something like that which would keep the DT formally
> separate, but include it by reference and also add whatever other nodes and
> properties that are necessary to specify things like exposing GPIO's, ADC's
> and power supply controls?  That way we could have userspace-consumer.c
> control the desired regulator, but not have the binding with the DT itself.
> (By the way, it appears to me that the userspace-consumer.c driver is rather
> orphaned without the ability to bind using a DT-like mechanism.  No updates
> are going its way these days.)
> 
> Thanks for your patience and consideration,
> 
> Chris
> 
> P.S. I had another (unrelated) thought about DT.  Since DT is used to link
> HW components together, and HW drivers make queries of the DT to make
> bindings, would it make sense to have some kind of a DT template (i.e. small
> .dtsi file) that corresponds to each driver reside in the directory with
> each driver.  Board device trees would reference these templates, and
> include references to relevant parameters that they specify.  This might
> also help make board DT device instances more uniform between .dts files. 

As far as I can tell, all of this is simply applying a policy atop of
the hardware we have. We already have subsystems and udev for dealing
with that, and we should enhance those if necessary rather than trying
to place this in DT.

Thanks,
Mark.
--
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

Fwd: Userspace and Device-Tree

[Chris Read]

On Fri, Aug 28, 2015 at 3:12 AM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:

> > In this one, http://www.spinics.net/lists/devicetree/msg43917.html, you
> > state that you 'never expect to see "userspace" in a DT binding string', as
> > DT is supposed to deal strictly with the interaction of HW components.
> >
> > If I understand things correctly (and I'm relatively new to DT having been
> > stuck with older kernels), we in the ARM/Linux world are using DT to do
> > three things:
> >     1.  Specify the hardware interactions
> >     2.  Remove the need for board files for each board variant
> >     3.  Allow the Linux kernel to plumb drivers together using the
> > 'compatible = "<whatever>"' syntax
> > My concerns lie in number 2 and number 3, with respect to userspace.
> >
> > In my experience (primarily embedded OMAP3, but moving on now) one of the
> > various purposes of the board file was to expose things to userspace
> > (GPIO's, power supplies, ADC's etc.) so that they could be observed and even
> > controlled from userspace.  So, I'm looking for how best to control hardware
> > from userspace but without the customized board files I'm familiar with.
> >
> > The above cited posting refers to the power regulator driver
> > userspace-consumer.c, which is a regulator driver specifically designed to
> > allow control of a hardware component from userspace.  I believe that this
> > is a useful function to provide, and want to make use of it in my version of
> > the kernel.  Is it possible to do so without a board file and without DT?
> > If so, can you point me at some help?
>
> I'm not specifically aware of how to achieve this, but this is really
> down to the various subsystems to handle, rather than DT.
>
> If you want to control regulators from userspace, then the regulator
> subsystem needs to understand and expose regulators, rather than this
> being left to arbitrary drivers to expose in arbitrary ways. If drivers
> aren't exposing everything that they can, that is a driver issue.
> Likewise for GPIOs, ADCs, etc.
>
> 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.

>
> > In this stackoverflow posting,
> > http://stackoverflow.com/questions/30008189/linux-kernel-regulator-consumer-
> > usage-from-userspace, which wanted to control a power supply from userspace,
>
> As far as I can tell from that posting, the regulator was exposed to
> userspace, but the subsystem had locked it to some particular state. I
> don't understand the precise details behind that, but the best people to
> talk to would be the maintainers of the regulator framework (Liam
> Girdwood and Mark Brown according to MAINTAINERS).
>
> > the solution they came up with was to create their own driver that exported
> > it, and then bind it in with the DT.  That doesn't really solve the
> > keeping-userspace-out-of-the-DT issue.  I think it would have been much more
> > efficient to have a standardized way to control a regulator from userspace
> > (e.g. userspace-consumer.c) and have a standardized way to have the kernel
> > bind it to the regulator.  My understanding, though, is that the new
> > standard way to get such bindings is with DT.
>
> As above, this has nothing to do with DT. I agree that the subsystems
> should expose standard interfaces for the resources they expose, but I
> don't think that it makes sense for an external file provided to the
> kernel to tell the kernel what and what not to expose to userspace --
> that's pure policy and/or implementation details.
>
> > Similarly, I'd like to be able to signal the export of a GPIO to userspace
> > (/sys/class/gpio/gpioWXY) without a customized board file.  Since we're
> > using DT to specify the hardware in a system, it would be a convenient place
> > to specify exporting GPIOs to userspace.
>
> I believe that the GPIO subsystem maintainers (Linus Walleij and
> Alexandre Courbot) were trying to make GPIO control from userspace more
> consistent (independent of DT) for a while. However I am not all that
> familiar with the GPIO subsystem and may have misunderstood some of the
> work that's going on there.
>
> > I've searched for ways to expose things to userspace for several days,
> > especially GPIOs, but the device tree still looks like an obvious place to
> > this naive person.  If there's a good way to do this without DT, I'm happy
> > to do so.  I'm also happy to have DT remain purely hardware oriented, but I
> > wonder if it would make sense to put an umbrella over DT that included other
> > things than DT, such as userspace.
> >
> > In summary, I'd like to see ways to specify the exposure of GPIOs, power
> > supplies, etc. to userspace, specified using device-tree like bindings.  If
> > the device-tree is not the place to do so, then could there be a
> > "system-tree" or something like that which would keep the DT formally
> > separate, but include it by reference and also add whatever other nodes and
> > properties that are necessary to specify things like exposing GPIO's, ADC's
> > and power supply controls?  That way we could have userspace-consumer.c
> > control the desired regulator, but not have the binding with the DT itself.
> > (By the way, it appears to me that the userspace-consumer.c driver is rather
> > orphaned without the ability to bind using a DT-like mechanism.  No updates
> > are going its way these days.)
> >
> > Thanks for your patience and consideration,
> >
> > Chris
> >
> > P.S. I had another (unrelated) thought about DT.  Since DT is used to link
> > HW components together, and HW drivers make queries of the DT to make
> > bindings, would it make sense to have some kind of a DT template (i.e. small
> > .dtsi file) that corresponds to each driver reside in the directory with
> > each driver.  Board device trees would reference these templates, and
> > include references to relevant parameters that they specify.  This might
> > also help make board DT device instances more uniform between .dts files.
>
> As far as I can tell, all of this is simply applying a policy atop of
> the hardware we have. We already have subsystems and udev for dealing
> with that, and we should enhance those if necessary rather than trying
> to place this in DT.
>
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.

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.

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

Re: Userspace and Device-Tree

[Mark Rutland]

Hi,

Please reply in plain text rather than HTML in future, as the latter
makes conversation far more awkward than it needs to be.

On Fri, Aug 28, 2015 at 06:24:54PM +0100, Chris Read wrote:
>    On Fri, Aug 28, 2015 at 3:12 AM, Mark Rutland <[1]mark.rutland@arm.com>
>    wrote:

[...]

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

In the case described, the distinction of being exposed on an
externally-accessible connector is something that could be described in
DT, with labels for the external connector IDs to make it nice and
simple for the user. Note that this is a physical property of the board
(GPIO X is connected to an external pin, where it is known as
"GPIO_FOO") rather than a policy (allow the user to arbitrarily control
GPIO X), but could be used to drive policy decisions (e.g. anything
exposed external could be placed under the control of the user).

Generally, users may have reasons to want to fiddle with GPIOs (or other
resources) that were not intended for their use at hardware design time
or DTB creation time, in much the same way as they might want to fiddle
with /dev/mem. Which is one reason I believe that this is a policy
issue.

If you can capture a physical distinction, then I don't have a problem
with that distinction being described in DT. However, the policy applied
to that is orthogonal to that.

>      > P.S. I had another (unrelated) thought about DT.  Since DT is used to
>      link
>      > HW components together, and HW drivers make queries of the DT to make
>      > bindings, would it make sense to have some kind of a DT template (i.e.
>      small
>      > .dtsi file) that corresponds to each driver reside in the directory
>      with
>      > each driver.  Board device trees would reference these templates, and
>      > include references to relevant parameters that they specify.  This
>      might
>      > also help make board DT device instances more uniform between .dts
>      files.
> 
>      As far as I can tell, all of this is simply applying a policy atop of
>      the hardware we have. We already have subsystems and udev for dealing
>      with that, and we should enhance those if necessary rather than trying
>      to place this in DT.
> 
>    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.
>    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.

I disagree, and believe that this is very much a policy issue, just one
that's made worse by a lack of information allowing the kernel and/or
userspace to make any reasonable informed decision.

As above, if you can capture a distinction at the hardware level, I do
not have a problem with that being described in DT. 

Thanks,
Mark.
--
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

Re: Userspace and Device-Tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

On Fri, Aug 28, 2015 at 06:57:42PM +0100, Mark Rutland wrote:

> Generally, users may have reasons to want to fiddle with GPIOs (or other
> resources) that were not intended for their use at hardware design time
> or DTB creation time, in much the same way as they might want to fiddle
> with /dev/mem. Which is one reason I believe that this is a policy
> issue.

This should hopefully be very much in the debugging category (like
/dev/mem is) though.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: Userspace and Device-Tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2286 bytes --]

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-5wv7dgnIgG8@public.gmane.org> 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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: Userspace and Device-Tree

[Chris Read]

On Fri, Aug 28, 2015 at 11:05 AM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> 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-5wv7dgnIgG8@public.gmane.org> 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.
There is also the case, as in the connector example above, where the
GPIOs are not connected to anything that has a driver associated with
it.  In those circumstances it seems reasonable to allow a kernel module
to act like the driver which you suggest would normally work out what
to do with the GPIOs, and export them if necessary.  My thought,
however, is that the kernel module would need to be configured with
board-specific data, including whether to expose the GPIOs to userspace.
It also seems like such configuration data might look like DT data.

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

There is a userspace power-regulator consumer driver (found in
drivers/regulator/userspace-consumer.c) that was created to do
just that.  It allows hooking up a userspace controlled consumer
to any regulator allowing control from userspace.  So far so good.

However, as I understand it, any hooks to allow attaching such that
consumer to a regulator would require the use of DT, and a patch
that was intended to provide those DT hooks was declined a year
or so ago.  So as I see it, it can't be used at present--at least without
some kind of board-specific source code to hook it up.  (And we don't
want board-specific source code.)

If a driver writer needs to conditionally expose some kind of control
to userspace based on some board-specific configuration mechanism,
I don't currently see a way to do that.

Thanks for your dialog on this--much appreciated,

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

Re: Userspace and Device-Tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2393 bytes --]

On Fri, Aug 28, 2015 at 11:43:19AM -0700, Chris Read wrote:
> On Fri, Aug 28, 2015 at 11:05 AM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:

Please delete unneeded context from your replies, it makes it much
easier to find any new content you have added.

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

> There is also the case, as in the connector example above, where the
> GPIOs are not connected to anything that has a driver associated with
> it.  In those circumstances it seems reasonable to allow a kernel module
> to act like the driver which you suggest would normally work out what

In this case the connector is the thing with the driver (or other in
kernel user) and should be reponsible for doing something sensible with
what's on the other end of the connector.

> to do with the GPIOs, and export them if necessary.  My thought,
> however, is that the kernel module would need to be configured with
> board-specific data, including whether to expose the GPIOs to userspace.
> It also seems like such configuration data might look like DT data.

Sure, but that's just a normal driver...  ideally for these sorts of
connectors there'd also be a way of enumerating anything that is
connected (but often that's not specified).

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

> There is a userspace power-regulator consumer driver (found in
> drivers/regulator/userspace-consumer.c) that was created to do
> just that.  It allows hooking up a userspace controlled consumer
> to any regulator allowing control from userspace.  So far so good.

No, you're missing the point.  The point is that that driver can be
instantiated from another device (one that describes the actual
hardware) if it is useful to do so.

> If a driver writer needs to conditionally expose some kind of control
> to userspace based on some board-specific configuration mechanism,
> I don't currently see a way to do that.

I'd be very cautious about general drivers exposing regulators to
userspace at all...

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: Userspace and Device-Tree

[Chris Read]

On Fri, Aug 28, 2015 at 11:52 AM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Fri, Aug 28, 2015 at 11:43:19AM -0700, Chris Read wrote:

> Please delete unneeded context from your replies, it makes it much
> easier to find any new content you have added.
Thanks.  I'll do better.

> Sure, but that's just a normal driver...  ideally for these sorts of
> connectors there'd also be a way of enumerating anything that is
> connected (but often that's not specified).

So for such a connector, would it be appropriate to have a kernel
module that gets configured using DT data, that is intended to be
an "enumerator" of GPIOs, in that it configures them (sets them to
input/output, gives labels, etc.), and also exposes them to
userspace (if specified in the configuration data)?

>> > A driver can instantiate a userspace consummer if it finds that useful.
>
>> There is a userspace power-regulator consumer driver (found in
>> drivers/regulator/userspace-consumer.c) that was created to do
>> just that.  It allows hooking up a userspace controlled consumer
>> to any regulator allowing control from userspace.  So far so good.
>
> No, you're missing the point.  The point is that that driver can be
> instantiated from another device (one that describes the actual
> hardware) if it is useful to do so.
Perhaps I'm misunderstanding.  Is there already a board-specific
not driver-specific way to have the userspace-consumer get attached
to a regulator?  Can you point me at it?

> I'd be very cautious about general drivers exposing regulators to
> userspace at all...

Certainly most don't.  We have externally powered devices that we
want to power on and off, though, so sometimes it's helpful.

Thanks,

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

Re: Userspace and Device-Tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]

On Fri, Aug 28, 2015 at 12:32:16PM -0700, Chris Read wrote:
> On Fri, Aug 28, 2015 at 11:52 AM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:

> > Sure, but that's just a normal driver...  ideally for these sorts of
> > connectors there'd also be a way of enumerating anything that is
> > connected (but often that's not specified).

> So for such a connector, would it be appropriate to have a kernel
> module that gets configured using DT data, that is intended to be
> an "enumerator" of GPIOs, in that it configures them (sets them to
> input/output, gives labels, etc.), and also exposes them to
> userspace (if specified in the configuration data)?

Possibly, or possibly it'd just be hard coded for the connector.

> > No, you're missing the point.  The point is that that driver can be
> > instantiated from another device (one that describes the actual
> > hardware) if it is useful to do so.

> Perhaps I'm misunderstanding.  Is there already a board-specific
> not driver-specific way to have the userspace-consumer get attached
> to a regulator?  Can you point me at it?

No.  To repeat what I said above the driver for one device can most
likely instantiate another.  This is unlikely to be board specific, a
regulator being controlled from userspace is going to depend on how we
support the device it controls not on which board the device it controls
happens to be on.

> > I'd be very cautious about general drivers exposing regulators to
> > userspace at all...

> Certainly most don't.  We have externally powered devices that we
> want to power on and off, though, so sometimes it's helpful.

I would expect the driver for the device to do that.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: Userspace and Device-Tree

[Alexandre Courbot]

>> Similarly, I'd like to be able to signal the export of a GPIO to userspace
>> (/sys/class/gpio/gpioWXY) without a customized board file.  Since we're
>> using DT to specify the hardware in a system, it would be a convenient place
>> to specify exporting GPIOs to userspace.
>
> I believe that the GPIO subsystem maintainers (Linus Walleij and
> Alexandre Courbot) were trying to make GPIO control from userspace more
> consistent (independent of DT) for a while. However I am not all that
> familiar with the GPIO subsystem and may have misunderstood some of the
> work that's going on there.

If I properly understood what Chris wants, he may want to have a look
at the following works:

- GPIO hogging mechanism to configure a GPIO using the device tree -
not sure if you can also export at that time?
- Markus' ongoing work on GPIO naming:
http://www.spinics.net/lists/linux-gpio/msg07844.html
- Device tree overlays, to separate the configuration of GPIOs for
user-space use (which is arguably specific to one's use case) from the
rest of the board's definition

With these 3 works I think Chris' needs would be fulfilled, at least
as far as GPIOs are concerned.
--
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

Re: Userspace and Device-Tree

[Chris Read]

On Sat, Aug 29, 2015 at 5:09 AM, Alexandre Courbot <gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> If I properly understood what Chris wants, he may want to have a look
> at the following works:
>
> - GPIO hogging mechanism to configure a GPIO using the device tree -
> not sure if you can also export at that time?
> - Markus' ongoing work on GPIO naming:
> http://www.spinics.net/lists/linux-gpio/msg07844.html
> - Device tree overlays, to separate the configuration of GPIOs for
> user-space use (which is arguably specific to one's use case) from the
> rest of the board's definition
>
> With these 3 works I think Chris' needs would be fulfilled, at least
> as far as GPIOs are concerned.

Thanks for the pointers, Alexandre.  I think that these are right down
the line of what I think is required.  Much of the work seems already
done.  As you mention, though, exporting doesn't seem to be supported
yet.  I would like to see the addition of exporting to the GPIO hogging
mechanism:
1. A boolean to indicate the exporting the GPIO
2. A boolean to indicate whether the GPIO can be reconfigured
     (i.e. direction-may-change)

For the regulator case, it looks like a hogging mechanism might be
appropriate.
--
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

Re: Userspace and Device-Tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 486 bytes --]

On Mon, Aug 31, 2015 at 07:30:24AM -0700, Chris Read wrote:

> yet.  I would like to see the addition of exporting to the GPIO hogging
> mechanism:
> 1. A boolean to indicate the exporting the GPIO

Why would this be appropriate?  Exporting a GPIO to userspace doesn't
sound like a property of the hardware...

> For the regulator case, it looks like a hogging mechanism might be
> appropriate.

Do you mean something like the existing support for marking regulators
as always enabled?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: Userspace and Device-Tree

[Chris Read]

On Mon, Aug 31, 2015 at 7:55 AM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> yet.  I would like to see the addition of exporting to the GPIO hogging
>> mechanism:
>> 1. A boolean to indicate the exporting the GPIO
>
> Why would this be appropriate?  Exporting a GPIO to userspace doesn't
> sound like a property of the hardware...

You're right.  It is not strictly hardware.  But I still need a place to specify
this attribute in a board-dependent way. I suppose you could think of an
end user as a hardware component (though we have soft parts too), then
you'd be specifying that hardware's access to the hardware via the
export flag.

>> For the regulator case, it looks like a hogging mechanism might be
>> appropriate.
>
> Do you mean something like the existing support for marking regulators
> as always enabled?

No.  I was assuming that the hogging mechanism would include the
exporting capability from GPIOs.
--
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

Re: Userspace and Device-Tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2011 bytes --]

On Mon, Aug 31, 2015 at 08:53:54AM -0700, Chris Read wrote:
> On Mon, Aug 31, 2015 at 7:55 AM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:

> > Why would this be appropriate?  Exporting a GPIO to userspace doesn't
> > sound like a property of the hardware...

> You're right.  It is not strictly hardware.  But I still need a place to specify
> this attribute in a board-dependent way. I suppose you could think of an
> end user as a hardware component (though we have soft parts too), then
> you'd be specifying that hardware's access to the hardware via the
> export flag.

That doesn't really hang together - it's nothing to do with the hardware
that this is what you want to do, someone might decide to connect an
expansion board which would most usefully be controlled by in kernel
drivers to exactly the same base hardware.

> >> For the regulator case, it looks like a hogging mechanism might be
> >> appropriate.

> > Do you mean something like the existing support for marking regulators
> > as always enabled?

> No.  I was assuming that the hogging mechanism would include the
> exporting capability from GPIOs.

So when you say "hogging" what you actually mean to say is "userspace
control"?  Please be clear in what you are saying, hogging normally just
means a way to provide a fixed configuration rather than runtime
configuration from userspace.  I'm sorry but I really don't think that
doing this is something that it is sensible to have as a feature, it's
not describing the hardware and it's an invitation to poor system
implementations.

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 fromm userspace.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: Userspace and Device-Tree

[Chris Read]

On Mon, Aug 31, 2015 at 11:01 AM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> You're right.  It is not strictly hardware.  But I still need a place to specify
>> this attribute in a board-dependent way. I suppose you could think of an
>> end user as a hardware component (though we have soft parts too), then
>> you'd be specifying that hardware's access to the hardware via the
>> export flag.
>
> That doesn't really hang together - it's nothing to do with the hardware
> that this is what you want to do, someone might decide to connect an
> expansion board which would most usefully be controlled by in kernel
> drivers to exactly the same base hardware.

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

> So when you say "hogging" what you actually mean to say is "userspace
> control"?  Please be clear in what you are saying,
Sorry, I was unaware that it has a precise meaning.  (And I hadn't
followed its evolution in the kernel.)

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

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.

It may be possible to make it a set of kernel command line parameters,
which would then be customized for each board.  There are, no doubt,
still other ways to accomplish this board-specific customization.
However, since there is already a board-specific mechanism to do
kernel driver/module configuration (i.e. DT), it seemed like a good idea
to piggy-back on it.

Obviously exporting to userspace isn't a hardware configuration
parameter, but the mechanism of hooking up and configuring drivers
that DT uses looks to me like the most efficient way implement this.

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

Re: Userspace and Device-Tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2505 bytes --]

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.

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: Userspace and Device-Tree

[Chris Read]

On Tue, Sep 1, 2015 at 1:17 PM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> .......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.

I agree with you (in almost all situations).

>> 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 understanding, is that we're trying very hard to avoid having any board
files, and that DT use was intended to facilitate getting away from them.
Perhaps my interpretation of the need to avoid board files is extreme?

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

That's a very intriguing idea to me.  Let me see if I understand your
suggestion fully.

It would involve creating a kernel module (not really a driver, since
it doesn't actually control hardware) as well as modifications to the DT.

In the DT we'd create a hardware description of a connector, which
indicates all the signals, etc. that come to it.  Signals which are
connected to other devices and are thus fully described elsewhere
would simply be referenced.  Nothing new would happen with those
signals via DT and kernel module.

However, signals that are not described elsewhere could be qualified
in the DT as appropriate for the hardware connector.  For GPIO's that
could include direction, level, name, etc.  Since those signals aren't
mated internally with any other hardware they would automatically be
exposed to userspace.  The new kernel module would be responsible
for configuring the newly described hardware as well as doing the
exposing to userspace.

That sounds quite workable to me.  It might get more complicated
than I'd prefer, especially if there are more things than GPIOs (such
as ADCs, DACs, etc.) that might come to the connector previously
unconfigured.  But I think the idea is sound--and it keeps the DT in
the hardware rather than the userspace business, which is what we
want.  It also sounds like it might be broadly applicable, and have
interest far beyond me.
--
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

Re: Userspace and Device-Tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 805 bytes --]

On Tue, Sep 01, 2015 at 03:19:44PM -0700, Chris Read wrote:
> On Tue, Sep 1, 2015 at 1:17 PM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:

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

> My understanding, is that we're trying very hard to avoid having any board
> files, and that DT use was intended to facilitate getting away from them.
> Perhaps my interpretation of the need to avoid board files is extreme?

Only on ARM, and in any case that code predates DT being used on ARM.

> It would involve creating a kernel module (not really a driver, since
> it doesn't actually control hardware) as well as modifications to the DT.

Your summary pretty much matches what I'm thinking yes.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: Userspace and Device-Tree

[Linus Walleij]

On Tue, Sep 1, 2015 at 3:19 PM, Chris Read <chrisrfq-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> That sounds quite workable to me.  It might get more complicated
> than I'd prefer, especially if there are more things than GPIOs (such
> as ADCs, DACs, etc.)

What do you mean by this? We have in-kernel support for ADC and
DAC, see drivers/iio/[adc|dac] and these have excellent userspace
interfaces.

Yours,
Linus Walleij
--
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

Re: Userspace and Device-Tree

[Chris Read]

On Mon, Sep 21, 2015 at 4:51 PM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> That sounds quite workable to me.  It might get more complicated
>> than I'd prefer, especially if there are more things than GPIOs (such
>> as ADCs, DACs, etc.)
>
> What do you mean by this? We have in-kernel support for ADC and
> DAC, see drivers/iio/[adc|dac] and these have excellent userspace
> interfaces.

That statement was made regarding adding a "connector" component
into the DT, which would describe a hardware connector in the system.
The connector component would allow describing what came to it, and
in the above discussion was specifically to allow configuring GPIOs in
the DT that otherwise would not have a component to connect to, and
thus would not be able to be exported to userspace in the DT.

My "(such as...)" comment was indicating that other components than
just GPIOs might be included in the connector, and hence there might
be some implications there.  Would there be initialization or dependencies
that would have to be handled?  I don't know, but my thought at the time
was that it might get complicated.

Thanks for asking,

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

Re: Userspace and Device-Tree

[Alexandre Courbot]

On Tue, Sep 1, 2015 at 4:20 AM, Chris Read <chrisrfq-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 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.
>
> 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.
>
> It may be possible to make it a set of kernel command line parameters,
> which would then be customized for each board.  There are, no doubt,
> still other ways to accomplish this board-specific customization.
> However, since there is already a board-specific mechanism to do
> kernel driver/module configuration (i.e. DT), it seemed like a good idea
> to piggy-back on it.
>
> Obviously exporting to userspace isn't a hardware configuration
> parameter, but the mechanism of hooking up and configuring drivers
> that DT uses looks to me like the most efficient way implement this.

Since the GPIO sysfs allows you to request any GPIO that is not
claimed by a kernel driver from userspace, is there a reason why you
cannot simply run board-specific init scripts that request and
configure the GPIOs you need? Once GPIO naming is merged, this should
be as elegant as it gets for what you want to do.
--
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

Re: Userspace and Device-Tree

[Chris Read]

On Wed, Sep 2, 2015 at 5:29 AM, Alexandre Courbot <gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Since the GPIO sysfs allows you to request any GPIO that is not
> claimed by a kernel driver from userspace, is there a reason why you
> cannot simply run board-specific init scripts that request and
> configure the GPIOs you need? Once GPIO naming is merged, this should
> be as elegant as it gets for what you want to do.

For many things this is true.  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.
--
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

Re: Userspace and Device-Tree

[Linus Walleij]

On Wed, Sep 2, 2015 at 6:35 AM, Chris Read <chrisrfq-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Wed, Sep 2, 2015 at 5:29 AM, Alexandre Courbot <gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Since the GPIO sysfs allows you to request any GPIO that is not
>> claimed by a kernel driver from userspace, is there a reason why you
>> cannot simply run board-specific init scripts that request and
>> configure the GPIOs you need? Once GPIO naming is merged, this should
>> be as elegant as it gets for what you want to do.
>
> For many things this is true.  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.

Yours,
Linus Walleij
--
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

Re: Userspace and Device-Tree

[Chris Read]

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.

I personally think it make sense to allow a board designer to somehow
specify in the DT (not doable now) that an otherwise unattached GPIO
should be exposed to userspace and whether or not to expose the
"direction" pseudo-file in sysfs that allows changing of the direction.
If the board designer thinks it's safe or necessary to change the
direction of the GPIO, then why not allow him to specify it as such.

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

Re: Userspace and Device-Tree

[Alexandre Courbot]

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

Re: Userspace and Device-Tree

[Linus Walleij]

On Tue, Sep 22, 2015 at 6:54 AM, 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.

I am usually conservative with this because all too often, people
do not know about all the stuff listed in
Documentation/gpio/drivers-on-gpio.txt
and their usual reasoning is "just lemme do this in userspace real
quick now because I have this project". And that doesn't sit well with
our long-term view of kernel ABIs.

For proper userspace ABI the sysfs has been deemed unusable
and does not scale. What is needed is a chardev rewrite as has
been discussed several times.

Yours,
Linus Walleij
--
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