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@xxxxxxx> > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
