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:
signature.asc
Description: Digital signature
