Re: Enabling regulators form userspace

[Mark Brown]

On Thu, Apr 23, 2015 at 11:19:50AM -0700, Dmitry Torokhov wrote:
> On Thu, Apr 23, 2015 at 06:13:28PM +0100, Mark Brown wrote:

> > Or, for that matter, if this ABI is in your vendor tree
> > then I do not even have to look at it :)

> I want it to be in mainline because I am not necessarily wearing my
> vendor hat when I ask them to either remove or not implement
> drivers-specific sysfs ABI in their driver.

So, that's an interesting but separate discussion I think which isn't
just confined to test interfaces - we also have some fun things going on
with callibration data for example.

> In another message you mentioned virtual.c Unfortunately the patch to
> allow driving it through device tree did not seem to go anywhere. IN the
> similar fashion, do you think we could add annotation to dveice tree to
> mark regulators that we explicitly allow controlling from userspace and
> then automatically create sysfs attributes similar to the ones from
> vitrual.c?

I'd still be a lot happier if that annotation were in the driver for the
device, there's the whole DT as hardware description thing going on here
and punting to userspace definitely seems like something we might
change our minds on later (in either direction).  For a tightly
integrated embedded system it makes no odds but they're not the only
users.

Please bear in mind that the userbase here also includes the RPi/BBB
communities where it seems difficult to get things like DT overlays
adopted, there's a lot of "just export everything to userspace,
whatever" going on which can lead to misery later on when things break
and you have to unpick what's going on.

> > > 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.

> They are worse: there is not way to fix them so that they work on all
> systems because currently we do not export regulator control. If it was
> exported the userspace programs would attempt to look up supplies that
> given controller uses in the same way the kernel does (i.e my
> touchscreen driver looks up vdd and then avdd; if they are not there
> kernel gives me dummies, in userspace I'll just shrug and continue). The
> regulator knowledge is not board-specific but rather
> controller-specific.

So, that's sounding a lot more like the organized export I was asking
for...

> > 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.

> We give them all the tools necessary and that should be enough. Maybe it
> can be generalized in a library if it proves too much of a pain - you
> give device description (gpio, supplies, clocks, whatever) and a library
> call with do a right thing for you - it does not mean it has to be in
> kernel. Right now all these dependencies live either in individual
> driver or in userspace; if we provide "coherent access" we need to put

No, they don't live in drivers - they live in DT and board files.  It's
not the "I need resource X" bit that's interesting, it's how you figure
out what resource that is on a random board.

> this knowledge into interface layer somehow. I really do not think
> i2c-dev should know about gpio, clocks, regulators, timings, ordering,
> etc. Another option, also unappealing, is having driver implement

If we're going down this road I'd expect us to provide the actual
implementation of the interface in the regulator subsystem and then have
something that I2C, SPI and so on can just call into (eg, ioctl() and
sysfs hooks).  I do agree that having every bus explicitly worry about
every resource would be ugly.

Timings and things probably are best punted to userspace, though I would
expect the overwhelming majority of these devices to be OK with just
being powered up.  I guess it's safer to just leave userspace to worry
about things though.

> interface to keep the device powered, not suspended, not runtime
> suspended, but otherwise untouched, until userspace is done with
> accessing it, and then go through re-initialization, similar to
> unbind/rebind, bit not quite. This is quite complex and has to be done
> in each driver. And we would need to have a kernel driver even for
> devices that we intend to drive purely from userspace. I do not think
> that this is the right direction to go in.

I'm not sure I follow this entirely.

Attachment: signature.asc
Description: Digital signature