On Fri, Aug 28, 2015 at 12:32:16PM -0700, Chris Read wrote: > On Fri, Aug 28, 2015 at 11:52 AM, Mark Brown <broonie@xxxxxxxxxx> wrote: > > Sure, but that's just a normal driver... ideally for these sorts of > > connectors there'd also be a way of enumerating anything that is > > connected (but often that's not specified). > So for such a connector, would it be appropriate to have a kernel > module that gets configured using DT data, that is intended to be > an "enumerator" of GPIOs, in that it configures them (sets them to > input/output, gives labels, etc.), and also exposes them to > userspace (if specified in the configuration data)? Possibly, or possibly it'd just be hard coded for the connector. > > No, you're missing the point. The point is that that driver can be > > instantiated from another device (one that describes the actual > > hardware) if it is useful to do so. > Perhaps I'm misunderstanding. Is there already a board-specific > not driver-specific way to have the userspace-consumer get attached > to a regulator? Can you point me at it? No. To repeat what I said above the driver for one device can most likely instantiate another. This is unlikely to be board specific, a regulator being controlled from userspace is going to depend on how we support the device it controls not on which board the device it controls happens to be on. > > I'd be very cautious about general drivers exposing regulators to > > userspace at all... > Certainly most don't. We have externally powered devices that we > want to power on and off, though, so sometimes it's helpful. I would expect the driver for the device to do that.
Attachment:
signature.asc
Description: Digital signature
