Re: new cpu iteration code...

[Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 09/19/2013 04:21 AM, Sudeep KarkadaNagesha wrote:
> Hi David,
> 
> On 18/09/13 22:37, David Miller wrote:
>>
>> I'm getting a flood of kernel log warnings on bootup now with
>> the generic of_get_cpu_node() code, it is wrong for sparc64
>> on several levels.
>>
>> There is never a root "/cpus" node, so this code always fails.
>> Usually the "cpu" nodes are simply listed at the top-level.
>>
> 
> As per ePAPR:

Sparc is OpenFirmware not FDT which the ePAPR is concerned with.

> 3.6 CPUS Node Properties
> A cpus node is required for all device trees. It does not represent a
> real device in the system, but acts as a container for child cpu nodes
> which represent the systems CPUs. #address-cells and #size-cells are
> required property.
> 
>> The correct way to go about this is to use something like:
>>
>> 	struct device_node *dp;
>>
>> 	for_each_node_by_type(dp, "cpu") {
>> 	}
>>
>> and therefore be agnostic as to the layout of the device
>> tree wrt. cpu nodes.
>>
>> Secondly, the property to use to get the physical cpu number is not
>> only different on sparc from what this code uses, but varies.  It can
>> be either "upa-portid" or "portid".  The "reg" property represents
>> various things and will be different for different cpu types and thus
>> is not a good candidate for fetching this information.
> 
> The value of "reg" defines a unique CPU/thread id for the CPU/threads
> represented by the CPU node. This is again a deviation from ePAPR.
> 
> I could not find any binding document or dts file with "upa-portid" or
> "portid" to think about possible solution.
> 
> I am yet to understand definition of backward compatibility and
> adherence to ePAPR from device tree perspective. Do we consider this as
> broken DT as it doesn't adhere to ePAPR or do we need to have backward
> compatibility here ?

The simple solution here is to just remove the warning. It doesn't
appear to me that sparc ever sets the cpu device of_node pointer.

Are there any cases on where sparc does have a /cpus node? If so we'd
need to make of_get_cpu_node a weak function or depend on a kconfig option.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html