On Fri, Dec 16, 2016 at 11:00:35PM +0100, Harald Geyer wrote: > Mark Brown writes: > > > I was hoping, that I somehow could get the necessary coordination from > > > the regulator framework. If the best I can get ATM is notifications, then > > > I'll try it and see what kind of code falls out of this. > Ok, tried that and it turns out there is no notification at > regulator_enable() ATM. I guess you'd merge a patch that added this > notification? Probably. > Sure, this is why regulator_force_disable() is the wrong tool for the job. > I was more looking for something (call it regulator_shutdown()) that > * blocked until the regulator is actually off > * made all calls to regulator_enable() from other consumers block (or fail) > * maybe sent notifications to consumers, so that they have a chance to > cooperate and call regulator_disable() at their earliest convenience. > * was undone by a call to either regulator_disable() or regulator_enable() > from the consumer that initially called regulator_shutdown() > I haven't explored this in detail - maybe there are good reasons not to > have it. That sounds like a complete mess from a user point of view - unless the other devices are actually cooperating it's going to have the same effect as doing nothing at all except it'll block the initiating consumer and possibly others doing enables, and as far as I can see it doesn't solve your problems with needing the regulator to be powered off for a specific amount of time. If it made enable calls block it'd be very disruptive for other users as they would suddenly find operations taking vastly longer than they were expecting which could end up being visible all the way back up to userspace.