From: "Javeed, Ashraf" <ashraf.javeed@intel.com>
To: Laszlo Ersek <lersek@redhat.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: "Kinney, Michael D" <michael.d.kinney@intel.com>,
"Gao, Liming" <liming.gao@intel.com>,
"Ni, Ray" <ray.ni@intel.com>, "Wu, Hao A" <hao.a.wu@intel.com>
Subject: Re: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers
Date: Fri, 26 Jul 2019 01:47:14 +0000 [thread overview]
Message-ID: <95C5C2B113DE604FB208120C742E9824578BEC23@BGSMSX101.gar.corp.intel.com> (raw)
In-Reply-To: <22b66f63-b17e-5d69-3a58-25cd75d8e077@redhat.com>
Hi Laszlo,
Good catch!
I shall provide patch V2 with the suggested fix.
Everyone,
Any other input with this regard?
Thanks
Ashraf
> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Friday, July 26, 2019 2:51 AM
> To: devel@edk2.groups.io; Javeed, Ashraf <ashraf.javeed@intel.com>
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming
> <liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>; Wu, Hao A
> <hao.a.wu@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@intel.com>
> > Cc: Michael D Kinney <michael.d.kinney@intel.com>
> > Cc: Liming Gao <liming.gao@intel.com>
> > Cc: Ray Ni <ray.ni@intel.com>
> > Cc: Hao A Wu <hao.a.wu@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;
> >
next prev parent reply other threads:[~2019-07-26 1:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-25 18:23 [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers Javeed, Ashraf
2019-07-25 21:20 ` [edk2-devel] " Laszlo Ersek
2019-07-25 21:52 ` Laszlo Ersek
2019-07-26 1:40 ` Javeed, Ashraf
2019-07-26 1:47 ` Javeed, Ashraf [this message]
2019-07-26 2:32 ` Wu, Hao A
[not found] <15B4B93608B7CE6F.24444@groups.io>
2019-07-25 18:22 ` Javeed, Ashraf
[not found] <15B4B82F76F0FE72.24444@groups.io>
2019-07-25 18:14 ` Javeed, Ashraf
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-list 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=95C5C2B113DE604FB208120C742E9824578BEC23@BGSMSX101.gar.corp.intel.com \
--to=devel@edk2.groups.io \
/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