On Fri, Aug 28, 2015 at 11:43:19AM -0700, Chris Read wrote: > On Fri, Aug 28, 2015 at 11:05 AM, Mark Brown <broonie@xxxxxxxxxx> wrote: Please delete unneeded context from your replies, it makes it much easier to find any new content you have added. > > What's the issue you see here? The GPIO subsystem isn't really for > > exposing things to userspace, it's for exposing GPIOs to the rest of the > > kernel. The DT should just describe how the GPIOs are used and then the > > bindings for whatever the GPIOs are connected to will work out what to > > do with them, including exporting them to userspace if that's how > > they're handled. > There is also the case, as in the connector example above, where the > GPIOs are not connected to anything that has a driver associated with > it. In those circumstances it seems reasonable to allow a kernel module > to act like the driver which you suggest would normally work out what In this case the connector is the thing with the driver (or other in kernel user) and should be reponsible for doing something sensible with what's on the other end of the connector. > to do with the GPIOs, and export them if necessary. My thought, > however, is that the kernel module would need to be configured with > board-specific data, including whether to expose the GPIOs to userspace. > It also seems like such configuration data might look like DT data. 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). > > A driver can instantiate a userspace consummer if it finds that useful. > There is a userspace power-regulator consumer driver (found in > drivers/regulator/userspace-consumer.c) that was created to do > just that. It allows hooking up a userspace controlled consumer > to any regulator allowing control from userspace. So far so good. 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. > If a driver writer needs to conditionally expose some kind of control > to userspace based on some board-specific configuration mechanism, > I don't currently see a way to do that. I'd be very cautious about general drivers exposing regulators to userspace at all...
Attachment:
signature.asc
Description: Digital signature
