On Tue, Sep 1, 2015 at 1:17 PM, Mark Brown <broonie@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
