On 12:11-20130501, sudeep.karkadanage...@arm.com wrote: > From: Sudeep KarkadaNagesha <sudeep.karkadanage...@arm.com> > > CPUs are registered as devices and their OPPs can be initialised from > the device tree. Whenever CPUs can be hotplugged out, the corresponding > cpu devices are not removed. As a result all their OPPs remain intact > even when they are offlined. > > But when they are hotplugged back-in, the cpufreq along with other cpu > related subsystem gets re-initialised. Since its almost same as secondary > cpu being brought up, no special consideration is taken in the hotplug > path. As a result of this the cpufreq will try to initialise the OPPs > again though the cpu device already contains the OPPs. > > This patch checks if there exist an OPP list associated with the device, > before attempting to initialise it. > > Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanage...@arm.com> > --- > drivers/base/power/opp.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c > index 4dfdc01..66d52d2 100644 > --- a/drivers/base/power/opp.c > +++ b/drivers/base/power/opp.c > @@ -706,6 +706,11 @@ static int of_init_opp_table_from_ofnode(struct device > *dev, > const __be32 *val; > int nr; > > + /* Check for existing list for 'dev' */ > + dev_opp = find_device_opp(dev); > + if (!IS_ERR(dev_opp)) > + return 0; /* Device OPP already initialized */ > + It gets a little touchy here -> the normal expectation is for the OPP entries to be populated onetime at boot. For example - driver bug where same device was attempted twice Vs the usecase you mention here - how'd we differentiate between the two? > prop = of_find_property(of_node, "operating-points", NULL); > if (!prop) > return -ENODEV; > -- > 1.7.10.4 > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
-- Regards, Nishanth Menon _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss