On Thu, Jul 22, 2021 at 10:47:49AM +0530, Aneesh Kumar K.V wrote:
On 7/22/21 8:06 AM, David Gibson wrote:
quoted
On Thu, Jul 22, 2021 at 11:59:15AM +1000, David Gibson wrote:
quoted
On Mon, Jun 28, 2021 at 08:41:12PM +0530, Aneesh Kumar K.V wrote:
quoted
No functional change in this patch.
The new name does not match how you describe "primary domain index" in
the documentation from patch 6/6. There it comes from the values in
associativity-reference-points, but here it simply comes from the
lengths of all the associativity properties.
No, sorry, I misread this code... misled by the old name, so it's a
good thing you're changing it.
But.. I'm still not sure the new name is accurate, either...
[snip]
quoted
quoted
if (form1_affinity) {
- depth = of_read_number(distance_ref_points, 1);
+ index = of_read_number(distance_ref_points, 1);
AFACIT distance_ref_points hasn't been altered from the
of_get_property() at this point, so isn't this setting depth / index
to the number of entries in ref-points, rather than the value of the
first entry (which is what primary domain index is supposed to be).
ibm,associativity-reference-points property format is as below.
# lsprop ibm,associativity-reference-points
ibm,associativity-reference-points
00000004 00000002
it doesn't have the number of elements as the first item.
For FORM1 1 element is the NUMA boundary index/primary_domain_index
For FORM0 2 element is the NUMA boundary index/primary_domain_index.
Sorry, my bad. I foolishly expected consistency from PAPR.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson