Re: platform/x86: p2sb: Allow p2sb_bar() calls during PCI device probe

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

On Sat, Nov 16, 2024 at 12:34:54PM +0100, Hans de Goede wrote:
> On 13-Nov-24 8:17 PM, Andy Shevchenko wrote:
> > On Wed, Nov 13, 2024 at 05:33:41PM +0100, Hans de Goede wrote:

...

> > That said, messing up with that address is most likely a problematic there.
> 
> The relocation also happens in the provided working dmesg. I agree that
> the relocation is weird, but that does not appear to be the issue.

Hmm... I'm then wondering why we can't just unhide the device once at the early
boot (via [x86 specific] PCI quirk) and live with that... My most worries were
about relocation, but currently reading the documentations I see that this
shouldn't be a problem as the lowest 3 bytes define the target address on the
backbone anyway. I.o.w. it shouldn't matter what is written in the bits 63..24.

And FTR, I haven't found any specifics for Denverton, it's just an early
generation of P2SB RTL, but documentation says it should work as the others
on a basic levels (like what we expect from it in the Linux kernel).

> At least it was not an issue before we switched to caching the bar
> returned by p2sb_bar() early on so that p2sb_bar() does not need
> to take looks.

Anyway, it's easy to check just by caching the initial value of 0xfd000000
and see if it helps.

Another point here is the power management. Is there any PM handling during
the resource (re-)assignment? It might put the whole piece to D3hot and make
it not working. But I'm purely speculating here...

-- 
With Best Regards,
Andy Shevchenko