From: Rob Herring <robherring2@xxxxxxxxx>
Date: Sun, 22 Sep 2013 15:13:35 -0500
> On 09/20/2013 11:44 AM, Sudeep KarkadaNagesha wrote:
>> On 19/09/13 18:38, David Miller wrote:
>>> From: Rob Herring <robherring2@xxxxxxxxx>
>>> Date: Thu, 19 Sep 2013 08:26:04 -0500
>>>
>>>> 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.
>>>
>>> Why wouldn't I want sparc to have this functionality now that the
>>> code is generically available.
>>>
>> Makes sense, but as you mentioned before we need to match other property
>> names namely "upa-portid", "portid" or "cpuid" for cpu physical id right
>> ? Are all these 32-bit values ?
>>
>>>> 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.
>>>
>>> I already gave a solution to this problem, make the loop iterator be:
>>>
>>> for_each_node_by_type(dp, "cpu")
>>>
>>
>> Does it make sense use this only when /cpus is not found ?
>> IMHO as the number of node in DT increases(which is the case on ARM
>> platforms) parsing entire tree may be expensive(which can be avoided in
>> case /cpus is found)
>
> Can't you simply do something like this for the search:
>
> cpus = of_find_node_by_path("/cpus");
> if (!cpus && IS_ENABLED(CONFIG_SPARC))
> cpus = of_find_node_by_path("/");
> if (!cpus) {
> pr_warn("Missing cpus node, bailing out\n");
> return NULL;
> }
>
> for_each_child_of_node(cpus, cpun) {
This doesn't work either Rob. Some UltraSPARC-IV systems put the cpu
nodes under directories representing the cores.
For the third time, the only thing which will work unilaterally is
the type base iterator I proposed above.
Why is there so much resistence to something which has an extremely
high likelyhood of working everywhere and not requiring any ifdef
crapola?
--
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
