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: <82ab3d06-40e6-41dd-bb43-9179d4497313@redhat.com>
Date: Wed, 13 Nov 2024 17:33:41 +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: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.

Daniel, are you seeing similar messages with a working kernel ?

Regards,

Hans