Re: [PATCH] x86/PCI: Revert: "Clip only host bridge windows for E820 regions"

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Tue, Jun 14, 2022 at 03:28:36PM +0300, Andy Shevchenko wrote:
> On Sun, Jun 12, 2022 at 04:43:25PM +0200, Hans de Goede wrote:
> > Clipping the bridge windows directly from pci_acpi_root_prepare_resources()
> > instead of clipping from arch_remove_reservations(), has a number of
> > unforseen consequences.
> > 
> > If there is an e820 reservation in the middle of a bridge window, then
> > the smallest of the 2 remaining parts of the window will be also clipped
> > off. Where as the previous code would clip regions requested by devices,
> > rather then the entire window, leaving regions which were either entirely
> > above or below a reservation in the middle of the window alone.
> > 
> > E.g. on the Steam Deck this leads to this log message:
> > 
> > acpi PNP0A08:00: clipped [mem 0x80000000-0xf7ffffff window] to [mem 0xa0100000-0xf7ffffff window]
> > 
> > which then gets followed by these log messages:
> > 
> > pci 0000:00:01.2: can't claim BAR 14 [mem 0x80600000-0x806fffff]: no compatible bridge window
> > pci 0000:00:01.3: can't claim BAR 14 [mem 0x80500000-0x805fffff]: no compatible bridge window
> > 
> > and many more of these. Ultimately this leads to the Steam Deck
> > no longer booting properly, so revert the change.
> > 
> > Note this is not a clean revert, this revert keeps the later change
> > to make the clipping dependent on a new pci_use_e820 bool, moving
> > the checking of this bool to arch_remove_reservations().
> 
> It does _not_ fix the Intel MID case. It requires to have my patch applied as well.
> So the difference as I see is the flags checking. I believe that you still need to
> have it in case pci_use_e820 == true. But it might be that I missed an importan
> detail.

Yeah, I missed that I have compiled a tested something else, and not what I was
focused on.

That said, I double checked with your patch and nothing else and v5.19-rc2
based tree works nicely.

Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

-- 
With Best Regards,
Andy Shevchenko