> I was reading userspace-consumer file ad was wondering whether would be> possible to use that in order to implement what SBS-IF [1] proposes> using sbs-enabled devices.

Looking at that I'm not sure why you wish to push this into user space?

The existing drivers for this sort of functionality are all regularkernel drivers (in drivers/power and to a lesser extent drivers/hwmon)and it looks like it'd be at least as much work to rearrange the powersupply stuff to support userspace drivers. My initial expectation wouldbe for a generic driver with some policy exposed to user space and someconfiguration exposed for architecture code (especially for setting upmulti-battery board layouts and things). That's not a terribly informedopinion, though.

> For doing that, probably userspace-consumer would have to be able to> set_voltage/get_voltage, set/get_current_limit and so on. So I was> thinking on changing userspace-consumer to use regulator_get() instead> of regulator_bulk_get() and make each instance of userspace-consumer to> talk to only and only one regulator.

I'd like to preserve the bulk switch if possible - part of the thinkingwas that things with more complex needs may well find it easier and/ormore robust to have custom kernel stubs which mapped one or moreregulators into the interfaces they needed. That was more for thingslike working out which of multiple supplies is which, though.

The existing virtual consumer, while intended as a test harnessoriginally and rather clunky as-is, is much closer to your needs. It isthe way it is partly as a sign that you really shouldn't be using it inproduction (which seems to be working!).

> Anyways, how do you guys feel about it ?

Like I say, from a quick read through of the specs I'm not sure that I'dpush this into user space but I've not thought about this deeply and maybe missing something.