Re: new cpu iteration code...

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:
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 ?

Regards,
Sudeep

--
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