[PATCH v4 12/19] cpufreq: cpufreq-cpu0: remove device tree parsing for cpu nodes

[Sudeep KarkadaNagesha]

On 09/09/13 15:32, Shawn Guo wrote:
> Hi Sudeep,
> 
> On Mon, Sep 09, 2013 at 10:24:39AM +0100, Sudeep KarkadaNagesha wrote:
>> Hi Shawn,
>>
>> Can you please clarify ? The fix would be as below but I would like to
>> know if setting cpu_dev to get_cpu_device(0) instead of &pdev->dev has
>> any impact on other parts of code using cpu_dev ?
> 
> I'm sorry.  I should have given it a test on hardware before ACKing the
> changes.
> 
> The fix below should not have other impact except the prefix of dev_err
> [info, dbg] message output ('cpufreq-cpu0:' to 'cpu cpu0:'), which
> shouldn't be a problem.
>
Hi Shawn,

Ok. But I am bit suspicious about devm_clk_get(cpu_dev, NULL).
I don't understand completely as how the clock are registered(whether
with dev_id or with connection_id).

A quick grep revealed that i.mx and shmobile is using conection id while
registering. If the clock is registered with connection id and retrieved
with cpu_dev(now dev_id is cpu0 and not cpufreq-cpu0), IIUC that would
break. If we pass pdev->dev for clk_get, it should be fine but again
IIUC it breaks highbank which gets all the information from DT.

So only solution I can think of is to continue to have the code
assigning (&pdev->dev)->of_node with cpu device node which is not clean
and arguable as incorrect since there is no DT node for cpufreq-cpu0.
I don't have a strong opinion though.

Let me know how would you like to fix this.

>>
>> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
>> index cbfffa9..871c336 100644
>> --- a/drivers/cpufreq/cpufreq-cpu0.c
>> +++ b/drivers/cpufreq/cpufreq-cpu0.c
>> @@ -177,7 +177,7 @@ static int cpu0_cpufreq_probe(struct platform_device
>> *pdev)
>>         struct device_node *np;
>>         int ret;
>>
>> -       cpu_dev = &pdev->dev;
>> +       cpu_dev = get_cpu_device(0);
>>
>>         np = of_node_get(cpu_dev->of_node);
>>         if (!np) {
>>
> 
> The imx6q-cpufreq driver needs a similar fixing.  Please include the
> following changes into your fixing patches.  Thanks.
> 
Ok no problem I can post the fix based on response for the above question.

Regard,
Sudeep