On Thu, 2018-06-21 at 10:28 +1000, Michael Ellerman wrote: > > That's true, though I think yours is the first report we've had of > problems. > > The old behaviour relied on device tree ordering in nearly all cases, so > you basically get whatever order your firmware happened to flatten the > device tree in. > > That tends to be consistent on a single system or with a single firmware > version, but it's not stable in general. If your firmware changes, or > you kexec then the ordering can change. > > So I'd definitely prefer we didn't go back to that behaviour, because > it's basically "random order". > > If there's anything you can do on your end to cope with the ne I think the numbering change has to be coped with. However: The main issue I see is that it somewhat hard wires that "reg" is a 64-bit property with the "interesting" bits in the bottom, and that "interesting" part somewhat happens to fit in 16-bits. It would have been better to get the full address out of reg (using the appropriate size specified in the parent #address-cells) and hash it. Cheers, Ben.
