diff mbox series

PCI/DPC: Disable ERR_COR explicitly for native dpc service

Message ID 1612356795-32505-2-git-send-email-yangyicong@hisilicon.com
State New
Headers show
Series PCI/DPC: Disable ERR_COR explicitly for native dpc service | expand

Commit Message

Yicong Yang Feb. 3, 2021, 12:53 p.m. UTC
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(-)

Comments

Bjorn Helgaas Feb. 18, 2021, 5:20 p.m. UTC | #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
>
Yicong Yang Feb. 24, 2021, 8:56 a.m. UTC | #2
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
>>
> 
> .
>
Bjorn Helgaas April 10, 2021, 3:21 p.m. UTC | #3
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
>
Lukas Wunner April 10, 2021, 7:17 p.m. UTC | #4
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
Kuppuswamy, Sathyanarayanan April 12, 2021, 3:32 a.m. UTC | #5
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
>>
Yicong Yang April 12, 2021, 9:32 a.m. UTC | #6
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
> 
> .
>
Yicong Yang April 12, 2021, 9:46 a.m. UTC | #7
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
>>>
>
diff mbox series

Patch

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);