On 15-09-20, 11:04, Lukasz Luba wrote: > Hi Viresh, > > On 9/2/20 8:24 AM, Viresh Kumar wrote: > > In order to prepare for lock-less stats update, add support to defer any > > updates to it until cpufreq_stats_record_transition() is called. > > > > Signed-off-by: Viresh Kumar <[email protected]> > > --- > > drivers/cpufreq/cpufreq_stats.c | 75 ++++++++++++++++++++++++--------- > > 1 file changed, 56 insertions(+), 19 deletions(-) > > > > diff --git a/drivers/cpufreq/cpufreq_stats.c > > b/drivers/cpufreq/cpufreq_stats.c > > index 94d959a8e954..fdf9e8556a49 100644 > > --- a/drivers/cpufreq/cpufreq_stats.c > > +++ b/drivers/cpufreq/cpufreq_stats.c > > @@ -22,17 +22,22 @@ struct cpufreq_stats { > > Would it be possible to move this structure in the > linux/cpufreq.h header? Any subsystem could have access to it, > like to the cpuidle stats.
Hmm, I am not sure why we should be doing it. In case of cpuidle many parts of the kernel are playing with cpuidle code, like drivers/idle/, drivers/cpuidle, etc. Something should land in include/ only if you want others to use it, but in case of cpufreq no one should be using cpufreq stats. So unless you have a real case where that might be beneficial, I am going to keep it as is. > Apart from that (and the comment regarding the 'atomic_t' field) > I don't see any issues. Thanks. -- viresh
