[edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers
Wu, Hao A
hao.a.wu at intel.com
Fri Jul 26 02:32:19 UTC 2019
> -----Original Message-----
> From: Javeed, Ashraf
> Sent: Friday, July 26, 2019 9:47 AM
> To: Laszlo Ersek; devel at edk2.groups.io
> Cc: Kinney, Michael D; Gao, Liming; Ni, Ray; Wu, Hao A
> Subject: RE: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe
> industry standard registers
>
> Hi Laszlo,
> Good catch!
> I shall provide patch V2 with the suggested fix.
>
> Everyone,
> Any other input with this regard?
With Laszlo's comment addressed,
Reviewed-by: Hao A Wu <hao.a.wu at intel.com>
Best Regards,
Hao Wu
>
> Thanks
> Ashraf
>
>
> > -----Original Message-----
> > From: Laszlo Ersek <lersek at redhat.com>
> > Sent: Friday, July 26, 2019 2:51 AM
> > To: devel at edk2.groups.io; Javeed, Ashraf <ashraf.javeed at intel.com>
> > Cc: Kinney, Michael D <michael.d.kinney at intel.com>; Gao, Liming
> > <liming.gao at intel.com>; Ni, Ray <ray.ni at intel.com>; Wu, Hao A
> > <hao.a.wu at intel.com>
> > Subject: Re: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe
> industry
> > standard registers
> >
> > 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 (#44430): https://edk2.groups.io/g/devel/message/44430
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]
-=-=-=-=-=-=-=-=-=-=-=-
More information about the edk2-devel-archive
mailing list