Messages in this thread | | | Date | Mon, 19 Jan 2009 18:08:02 +0000 | From | Jonathan Cameron <> | Subject | Re: [RFC] Regulator: Add a voltage changed event to notify consumers |
| |
Jonathan Cameron wrote: > Mark Brown wrote: >> On Sun, Jan 18, 2009 at 06:47:25PM +0000, Jonathan Cameron wrote: >> >>> -out: >>> + mutex_unlock(&rdev->mutex); >>> + _notifier_call_chain(rdev, REGULATOR_EVENT_VOLTAGE_CHANGE, NULL); >>> + return 0; >>> +out_unlock: >> It'd be nice if we could modify _notifier_call_chain() to push the >> locking out a bit so we don't need to drop the lock before calling the >> notifier. On the other hand, for anything that isn't memory mapped or >> GPIO controlled (most regulators are in this category) the cost of the >> I/O is going to make this a non-issue. > Agreed. On that note, isn't any call to regulator_force_disable > currently going to deadlock? (lock held in regulator_force_disable, > then re-called in _notifier_call_chain.) > > I'll have a look into moving the locks out of _notifier_call_chain. Having had a quick look at this, it comes down to a question of whether we want to hold the lock on one regulator whilst notifying any regulators it supplies.
I personally can't see that this would be a problem, but it has definitely been structured to avoid doing so.
Trying to come up with scenarios that may make this a problem:
Parent notifies child of a voltage change. This change results in some complex problem (not covered by constraints - I'm stretching here) that in turn causes a the child regulator to request a forced disable from the parent and causes deadlock.
Can anyone come up with a non contrived reason not to move constraints clean out of _notifier_call_chain and rely on caller holding the lock? Clearly this also requires applying locks to child regulators in the loop at the end of _notifier_call_chain.
Next email contains a patch combing this change with the voltage notification patch.
Cheers,
Jonathan
| |