public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
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;
> >


  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