[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 7/7] xen/arm: get the number of cpus from device tree
On Thu, 15 Nov 2012, Ian Campbell wrote: > On Thu, 2012-11-15 at 15:26 +0000, Stefano Stabellini wrote: > > On Thu, 15 Nov 2012, Ian Campbell wrote: > > > On Tue, 2012-11-13 at 15:42 +0000, Stefano Stabellini wrote: > > > > diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c > > > > index 3d1f0f4..5b6dab9 100644 > > > > --- a/xen/common/device_tree.c > > > > +++ b/xen/common/device_tree.c > > > > @@ -153,6 +153,25 @@ const char *device_tree_bootargs(const void *fdt) > > > > return prop->data; > > > > } > > > > > > > > +int device_tree_cpus(const void *fdt) > > > > +{ > > > > + int node = 0, depth = 1; > > > > + int cpus = 0; > > > > + > > > > + node = fdt_path_offset(fdt, "/cpus/cpu"); > > > > + if ( node < 0 ) > > > > + return 1; /* we have at least one cpu */ > > > > + > > > > + while ( node >= 0 && depth >= 0 ) { > > > > + if ( strncmp(fdt_get_name(fdt, node, NULL), "cpu", 3) ) > > > > + continue; > > > > + node = fdt_next_node(fdt, node, &depth); > > > > + cpus++; > > > > > > Do we not need to track the largest <n> for each cpu@<n> which we see, > > > in order to handle systems with e.g. CPUs 0, 1, 4 & 5? > > > > Actually the hardware ID is expressed by the <reg> propery. > > Maybe we should set the corresponding ID in cpu_present_map from > > device_tree_cpus? > > I'm not sure what you mean. I mean that it is not the @<num> that expresses the cpu number from the hardware point of view. The cpu number is held by the <reg> property of the cpu node. Considering that the second cpu could theoretically have ID number 5, we should go and mark cpu 1-4 as non present in the cpu masks. We should only set cpu number 5 as present. > > > There are some helpers in device_tree.c to walk over trees like this, > > > are none of them suitable? > > > > Do you mean device_tree_node_matches? > > Yes, I can use that instead of strncmp. I'll do that. > > You should , but that's not what I was talkig about ;-) > > I was thinking of device_tree_for_each_node but I suppose that doesn't > quite fit? But perhaps you can integrate with early_scan_node? Maybe, but now that I think about it we should be matching on device_type rather than node name. We should do the same for memory too. We need to either change device_tree_node_matches or write a new matching function. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |