The NVME device pluged in some AMD PCIE root port will resume timeout from s2idle which caused by NVME power CFG lost in the SMU FW restore. This issue can be workaround by using PCIe power set with simple suspend/resume process path instead of APST. In the onwards ASIC will try do the NVME shutdown save and restore in the BIOS and still need PCIe power setting to resume from RTD3 for s2idle.
In this preparation patch add a PCIe quirk for the AMD.
Cc: stable@vger.kernel.org # 5.11+ Signed-off-by: Prike Liang Prike.Liang@amd.com Signed-off-by: Shyam Sundar S K Shyam-sundar.S-k@amd.com [ck: split patches for nvme and pcie] Signed-off-by: Chaitanya Kulkarni chaitanya.kulkarni@wdc.com
Reviewed-by: Chaitanya Kulkarni chaitanya.kulkarni@wdc.com --- Changes in v2: Fix the patch format and check chip root complex DID instead of PCIe RP to avoid the storage device plugged in internal PCIe RP by USB adaptor.
Changes in v3: According to Christoph Hellwig do NVME PCIe related identify opt better in PCIe quirk driver rather than in NVME module.
Changes in v4: Split the fix to PCIe and NVMe part and then call the pci_dev_put() put the device reference count and finally refine the commit info. --- drivers/pci/quirks.c | 10 ++++++++++ include/linux/pci.h | 2 ++ 2 files changed, 12 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 653660e3..f95c8b2 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -312,6 +312,16 @@ static void quirk_nopciamd(struct pci_dev *dev) } DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8151_0, quirk_nopciamd);
+static void quirk_amd_nvme_fixup(struct pci_dev *dev) +{ + struct pci_dev *rdev; + + dev->dev_flags |= PCI_DEV_FLAGS_AMD_NVME_SIMPLE_SUSPEND; + pci_info(dev, "AMD simple suspend opt enabled\n"); + +} +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1630, quirk_amd_nvme_fixup); + /* Triton requires workarounds to be used by the drivers */ static void quirk_triton(struct pci_dev *dev) { diff --git a/include/linux/pci.h b/include/linux/pci.h index 53f4904..a6e1b1b 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -227,6 +227,8 @@ enum pci_dev_flags { PCI_DEV_FLAGS_NO_FLR_RESET = (__force pci_dev_flags_t) (1 << 10), /* Don't use Relaxed Ordering for TLPs directed at this device */ PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 11), + /* AMD simple suspend opt quirk */ + PCI_DEV_FLAGS_AMD_NVME_SIMPLE_SUSPEND = (__force pci_dev_flags_t) (1 << 12), };
enum pci_irq_reroute_variant {
The NVME device pluged in some AMD PCIE root port will resume timeout from s2idle which caused by NVME power CFG lost in the SMU FW restore. This issue can be workaround by using PCIe power set with simple suspend/resume process path instead of APST. In the onwards ASIC will try do the NVME shutdown save and restore in the BIOS and still need PCIe power setting to resume from RTD3 for s2idle.
Update the nvme_acpi_storage_d3() _with previously added quirk.
Cc: stable@vger.kernel.org # 5.11+ Signed-off-by: Prike Liang Prike.Liang@amd.com Signed-off-by: Shyam Sundar S K Shyam-sundar.S-k@amd.com [ck: split patches for nvme and pcie] Signed-off-by: Chaitanya Kulkarni chaitanya.kulkarni@wdc.com
Reviewed-by: Chaitanya Kulkarni chaitanya.kulkarni@wdc.com --- Changes in v2: Fix the patch format and check chip root complex DID instead of PCIe RP to avoid the storage device plugged in internal PCIe RP by USB adaptor.
Changes in v3: According to Christoph Hellwig do NVME PCIe related identify opt better in PCIe quirk driver rather than in NVME module.
Changes in v4: Split the fix to PCIe and NVMe part and then call the pci_dev_put() put the device reference count and finally refine the commit info. --- drivers/nvme/host/pci.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index 6bad4d4..ce9f42b 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -2832,6 +2832,7 @@ static bool nvme_acpi_storage_d3(struct pci_dev *dev) { struct acpi_device *adev; struct pci_dev *root; + struct pci_dev *rdev; acpi_handle handle; acpi_status status; u8 val; @@ -2845,6 +2846,12 @@ static bool nvme_acpi_storage_d3(struct pci_dev *dev) if (!root) return false;
+ rdev = pci_get_domain_bus_and_slot(0, 0, PCI_DEVFN(0, 0)); + if (rdev && (rdev->dev_flags & PCI_DEV_FLAGS_AMD_NVME_SIMPLE_SUSPEND)) { + pci_dev_put(rdev); + return true; + } + adev = ACPI_COMPANION(&root->dev); if (!adev) return false;
On Thu, Apr 15, 2021 at 11:52:05AM +0800, Prike Liang wrote:
The NVME device pluged in some AMD PCIE root port will resume timeout from s2idle which caused by NVME power CFG lost in the SMU FW restore. This issue can be workaround by using PCIe power set with simple suspend/resume process path instead of APST. In the onwards ASIC will try do the NVME shutdown save and restore in the BIOS and still need PCIe power setting to resume from RTD3 for s2idle.
Update the nvme_acpi_storage_d3() _with previously added quirk.
Cc: stable@vger.kernel.org # 5.11+ Signed-off-by: Prike Liang Prike.Liang@amd.com Signed-off-by: Shyam Sundar S K Shyam-sundar.S-k@amd.com [ck: split patches for nvme and pcie] Signed-off-by: Chaitanya Kulkarni chaitanya.kulkarni@wdc.com
Reviewed-by: Chaitanya Kulkarni chaitanya.kulkarni@wdc.com
You don't sign off and review a patch. And you do not put a blank line between them, this should all be one chunk of text.
Changes in v2: Fix the patch format and check chip root complex DID instead of PCIe RP to avoid the storage device plugged in internal PCIe RP by USB adaptor.
Changes in v3: According to Christoph Hellwig do NVME PCIe related identify opt better in PCIe quirk driver rather than in NVME module.
Changes in v4: Split the fix to PCIe and NVMe part and then call the pci_dev_put() put the device reference count and finally refine the commit info.
drivers/nvme/host/pci.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index 6bad4d4..ce9f42b 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -2832,6 +2832,7 @@ static bool nvme_acpi_storage_d3(struct pci_dev *dev) { struct acpi_device *adev; struct pci_dev *root;
- struct pci_dev *rdev; acpi_handle handle; acpi_status status; u8 val;
@@ -2845,6 +2846,12 @@ static bool nvme_acpi_storage_d3(struct pci_dev *dev) if (!root) return false;
- rdev = pci_get_domain_bus_and_slot(0, 0, PCI_DEVFN(0, 0));
Please look at the root bus for the specific device, do not assume that you are only on this specific bus.
greg k-h
[AMD Public Use]
From: Greg KH gregkh@linuxfoundation.org Sent: Thursday, April 15, 2021 2:30 PM To: Liang, Prike Prike.Liang@amd.com Cc: linux-nvme@lists.infradead.org; Chaitanya.Kulkarni@wdc.com; hch@infradead.org; stable@vger.kernel.org; Deucher, Alexander Alexander.Deucher@amd.com; S-k, Shyam-sundar <Shyam-sundar.S- k@amd.com> Subject: Re: [PATCH v4 2/2] nvme-pci: add AMD PCIe quirk for suspend/resume
On Thu, Apr 15, 2021 at 11:52:05AM +0800, Prike Liang wrote:
The NVME device pluged in some AMD PCIE root port will resume timeout from s2idle which caused by NVME power CFG lost in the SMU FW restore. This issue can be workaround by using PCIe power set with simple suspend/resume process path instead of APST. In the onwards ASIC will try do the NVME shutdown save and restore in the BIOS and still need PCIe power setting to resume from RTD3 for s2idle.
Update the nvme_acpi_storage_d3() _with previously added quirk.
Cc: stable@vger.kernel.org # 5.11+ Signed-off-by: Prike Liang Prike.Liang@amd.com Signed-off-by: Shyam Sundar S K Shyam-sundar.S-k@amd.com [ck: split patches for nvme and pcie] Signed-off-by: Chaitanya Kulkarni chaitanya.kulkarni@wdc.com
Reviewed-by: Chaitanya Kulkarni chaitanya.kulkarni@wdc.com
You don't sign off and review a patch. And you do not put a blank line between them, this should all be one chunk of text.
Changes in v2: Fix the patch format and check chip root complex DID instead of PCIe RP to avoid the storage device plugged in internal PCIe RP by USB adaptor.
Changes in v3: According to Christoph Hellwig do NVME PCIe related identify opt better in PCIe quirk driver rather than in NVME module.
Changes in v4: Split the fix to PCIe and NVMe part and then call the pci_dev_put() put the device reference count and finally refine the commit info.
drivers/nvme/host/pci.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index 6bad4d4..ce9f42b 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -2832,6 +2832,7 @@ static bool nvme_acpi_storage_d3(struct pci_dev *dev) { struct acpi_device *adev; struct pci_dev *root; +struct pci_dev *rdev; acpi_handle handle; acpi_status status; u8 val; @@ -2845,6 +2846,12 @@ static bool nvme_acpi_storage_d3(struct
pci_dev *dev)
if (!root) return false;
+rdev = pci_get_domain_bus_and_slot(0, 0, PCI_DEVFN(0, 0));
Please look at the root bus for the specific device, do not assume that you are only on this specific bus.
Thanks proposal, do you mean search the root complex device should by NVMe RP bus and something like as the following? rdev = pci_get_domain_bus_and_slot(pci_domain_nr(root->bus), root->bus->number, PCI_DEVFN(0, 0));
greg k-h
A cover letter for the series would be really nice.
On Thu, Apr 15, 2021 at 11:52:04AM +0800, Prike Liang wrote:
The NVME device pluged in some AMD PCIE root port will resume timeout from s2idle which caused by NVME power CFG lost in the SMU FW restore. This issue can be workaround by using PCIe power set with simple suspend/resume process path instead of APST. In the onwards ASIC will try do the NVME shutdown save and restore in the BIOS and still need PCIe power setting to resume from RTD3 for s2idle.
In this preparation patch add a PCIe quirk for the AMD.
The above looks very hard to understand to me. It uses some AMD specific terms, and also is overly specific to NVMe. Any other PCIe device not doing a runtime-D3 in these slots will have the same problem.
So I think you should generalize the flag name and description to describe what broken behavior the AMD root port has here, and only cursory refer to drivers that are broken by it.
I'd also much prefer if the flag is used on every pci_dev that is affected by the broken behavior rather than requiring another lookup in the driver.
[AMD Public Use]
From: Christoph Hellwig hch@infradead.org Sent: Thursday, April 15, 2021 4:21 PM To: Liang, Prike Prike.Liang@amd.com Cc: linux-nvme@lists.infradead.org; Chaitanya.Kulkarni@wdc.com; gregkh@linuxfoundation.org; hch@infradead.org; stable@vger.kernel.org; Deucher, Alexander Alexander.Deucher@amd.com; S-k, Shyam-sundar Shyam-sundar.S-k@amd.com Subject: Re: [PATCH v4 1/2] PCI: add AMD PCIe quirk for nvme shutdown opt
A cover letter for the series would be really nice.
Will add a cover letter patch for overview of issue background.
On Thu, Apr 15, 2021 at 11:52:04AM +0800, Prike Liang wrote:
The NVME device pluged in some AMD PCIE root port will resume timeout from s2idle which caused by NVME power CFG lost in the SMU FW restore. This issue can be workaround by using PCIe power set with simple suspend/resume process path instead of APST. In the onwards ASIC will try do the NVME shutdown save and restore in the BIOS and still need PCIe power setting to resume from RTD3 for s2idle.
In this preparation patch add a PCIe quirk for the AMD.
The above looks very hard to understand to me. It uses some AMD specific terms, and also is overly specific to NVMe. Any other PCIe device not doing a runtime-D3 in these slots will have the same problem.
Yes, but the other peripheral device seems all can reach its min device power state during s2idle suspend process. To be honest, I don't dedicate to the NVMe development and only from the NVMe legacy suspend-resume software sequence can see during this default suspend only do some save-restore APST link states and the NVMe device still remain in the D0 state and then the device force to safe shutdown in the SMU firmware. Then the NVMe device will keep D0 un-initialize state during s2idle resume and NVMe command request will be performed abnormally and eventually result in accessing timeout.
So I think you should generalize the flag name and description to describe what broken behavior the AMD root port has here, and only cursory refer to drivers that are broken by it.
Will give more descriptor about the flag usage.
I'd also much prefer if the flag is used on every pci_dev that is affected by the broken behavior rather than requiring another lookup in the driver.
Sorry can't get the meaning, could you give more detail how to implement this?
Thanks, Prike
On Thu, Apr 15, 2021 at 09:41:53AM +0000, Liang, Prike wrote:
From: Christoph Hellwig hch@infradead.org
I'd also much prefer if the flag is used on every pci_dev that is affected by the broken behavior rather than requiring another lookup in the driver.
Sorry can't get the meaning, could you give more detail how to implement this?
The suggestion is child devices of the pci bus inherit the quirk so drivers don't need to look up the parent device that requires it.
That makes sense for a couple reasons. For one, your hard-coded 0:0.0 probably aligns to actual implementations, but I did't find a spec requirement that the host bridge occupy that BDf, so not having to look up a fixed location is more flexible.
If I understand the suggestion correctly, I think it's probably easier to thread the quirk through the pci_bus->bus_flags. Does the below (untested) make sense?
--- diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index d47bb18b976a..022ff6cf202f 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -2834,6 +2834,9 @@ static bool nvme_acpi_storage_d3(struct pci_dev *dev) acpi_status status; u8 val;
+ if (dev->bus->bus_flags & PCI_BUS_FLAGS_DISABLE_ON_S2I) + return true; + /* * Look for _DSD property specifying that the storage device on the port * must use D3 to support deep platform power savings during diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 953f15abc850..34ba691ec545 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -558,10 +558,13 @@ static struct pci_bus *pci_alloc_bus(struct pci_bus *parent) INIT_LIST_HEAD(&b->resources); b->max_bus_speed = PCI_SPEED_UNKNOWN; b->cur_bus_speed = PCI_SPEED_UNKNOWN; + if (parent) { #ifdef CONFIG_PCI_DOMAINS_GENERIC - if (parent) b->domain_nr = parent->domain_nr; #endif + if (parent->bus_flags & PCI_BUS_FLAGS_DISABLE_ON_S2I) + b->bus_flags |= PCI_BUS_FLAGS_DISABLE_ON_S2I; + } return b; }
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 653660e3ba9e..e8f74661138a 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -312,6 +312,14 @@ static void quirk_nopciamd(struct pci_dev *dev) } DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8151_0, quirk_nopciamd);
+static void quirk_amd_s2i_fixup(struct pci_dev *dev) +{ + dev->bus->bus_flags |= PCI_BUS_FLAGS_DISABLE_ON_S2I; + pci_info(dev, "AMD simple suspend opt enabled\n"); + +} +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x1630, quirk_amd_s2i_fixup); + /* Triton requires workarounds to be used by the drivers */ static void quirk_triton(struct pci_dev *dev) { diff --git a/include/linux/pci.h b/include/linux/pci.h index 86c799c97b77..7072e2ec88a2 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -240,6 +240,8 @@ enum pci_bus_flags { PCI_BUS_FLAGS_NO_MMRBC = (__force pci_bus_flags_t) 2, PCI_BUS_FLAGS_NO_AERSID = (__force pci_bus_flags_t) 4, PCI_BUS_FLAGS_NO_EXTCFG = (__force pci_bus_flags_t) 8, + /* Driver must pci_disable_device() for suspend-to-idle */ + PCI_BUS_FLAGS_DISABLE_ON_S2I = (__force pci_bus_flags_t) 16, };
/* Values from Link Status register, PCIe r3.1, sec 7.8.8 */ --
[AMD Public Use]
From: Keith Busch kbusch@kernel.org Sent: Friday, April 16, 2021 6:26 AM To: Liang, Prike Prike.Liang@amd.com Cc: Christoph Hellwig hch@infradead.org; linux-nvme@lists.infradead.org; Chaitanya.Kulkarni@wdc.com; gregkh@linuxfoundation.org; stable@vger.kernel.org; Deucher, Alexander Alexander.Deucher@amd.com; S-k, Shyam-sundar <Shyam-sundar.S- k@amd.com> Subject: Re: [PATCH v4 1/2] PCI: add AMD PCIe quirk for nvme shutdown opt
On Thu, Apr 15, 2021 at 09:41:53AM +0000, Liang, Prike wrote:
From: Christoph Hellwig hch@infradead.org
I'd also much prefer if the flag is used on every pci_dev that is affected by the broken behavior rather than requiring another lookup in
the driver.
Sorry can't get the meaning, could you give more detail how to implement
this?
The suggestion is child devices of the pci bus inherit the quirk so drivers don't need to look up the parent device that requires it.
That makes sense for a couple reasons. For one, your hard-coded 0:0.0 probably aligns to actual implementations, but I did't find a spec requirement that the host bridge occupy that BDf, so not having to look up a fixed location is more flexible.
If I understand the suggestion correctly, I think it's probably easier to thread the quirk through the pci_bus->bus_flags. Does the below (untested) make sense?
Thanks Busch for elaborate clarification. The PCIe RC bus flag can pass to NVMe device successfully and it works well for this case. I will update the patch accordingly.
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c index d47bb18b976a..022ff6cf202f 100644 --- a/drivers/nvme/host/pci.c +++ b/drivers/nvme/host/pci.c @@ -2834,6 +2834,9 @@ static bool nvme_acpi_storage_d3(struct pci_dev *dev) acpi_status status; u8 val;
+if (dev->bus->bus_flags & PCI_BUS_FLAGS_DISABLE_ON_S2I) +return true;
/*
- Look for _DSD property specifying that the storage device on the
port
- must use D3 to support deep platform power savings during diff --
git a/drivers/pci/probe.c b/drivers/pci/probe.c index 953f15abc850..34ba691ec545 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -558,10 +558,13 @@ static struct pci_bus *pci_alloc_bus(struct pci_bus *parent) INIT_LIST_HEAD(&b->resources); b->max_bus_speed = PCI_SPEED_UNKNOWN; b->cur_bus_speed = PCI_SPEED_UNKNOWN; +if (parent) { #ifdef CONFIG_PCI_DOMAINS_GENERIC -if (parent) b->domain_nr = parent->domain_nr; #endif +if (parent->bus_flags & PCI_BUS_FLAGS_DISABLE_ON_S2I) +b->bus_flags |= PCI_BUS_FLAGS_DISABLE_ON_S2I; +} return b; }
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 653660e3ba9e..e8f74661138a 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -312,6 +312,14 @@ static void quirk_nopciamd(struct pci_dev *dev) } DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8151_0,quirk_nopciamd);
+static void quirk_amd_s2i_fixup(struct pci_dev *dev) { +dev->bus->bus_flags |= PCI_BUS_FLAGS_DISABLE_ON_S2I; +pci_info(dev, "AMD simple suspend opt enabled\n");
+} +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x1630, +quirk_amd_s2i_fixup);
/* Triton requires workarounds to be used by the drivers */ static void quirk_triton(struct pci_dev *dev) { diff --git a/include/linux/pci.h b/include/linux/pci.h index 86c799c97b77..7072e2ec88a2 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -240,6 +240,8 @@ enum pci_bus_flags { PCI_BUS_FLAGS_NO_MMRBC= (__force pci_bus_flags_t) 2, PCI_BUS_FLAGS_NO_AERSID= (__force pci_bus_flags_t) 4, PCI_BUS_FLAGS_NO_EXTCFG= (__force pci_bus_flags_t) 8, +/* Driver must pci_disable_device() for suspend-to-idle */ +PCI_BUS_FLAGS_DISABLE_ON_S2I= (__force pci_bus_flags_t) 16, };
/* Values from Link Status register, PCIe r3.1, sec 7.8.8 */
[+cc linux-pci, Rafael, thread at https://lore.kernel.org/linux-nvme/1618458725-17164-1-git-send-email-Prike.L...]
On Thu, Apr 15, 2021 at 11:52:04AM +0800, Prike Liang wrote:
The NVME device pluged in some AMD PCIE root port will resume timeout from s2idle which caused by NVME power CFG lost in the SMU FW restore. This issue can be workaround by using PCIe power set with simple suspend/resume process path instead of APST. In the onwards ASIC will try do the NVME shutdown save and restore in the BIOS and still need PCIe power setting to resume from RTD3 for s2idle.
In this preparation patch add a PCIe quirk for the AMD.
This needs to be cc'd to linux-pci (I did it for you this time).
Sorry, I can't make any sense out of the commit log. Is this a Root Port defect or an NVMe device defect?
Patch 2/2 only uses PCI_DEV_FLAGS_AMD_NVME_SIMPLE_SUSPEND in the nvme driver, so AFAICT there is no reason for the PCI core to keep track of the flag for you.
I see below that Christoph suggests it needs to be in the PCI core, but the reason needs to be explained in the commit log.
I have not acked this patch. Please don't merge it before clearing these things up.
Cc: stable@vger.kernel.org # 5.11+ Signed-off-by: Prike Liang Prike.Liang@amd.com Signed-off-by: Shyam Sundar S K Shyam-sundar.S-k@amd.com [ck: split patches for nvme and pcie] Signed-off-by: Chaitanya Kulkarni chaitanya.kulkarni@wdc.com
Reviewed-by: Chaitanya Kulkarni chaitanya.kulkarni@wdc.com
Changes in v2: Fix the patch format and check chip root complex DID instead of PCIe RP to avoid the storage device plugged in internal PCIe RP by USB adaptor.
Changes in v3: According to Christoph Hellwig do NVME PCIe related identify opt better in PCIe quirk driver rather than in NVME module.
Changes in v4: Split the fix to PCIe and NVMe part and then call the pci_dev_put() put the device reference count and finally refine the commit info.
drivers/pci/quirks.c | 10 ++++++++++ include/linux/pci.h | 2 ++ 2 files changed, 12 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 653660e3..f95c8b2 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -312,6 +312,16 @@ static void quirk_nopciamd(struct pci_dev *dev) } DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_8151_0, quirk_nopciamd); +static void quirk_amd_nvme_fixup(struct pci_dev *dev) +{
- struct pci_dev *rdev;
- dev->dev_flags |= PCI_DEV_FLAGS_AMD_NVME_SIMPLE_SUSPEND;
- pci_info(dev, "AMD simple suspend opt enabled\n");
+} +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1630, quirk_amd_nvme_fixup);
/* Triton requires workarounds to be used by the drivers */ static void quirk_triton(struct pci_dev *dev) { diff --git a/include/linux/pci.h b/include/linux/pci.h index 53f4904..a6e1b1b 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -227,6 +227,8 @@ enum pci_dev_flags { PCI_DEV_FLAGS_NO_FLR_RESET = (__force pci_dev_flags_t) (1 << 10), /* Don't use Relaxed Ordering for TLPs directed at this device */ PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 11),
- /* AMD simple suspend opt quirk */
- PCI_DEV_FLAGS_AMD_NVME_SIMPLE_SUSPEND = (__force pci_dev_flags_t) (1 << 12),
}; enum pci_irq_reroute_variant { -- 2.7.4
Linux-nvme mailing list Linux-nvme@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-nvme
On Fri, Apr 30, 2021 at 12:50:49PM -0500, Bjorn Helgaas wrote:
This needs to be cc'd to linux-pci (I did it for you this time).
I did ask for that before.
Sorry, I can't make any sense out of the commit log. Is this a Root Port defect or an NVMe device defect?
It is a root port quirk, although it appears to be intentional as Intel is doing the same thing on some platforms.
Patch 2/2 only uses PCI_DEV_FLAGS_AMD_NVME_SIMPLE_SUSPEND in the nvme driver, so AFAICT there is no reason for the PCI core to keep track of the flag for you.
I see below that Christoph suggests it needs to be in the PCI core, but the reason needs to be explained in the commit log.
As far as I can tell this has nothing to do with NVMe except for the fact that right now it mostly hits NVMe as the nvme drivers is one of the few drivers not always doing a full device shutdown when the system goes into the S3 power state. But various x86 platforms now randomly power done the link in that case.
I have not acked this patch. Please don't merge it before clearing these things up.
I would never merge PCI core changes that haven't been reviewd by the maintainer.
On Mon, May 03, 2021 at 08:14:07AM +0100, Christoph Hellwig wrote:
On Fri, Apr 30, 2021 at 12:50:49PM -0500, Bjorn Helgaas wrote:
Patch 2/2 only uses PCI_DEV_FLAGS_AMD_NVME_SIMPLE_SUSPEND in the nvme driver, so AFAICT there is no reason for the PCI core to keep track of the flag for you.
I see below that Christoph suggests it needs to be in the PCI core, but the reason needs to be explained in the commit log.
As far as I can tell this has nothing to do with NVMe except for the fact that right now it mostly hits NVMe as the nvme drivers is one of the few drivers not always doing a full device shutdown when the system goes into the S3 power state. But various x86 platforms now randomly power done the link in that case.
Right, and the v5 of this series uses a generic name for the PCI quirk without mentioning "NVME".
On Mon, May 03, 2021 at 07:57:02AM -0700, Keith Busch wrote:
On Mon, May 03, 2021 at 08:14:07AM +0100, Christoph Hellwig wrote:
On Fri, Apr 30, 2021 at 12:50:49PM -0500, Bjorn Helgaas wrote:
Patch 2/2 only uses PCI_DEV_FLAGS_AMD_NVME_SIMPLE_SUSPEND in the nvme driver, so AFAICT there is no reason for the PCI core to keep track of the flag for you.
I see below that Christoph suggests it needs to be in the PCI core, but the reason needs to be explained in the commit log.
As far as I can tell this has nothing to do with NVMe except for the fact that right now it mostly hits NVMe as the nvme drivers is one of the few drivers not always doing a full device shutdown when the system goes into the S3 power state. But various x86 platforms now randomly power done the link in that case.
Right, and the v5 of this series uses a generic name for the PCI quirk without mentioning "NVME".
It'd be nice if somebody would figure out how to cc: linux-pci on these patches.
[AMD Public Use]
From: Bjorn Helgaas helgaas@kernel.org Sent: Monday, May 3, 2021 11:50 PM To: Keith Busch kbusch@kernel.org Cc: Christoph Hellwig hch@infradead.org; Liang, Prike Prike.Liang@amd.com; linux-nvme@lists.infradead.org; Chaitanya.Kulkarni@wdc.com; gregkh@linuxfoundation.org; stable@vger.kernel.org; Deucher, Alexander Alexander.Deucher@amd.com; S-k, Shyam-sundar <Shyam-sundar.S- k@amd.com>; linux-pci@vger.kernel.org; Rafael J. Wysocki rjw@rjwysocki.net Subject: Re: [PATCH v4 1/2] PCI: add AMD PCIe quirk for nvme shutdown opt
On Mon, May 03, 2021 at 07:57:02AM -0700, Keith Busch wrote:
On Mon, May 03, 2021 at 08:14:07AM +0100, Christoph Hellwig wrote:
On Fri, Apr 30, 2021 at 12:50:49PM -0500, Bjorn Helgaas wrote:
Patch 2/2 only uses PCI_DEV_FLAGS_AMD_NVME_SIMPLE_SUSPEND in
the
nvme driver, so AFAICT there is no reason for the PCI core to keep track of the flag for you.
I see below that Christoph suggests it needs to be in the PCI core, but the reason needs to be explained in the commit log.
As far as I can tell this has nothing to do with NVMe except for the fact that right now it mostly hits NVMe as the nvme drivers is one of the few drivers not always doing a full device shutdown when the system goes into the S3 power state. But various x86 platforms now randomly power done the link in that case.
Right, and the v5 of this series uses a generic name for the PCI quirk without mentioning "NVME".
It'd be nice if somebody would figure out how to cc: linux-pci on these patches.
Thank you for your review. Sorry miss that and now linux-pci has been added to the v5 patch.
linux-stable-mirror@lists.linaro.org
-
Bjorn Helgaas -
Christoph Hellwig -
Greg KH -
Keith Busch -
Liang, Prike -
Prike Liang