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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
