lkml.org 
[lkml]   [2017]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3 3/4] regulator: core: Parse coupled regulators properties
On Thu, Dec 21, 2017 at 11:08:19AM +0100, Maciej Purski wrote:
> On 12/12/2017 12:35 PM, Mark Brown wrote:
> > On Thu, Dec 07, 2017 at 10:46:14AM +0100, Maciej Purski wrote:

> > > + mutex_lock(&regulator_list_mutex);
> > > + regulator_resolve_coupling(rdev);
> > > + mutex_unlock(&regulator_list_mutex);

> > I'd really expect us to be failing to probe if we run into an error.
> > Otherwise we could end up doing bad things to the hardware at runtime
> > later on, or confusing ourselves and crashing with partially set up
> > datastructures.

> We cannot fail to probe if some of the regulators are not registered
> successfully, as depending on the probing sequence, there will be some
> regulators, which won't be available when registering others. We can fail
> when resolving coupling if we encounter other errors such as max_spread not
> provided or disability to set voltage. Maybe that is what you meant.

Yes, exactly - not having all the regulators yet isn't the only possible
error and this will just ignore all errors.

> > It's also not 100% clear to me how we handle the case
> > where only some of the coupled regulators have probed.

> I have two ideas how to handle it. We can prohibit setting the voltage and
> always fail on attempt to set voltage of a coupled regulator. Or we can just
> ignore it and set voltage of the regulator without checking the unregistered
> ones.

At least one of those needs to be implemented (not setting the voltage
seems safer).
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2017-12-21 13:03    [W:0.061 / U:0.900 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site