Re: Enabling regulators form userspace

[Mark Brown]

On Thu, Apr 23, 2015 at 09:08:07AM -0700, Dmitry Torokhov wrote:
> On Thu, Apr 23, 2015 at 11:35:45AM +0100, Mark Brown wrote:

> > This really sounds like you should be writing a device driver here, even
> > if it's just a little module you write separately to the actual device
> > driver used in real systems.

> No, no way. If it is lives in kernel I have to review it and then either
> upstream and maintain it in mainline or maintain it as out-of-tree
> driver. If it is in userspace I do not even have to look at it.

I'm sure someone else has extensive validation requirements for their
userspace code!  Or, for that matter, if this ABI is in your vendor tree
then I do not even have to look at it :)

> > It's not about the quality of an individual driver, it's about the
> > potential for misuse - making the kernel interfaces such that it's easy
> > to do the right thing and hard to do the wrong thing.  Having the
> > ability to just bang on this stuff from userspace seems like it's
> > encouraging problematic behaviour.

> What kind of misuse are you concerned with? I can see that we may not
> necessarily want to allow setting arbitrary voltage directly from
> userspace, but asking kernel nicely to enable regulator with
> regulator_enable() (we may refuse for regulators that are requested in
> exclusive use) and similarly disable it with regulator_disable() should
> not be any more dangerous than having a random kernel module do that.

Things like people putting parts of their power management for things
with actual drivers into userspace, and epecially people mixing user
space and kernel power management.

I also don't buy the idea that a userspace interface wouldn't involve
setting voltages, if we can perform some operations people are going to
want to be able to perform all of them.

> Sometimes shoving everything into the kernel is not the best idea; some
> tasks are better suited for userspace. We already allow raw userspace
> access to i2c, usb, spi, pci, PS/2 ports, parallel ports, and probably
> more. Why regulators should be special in this regard and accessible
> only through kernel? This causes programs that work fine on one
> architecture (x86) to fail when moved to another (arm) with no way of
> fixing it.

Well, they're going to fail on systems that require regulator code
without magic userpace code anyway so we're no worse off here.

I'm not saying we shouldn't have userspace control at all, I'm saying
that we should export coherent devices to userspace rather than just
some random unstructured stuff asking for hacks - something like the
facility I suggested for the userspace interface for the control
interfaces to also export control of the power for the device.  That
seems like it should also be more helpful for userspace programmers to
work with, they ought to be able to readily do things like "turn on all
the power for the device" (and probably have it done for them by
default) rather than have to discover which hoops they have to jump
through on which system.

Userspace control of devices seems like a reasonable thing to want but
that doesn't mean that it's a good idea to just provide userspace with
an unstructured pile of stuff to sort through.

Attachment: signature.asc
Description: Digital signature