Messages in this thread | | | Date | Wed, 27 Apr 2016 08:29:22 +0530 | From | Viresh Kumar <> | Subject | Re: [PATCH 06/10] PM / OPP: Add dev_pm_opp_get_sharing_cpus() |
| |
On 22-04-16, 15:21, Stephen Boyd wrote: > On 04/21, Viresh Kumar wrote: > > diff --git a/drivers/base/power/opp/cpu.c b/drivers/base/power/opp/cpu.c > > index 55cbf9bd8707..9c4eb90759fb 100644 > > --- a/drivers/base/power/opp/cpu.c > > +++ b/drivers/base/power/opp/cpu.c > > @@ -329,3 +329,48 @@ int dev_pm_opp_set_sharing_cpus(struct device *cpu_dev, cpumask_var_t cpumask) > > return ret; > > } > > EXPORT_SYMBOL_GPL(dev_pm_opp_set_sharing_cpus); > > + > > +/** > > + * dev_pm_opp_get_sharing_cpus() - Get cpumask of CPUs sharing OPPs with @cpu_dev > > + * @cpu_dev: CPU device for which we do this operation > > + * @cpumask: cpumask to update with information of sharing CPUs > > + * > > + * This updates the @cpumask with CPUs that are sharing OPPs with @cpu_dev. > > + * > > + * Returns -ENODEV if OPP table isn't already present. > > + * > > + * Locking: The internal opp_table and opp structures are RCU protected. > > + * Hence this function internally uses RCU updater strategy with mutex locks > > + * to keep the integrity of the internal data structures. Callers should ensure > > + * that this function is *NOT* called under RCU protection or in contexts where > > + * mutex cannot be locked. > > + */ > > +int dev_pm_opp_get_sharing_cpus(struct device *cpu_dev, cpumask_var_t cpumask) > > Is there a reason we use cpumask_var_t instead of struct cpumask * > here? My understanding is that cpumask_var_t is for stack > declarations.
Just because we have been using that *consistently* everywhere in cpufreq and OPP core.
I am fine with cpumask * as well, but we should be consistent.
So, I will keep it cpumask_var_t for this patch, and lets see if we want to change all occurrences of the same in cpufreq and OPP core.
Sounds reasonable ?
-- viresh
| |