On Tue, Sep 1, 2015 at 4:20 AM, Chris Read <chrisrfq@xxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
