From: "Laszlo Ersek" <lersek@redhat.com>
To: devel@edk2.groups.io, ashraf.javeed@intel.com
Cc: Michael D Kinney <michael.d.kinney@intel.com>,
Liming Gao <liming.gao@intel.com>, Ray Ni <ray.ni@intel.com>,
Hao A Wu <hao.a.wu@intel.com>
Subject: Re: [edk2-devel] [PATCH] MdePkg/PciExpress21.h: Fix the PCIe industry standard registers
Date: Thu, 25 Jul 2019 23:20:31 +0200 [thread overview]
Message-ID: <22b66f63-b17e-5d69-3a58-25cd75d8e077@redhat.com> (raw)
In-Reply-To: <20190725182302.7848-1-ashraf.javeed@intel.com>
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-25 21:20 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 ` Laszlo Ersek [this message]
2019-07-25 21:52 ` [edk2-devel] " Laszlo Ersek
2019-07-26 1:40 ` Javeed, Ashraf
2019-07-26 1:47 ` Javeed, Ashraf
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=22b66f63-b17e-5d69-3a58-25cd75d8e077@redhat.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