On 09/20, Viresh Kumar wrote: > On 20-09-17, 10:00, Stephen Boyd wrote: > > On 09/20, Viresh Kumar wrote: > > > > diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c > > > index 4360b4efcd4c..668fd940d362 100644 > > > --- a/drivers/base/power/opp/core.c > > > +++ b/drivers/base/power/opp/core.c > > > @@ -1627,6 +1627,9 @@ static int _opp_set_availability(struct device > > > *dev, unsigned long freq, > > > > > > opp->available = availability_req; > > > > > > + dev_pm_opp_get(opp); > > > + mutex_unlock(&opp_table->lock); > > > > Does this prevent the OPP from changing while the lock is > > released? > > No, its just ref counting and will only prevent it from getting freed. > > There is only one thing that can change for an OPP though after it is > created, its availability.
Ok. > > > That would be the only difference from before. It's > > possible that nobody cares about this situation though. > > I am not sure if its worth caring for right now :) > > Also the notifier chain will not start again until the previous call > chain is finished. So we are kind of synchronized here. > Yep. Just me worrying out loud. You can add my Reviewed-by: Stephen Boyd <[email protected]> -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
