On Wed, Jul 03, 2019 at 03:31:30PM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2019-07-02 at 22:08 -0500, Bjorn Helgaas wrote: > > > > > No it actually is. The policy on these is to rather explicitely ignore > > > what was set. If you just switch to honoring it, a good number of those > > > platforms will break. (We know that happens on arm64 as we are trying > > > to do just that). > > > > It's only different if you're assuming something about how Linux > > allocates things. That assumption is implicit, which makes this > > fragile. > > I don't understand your argument. > > Linux has *always* been responsible for the full assignment on these, > there is no UEFI/ACPI, no runtime firmware involved, I don't see the > point in trying to change that policy. The owners of these platforms > chose to do things that way, effectively assuming that Linux will do a > better job than whatever firmware (if any) did. > > I remember cases for example where the firmware would just hard wire a > BAR for a boot device to some random value right in the middle of the > address space. If we started honoring this, it would effectively have > split the already small available memory space for PCI on that card, it > made no sense to try to keep that setup. This was a case of some > obscure ppc embedded board, but that doesn't matter, I dont' see why we > should even consider changing the policy on these things. It's not like > we have to maintain two different algorithms anyway, we're just > skipping the claim pass, At least with my initial patch series it will > be obvious and done in a single place. > > > You could make this concrete by supplying an example of the actual > > firmware assignments that are broken, and the better ones that Linux > > produces. I'm talking about window and BAR values, not all the > > needless differences in how the resource tree is managed. > > Why would I waste time chasing the hundreds of random embedded boards > around to do that ? All I asked for was a single example so we could talk about something specific instead of handwaving, and your example of a device in the middle of the address space was a good one. That could happen just as easily on a "reassign if broken" platform like x86 as on a "reassign everything" platform, so I would rather make the generic code smart enough to deal with it than have the platform or driver set a "reassign everything" flag. But I think we're really talking past each other, and we're not talking about an actual patch, so I don't think we need to come to any conclusions yet. Bjorn
