Re: Archs using generic PCI controller drivers vs. resource policy

[Bjorn Helgaas <helgaas@kernel.org>]

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