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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2c828592-dbdd-4cd4-b366-70797d63329d@redhat.com>
Date: Wed, 13 Nov 2024 18:04:44 +0100
From: Hans de Goede <hdegoede@...hat.com>
To: "Daniel Walker (danielwa)" <danielwa@...co.com>,
 Shin'ichiro Kawasaki <shinichiro.kawasaki@....com>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
 Ilpo J�rvinen <ilpo.jarvinen@...ux.intel.com>,
 Klara Modin <klarasmodin@...il.com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Danil Rybakov <danilrybakov249@...il.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "xe-linux-external(mailer list)" <xe-linux-external@...co.com>
Subject: Re: platform/x86: p2sb: Allow p2sb_bar() calls during PCI device
 probe

Hi,

On 13-Nov-24 5:33 PM, Hans de Goede wrote:
> Hi,
> 
> On 13-Nov-24 5:24 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 13-Nov-24 4:42 PM, Daniel Walker (danielwa) wrote:
>>>
>>> Hi,
>>>
>>> I bisected an issue of a missing pci device to commit 2841631 the commit title
>>> in the subject line which was included in v6.1 stable branch.
>>>
>>> There was a later fix for a similar missing pci device commit 36c676e2 which
>>> appears to be for Goldmont/Apollo Lake. The hardware I'm using is
>>> Goldmont/Denverton. This fix did not appear to change the behavior I'm seeing.
>>>
>>> The pci device which is disappearing is a custom gpio device.
>>>
>>> I tested v6.12-rc5-next to see if any other changes had fixed the issue, but there was
>>> no change in behavior since commit 2841631 .
>>>
>>> When booting up the device is shown in the pci boot messages but the device
>>> doesn't end up making it to lspci once you get to a prompt.
>>
>> Please give the attached patch a try, this will hopefully fix things.
>>
>> Once I have confirmation that this fixes things I'll post it to the list.
>>
>> Note this will not backport to the 6.1 stable branch cleanly due to
>> changes in the x86_cpu_id macros in mainline. Backporting it should
>> be trivial. Please send a backport to stable@...r.kernel.org yourself
>> once this has been merged upstream.
>>
>> If you backport this, please also backport 36c676e2 first.
> 
> Never mind, self nack. This is correct for Gemini Lake which
> has its SPI at device.function 13.2 like Apollo Lake.
> 
> But looking at the dmesg Denverton actually has it at 1f.1
> aka 31.1 like most other Intel SoCs.
> 
> Which make me wonder why this does not work on Denverton.
> 
> It probably has something to do with these 2 messages:
> 
> pci 0000:00:1f.1: BAR 0 [mem 0xfd000000-0xfdffffff 64bit]: can't claim; no compatible bridge window
> pci 0000:00:1f.1: BAR 0 [mem 0x280000000-0x280ffffff 64bit]: assigned
> 
> I'm guessing that this re-assignment is messing up
> the p2sb BAR caching, after which things go wrong.

Hmm, but that should be fixed by 2c6370e66076 ("platform/x86: p2sb: Don't init until unassigned resources have been assigned")

and you are seeing this with 6.12, which has that.

Can you try adding a pr_info() to the top of p2sb_cache_resources()
with 6.12 and then collec a new dmesg ?

If that pr_info() is done after the:

pci 0000:00:1f.1: BAR 0 [mem 0x280000000-0x280ffffff 64bit]: assigned

message then that does not explain things.

Regards,

Hans