From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Herring Subject: Re: new cpu iteration code... Date: Thu, 19 Sep 2013 08:26:04 -0500 Message-ID: <523AFB6C.5070300@gmail.com> References: <20130918.173726.1443745664398441126.davem@davemloft.net> <523AC214.4040601@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <523AC214.4040601-5wv7dgnIgG8@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Sudeep KarkadaNagesha Cc: David Miller , "grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org" , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: devicetree@vger.kernel.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