[edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers

[Laszlo Ersek]

Hi Javeed,

On 07/25/19 20:23, Javeed, Ashraf wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2007
> The following two PCI Capability Structure registers are updated as per
> the PCI Base Specification Revision 4:-
> (1) The PCI Device capability register 2(PCI_REG_PCIE_DEVICE_CAPABILITY2)
>     needs to be upgraded for the PCI features like -
>     LN system CLS (LnSystemCLS),
>     10b Tag completer/requester register fields
>     (TenBitTagCompleterSupported, TenBitTagRequesterSupported),
>     Emergency power reduction support and initialization requirement
>     (EmergencyPowerReductionSupported,
>      EmergencyPowerReductionInitializationRequired),
>     and FRS support (FrsSupported ).
> 
> (2) The PCI Device Control register 2(PCI_REG_PCIE_DEVICE_CONTROL2) needs
>     to be upgraded for the -
>     Emergency power reduction request enabling
>     (EmergencyPowerReductionRequest), and also the 10b Extended Tag
>     enabling (TenBitTagRequesterEnable).
> 
> The following two are defined as per the PCI Express Base Specification
> Revision 2.1:-
> (1) Defined macro definitions for all the ranges of Maximum Payload Sizes
>     and Maximum Read Request Sizes defined
> 
> (2) Defined macro definitions for all the ranges of Completion Timeout
>     value.
> 
> Signed-off-by: Ashraf Javeed <ashraf.javeed at intel.com>
> Cc: Michael D Kinney <michael.d.kinney at intel.com>
> Cc: Liming Gao <liming.gao at intel.com>
> Cc: Ray Ni <ray.ni at intel.com>
> Cc: Hao A Wu <hao.a.wu at intel.com>
> ---
>  MdePkg/Include/IndustryStandard/PciExpress21.h | 39 ++++++++++++++++++++++++++++++++++++---
>  1 file changed, 36 insertions(+), 3 deletions(-)
> 
> diff --git a/MdePkg/Include/IndustryStandard/PciExpress21.h b/MdePkg/Include/IndustryStandard/PciExpress21.h
> index d4003de74c..e652e77a1e 100644
> --- a/MdePkg/Include/IndustryStandard/PciExpress21.h
> +++ b/MdePkg/Include/IndustryStandard/PciExpress21.h
> @@ -91,6 +91,24 @@ typedef union {
>    UINT16   Uint16;
>  } PCI_REG_PCIE_DEVICE_CONTROL;
>  
> +#define PCIE_MAX_PAYLOAD_SIZE_128B   0
> +#define PCIE_MAX_PAYLOAD_SIZE_256B   1
> +#define PCIE_MAX_PAYLOAD_SIZE_512B   2
> +#define PCIE_MAX_PAYLOAD_SIZE_1024B  3
> +#define PCIE_MAX_PAYLOAD_SIZE_2048B  4
> +#define PCIE_MAX_PAYLOAD_SIZE_4096B  5
> +#define PCIE_MAX_PAYLOAD_SIZE_RVSD1  6
> +#define PCIE_MAX_PAYLOAD_SIZE_RVSD2  7
> +
> +#define PCIE_MAX_READ_REQ_SIZE_128B    0
> +#define PCIE_MAX_READ_REQ_SIZE_256B    1
> +#define PCIE_MAX_READ_REQ_SIZE_512B    2
> +#define PCIE_MAX_READ_REQ_SIZE_1024B   3
> +#define PCIE_MAX_READ_REQ_SIZE_2048B   4
> +#define PCIE_MAX_READ_REQ_SIZE_4096B   5
> +#define PCIE_MAX_READ_REQ_SIZE_RVSD1   6
> +#define PCIE_MAX_READ_REQ_SIZE_RVSD2   7
> +
>  typedef union {
>    struct {
>      UINT16 CorrectableError : 1;
> @@ -250,16 +268,30 @@ typedef union {
>      UINT32 NoRoEnabledPrPrPassing : 1;
>      UINT32 LtrMechanism : 1;
>      UINT32 TphCompleter : 2;
> -    UINT32 Reserved : 4;
> +    UINT32 LnSystemCLS : 2;
> +    UINT32 TenBitTagCompleterSupported : 1;
> +    UINT32 TenBitTagRequesterSupported : 1;
>      UINT32 Obff : 2;
>      UINT32 ExtendedFmtField : 1;
>      UINT32 EndEndTlpPrefix : 1;
>      UINT32 MaxEndEndTlpPrefixes : 2;
> -    UINT32 Reserved2 : 8;
> +    UINT32 EmergencyPowerReductionSupported : 2;
> +    UINT32 EmergencyPowerReductionInitializationRequired : 1;
> +    UINT32 Reserved : 4;
> +    UINT32 FrsSupported : 1;

This is risky practice. There could be code "out there" that already
uses the Reserved field in place of the named LnSystemCLS,
TenBitTagCompleterSupported, TenBitTagRequesterSupported fields.

Of course, my point is *not* that we should keep the old Reserved field
-- if code uses a field called Reserved, it should be prepared for build
breakages, when those fields are finally given sensible names.

Instead, what is risky is reintroducing the Reserved field with the same
name, but different meaning. It could silently break code that refers to
Reserved.

Thus, in such cases, it's better to locate the highest-numbered Reserved
field in the structure, add one to that number, and introduce
Reserved(N+1). This is guaranteed to trigger a compilation failure in
code that refers to Reserved right now.

In this particular case (= in structure
PCI_REG_PCIE_DEVICE_CAPABILITY2), the new field would be "Reserved3".
The patch should remove Reserved and Reserved2, and add Reserved3.

Thanks
Laszlo

>    } Bits;
>    UINT32   Uint32;
>  } PCI_REG_PCIE_DEVICE_CAPABILITY2;
>  
> +#define PCIE_COMPLETION_TIMEOUT_NOT_SUPPORTED           0
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_SUPPORTED       1
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_B_SUPPORTED       2
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_SUPPORTED     3
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_B_C_SUPPORTED     6
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_C_SUPPORTED   7
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_B_C_D_SUPPORTED   14
> +#define PCIE_COMPLETION_TIMEOUT_RANGE_A_B_C_D_SUPPORTED 15
> +
>  #define PCIE_DEVICE_CAPABILITY_OBFF_MESSAGE BIT0
>  #define PCIE_DEVICE_CAPABILITY_OBFF_WAKE    BIT1
>  
> @@ -273,7 +305,8 @@ typedef union {
>      UINT16 IdoRequest : 1;
>      UINT16 IdoCompletion : 1;
>      UINT16 LtrMechanism : 2;
> -    UINT16 Reserved : 2;
> +    UINT16 EmergencyPowerReductionRequest : 1;
> +    UINT16 TenBitTagRequesterEnable : 1;
>      UINT16 Obff : 2;
>      UINT16 EndEndTlpPrefixBlocking : 1;
>    } Bits;
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#44417): https://edk2.groups.io/g/devel/message/44417
Mute This Topic: https://groups.io/mt/32555963/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-