On Fri, Oct 03, 2014 at 05:37:16PM +0100, Lorenzo Pieralisi wrote:
To be honest with you all I would have preferred to sort this out with DT, that's already doable now without this patch.
We'd still have to make sure there's a complete topology binding for ACPI and get through standardisation if any changes are needed. I guess it's probably mostly OK as the scenarios should all be shared with x86 systems but I've not looked to see if some of the subsetting that's being done for ACPI on ARMv8 causes issues.
Having said that, for platforms setting MPIDR_EL1 to reasonable values, I think that's what we should do, squash the upper MPIDR levels (for the non SMT case too). Please stick a proper comment for that to the code. We can always rely on DT to fix other cases that can't be treated properly with code above.
OK, I'll send a patch.
I took some time to think about that, since I am aware of tools (ie powertop) taking the socket id value verbatim, which can become a big number when we squash it. Since it is not a userspace API (or at least it is written nowhere that the socket id value must be a sequential, monotonic value starting from 0 and and on top of that that's an arch specific id that as far as I know must only be unique) I think the change above (plus additional code for non-SMT case) is acceptable.
More than that, it's explicitly documented as being intended to be the hardware platform's ID in cputopology.txt. I've no idea where this assumption that the numbers have to be sequential came from but it's been such a source of pain :/