[PATCH v2] PCI/DPC: Check host->native_dpc before enable dpc service
Per Downstream Port Containment Related Enhancements ECN[1] Table 4-6, Interpretation of _OSC Control Field Returned Value, for bit 7 of _OSC control return value: "Firmware sets this bit to 1 to grant the OS control over PCI Express Downstream Port Containment configuration." "If control of this feature was requested and denied, or was not requested, the firmware returns this bit set to 0." We store bit 7 of _OSC control return value in host->native_dpc, check it before enable the dpc service as the firmware may not grant the control. [1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019, affecting PCI Firmware Specification, Rev. 3.2 https://members.pcisig.com/wg/PCI-SIG/document/12888 Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> --- Change since v1: - use correct reference for _OSC control return value drivers/pci/pcie/portdrv_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c index e1fed664..7445d03 100644 --- a/drivers/pci/pcie/portdrv_core.c +++ b/drivers/pci/pcie/portdrv_core.c @@ -253,7 +253,8 @@ static int get_port_device_capability(struct pci_dev *dev) */ if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) && pci_aer_available() && - (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER))) + (pcie_ports_dpc_native || + ((services & PCIE_PORT_SERVICE_AER) && host->native_dpc))) services |= PCIE_PORT_SERVICE_DPC; if (pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM || -- 2.8.1
Per Downstream Port Containment Related Enhancements ECN[1], Table 4-6 Interpretation of _OSC Control Field Returned Value, for bit 7 of _OSC control return value: "If firmware allows the OS control of this feature, then, in the context of the _OSC method the OS must ensure that Downstream Port Containment ERR_COR signaling is disabled as described in the PCI Express Base Specification." and PCI Express Base Specification Revision 4.0 Version 1.0 section 6.2.10.2, Use of DPC ERR_COR Signaling: "...DPC ERR_COR signaling is primarily intended for use by platform firmware..." Currently we don't set DPC ERR_COR enable bit, but explicitly clear the bit to ensure it's disabled. [1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019, affecting PCI Firmware Specification, Rev. 3.2 https://members.pcisig.com/wg/PCI-SIG/document/12888 Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> --- drivers/pci/pcie/dpc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c index e05aba8..5cc8ef3 100644 --- a/drivers/pci/pcie/dpc.c +++ b/drivers/pci/pcie/dpc.c @@ -302,7 +302,7 @@ static int dpc_probe(struct pcie_device *dev) pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CAP, &cap); pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, &ctl); - ctl = (ctl & 0xfff4) | PCI_EXP_DPC_CTL_EN_FATAL | PCI_EXP_DPC_CTL_INT_EN; + ctl = (ctl & 0xffe4) | PCI_EXP_DPC_CTL_EN_FATAL | PCI_EXP_DPC_CTL_INT_EN; pci_write_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, ctl); pci_info(pdev, "enabled with IRQ %d\n", dev->irq); -- 2.8.1
On Wed, Feb 03, 2021 at 08:53:15PM +0800, Yicong Yang wrote:
Per Downstream Port Containment Related Enhancements ECN[1], Table 4-6 Interpretation of _OSC Control Field Returned Value, for bit 7 of _OSC control return value:
"If firmware allows the OS control of this feature, then, in the context of the _OSC method the OS must ensure that Downstream Port Containment ERR_COR signaling is disabled as described in the PCI Express Base Specification."
I think "the OS must ensure" is a typo in the spec. In the new r3.3 of the spec, it has been corrected to: If firmware allows the operating system control of this feature, then, in the context of the _OSC method firmware must clear the DPC ERR_COR Enable bit in the DPC Control Register (refer to the PCI Express Base Specification) to 0.
and PCI Express Base Specification Revision 4.0 Version 1.0 section 6.2.10.2, Use of DPC ERR_COR Signaling:
"...DPC ERR_COR signaling is primarily intended for use by platform firmware..."
Currently we don't set DPC ERR_COR enable bit, but explicitly clear the bit to ensure it's disabled.
Does this fix a problem you observed? If you're seeing a problem, and this patch fixes it, we need to do something. But if it's just to line up with the language in the spec, I think we can rely on the corrected spec language, which says the *firmware* is responsible for doing this, and leave dpc_probe() alone.
[1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019, affecting PCI Firmware Specification, Rev. 3.2 https://members.pcisig.com/wg/PCI-SIG/document/12888
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> --- drivers/pci/pcie/dpc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c index e05aba8..5cc8ef3 100644 --- a/drivers/pci/pcie/dpc.c +++ b/drivers/pci/pcie/dpc.c @@ -302,7 +302,7 @@ static int dpc_probe(struct pcie_device *dev) pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CAP, &cap); pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, &ctl);
- ctl = (ctl & 0xfff4) | PCI_EXP_DPC_CTL_EN_FATAL | PCI_EXP_DPC_CTL_INT_EN; + ctl = (ctl & 0xffe4) | PCI_EXP_DPC_CTL_EN_FATAL | PCI_EXP_DPC_CTL_INT_EN;
If we need to clear things here, I'd prefer to have names instead of the 0xfff4 or 0xffe4 magic numbers.
pci_write_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, ctl); pci_info(pdev, "enabled with IRQ %d\n", dev->irq);
-- 2.8.1
On 2021/2/19 1:20, Bjorn Helgaas wrote:
On Wed, Feb 03, 2021 at 08:53:15PM +0800, Yicong Yang wrote:
Per Downstream Port Containment Related Enhancements ECN[1], Table 4-6 Interpretation of _OSC Control Field Returned Value, for bit 7 of _OSC control return value:
"If firmware allows the OS control of this feature, then, in the context of the _OSC method the OS must ensure that Downstream Port Containment ERR_COR signaling is disabled as described in the PCI Express Base Specification."
I think "the OS must ensure" is a typo in the spec. In the new r3.3 of the spec, it has been corrected to:
If firmware allows the operating system control of this feature, then, in the context of the _OSC method firmware must clear the DPC ERR_COR Enable bit in the DPC Control Register (refer to the PCI Express Base Specification) to 0.
yes, it's probably a typo according to the latest spec.
and PCI Express Base Specification Revision 4.0 Version 1.0 section 6.2.10.2, Use of DPC ERR_COR Signaling:
"...DPC ERR_COR signaling is primarily intended for use by platform firmware..."
Currently we don't set DPC ERR_COR enable bit, but explicitly clear the bit to ensure it's disabled.
Does this fix a problem you observed? If you're seeing a problem, and this patch fixes it, we need to do something. But if it's just to line up with the language in the spec, I think we can rely on the corrected spec language, which says the *firmware* is responsible for doing this, and leave dpc_probe() alone.
this patch comes when i was debugging the EDR and navigating the code and spec (i cannot get the latest spec at that time). no problem was observed but i have thought it might be sanity to ensure the ERR_COR was not set. it's ok leave the code as is, as the latest spec exlicitly requires the firmware to ensure this.
[1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019, affecting PCI Firmware Specification, Rev. 3.2 https://members.pcisig.com/wg/PCI-SIG/document/12888
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> --- drivers/pci/pcie/dpc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c index e05aba8..5cc8ef3 100644 --- a/drivers/pci/pcie/dpc.c +++ b/drivers/pci/pcie/dpc.c @@ -302,7 +302,7 @@ static int dpc_probe(struct pcie_device *dev) pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CAP, &cap); pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, &ctl);
- ctl = (ctl & 0xfff4) | PCI_EXP_DPC_CTL_EN_FATAL | PCI_EXP_DPC_CTL_INT_EN; + ctl = (ctl & 0xffe4) | PCI_EXP_DPC_CTL_EN_FATAL | PCI_EXP_DPC_CTL_INT_EN;
If we need to clear things here, I'd prefer to have names instead of the 0xfff4 or 0xffe4 magic numbers.
sure, that will be clearer. i just followed the previous implementation. Thanks, Yicong
pci_write_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, ctl); pci_info(pdev, "enabled with IRQ %d\n", dev->irq);
-- 2.8.1
.
On Wed, Feb 03, 2021 at 08:53:15PM +0800, Yicong Yang wrote:
Per Downstream Port Containment Related Enhancements ECN[1], Table 4-6 Interpretation of _OSC Control Field Returned Value, for bit 7 of _OSC control return value:
"If firmware allows the OS control of this feature, then, in the context of the _OSC method the OS must ensure that Downstream Port Containment ERR_COR signaling is disabled as described in the PCI Express Base Specification."
and PCI Express Base Specification Revision 4.0 Version 1.0 section 6.2.10.2, Use of DPC ERR_COR Signaling:
"...DPC ERR_COR signaling is primarily intended for use by platform firmware..."
Currently we don't set DPC ERR_COR enable bit, but explicitly clear the bit to ensure it's disabled.
[1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019, affecting PCI Firmware Specification, Rev. 3.2 https://members.pcisig.com/wg/PCI-SIG/document/12888
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Anybody want to chime in and review this? Sometimes I feel like a one-man band :)
--- drivers/pci/pcie/dpc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c index e05aba8..5cc8ef3 100644 --- a/drivers/pci/pcie/dpc.c +++ b/drivers/pci/pcie/dpc.c @@ -302,7 +302,7 @@ static int dpc_probe(struct pcie_device *dev) pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CAP, &cap); pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, &ctl);
- ctl = (ctl & 0xfff4) | PCI_EXP_DPC_CTL_EN_FATAL | PCI_EXP_DPC_CTL_INT_EN; + ctl = (ctl & 0xffe4) | PCI_EXP_DPC_CTL_EN_FATAL | PCI_EXP_DPC_CTL_INT_EN; pci_write_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, ctl); pci_info(pdev, "enabled with IRQ %d\n", dev->irq);
-- 2.8.1
On Sat, Apr 10, 2021 at 10:21:03AM -0500, Bjorn Helgaas wrote:
Anybody want to chime in and review this? Sometimes I feel like a one-man band :)
Can't say anything about the object of the patch, but style-wise this looks cryptic:
--- a/drivers/pci/pcie/dpc.c +++ b/drivers/pci/pcie/dpc.c @@ -302,7 +302,7 @@ static int dpc_probe(struct pcie_device *dev) pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, &ctl);
- ctl = (ctl & 0xfff4) | PCI_EXP_DPC_CTL_EN_FATAL | PCI_EXP_DPC_CTL_INT_EN; + ctl = (ctl & 0xffe4) | PCI_EXP_DPC_CTL_EN_FATAL | PCI_EXP_DPC_CTL_INT_EN; pci_write_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, ctl);
Instead of writing "ctl & 0xfff4", I'd prefer defining macros for the register bits of interest, then use "ctl &= ~(u16)(bits to clear)" and in a separate line use "ctl |= (bits to set)". Obviously, clearing bits that are unconditionally set afterwards is unnecessary (as is done here).
pci_info(pdev, "enabled with IRQ %d\n", dev->irq);
This looks superfluous since the IRQ can be found out in /proc/interrupts. Thanks, Lukas
On 2021/4/11 3:17, Lukas Wunner wrote:
On Sat, Apr 10, 2021 at 10:21:03AM -0500, Bjorn Helgaas wrote:
Anybody want to chime in and review this? Sometimes I feel like a one-man band :)
Can't say anything about the object of the patch, but style-wise this looks cryptic:
--- a/drivers/pci/pcie/dpc.c +++ b/drivers/pci/pcie/dpc.c @@ -302,7 +302,7 @@ static int dpc_probe(struct pcie_device *dev) pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, &ctl);
- ctl = (ctl & 0xfff4) | PCI_EXP_DPC_CTL_EN_FATAL | PCI_EXP_DPC_CTL_INT_EN; + ctl = (ctl & 0xffe4) | PCI_EXP_DPC_CTL_EN_FATAL | PCI_EXP_DPC_CTL_INT_EN; pci_write_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, ctl);
Instead of writing "ctl & 0xfff4", I'd prefer defining macros for the register bits of interest, then use "ctl &= ~(u16)(bits to clear)" and in a separate line use "ctl |= (bits to set)".
yes. that's clearer. I'll use macros if we're going to have this patch.
Obviously, clearing bits that are unconditionally set afterwards is unnecessary (as is done here).
ok. I found this when I read the Spec and thought it might be sanity to ensure the bit is not set.
pci_info(pdev, "enabled with IRQ %d\n", dev->irq);
This looks superfluous since the IRQ can be found out in /proc/interrupts.
this can help us track dpc interrupts on certain ports through /proc/interrupts, as all the dpc interrupts are named 'pcie-dpc' and its hard to distinguish. Thanks, Yicong
Thanks,
Lukas
.
On 4/10/21 8:21 AM, Bjorn Helgaas wrote:
On Wed, Feb 03, 2021 at 08:53:15PM +0800, Yicong Yang wrote:
Per Downstream Port Containment Related Enhancements ECN[1], Table 4-6 Interpretation of _OSC Control Field Returned Value, for bit 7 of _OSC control return value:
"If firmware allows the OS control of this feature, then, in the context of the _OSC method the OS must ensure that Downstream Port Containment ERR_COR signaling is disabled as described in the PCI Express Base Specification."
and PCI Express Base Specification Revision 4.0 Version 1.0 section 6.2.10.2, Use of DPC ERR_COR Signaling:
"...DPC ERR_COR signaling is primarily intended for use by platform firmware..."
Currently we don't set DPC ERR_COR enable bit, but explicitly clear the bit to ensure it's disabled. Instead of spec reference, can you explain what error you are fixing? without this fix what will be the impact and explain how you mitigating it with your fix.
[1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019, affecting PCI Firmware Specification, Rev. 3.2 https://members.pcisig.com/wg/PCI-SIG/document/12888
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Anybody want to chime in and review this? Sometimes I feel like a one-man band :)
--- drivers/pci/pcie/dpc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c index e05aba8..5cc8ef3 100644 --- a/drivers/pci/pcie/dpc.c +++ b/drivers/pci/pcie/dpc.c @@ -302,7 +302,7 @@ static int dpc_probe(struct pcie_device *dev) pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CAP, &cap); pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, &ctl);
- ctl = (ctl & 0xfff4) | PCI_EXP_DPC_CTL_EN_FATAL | PCI_EXP_DPC_CTL_INT_EN; + ctl = (ctl & 0xffe4) | PCI_EXP_DPC_CTL_EN_FATAL | PCI_EXP_DPC_CTL_INT_EN; pci_write_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, ctl); pci_info(pdev, "enabled with IRQ %d\n", dev->irq);
-- 2.8.1
-- Sathyanarayanan Kuppuswamy Linux Kernel Developer
On 2021/4/12 11:32, Kuppuswamy, Sathyanarayanan wrote:
On 4/10/21 8:21 AM, Bjorn Helgaas wrote:
On Wed, Feb 03, 2021 at 08:53:15PM +0800, Yicong Yang wrote:
Per Downstream Port Containment Related Enhancements ECN[1], Table 4-6 Interpretation of _OSC Control Field Returned Value, for bit 7 of _OSC control return value:
"If firmware allows the OS control of this feature, then, in the context of the _OSC method the OS must ensure that Downstream Port Containment ERR_COR signaling is disabled as described in the PCI Express Base Specification."
and PCI Express Base Specification Revision 4.0 Version 1.0 section 6.2.10.2, Use of DPC ERR_COR Signaling:
"...DPC ERR_COR signaling is primarily intended for use by platform firmware..."
Currently we don't set DPC ERR_COR enable bit, but explicitly clear the bit to ensure it's disabled. Instead of spec reference, can you explain what error you are fixing? without this fix what will be the impact and explain how you mitigating it with your fix.
I found this when I read the code and spec. No actual problem. I have thought it might be sanity to ensure the ERR_COR are not set if the firmware doesn't ensure this. In the PCI Firmware Specification, Rev. 3.3, it mentioned that firmware must ensure this bit to be cleared if DPC goes native, so not sure this patch is necessary now. Thanks, Yicong
[1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019, affecting PCI Firmware Specification, Rev. 3.2 https://members.pcisig.com/wg/PCI-SIG/document/12888
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Anybody want to chime in and review this? Sometimes I feel like a one-man band :)
--- drivers/pci/pcie/dpc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c index e05aba8..5cc8ef3 100644 --- a/drivers/pci/pcie/dpc.c +++ b/drivers/pci/pcie/dpc.c @@ -302,7 +302,7 @@ static int dpc_probe(struct pcie_device *dev) pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CAP, &cap); pci_read_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, &ctl); - ctl = (ctl & 0xfff4) | PCI_EXP_DPC_CTL_EN_FATAL | PCI_EXP_DPC_CTL_INT_EN; + ctl = (ctl & 0xffe4) | PCI_EXP_DPC_CTL_EN_FATAL | PCI_EXP_DPC_CTL_INT_EN; pci_write_config_word(pdev, pdev->dpc_cap + PCI_EXP_DPC_CTL, ctl); pci_info(pdev, "enabled with IRQ %d\n", dev->irq); -- 2.8.1
On 2021/2/3 20:53, Yicong Yang wrote:
Per Downstream Port Containment Related Enhancements ECN[1] Table 4-6, Interpretation of _OSC Control Field Returned Value, for bit 7 of _OSC control return value:
"Firmware sets this bit to 1 to grant the OS control over PCI Express Downstream Port Containment configuration." "If control of this feature was requested and denied, or was not requested, the firmware returns this bit set to 0."
We store bit 7 of _OSC control return value in host->native_dpc, check it before enable the dpc service as the firmware may not grant the control.
[1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019, affecting PCI Firmware Specification, Rev. 3.2 https://members.pcisig.com/wg/PCI-SIG/document/12888
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> --- Change since v1: - use correct reference for _OSC control return value
drivers/pci/pcie/portdrv_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c index e1fed664..7445d03 100644 --- a/drivers/pci/pcie/portdrv_core.c +++ b/drivers/pci/pcie/portdrv_core.c @@ -253,7 +253,8 @@ static int get_port_device_capability(struct pci_dev *dev) */ if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) && pci_aer_available() && - (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER))) + (pcie_ports_dpc_native || + ((services & PCIE_PORT_SERVICE_AER) && host->native_dpc))) services |= PCIE_PORT_SERVICE_DPC;
the check here maybe problematic. the bit 7 of _OSC return value is reserved previously and the change here may break the backward compatibility. currently we make dpc enabled along with aer, which can ensure the native dpc won't be enabled if the edr is enabled. i feel a bit confused as the bit 7 is not used. does it provide a way to enable native dpc regardless of aer ownership? just as pcie_ports=dpc-native does when i checked the discussion in [1]. [1] https://lore.kernel.org/linux-pci/20191023192205.97024-1-olof@lixom.net/ Thanks, Yicong
if (pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM ||
On Wed, Feb 24, 2021 at 05:47:58PM +0800, Yicong Yang wrote:
On 2021/2/3 20:53, Yicong Yang wrote:
Per Downstream Port Containment Related Enhancements ECN[1] Table 4-6, Interpretation of _OSC Control Field Returned Value, for bit 7 of _OSC control return value:
"Firmware sets this bit to 1 to grant the OS control over PCI Express Downstream Port Containment configuration." "If control of this feature was requested and denied, or was not requested, the firmware returns this bit set to 0."
We store bit 7 of _OSC control return value in host->native_dpc, check it before enable the dpc service as the firmware may not grant the control.
[1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019, affecting PCI Firmware Specification, Rev. 3.2 https://members.pcisig.com/wg/PCI-SIG/document/12888
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> --- Change since v1: - use correct reference for _OSC control return value
drivers/pci/pcie/portdrv_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c index e1fed664..7445d03 100644 --- a/drivers/pci/pcie/portdrv_core.c +++ b/drivers/pci/pcie/portdrv_core.c @@ -253,7 +253,8 @@ static int get_port_device_capability(struct pci_dev *dev) */ if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) && pci_aer_available() && - (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER))) + (pcie_ports_dpc_native || + ((services & PCIE_PORT_SERVICE_AER) && host->native_dpc))) services |= PCIE_PORT_SERVICE_DPC;
the check here maybe problematic. the bit 7 of _OSC return value is reserved previously and the change here may break the backward compatibility. currently we make dpc enabled along with aer, which can ensure the native dpc won't be enabled if the edr is enabled.
Since you think this is problematic, I'll drop it for now. If you decide it's the right thing to do, please post it again.
i feel a bit confused as the bit 7 is not used. does it provide a way to enable native dpc regardless of aer ownership? just as pcie_ports=dpc-native does when i checked the discussion in [1].
[1] https://lore.kernel.org/linux-pci/20191023192205.97024-1-olof@lixom.net/
Thanks, Yicong
if (pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM ||
On 2021/7/27 6:05, Bjorn Helgaas wrote:
On Wed, Feb 24, 2021 at 05:47:58PM +0800, Yicong Yang wrote:
On 2021/2/3 20:53, Yicong Yang wrote:
Per Downstream Port Containment Related Enhancements ECN[1] Table 4-6, Interpretation of _OSC Control Field Returned Value, for bit 7 of _OSC control return value:
"Firmware sets this bit to 1 to grant the OS control over PCI Express Downstream Port Containment configuration." "If control of this feature was requested and denied, or was not requested, the firmware returns this bit set to 0."
We store bit 7 of _OSC control return value in host->native_dpc, check it before enable the dpc service as the firmware may not grant the control.
[1] Downstream Port Containment Related Enhancements ECN, Jan 28, 2019, affecting PCI Firmware Specification, Rev. 3.2 https://members.pcisig.com/wg/PCI-SIG/document/12888
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com> --- Change since v1: - use correct reference for _OSC control return value
drivers/pci/pcie/portdrv_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c index e1fed664..7445d03 100644 --- a/drivers/pci/pcie/portdrv_core.c +++ b/drivers/pci/pcie/portdrv_core.c @@ -253,7 +253,8 @@ static int get_port_device_capability(struct pci_dev *dev) */ if (pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DPC) && pci_aer_available() && - (pcie_ports_dpc_native || (services & PCIE_PORT_SERVICE_AER))) + (pcie_ports_dpc_native || + ((services & PCIE_PORT_SERVICE_AER) && host->native_dpc))) services |= PCIE_PORT_SERVICE_DPC;
the check here maybe problematic. the bit 7 of _OSC return value is reserved previously and the change here may break the backward compatibility. currently we make dpc enabled along with aer, which can ensure the native dpc won't be enabled if the edr is enabled.
Since you think this is problematic, I'll drop it for now. If you decide it's the right thing to do, please post it again.
yes, I still think this has problem. sorry for the noise.
i feel a bit confused as the bit 7 is not used. does it provide a way to enable native dpc regardless of aer ownership? just as pcie_ports=dpc-native does when i checked the discussion in [1].
[1] https://lore.kernel.org/linux-pci/20191023192205.97024-1-olof@lixom.net/
Thanks, Yicong
if (pci_pcie_type(dev) == PCI_EXP_TYPE_DOWNSTREAM ||
.
participants (4)
-
Bjorn Helgaas -
Kuppuswamy, Sathyanarayanan -
Lukas Wunner -
Yicong Yang