[trusty] [PATCH 2/3] cpufreq: powernv: Use cpufreq_frequency_table.driver_data to store pstate ids

[Gautham R Shenoy]

Hi Seth,

On Wed, Apr 23, 2014 at 11:06:35AM -0500, Seth Forshee wrote:
> On Mon, Apr 21, 2014 at 11:29:47AM +0530, Gautham R Shenoy wrote:
> > On Fri, Apr 18, 2014 at 08:12:01AM -0500, Seth Forshee wrote:
> > > On Thu, Apr 17, 2014 at 12:37:00PM -0300, Mauricio Faria de Oliveira wrote:
> > > > From: "Gautham R. Shenoy" <ego at linux.vnet.ibm.com>
> > > > 
> > > > The .driver_data field in the cpufreq_frequency_table was supposed to
> > > > be private to the drivers. However at some later point, it was being
> > > > used to indicate if the particular frequency in the table is the
> > > > BOOST_FREQUENCY. After patches [1] and [2], the .driver_data is once
> > > > again private to the driver. Thus we can safely use
> > > > cpufreq_frequency_table.driver_data to store pstate_ids instead of
> > > > having to maintain a separate array powernv_pstate_ids[] for this
> > > > purpose.
> > > > 
> > > > [1]:
> > > >   Subject: cpufreq: don't print value of .driver_data from core
> > > >   From   : Viresh Kumar <viresh.kumar@ linaro.org>
> > > >   url    : http://marc.info/?l=linux-pm&m=139601421504709&w=2
> > > > 
> > > > [2]:
> > > >   Subject: cpufreq: create another field .flags in cpufreq_frequency_table
> > > >   From   : Viresh Kumar <viresh.kumar at linaro.org>
> > > >   url    : http://marc.info/?l=linux-pm&m=139601416804702&w=2
> > > 
> > > These two commits were merged by Linus in 3.15-rc1, and we don't have
> > > them in trusty. Aren't we going to need these too?
> > 
> > We need these two patches as well since the my patch which makes use
> > of .driver_data field to record the pstates is safe only when these
> > two patches are applied.
> 
> I looked again. [1] could be backported, but it doesn't really seem
> necessary as it only affects a printk (i.e. read) of driver_data and
> thus shouldn't interfere with the use in your patch. [2] doesn't make
> sense for trusty though, because the boost support didn't appear until
> 3.14 (and thus there's no use of driver_data for storing
> CPUFREQ_BOOST_FREQ in trusty).

I missed the fact that the kernel version against which this patch is
to be backported is 3.13. I was under the impression that it was
3.14. Yes, you are right. The boost feature doesn't appear until 3.14
and we don't need to worry about [2].

> 
> I don't see anything else in the core cpufreq code in trusty which
> touches driver data in struct cpufreq_frequency_table, so I think we
> should be okay. Let me know if you find something I missed.

No this is fine. 
> 
> Thanks,
> Seth
> 
--
Thanks and Regards
gautham.