[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f2b81356-e702-3026-660f-d9a88edff632@amd.com>
Date: Sun, 7 May 2023 07:51:44 -0500
From: Mario Limonciello <mario.limonciello@....com>
To: Guenter Roeck <linux@...ck-us.net>,
Linux regressions mailing list <regressions@...ts.linux.dev>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>,
Hans de Goede <hdegoede@...hat.com>,
Shyam Sundar S K <Shyam-sundar.S-k@....com>,
Sanket Goswami <Sanket.Goswami@....com>,
Richard gong <richard.gong@....com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
linux-pci@...r.kernel.org
Subject: Re: [PATCH 1/2] amd_nb: Add PCI ID for family 19h model 78h
On 5/6/23 09:05, Guenter Roeck wrote:
> On Thu, Apr 27, 2023 at 12:33:36AM -0500, Mario Limonciello wrote:
>> s2idle previously worked on this system, but it regressed in kernel
>> 6.4 due to commit 310e782a99c7 ("platform/x86/amd: pmc: Utilize SMN
>> index 0 for driver probe").
>>
>> The reason for the regression is that before this commit the SMN
>> communication was hardcoded, but after amd_smn_read() is used which
>> relies upon the misc PCI ID used by DF function 3 being included in
>> a table. The ID was missing for model 78h, so this meant that the
>> amd_smn_read() wouldn't work.
>>
>> Add the missing ID into amd_nb, restoring s2idle on this system.
>>
>> Fixes: 310e782a99c7 ("platform/x86/amd: pmc: Utilize SMN index 0 for driver probe")
>> Signed-off-by: Mario Limonciello <mario.limonciello@....com>
> FWIW:
>
> Acked-by: Guenter Roeck <linux@...ck-us.net>
>
> Note that this patch is not upstream, meaning the second patch
> in the series can not be applied either. I am not sure if that is
> because of "regressed in kernel 6.4" - after all, that kernel does not
> exist yet. The offending patch _is_ in the upstream kernel, though.
> It might make sense to inform the regression bot if the problem is
> not fixed when v6.4-rc1 is made available.
You're right; the commit message should:
s,but it regressed in kernel 6.4 due,but it regressed in,
Boris told me that he's waiting for 6.4-rc1 to pick this series up.
#regzbot ^introduced 310e782a99c7
>
> Guenter
>
>> ---
>> arch/x86/kernel/amd_nb.c | 2 ++
>> include/linux/pci_ids.h | 1 +
>> 2 files changed, 3 insertions(+)
>>
>> diff --git a/arch/x86/kernel/amd_nb.c b/arch/x86/kernel/amd_nb.c
>> index 4266b64631a4..7e331e8f3692 100644
>> --- a/arch/x86/kernel/amd_nb.c
>> +++ b/arch/x86/kernel/amd_nb.c
>> @@ -36,6 +36,7 @@
>> #define PCI_DEVICE_ID_AMD_19H_M50H_DF_F4 0x166e
>> #define PCI_DEVICE_ID_AMD_19H_M60H_DF_F4 0x14e4
>> #define PCI_DEVICE_ID_AMD_19H_M70H_DF_F4 0x14f4
>> +#define PCI_DEVICE_ID_AMD_19H_M78H_DF_F4 0x12fc
>>
>> /* Protect the PCI config register pairs used for SMN. */
>> static DEFINE_MUTEX(smn_mutex);
>> @@ -79,6 +80,7 @@ static const struct pci_device_id amd_nb_misc_ids[] = {
>> { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M50H_DF_F3) },
>> { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M60H_DF_F3) },
>> { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M70H_DF_F3) },
>> + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M78H_DF_F3) },
>> {}
>> };
>>
>> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
>> index 45c3d62e616d..95f33dadb2be 100644
>> --- a/include/linux/pci_ids.h
>> +++ b/include/linux/pci_ids.h
>> @@ -567,6 +567,7 @@
>> #define PCI_DEVICE_ID_AMD_19H_M50H_DF_F3 0x166d
>> #define PCI_DEVICE_ID_AMD_19H_M60H_DF_F3 0x14e3
>> #define PCI_DEVICE_ID_AMD_19H_M70H_DF_F3 0x14f3
>> +#define PCI_DEVICE_ID_AMD_19H_M78H_DF_F3 0x12fb
>> #define PCI_DEVICE_ID_AMD_CNB17H_F3 0x1703
>> #define PCI_DEVICE_ID_AMD_LANCE 0x2000
>> #define PCI_DEVICE_ID_AMD_LANCE_HOME 0x2001
>> --
>> 2.34.1
>>
Powered by blists - more mailing lists