From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Thatchanamurthy Satish <Satish.Thatchanamurt@dell.com>,
Tushar Dave <tdave@nvidia.com>
Subject: Re: [PATCH v1] PCI/EDR: Align EDR implementation with PCI firmware r3.3 spec
Date: Wed, 1 May 2024 15:07:39 -0700 [thread overview]
Message-ID: <1b54ca20-5dce-4257-bc3f-38e3106b6746@linux.intel.com> (raw)
In-Reply-To: <20240501215009.GA1497134@bhelgaas>
Hi,
On 5/1/24 2:50 PM, Bjorn Helgaas wrote:
> On Wed, May 01, 2024 at 02:25:43AM +0000, Kuppuswamy Sathyanarayanan wrote:
>> During the Error Disconnect Recover (EDR) spec transition from r3.2 ECN
>> to PCI firmware spec r3.3, improvements were made to definitions of
>> EDR_PORT_DPC_ENABLE_DSM (0x0C) and EDR_PORT_LOCATE_DSM(0x0D) _DSMs.
>>
>> Specifically,
>>
>> * EDR_PORT_DPC_ENABLE_DSM _DSM version changed from 5 to 6, and
>> arg4 is now a package type instead of an integer in version 5.
>> * EDR_PORT_LOCATE_DSM _DSM uses BIT(31) to return the status of the
>> operation.
>>
>> Ensure _DSM implementation aligns with PCI firmware r3.3 spec
>> recommendation. More details about the EDR_PORT_DPC_ENABLE_DSM and
>> EDR_PORT_LOCATE_DSM _DSMs can be found in PCI firmware specification,
>> r3.3, sec 4.6.12 and sec 4.6.13.
>>
>> While at it, fix a typo in EDR_PORT_LOCATE_DSM comments.
>>
>> Fixes: ac1c8e35a326 ("PCI/DPC: Add Error Disconnect Recover (EDR) support")
>> Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
>> ---
>> drivers/pci/pcie/edr.c | 23 +++++++++++++++++------
>> 1 file changed, 17 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/pci/pcie/edr.c b/drivers/pci/pcie/edr.c
>> index 5f4914d313a1..fea098e22e3e 100644
>> --- a/drivers/pci/pcie/edr.c
>> +++ b/drivers/pci/pcie/edr.c
>> @@ -35,7 +35,7 @@ static int acpi_enable_dpc(struct pci_dev *pdev)
>> * Behavior when calling unsupported _DSM functions is undefined,
>> * so check whether EDR_PORT_DPC_ENABLE_DSM is supported.
>> */
>> - if (!acpi_check_dsm(adev->handle, &pci_acpi_dsm_guid, 5,
>> + if (!acpi_check_dsm(adev->handle, &pci_acpi_dsm_guid, 6,
>> 1ULL << EDR_PORT_DPC_ENABLE_DSM))
> How confident are we that this won't break any existing platforms?
Since we are already using arg4 as package, it wont work with
platforms that implement version 5. So I think we won't be
breaking any existing users of version 5.
> Any idea how many platforms implement EDR_PORT_DPC_ENABLE_DSM and what
> Revision IDs they support?
I am not very sure about it. I think it is being used in some Dell
and Nvidia platforms.
@Satish from Dell, tested this fix in some Dell server platforms
that implements this support and found it working.
@Tushar Dave, since you previously submitted some error report
related to EDR, I assume you have some platforms that uses these
_DSMs. Can you please take a look at this patch and let us know
whether it works for you?
>
>> return 0;
>>
>> @@ -47,11 +47,11 @@ static int acpi_enable_dpc(struct pci_dev *pdev)
>> argv4.package.elements = &req;
>>
>> /*
>> - * Per Downstream Port Containment Related Enhancements ECN to PCI
>> - * Firmware Specification r3.2, sec 4.6.12, EDR_PORT_DPC_ENABLE_DSM is
>> - * optional. Return success if it's not implemented.
>> + * Per PCI Firmware Specification r3.3, sec 4.6.12,
>> + * EDR_PORT_DPC_ENABLE_DSM is optional. Return success if it's not
>> + * implemented.
>> */
>> - obj = acpi_evaluate_dsm(adev->handle, &pci_acpi_dsm_guid, 5,
>> + obj = acpi_evaluate_dsm(adev->handle, &pci_acpi_dsm_guid, 6,
>> EDR_PORT_DPC_ENABLE_DSM, &argv4);
>> if (!obj)
>> return 0;
>> @@ -86,7 +86,7 @@ static struct pci_dev *acpi_dpc_port_get(struct pci_dev *pdev)
>>
>> /*
>> * Behavior when calling unsupported _DSM functions is undefined,
>> - * so check whether EDR_PORT_DPC_ENABLE_DSM is supported.
>> + * so check whether EDR_PORT_LOCATE_DSM is supported.
>> */
>> if (!acpi_check_dsm(adev->handle, &pci_acpi_dsm_guid, 5,
>> 1ULL << EDR_PORT_LOCATE_DSM))
>> @@ -103,6 +103,17 @@ static struct pci_dev *acpi_dpc_port_get(struct pci_dev *pdev)
>> return NULL;
>> }
>>
>> + /*
>> + * Per PCI Firmware Specification r3.3, sec 4.6.13, bit 31 represents
>> + * the success/failure of the operation. If bit 31 is set, the operation
>> + * is failed.
>> + */
>> + if (obj->integer.value & BIT(31)) {
>> + ACPI_FREE(obj);
>> + pci_err(pdev, "Locate Port _DSM failed\n");
>> + return NULL;
>> + }
> This changes two _DSMs, and I think it should be two patches.
Ok. I can split it into two patches.
> Same question here: we now depend on functionality we didn't depend on
> before. How confident are we in this?
In some platforms I have tested so far, it seems to work. But I am
not sure whether there are other platforms that does not implement
this support.
IMO, since this change aligns with the spec, it is best to fix it.
>
>> /*
>> * Firmware returns DPC port BDF details in following format:
>> * 15:8 = bus
>> --
>> 2.25.1
>>
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
next prev parent reply other threads:[~2024-05-01 22:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-01 2:25 [PATCH v1] PCI/EDR: Align EDR implementation with PCI firmware r3.3 spec Kuppuswamy Sathyanarayanan
2024-05-01 21:50 ` Bjorn Helgaas
2024-05-01 22:07 ` Kuppuswamy Sathyanarayanan [this message]
2024-05-02 22:01 ` Thatchanamurthy, Satish
2024-05-08 20:14 ` Bjorn Helgaas
2024-05-08 20:41 ` Kuppuswamy Sathyanarayanan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1b54ca20-5dce-4257-bc3f-38e3106b6746@linux.intel.com \
--to=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=Satish.Thatchanamurt@dell.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=tdave@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).