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