* Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol [not found] <15AE3668F84BF3B8.28761@groups.io> @ 2019-07-04 13:20 ` Javeed, Ashraf 2019-07-04 16:25 ` Laszlo Ersek 0 siblings, 1 reply; 12+ messages in thread From: Javeed, Ashraf @ 2019-07-04 13:20 UTC (permalink / raw) To: devel@edk2.groups.io, Javeed, Ashraf Cc: Kinney, Michael D, Gao, Liming, Ni, Ray Please note that this new feature change would be moved to Edk2-staging after obtaining the Reviewed-By. Regards Ashraf > -----Original Message----- > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Javeed, > Ashraf > Sent: Thursday, July 4, 2019 6:42 PM > To: 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> > Subject: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI > encodings to PCI Plat protocol > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1954 > New interface added to PCI Platform Protocol / PCI Override Protocol to > retrieve device-specific platform policy for the following PCI standard features, > like Maximum Payload Size (MPS), Maximum Read Request Size > (MRRS),Extended Tags, Relax Order, No-Snoop, Active State Power > Management (ASPM),Latency Time Reporting (LTR), AtomicOp, Reference Clock > Configuration, Extended SYNCH, PTM support, and Completion Timeout (CTO). > New source files added with enhanced definitions are in: > MdePkg/Include/Protocol/PciPlatform2.h, > MdePkg/Include/Protocol/PciOverride2.h > > 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> > --- > MdePkg/Include/Protocol/PciOverride2.h | 46 > ++++++++++++++++++++++++++++++++++++++++++++++ > MdePkg/Include/Protocol/PciPlatform2.h | 396 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > ++++++ > MdePkg/MdePkg.dec | 6 ++++++ > 3 files changed, 448 insertions(+) > > diff --git a/MdePkg/Include/Protocol/PciOverride2.h > b/MdePkg/Include/Protocol/PciOverride2.h > new file mode 100644 > index 0000000000..cf452d9f8f > --- /dev/null > +++ b/MdePkg/Include/Protocol/PciOverride2.h > @@ -0,0 +1,46 @@ > +/** @file > + This file declares EFI PCI Override protocol which provides the > +interface between > + the PCI bus driver/PCI Host Bridge Resource Allocation driver and an > +implementation's > + driver to describe the unique features of a platform. > + This protocol is optional. > + > + Copyright (c) 2019, Intel Corporation. All rights reserved.<BR> This > + program and the accompanying materials are licensed and made > + available under the terms and conditions of the BSD License which > + accompanies this distribution. The full text of the license may be > + found at http://opensource.org/licenses/bsd-license.php > + > + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" > BASIS, > + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER > EXPRESS OR IMPLIED. > + > + @par Revision Reference: > + This Protocol is defined in UEFI Platform Initialization > + Specification 1.2 Volume 5: Standards > + > +**/ > + > +#ifndef _PCI_OVERRIDE2_H_ > +#define _PCI_OVERRIDE2_H_ > + > +/// > +/// EFI_PCI_OVERRIDE_PROTOCOL has the same structure with > +EFI_PCI_PLATFORM_PROTOCOL /// #include <Protocol/PciPlatform2.h> > + > +/// > +/// Global ID for the EFI_PCI_OVERRIDE_PROTOCOL /// #define > +EFI_PCI_OVERRIDE2_GUID \ > + { \ > + 0xb9d5ea1, 0x66cb, 0x4546, {0xb0, 0xbb, 0x5c, 0x6d, 0xae, 0xd9, > +0x42, 0x47} \ > + } > + > +/// > +/// Declaration for EFI_PCI_OVERRIDE_PROTOCOL /// typedef > +EFI_PCI_PLATFORM_PROTOCOL2 EFI_PCI_OVERRIDE_PROTOCOL2; > + > + > +extern EFI_GUID gEfiPciOverrideProtocol2Guid; > + > +#endif > diff --git a/MdePkg/Include/Protocol/PciPlatform2.h > b/MdePkg/Include/Protocol/PciPlatform2.h > new file mode 100644 > index 0000000000..3ff41b7754 > --- /dev/null > +++ b/MdePkg/Include/Protocol/PciPlatform2.h > @@ -0,0 +1,396 @@ > +/** @file > + This file declares PCI Platform Protocol that provide the interface > +between > + the PCI bus driver/PCI Host Bridge Resource Allocation driver and a > +platform-specific > + driver to describe the unique features of a platform. > + This protocol is optional. > + > +Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.<BR> > +This program and the accompanying materials are licensed and made > +available under the terms and conditions of the BSD License that accompanies > this distribution. > +The full text of the license may be found at > +http://opensource.org/licenses/bsd-license.php. > + > +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, > +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS > OR IMPLIED. > + > + @par Revision Reference: > + This Protocol is defined in UEFI Platform Initialization > + Specification 1.2 Volume 5: Standards > + > +**/ > + > +#ifndef _PCI_PLATFORM2_H_ > +#define _PCI_PLATFORM2_H_ > + > +/// > +/// This file must be included because the EFI_PCI_PLATFORM_PROTOCOL2 > +uses /// EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PHASE. > +/// > +#include <Protocol/PciHostBridgeResourceAllocation.h> > + > +/// > +/// Reuse the existing definition to maintain backward compatibility > +/// #include <Protocol/PciPlatform.h> > + > +/// > +/// Global ID for the EFI_PCI_PLATFORM_PROTOCOL2. > +/// > +#define EFI_PCI_PLATFORM_PROTOCOL2_GUID \ > + { \ > + 0x787b0367, 0xa945, 0x4d60, {0x8d, 0x34, 0xb9, 0xd1, 0x88, 0xd2, > +0xd0, 0xb6} \ > + } > + > +/// > +/// As per the present definition and specification of this protocol, > +the major /// version is 1, and minor version is 1. Any driver > +utilizing this protocol /// shall use these versions number to maintain > +the backward compatibility as /// per its specification changes in future. > +/// > +enum EfiPciPlatformProtocolVersion { > + EFI_PCI_PLATFORM_PROTOCOL_MAJOR_VERSION = 1, > + EFI_PCI_PLATFORM_PROTOCOL_MINOR_VERSION = 1 }; > + > +/// > +/// Forward declaration for EFI_PCI_PLATFORM_PROTOCOL2. > +/// > +typedef struct _EFI_PCI_PLATFORM_PROTOCOL2 > EFI_PCI_PLATFORM_PROTOCOL2; > + > +/// > +/// Following are the data types for EFI_PCI_PLATYFORM_EXTENDED_POLICY > +/// each for the PCI standard feature and its corresponding bitmask /// > +representing the valid combinations of PCI attributes /// > + > +/// > +/// This data type is to retrieve the PCI device platform policy for > +the PCI- /// compliant feature Maximum Payload Size (MPS). Refer to PCI > +Base Specification /// 4, (chapter 7.5.3.4) on how to translate the > +below EFI encodings as per the /// PCI hardware terminology. If this > +data member value is returned as 0 than /// there is no platform policy > +to override, this feature would be enabled as /// per its PCI > +specification based on the device capabilities. Below is it /// data > +type and the macro definitions which the driver uses for interpreting /// the > platform policy. > +/// > +typedef UINT8 EFI_PCI_CONF_MAX_PAYLOAD_SIZE; > + > +#define EFI_PCI_CONF_MAX_PAYLOAD_SIZE_AUTO 0x00 //No request for > override > +#define EFI_PCI_CONF_MAX_PAYLOAD_SIZE_128B 0x01 //set to default 128B > +#define EFI_PCI_CONF_MAX_PAYLOAD_SIZE_256B 0x02 //set to 256B if > applicable > +#define EFI_PCI_CONF_MAX_PAYLOAD_SIZE_512B 0x03 //set to 512B if > applicable > +#define EFI_PCI_CONF_MAX_PAYLOAD_SIZE_1024B 0x04 //set to 1024B if > +applicable #define EFI_PCI_CONF_MAX_PAYLOAD_SIZE_2048B 0x05 //set to > +2048B if applicable #define EFI_PCI_CONF_MAX_PAYLOAD_SIZE_4096B 0x06 > +//set to 4096B if applicable > + > +/// > +/// This data type is to retrieve the PCI device platform policy for > +the PCI- /// compliant feature Maximum Read Request Size (MRRS). Refer > +to PCI Base /// Specification 4, (chapter 7.5.3.4) on how to translate > +the below EFI /// encodings as per the PCI hardware terminology. If > +this data member value /// is returned as 0 than there is no platform > +policy to override, this feature /// would be enabled as per its PCI specification > based on the device capabilities. > +/// Below is it data type and the macro definitions which the driver > +uses for /// interpreting the platform policy. > +/// > +typedef UINT8 EFI_PCI_CONF_MAX_READ_REQ_SIZE; > + > +#define EFI_PCI_CONF_MAX_READ_REQ_SIZE_AUTO 0x00 //No request for > +override #define EFI_PCI_CONF_MAX_READ_REQ_SIZE_128B 0x01 //set to > +default 128B #define EFI_PCI_CONF_MAX_READ_REQ_SIZE_256B 0x02 //set > +to 256B if applicable #define EFI_PCI_CONF_MAX_READ_REQ_SIZE_512B 0x03 > +//set to 512B if applicable #define > +EFI_PCI_CONF_MAX_READ_REQ_SIZE_1024B 0x04 //set to 1024B if applicable > +#define EFI_PCI_CONF_MAX_READ_REQ_SIZE_2048B 0x05 //set to 2048B if > +applicable #define EFI_PCI_CONF_MAX_READ_REQ_SIZE_4096B 0x06 //set to > +4096B if applicable > + > +/// > +/// This data type is to retrieve the PCI device platform policy for > +the PCI- /// compliant feature Extended Tags. Refer to PCI Base > +Specification /// 4, (chapter 7.5.3.4) on how to translate the below > +EFI encodings as per the /// PCI hardware terminology. If this data > +member value is returned as 0 than /// there is no platform policy to > +override, this feature would be enabled as /// per its PCI > +specification based on the device capabilities. Below is it /// data > +type and the macro definitions which the driver uses for interpreting /// the > platform policy. > +/// > +typedef UINT8 EFI_PCI_CONF_EXTENDED_TAG; > + > +#define EFI_PCI_CONF_EXTENDED_TAG_AUTO 0x00 //No request for > override > +#define EFI_PCI_CONF_EXTENDED_TAG_5BIT 0x01 //set to default 5-bit > +#define EFI_PCI_CONF_EXTENDED_TAG_8BIT 0x02 //set to 8-bit if applicable > +#define EFI_PCI_CONF_EXTENDED_TAG_10BIT 0x03 //set to 10-bit if > +applicable > + > +/// > +/// This data type is to retrieve the PCI device platform policy for > +the PCI- /// compliant feature PCIe link's Active State Power Mgmt > +(ASPM). Refer to PCI Base /// Specification 4, (chapter 7.5.3.7) on how > +to translate the below EFI /// encodings as per the PCI hardware > +terminology. If this data member value /// is returned as 0 than there > +is no platform policy to override, this feature /// would be enabled as per its > PCI specification based on the device capabilities. > +/// Below is it data type and the macro definitions which the driver > +uses for /// interpreting the platform policy. > +/// > +typedef UINT8 EFI_PCI_CONF_ASPM_SUPPORT; > + > +#define EFI_PCI_CONF_ASPM_AUTO 0x00 //No request for override > +#define EFI_PCI_CONF_ASPM_DISABLE 0x01 //set to default disable state > +#define EFI_PCI_CONF_ASPM_L0s_SUPPORT 0x02 //set to L0s state > +#define EFI_PCI_CONF_ASPM_L1_SUPPORT 0x03 //set to L1 state > +#define EFI_PCI_CONF_ASPM_L0S_L1_SUPPORT 0x04 //set to L0s and L1 > +state > + > +/// > +/// This data type is to retrieve the PCI device platform policy for > +the PCI- /// compliant feature PCIe Device's Relax Ordering > +enable/disable. Refer to PCI Base /// Specification 4, (chapter > +7.5.3.4) on how to translate the below EFI /// encodings as per the PCI > +hardware terminology. If this data member value /// is returned as 0 > +than there is no platform policy to override, this feature /// would be enabled > as per its PCI specification based on the device capabilities. > +/// Below is it data type and the macro definitions which the driver > +uses for /// interpreting the platform policy. > +/// > +typedef UINT8 EFI_PCI_CONF_RELAX_ORDER; > + > +#define EFI_PCI_CONF_RO_AUTO 0x00 //No request for override > +#define EFI_PCI_CONF_RO_DISABLE 0x01 //set to default disable state > +#define EFI_PCI_CONF_RO_ENABLE 0x02 //set to enable state > + > +/// > +/// This data type is to retrieve the PCI device platform policy for > +the PCI- /// compliant feature PCIe Device's No-Snoop enable/disable. > +Refer to PCI Base /// Specification 4, (chapter 7.5.3.4) on how to > +translate the below EFI /// encodings as per the PCI hardware > +terminology. If this data member value /// is returned as 0 than there > +is no platform policy to override, this feature /// would be enabled as per its > PCI specification based on the device capabilities. > +/// Below is it data type and the macro definitions which the driver > +uses for /// interpreting the platform policy. > +/// > +typedef UINT8 EFI_PCI_CONF_NO_SNOOP; > + > +#define EFI_PCI_CONF_NS_AUTO 0x00 //No request for override > +#define EFI_PCI_CONF_NS_DISABLE 0x01 //set to default disable state > +#define EFI_PCI_CONF_NS_ENABLE 0x02 //set to enable state > + > +/// > +/// This data type is to retrieve the PCI device platform policy for > +the PCI- /// compliant feature PCIe link's Clock configuration is common or > discrete. > +/// Refer to PCI Base Specification 4, (chapter 7.5.3.7) on how to > +translate the /// below EFI encodings as per the PCI hardware > +terminology. If this data member /// value is returned as 0 than there > +is no platform policy to override, this /// feature would be enabled as > +per its PCI specification based on the device /// capabilities. Below > +is its data type and the macro definitions which the /// driver uses for > interpreting the platform policy. > +/// > +typedef UINT8 EFI_PCI_CONF_COMMON_CLOCK_CFG; > + > +#define EFI_PCI_CONF_CLK_CFG_AUTO 0x00 //No request for override > +#define EFI_PCI_CONF_CLK_CFG_ASYNCH 0x01 //set to default > asynchronous clock > +#define EFI_PCI_CONF_CLK_CFG_COMMON 0x02 //set to common clock > + > +/// > +/// This data type is to retrieve the PCI device platform policy for > +the PCI- /// compliant feature PCIe link's Extended Synch enable or disable. > +/// Refer to PCI Base Specification 4, (chapter 7.5.3.7) on how to > +translate the /// below EFI encodings as per the PCI hardware > +terminology. If this data member /// value is returned as 0 than there > +is no platform policy to override, this /// feature would be enabled as > +per its PCI specification based on the device /// capabilities. Below > +is its data type and the macro definitions which the /// driver uses for > interpreting the platform policy. > +/// > +typedef UINT8 EFI_PCI_CONF_EXTENDED_SYNCH; > + > +#define EFI_PCI_CONF_EXT_SYNCH_AUTO 0x00 //No request for override > +#define EFI_PCI_CONF_EXT_SYNCH_DISABLE 0x01 //set to default disable > +state #define EFI_PCI_CONF_EXT_SYNCH_ENABLE 0x02 //set to enable > +state > + > +/// > +/// This data type is to retrieve the PCI device platform policy for > +the PCI- /// compliant feature PCIe Device's AtomicOp Requester enable or > disable. > +/// Refer to PCI Base Specification 4, (chapter 7.5.3.16) on how to > +translate the /// below EFI encodings as per the PCI hardware > +terminology. If this data member /// value is returned as 0 than there > +is no platform policy to override, this /// feature would be enabled as > +per its PCI specification based on the device /// capabilities. Below > +is its data type and the macro definitions which the /// driver uses for > interpreting the platform policy. > +/// > +typedef UINT8 EFI_PCI_CONF_ATOMIC_OP; > + > +#define EFI_PCI_CONF_ATOMIC_OP_AUTO 0x00 //No request for override > +#define EFI_PCI_CONF_ATOMIC_OP_DISABLE 0x01 //set to default disable > +state #define EFI_PCI_CONF_ATOMIC_OP_ENABLE 0x02 //set to enable > +state > + > +/// > +/// This data type is to retrieve the PCI device platform policy for > +the PCI- /// compliant feature PCIe Device's LTR Mechanism enable/disable. > +/// Refer to PCI Base Specification 4, (chapter 7.5.3.16) on how to > +translate the /// below EFI encodings as per the PCI hardware > +terminology. If this data member /// value is returned as 0 than there > +is no platform policy to override, this /// feature would be enabled as > +per its PCI specification based on the device /// capabilities. Below > +is its data type and the macro definitions which the /// driver uses for > interpreting the platform policy. > +/// > +typedef UINT8 EFI_PCI_CONF_LTR; > + > +#define EFI_PCI_CONF_LTR_AUTO 0x00 //No request for override > +#define EFI_PCI_CONF_LTR_DISABLE 0x01 //set to default disable state > +#define EFI_PCI_CONF_LTR_ENABLE 0x02 //set to enable state > + > +/// > +/// This data type is to retrieve the PCI device platform policy for > +the PCI- /// compliant feature PCIe Device's Precision Time Measurement > (PTM) enable/disable. > +/// Refer to PCI Base Specification 4, (chapter 7.5.3.16) on how to > +translate the /// below EFI encodings as per the PCI hardware > +terminology. If this data member /// value is returned as 0 than there > +is no platform policy to override, this /// feature would be enabled as > +per its PCI specification based on the device /// capabilities. Below > +is its data type and the macro definitions which the /// driver uses for > interpreting the platform policy. > +/// > +typedef UINT8 EFI_PCI_CONF_PTM; > + > +#define EFI_PCI_CONF_PTM_AUTO 0x00 //No request for override > +#define EFI_PCI_CONF_PTM_DISABLE 0x01 //set to default disable state > +#define EFI_PCI_CONF_PTM_ENABLE 0x02 //set to enable state only > +#define EFI_PCI_CONF_PTM_ROOT_SEL 0x02 //set to root select & enable > + > +/// > +/// This data type is to retrieve the PCI device platform policy for > +the PCI- /// compliant feature PCIe Device's Completion Timeout (CTO) > +set to supported ranges /// or disable. Refer to PCI Base Specification > +4, (chapter 7.5.3.16) on how to /// translate the below EFI encodings > +as per the PCI hardware terminology. If this /// data member value is > +returned as 0 than there is no platform policy to override, /// this > +feature would be enabled as per its PCI specification based on the > +device /// capabilities. Below is its data type and the macro definitions which > the /// driver uses for interpreting the platform policy. > +/// > +typedef UINT8 EFI_PCI_CONF_CTO_SUPPORT; > + > +#define EFI_PCI_CONF_CTO_AUTO 0x00 //No request for override > +#define EFI_PCI_CONF_CTO_DEFAULT 0x01 //set to default range of 5us to > 50ms if applicable > +#define EFI_PCI_CONF_CTO_RANGE_A1 0x02 //set to range of 50us to > 100us if applicable > +#define EFI_PCI_CONF_CTO_RANGE_A2 0x03 //set to range of 1ms to 10ms > if applicable > +#define EFI_PCI_CONF_CTO_RANGE_B1 0x04 //set to range of 16ms to > 55ms if applicable > +#define EFI_PCI_CONF_CTO_RANGE_B2 0x05 //set to range of 65ms to > 210ms if applicable > +#define EFI_PCI_CONF_CTO_RANGE_C1 0x06 //set to range of 260ms to > 900ms if applicable > +#define EFI_PCI_CONF_CTO_RANGE_C2 0x07 //set to range of 1s to 3.5s if > applicable > +#define EFI_PCI_CONF_CTO_RANGE_D1 0x08 //set to range of 4s to 13s if > applicable > +#define EFI_PCI_CONF_CTO_RANGE_D2 0x09 //set to range of 17s to 64s if > applicable > +#define EFI_PCI_CONF_CTO_DET_DISABLE 0x10 //set to CTO detection > +disable if applicable > + > +/// > +/// Reserves for future use > +/// > +typedef UINT8 EFI_PCI_CONF_RESERVES; > + > +/// > +/// The EFI_PCI_PLATYFORM_EXTENDED_POLICY is altogether 128-byte size, > +with each /// byte field representing one PCI standerd feature defined > +in the PCI Express Base /// Specification 4.0, version 1.0. > +/// > +typedef struct { > + EFI_PCI_CONF_MAX_PAYLOAD_SIZE DeviceCtlMPS; > + EFI_PCI_CONF_MAX_READ_REQ_SIZE DeviceCtlMRRS; > + EFI_PCI_CONF_EXTENDED_TAG DeviceCtlExtTag; > + EFI_PCI_CONF_RELAX_ORDER DeviceCtlRelaxOrder; > + EFI_PCI_CONF_NO_SNOOP DeviceCtlNoSnoop; > + EFI_PCI_CONF_ASPM_SUPPORT LinkCtlASPMState; > + EFI_PCI_CONF_COMMON_CLOCK_CFG LinkCtlCommonClkCfg; > + EFI_PCI_CONF_EXTENDED_SYNCH LinkCtlExtSynch; > + EFI_PCI_CONF_ATOMIC_OP DeviceCtl2AtomicOp; > + EFI_PCI_CONF_LTR DeviceCtl2LTR; > + EFI_PCI_CONF_PTM PTMControl; > + EFI_PCI_CONF_CTO_SUPPORT CTOsupport; > + EFI_PCI_CONF_RESERVES Reserves[116]; > +} EFI_PCI_PLATFORM_EXTENDED_POLICY; > + > +/** > + Retrieves the PCI device-specific platform policy regarding enumeration. > + > + The PCI Bus driver and PCI Host Bridge Resource Allocation Protocol > + drivers can call this member function to retrieve the platform > + policies specific to PCI device, regarding the PCI enumeration. > + > + The GetDevicePolicy() function retrieves the platform policy for a > + particular component regarding PCI enumeration. The PCI bus driver > + and the PCI Host Bridge Resource Allocation Protocol driver can call > + this member function to retrieve the policy. > + The existing GetPlatformPolicy() member function is used by the PCI > + Bus driver to program the legacy ranges, the data that is returned by > + that member function determines the supported attributes that are > + returned by the > + EFI_PCI_IO_PROTOCOL.Attributes() function. > + The GetDevicePolicy() member function is meant to return data about > + other PCI compliant features which would be supported by the PCI Bus > + driver in future; like for example the MPS, MRRS, Extended Tag, ASPM, > + etc. The details about this PCI features can be obtained from the PCI > + Base Specification 4.x. The EFI encodings for these feature are > + defined in the EFI_PCI_PLATFORM_EXTENDED_POLICY, see the Related > Definition section for this. > + This member function will use the associated EFI handle of the PCI IO > + Protocol to determine the physical PCI device within the chipset, to > + return its device-specific platform policies. > + > + @param[in] This Pointer to the EFI_PCI_PLATFORM_PROTOCOL2 > instance. > + @param[in] PciDevice The associated PCI IO Protocol handle of the PCI > + device. Type EFI_HANDLE is defined in > + InstallProtocolInterface() in the UEFI 2.1 > + Specification @param[in] PciExtPolicy > + The platform policy with respect to other PCI features > + like, the MPS, MRRS, etc. Type > EFI_PCI_PLATFORM_EXTENDED_POLICY > + is defined in "Related Definitions" below. > + > + > + @retval EFI_SUCCESS The function completed successfully, may returns > + platform policy data for the given PCI component > + @retval EFI_UNSUPPORTED PCI component belongs to PCI topology but > not > + part of chipset to provide the > + platform policy @retval EFI_INVALID_PARAMETER If any of the input > parameters are passed with > + invalid data > + > + **/ > +typedef > +EFI_STATUS > +(EFIAPI * EFI_PCI_PLATFORM_GET_DEVICE_POLICY) ( > + IN CONST EFI_PCI_PLATFORM_PROTOCOL2 *This, > + IN EFI_HANDLE PciDevice, > + OUT EFI_PCI_PLATFORM_EXTENDED_POLICY *PciExtPolicy ); > + > +/// > +/// This protocol provides the interface between the PCI bus driver/PCI > +Host /// Bridge Resource Allocation driver and a platform-specific > +driver to describe /// the unique features of a platform. > +/// > +struct _EFI_PCI_PLATFORM_PROTOCOL2 { > + /// > + /// The notification from the PCI bus enumerator to the platform that > +it is about to > + /// enter a certain phase during the enumeration process. > + /// > + EFI_PCI_PLATFORM_PHASE_NOTIFY PlatformNotify; > + /// > + /// The notification from the PCI bus enumerator to the platform for > +each PCI > + /// controller at several predefined points during PCI controller initialization. > + /// > + EFI_PCI_PLATFORM_PREPROCESS_CONTROLLER PlatformPrepController; > + /// > + /// Retrieves the platform policy regarding enumeration. > + /// > + EFI_PCI_PLATFORM_GET_PLATFORM_POLICY GetPlatformPolicy; > + /// > + /// Gets the PCI device's option ROM from a platform-specific location. > + /// > + EFI_PCI_PLATFORM_GET_PCI_ROM GetPciRom; > + /// > + /// Retrieves the PCI device-specific platform policy regarding enumeration. > + /// > + EFI_PCI_PLATFORM_GET_DEVICE_POLICY GetDevicePolicy; > + /// > + /// The major version of this PCI Platform Protocol > + /// > + UINT8 MajorVersion; > + /// > + /// The minor version of this PCI Platform Protocol > + /// > + UINT8 MinorVersion; > + > +}; > + > +extern EFI_GUID gEfiPciPlatformProtocol2Guid; > + > +#endif > diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index > 6c563375ee..2448d2ab5d 100644 > --- a/MdePkg/MdePkg.dec > +++ b/MdePkg/MdePkg.dec > @@ -1013,6 +1013,12 @@ > ## Include/Protocol/PciOverride.h > gEfiPciOverrideProtocolGuid = { 0xb5b35764, 0x460c, 0x4a06, {0x99, 0xfc, > 0x77, 0xa1, 0x7c, 0x1b, 0x5c, 0xeb }} > > + ## Include/Protocol/PciPlatform2.h > + gEfiPciPlatformProtocol2Guid = { 0x787b0367, 0xa945, 0x4d60, { 0x8d, > 0x34, 0xb9, 0xd1, 0x88, 0xd2, 0xd0, 0xb6 }} > + > + ## Include/Protocol/PciOverride2.h > + gEfiPciOverrideProtocol2Guid = { 0xb9d5ea1, 0x66cb, 0x4546, { 0xb0, 0xbb, > 0x5c, 0x6d, 0xae, 0xd9, 0x42, 0x47 }} > + > ## Include/Protocol/PciEnumerationComplete.h > gEfiPciEnumerationCompleteProtocolGuid = { 0x30cfe3e7, 0x3de1, 0x4586, > {0xbe, 0x20, 0xde, 0xab, 0xa1, 0xb3, 0xb7, 0x93}} > > -- > 2.21.0.windows.1 > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol 2019-07-04 13:20 ` [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol Javeed, Ashraf @ 2019-07-04 16:25 ` Laszlo Ersek 2019-07-05 2:13 ` Liming Gao 0 siblings, 1 reply; 12+ messages in thread From: Laszlo Ersek @ 2019-07-04 16:25 UTC (permalink / raw) To: devel, ashraf.javeed; +Cc: Kinney, Michael D, Gao, Liming, Ni, Ray On 07/04/19 15:20, Javeed, Ashraf wrote: > Please note that this new feature change would be moved to Edk2-staging after obtaining the Reviewed-By. If the feature targets edk2-staging, then please use the following subject prefix: [PATCH edk2-staging] rather than just [PATCH]. Thanks. Laszlo ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol 2019-07-04 16:25 ` Laszlo Ersek @ 2019-07-05 2:13 ` Liming Gao 2019-07-05 2:38 ` Ni, Ray 0 siblings, 1 reply; 12+ messages in thread From: Liming Gao @ 2019-07-05 2:13 UTC (permalink / raw) To: devel@edk2.groups.io, lersek@redhat.com, Javeed, Ashraf Cc: Kinney, Michael D, Ni, Ray And, please also specify branch name in edk2-staging. The subject title likes : [PATCH edk2-staging\BranchName] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol >-----Original Message----- >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of >Laszlo Ersek >Sent: Friday, July 05, 2019 12:25 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> >Subject: Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI >encodings to PCI Plat protocol > >On 07/04/19 15:20, Javeed, Ashraf wrote: >> Please note that this new feature change would be moved to Edk2-staging >after obtaining the Reviewed-By. > >If the feature targets edk2-staging, then please use the following >subject prefix: > >[PATCH edk2-staging] > >rather than just > >[PATCH]. > >Thanks. >Laszlo > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol 2019-07-05 2:13 ` Liming Gao @ 2019-07-05 2:38 ` Ni, Ray 2019-07-05 2:48 ` Liming Gao 0 siblings, 1 reply; 12+ messages in thread From: Ni, Ray @ 2019-07-05 2:38 UTC (permalink / raw) To: Gao, Liming, devel@edk2.groups.io, lersek@redhat.com, Javeed, Ashraf Cc: Kinney, Michael D Liming, I understand Laszlo's comment requiring repo name in the patch title to tell everyone where the code will be. But before the patch is pushed, the patch owner in theory cannot guarantee the branch can be successfully created after the R-b is got. Because someone may create a branch with the same name. Is there any public document for the patch which goes to staging repo? Thanks, Ray > -----Original Message----- > From: Gao, Liming > Sent: Friday, July 5, 2019 10:13 AM > To: devel@edk2.groups.io; lersek@redhat.com; Javeed, Ashraf > <ashraf.javeed@intel.com> > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray > <ray.ni@intel.com> > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI > encodings to PCI Plat protocol > > And, please also specify branch name in edk2-staging. > > The subject title likes : [PATCH edk2-staging\BranchName] > [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol > > >-----Original Message----- > >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of > >Laszlo Ersek > >Sent: Friday, July 05, 2019 12:25 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> > >Subject: Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, > >EFI encodings to PCI Plat protocol > > > >On 07/04/19 15:20, Javeed, Ashraf wrote: > >> Please note that this new feature change would be moved to > >> Edk2-staging > >after obtaining the Reviewed-By. > > > >If the feature targets edk2-staging, then please use the following > >subject prefix: > > > >[PATCH edk2-staging] > > > >rather than just > > > >[PATCH]. > > > >Thanks. > >Laszlo > > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol 2019-07-05 2:38 ` Ni, Ray @ 2019-07-05 2:48 ` Liming Gao 2019-07-05 3:13 ` Ni, Ray 0 siblings, 1 reply; 12+ messages in thread From: Liming Gao @ 2019-07-05 2:48 UTC (permalink / raw) To: Ni, Ray, devel@edk2.groups.io, lersek@redhat.com, Javeed, Ashraf Cc: Kinney, Michael D Ray: Yes. Please see https://github.com/tianocore/edk2-staging Thanks Liming >-----Original Message----- >From: Ni, Ray >Sent: Friday, July 05, 2019 10:39 AM >To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io; >lersek@redhat.com; Javeed, Ashraf <ashraf.javeed@intel.com> >Cc: Kinney, Michael D <michael.d.kinney@intel.com> >Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI >encodings to PCI Plat protocol > >Liming, >I understand Laszlo's comment requiring repo name in the patch title to tell >everyone where the code will be. >But before the patch is pushed, the patch owner in theory cannot guarantee >the branch can be successfully created after the R-b is got. Because someone >may create a branch with the same name. > >Is there any public document for the patch which goes to staging repo? > >Thanks, >Ray > >> -----Original Message----- >> From: Gao, Liming >> Sent: Friday, July 5, 2019 10:13 AM >> To: devel@edk2.groups.io; lersek@redhat.com; Javeed, Ashraf >> <ashraf.javeed@intel.com> >> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray >> <ray.ni@intel.com> >> Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI >> encodings to PCI Plat protocol >> >> And, please also specify branch name in edk2-staging. >> >> The subject title likes : [PATCH edk2-staging\BranchName] >> [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol >> >> >-----Original Message----- >> >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of >> >Laszlo Ersek >> >Sent: Friday, July 05, 2019 12:25 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> >> >Subject: Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, >> >EFI encodings to PCI Plat protocol >> > >> >On 07/04/19 15:20, Javeed, Ashraf wrote: >> >> Please note that this new feature change would be moved to >> >> Edk2-staging >> >after obtaining the Reviewed-By. >> > >> >If the feature targets edk2-staging, then please use the following >> >subject prefix: >> > >> >[PATCH edk2-staging] >> > >> >rather than just >> > >> >[PATCH]. >> > >> >Thanks. >> >Laszlo >> > >> > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol 2019-07-05 2:48 ` Liming Gao @ 2019-07-05 3:13 ` Ni, Ray 2019-07-05 3:23 ` Liming Gao 0 siblings, 1 reply; 12+ messages in thread From: Ni, Ray @ 2019-07-05 3:13 UTC (permalink / raw) To: Gao, Liming, devel@edk2.groups.io, lersek@redhat.com, Javeed, Ashraf Cc: Kinney, Michael D Some unclear parts in the document: 1. Document says title begins with "staging/branch". The "branch" means the "branch" word itself or should be replaced with a concrete branch name? I prefer "branch" word. Reasons in previous mail. NOTE: this affects the individual patch owner. 2. Who owns the staging/master branch sync to edk2/master? Document says the staging/branch is based on staging/master but I guess usually staging patch owner creates staging/branch based on edk2/master. Thanks, Ray > -----Original Message----- > From: Gao, Liming > Sent: Friday, July 5, 2019 10:49 AM > To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; lersek@redhat.com; > Javeed, Ashraf <ashraf.javeed@intel.com> > Cc: Kinney, Michael D <michael.d.kinney@intel.com> > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI > encodings to PCI Plat protocol > > Ray: > Yes. Please see https://github.com/tianocore/edk2-staging > > Thanks > Liming > >-----Original Message----- > >From: Ni, Ray > >Sent: Friday, July 05, 2019 10:39 AM > >To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io; > >lersek@redhat.com; Javeed, Ashraf <ashraf.javeed@intel.com> > >Cc: Kinney, Michael D <michael.d.kinney@intel.com> > >Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, > >EFI encodings to PCI Plat protocol > > > >Liming, > >I understand Laszlo's comment requiring repo name in the patch title to > >tell everyone where the code will be. > >But before the patch is pushed, the patch owner in theory cannot > >guarantee the branch can be successfully created after the R-b is got. > >Because someone may create a branch with the same name. > > > >Is there any public document for the patch which goes to staging repo? > > > >Thanks, > >Ray > > > >> -----Original Message----- > >> From: Gao, Liming > >> Sent: Friday, July 5, 2019 10:13 AM > >> To: devel@edk2.groups.io; lersek@redhat.com; Javeed, Ashraf > >> <ashraf.javeed@intel.com> > >> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray > >> <ray.ni@intel.com> > >> Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, > >> EFI encodings to PCI Plat protocol > >> > >> And, please also specify branch name in edk2-staging. > >> > >> The subject title likes : [PATCH edk2-staging\BranchName] > >> [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol > >> > >> >-----Original Message----- > >> >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf > >> >Of Laszlo Ersek > >> >Sent: Friday, July 05, 2019 12:25 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> > >> >Subject: Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, > >> >EFI encodings to PCI Plat protocol > >> > > >> >On 07/04/19 15:20, Javeed, Ashraf wrote: > >> >> Please note that this new feature change would be moved to > >> >> Edk2-staging > >> >after obtaining the Reviewed-By. > >> > > >> >If the feature targets edk2-staging, then please use the following > >> >subject prefix: > >> > > >> >[PATCH edk2-staging] > >> > > >> >rather than just > >> > > >> >[PATCH]. > >> > > >> >Thanks. > >> >Laszlo > >> > > >> > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol 2019-07-05 3:13 ` Ni, Ray @ 2019-07-05 3:23 ` Liming Gao 2019-07-05 5:23 ` Javeed, Ashraf 0 siblings, 1 reply; 12+ messages in thread From: Liming Gao @ 2019-07-05 3:23 UTC (permalink / raw) To: Ni, Ray, devel@edk2.groups.io, lersek@redhat.com, Javeed, Ashraf Cc: Kinney, Michael D Ray: > -----Original Message----- > From: Ni, Ray > Sent: Friday, July 5, 2019 11:14 AM > To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io; lersek@redhat.com; Javeed, Ashraf <ashraf.javeed@intel.com> > Cc: Kinney, Michael D <michael.d.kinney@intel.com> > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol > > Some unclear parts in the document: > 1. Document says title begins with "staging/branch". The "branch" means the "branch" word itself > or should be replaced with a concrete branch name? I prefer "branch" word. Reasons in previous mail. > NOTE: this affects the individual patch owner. I understand here is the specific branch name. The patch is required to be pushed into the specific branch instead of 'branch'. I think the patch owner should propose which branch to include his patch. He can propose new branch or use the existing branch. > 2. Who owns the staging/master branch sync to edk2/master? Document says the staging/branch is > based on staging/master but I guess usually staging patch owner creates staging/branch based on edk2/master. Yes. I think so. Thanks Liming > > Thanks, > Ray > > > -----Original Message----- > > From: Gao, Liming > > Sent: Friday, July 5, 2019 10:49 AM > > To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; lersek@redhat.com; > > Javeed, Ashraf <ashraf.javeed@intel.com> > > Cc: Kinney, Michael D <michael.d.kinney@intel.com> > > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI > > encodings to PCI Plat protocol > > > > Ray: > > Yes. Please see https://github.com/tianocore/edk2-staging > > > > Thanks > > Liming > > >-----Original Message----- > > >From: Ni, Ray > > >Sent: Friday, July 05, 2019 10:39 AM > > >To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io; > > >lersek@redhat.com; Javeed, Ashraf <ashraf.javeed@intel.com> > > >Cc: Kinney, Michael D <michael.d.kinney@intel.com> > > >Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, > > >EFI encodings to PCI Plat protocol > > > > > >Liming, > > >I understand Laszlo's comment requiring repo name in the patch title to > > >tell everyone where the code will be. > > >But before the patch is pushed, the patch owner in theory cannot > > >guarantee the branch can be successfully created after the R-b is got. > > >Because someone may create a branch with the same name. > > > > > >Is there any public document for the patch which goes to staging repo? > > > > > >Thanks, > > >Ray > > > > > >> -----Original Message----- > > >> From: Gao, Liming > > >> Sent: Friday, July 5, 2019 10:13 AM > > >> To: devel@edk2.groups.io; lersek@redhat.com; Javeed, Ashraf > > >> <ashraf.javeed@intel.com> > > >> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray > > >> <ray.ni@intel.com> > > >> Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, > > >> EFI encodings to PCI Plat protocol > > >> > > >> And, please also specify branch name in edk2-staging. > > >> > > >> The subject title likes : [PATCH edk2-staging\BranchName] > > >> [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol > > >> > > >> >-----Original Message----- > > >> >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf > > >> >Of Laszlo Ersek > > >> >Sent: Friday, July 05, 2019 12:25 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> > > >> >Subject: Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, > > >> >EFI encodings to PCI Plat protocol > > >> > > > >> >On 07/04/19 15:20, Javeed, Ashraf wrote: > > >> >> Please note that this new feature change would be moved to > > >> >> Edk2-staging > > >> >after obtaining the Reviewed-By. > > >> > > > >> >If the feature targets edk2-staging, then please use the following > > >> >subject prefix: > > >> > > > >> >[PATCH edk2-staging] > > >> > > > >> >rather than just > > >> > > > >> >[PATCH]. > > >> > > > >> >Thanks. > > >> >Laszlo > > >> > > > >> > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol 2019-07-05 3:23 ` Liming Gao @ 2019-07-05 5:23 ` Javeed, Ashraf 2019-07-05 10:31 ` Ni, Ray 2019-07-05 15:35 ` Laszlo Ersek 0 siblings, 2 replies; 12+ messages in thread From: Javeed, Ashraf @ 2019-07-05 5:23 UTC (permalink / raw) To: Gao, Liming, Ni, Ray, devel@edk2.groups.io, lersek@redhat.com Cc: Kinney, Michael D Hi, Please note that these 2 tags are automatically added when the mail is sent with the formatted patch of the commit.... [edk2-devel] [PATCH] I could add the branch name tag when I sent the commit in the Edk2-staging branch for review with the community - [Edk2-staging\Branch name]. This tags will be preceded with the above 2 tags in the subject line of that mail (too many prefix tags). Can I get Reviewed-By to move this in to the Edk2-staging branch? Please note that this would require a PI Spec update. Thanks Ashraf > -----Original Message----- > From: Gao, Liming > Sent: Friday, July 5, 2019 8:53 AM > To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; lersek@redhat.com; > Javeed, Ashraf <ashraf.javeed@intel.com> > Cc: Kinney, Michael D <michael.d.kinney@intel.com> > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI > encodings to PCI Plat protocol > > Ray: > > > -----Original Message----- > > From: Ni, Ray > > Sent: Friday, July 5, 2019 11:14 AM > > To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io; > > lersek@redhat.com; Javeed, Ashraf <ashraf.javeed@intel.com> > > Cc: Kinney, Michael D <michael.d.kinney@intel.com> > > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, > > EFI encodings to PCI Plat protocol > > > > Some unclear parts in the document: > > 1. Document says title begins with "staging/branch". The "branch" means the > "branch" word itself > > or should be replaced with a concrete branch name? I prefer "branch" word. > Reasons in previous mail. > > NOTE: this affects the individual patch owner. > I understand here is the specific branch name. The patch is required to be pushed > into the specific branch instead of 'branch'. > I think the patch owner should propose which branch to include his patch. He > can propose new branch or use the existing branch. > > > 2. Who owns the staging/master branch sync to edk2/master? Document says > the staging/branch is > > based on staging/master but I guess usually staging patch owner creates > staging/branch based on edk2/master. > Yes. I think so. > > Thanks > Liming > > > > Thanks, > > Ray > > > > > -----Original Message----- > > > From: Gao, Liming > > > Sent: Friday, July 5, 2019 10:49 AM > > > To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; > > > lersek@redhat.com; Javeed, Ashraf <ashraf.javeed@intel.com> > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com> > > > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, > > > EFI encodings to PCI Plat protocol > > > > > > Ray: > > > Yes. Please see https://github.com/tianocore/edk2-staging > > > > > > Thanks > > > Liming > > > >-----Original Message----- > > > >From: Ni, Ray > > > >Sent: Friday, July 05, 2019 10:39 AM > > > >To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io; > > > >lersek@redhat.com; Javeed, Ashraf <ashraf.javeed@intel.com> > > > >Cc: Kinney, Michael D <michael.d.kinney@intel.com> > > > >Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New > > > >interface, EFI encodings to PCI Plat protocol > > > > > > > >Liming, > > > >I understand Laszlo's comment requiring repo name in the patch > > > >title to tell everyone where the code will be. > > > >But before the patch is pushed, the patch owner in theory cannot > > > >guarantee the branch can be successfully created after the R-b is got. > > > >Because someone may create a branch with the same name. > > > > > > > >Is there any public document for the patch which goes to staging repo? > > > > > > > >Thanks, > > > >Ray > > > > > > > >> -----Original Message----- > > > >> From: Gao, Liming > > > >> Sent: Friday, July 5, 2019 10:13 AM > > > >> To: devel@edk2.groups.io; lersek@redhat.com; Javeed, Ashraf > > > >> <ashraf.javeed@intel.com> > > > >> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray > > > >> <ray.ni@intel.com> > > > >> Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New > > > >> interface, EFI encodings to PCI Plat protocol > > > >> > > > >> And, please also specify branch name in edk2-staging. > > > >> > > > >> The subject title likes : [PATCH edk2-staging\BranchName] > > > >> [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat > > > >> protocol > > > >> > > > >> >-----Original Message----- > > > >> >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On > > > >> >Behalf Of Laszlo Ersek > > > >> >Sent: Friday, July 05, 2019 12:25 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> > > > >> >Subject: Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New > > > >> >interface, EFI encodings to PCI Plat protocol > > > >> > > > > >> >On 07/04/19 15:20, Javeed, Ashraf wrote: > > > >> >> Please note that this new feature change would be moved to > > > >> >> Edk2-staging > > > >> >after obtaining the Reviewed-By. > > > >> > > > > >> >If the feature targets edk2-staging, then please use the > > > >> >following subject prefix: > > > >> > > > > >> >[PATCH edk2-staging] > > > >> > > > > >> >rather than just > > > >> > > > > >> >[PATCH]. > > > >> > > > > >> >Thanks. > > > >> >Laszlo > > > >> > > > > >> > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol 2019-07-05 5:23 ` Javeed, Ashraf @ 2019-07-05 10:31 ` Ni, Ray 2019-07-05 11:12 ` Javeed, Ashraf [not found] ` <15AE7E6E11B2DE53.4080@groups.io> 2019-07-05 15:35 ` Laszlo Ersek 1 sibling, 2 replies; 12+ messages in thread From: Ni, Ray @ 2019-07-05 10:31 UTC (permalink / raw) To: Javeed, Ashraf, Gao, Liming, devel@edk2.groups.io, lersek@redhat.com Cc: Kinney, Michael D Ashraf, Can you please attach the patch in the mail? I failed to extract the patch content from the mail. Thanks, Ray > -----Original Message----- > From: Javeed, Ashraf > Sent: Friday, July 5, 2019 1:24 PM > To: Gao, Liming <liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>; > devel@edk2.groups.io; lersek@redhat.com > Cc: Kinney, Michael D <michael.d.kinney@intel.com> > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI > encodings to PCI Plat protocol > > Hi, > Please note that these 2 tags are automatically added when the mail is sent > with the formatted patch of the commit.... > [edk2-devel] [PATCH] > > I could add the branch name tag when I sent the commit in the Edk2-staging > branch for review with the community - [Edk2-staging\Branch name]. This > tags will be preceded with the above 2 tags in the subject line of that mail > (too many prefix tags). > > Can I get Reviewed-By to move this in to the Edk2-staging branch? Please > note that this would require a PI Spec update. > > Thanks > Ashraf > > > -----Original Message----- > > From: Gao, Liming > > Sent: Friday, July 5, 2019 8:53 AM > > To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; > > lersek@redhat.com; Javeed, Ashraf <ashraf.javeed@intel.com> > > Cc: Kinney, Michael D <michael.d.kinney@intel.com> > > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, > > EFI encodings to PCI Plat protocol > > > > Ray: > > > > > -----Original Message----- > > > From: Ni, Ray > > > Sent: Friday, July 5, 2019 11:14 AM > > > To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io; > > > lersek@redhat.com; Javeed, Ashraf <ashraf.javeed@intel.com> > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com> > > > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, > > > EFI encodings to PCI Plat protocol > > > > > > Some unclear parts in the document: > > > 1. Document says title begins with "staging/branch". The "branch" > > > means the > > "branch" word itself > > > or should be replaced with a concrete branch name? I prefer "branch" > word. > > Reasons in previous mail. > > > NOTE: this affects the individual patch owner. > > I understand here is the specific branch name. The patch is required > > to be pushed into the specific branch instead of 'branch'. > > I think the patch owner should propose which branch to include his > > patch. He can propose new branch or use the existing branch. > > > > > 2. Who owns the staging/master branch sync to edk2/master? Document > > > says > > the staging/branch is > > > based on staging/master but I guess usually staging patch owner > > > creates > > staging/branch based on edk2/master. > > Yes. I think so. > > > > Thanks > > Liming > > > > > > Thanks, > > > Ray > > > > > > > -----Original Message----- > > > > From: Gao, Liming > > > > Sent: Friday, July 5, 2019 10:49 AM > > > > To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; > > > > lersek@redhat.com; Javeed, Ashraf <ashraf.javeed@intel.com> > > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com> > > > > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New > > > > interface, EFI encodings to PCI Plat protocol > > > > > > > > Ray: > > > > Yes. Please see https://github.com/tianocore/edk2-staging > > > > > > > > Thanks > > > > Liming > > > > >-----Original Message----- > > > > >From: Ni, Ray > > > > >Sent: Friday, July 05, 2019 10:39 AM > > > > >To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io; > > > > >lersek@redhat.com; Javeed, Ashraf <ashraf.javeed@intel.com> > > > > >Cc: Kinney, Michael D <michael.d.kinney@intel.com> > > > > >Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New > > > > >interface, EFI encodings to PCI Plat protocol > > > > > > > > > >Liming, > > > > >I understand Laszlo's comment requiring repo name in the patch > > > > >title to tell everyone where the code will be. > > > > >But before the patch is pushed, the patch owner in theory cannot > > > > >guarantee the branch can be successfully created after the R-b is got. > > > > >Because someone may create a branch with the same name. > > > > > > > > > >Is there any public document for the patch which goes to staging repo? > > > > > > > > > >Thanks, > > > > >Ray > > > > > > > > > >> -----Original Message----- > > > > >> From: Gao, Liming > > > > >> Sent: Friday, July 5, 2019 10:13 AM > > > > >> To: devel@edk2.groups.io; lersek@redhat.com; Javeed, Ashraf > > > > >> <ashraf.javeed@intel.com> > > > > >> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray > > > > >> <ray.ni@intel.com> > > > > >> Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New > > > > >> interface, EFI encodings to PCI Plat protocol > > > > >> > > > > >> And, please also specify branch name in edk2-staging. > > > > >> > > > > >> The subject title likes : [PATCH edk2-staging\BranchName] > > > > >> [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat > > > > >> protocol > > > > >> > > > > >> >-----Original Message----- > > > > >> >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On > > > > >> >Behalf Of Laszlo Ersek > > > > >> >Sent: Friday, July 05, 2019 12:25 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> > > > > >> >Subject: Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New > > > > >> >interface, EFI encodings to PCI Plat protocol > > > > >> > > > > > >> >On 07/04/19 15:20, Javeed, Ashraf wrote: > > > > >> >> Please note that this new feature change would be moved to > > > > >> >> Edk2-staging > > > > >> >after obtaining the Reviewed-By. > > > > >> > > > > > >> >If the feature targets edk2-staging, then please use the > > > > >> >following subject prefix: > > > > >> > > > > > >> >[PATCH edk2-staging] > > > > >> > > > > > >> >rather than just > > > > >> > > > > > >> >[PATCH]. > > > > >> > > > > > >> >Thanks. > > > > >> >Laszlo > > > > >> > > > > > >> > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol 2019-07-05 10:31 ` Ni, Ray @ 2019-07-05 11:12 ` Javeed, Ashraf [not found] ` <15AE7E6E11B2DE53.4080@groups.io> 1 sibling, 0 replies; 12+ messages in thread From: Javeed, Ashraf @ 2019-07-05 11:12 UTC (permalink / raw) To: Ni, Ray, Gao, Liming, devel@edk2.groups.io, lersek@redhat.com Cc: Kinney, Michael D [-- Attachment #1: Type: text/plain, Size: 6979 bytes --] Please let me know if this is good enough? Thanks Ashraf > -----Original Message----- > From: Ni, Ray > Sent: Friday, July 5, 2019 4:02 PM > To: Javeed, Ashraf <ashraf.javeed@intel.com>; Gao, Liming > <liming.gao@intel.com>; devel@edk2.groups.io; lersek@redhat.com > Cc: Kinney, Michael D <michael.d.kinney@intel.com> > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI > encodings to PCI Plat protocol > > Ashraf, > Can you please attach the patch in the mail? > I failed to extract the patch content from the mail. > > Thanks, > Ray > > > -----Original Message----- > > From: Javeed, Ashraf > > Sent: Friday, July 5, 2019 1:24 PM > > To: Gao, Liming <liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>; > > devel@edk2.groups.io; lersek@redhat.com > > Cc: Kinney, Michael D <michael.d.kinney@intel.com> > > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, > > EFI encodings to PCI Plat protocol > > > > Hi, > > Please note that these 2 tags are automatically added when the mail is > > sent with the formatted patch of the commit.... > > [edk2-devel] [PATCH] > > > > I could add the branch name tag when I sent the commit in the > > Edk2-staging branch for review with the community - > > [Edk2-staging\Branch name]. This tags will be preceded with the above > > 2 tags in the subject line of that mail (too many prefix tags). > > > > Can I get Reviewed-By to move this in to the Edk2-staging branch? > > Please note that this would require a PI Spec update. > > > > Thanks > > Ashraf > > > > > -----Original Message----- > > > From: Gao, Liming > > > Sent: Friday, July 5, 2019 8:53 AM > > > To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; > > > lersek@redhat.com; Javeed, Ashraf <ashraf.javeed@intel.com> > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com> > > > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, > > > EFI encodings to PCI Plat protocol > > > > > > Ray: > > > > > > > -----Original Message----- > > > > From: Ni, Ray > > > > Sent: Friday, July 5, 2019 11:14 AM > > > > To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io; > > > > lersek@redhat.com; Javeed, Ashraf <ashraf.javeed@intel.com> > > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com> > > > > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New > > > > interface, EFI encodings to PCI Plat protocol > > > > > > > > Some unclear parts in the document: > > > > 1. Document says title begins with "staging/branch". The "branch" > > > > means the > > > "branch" word itself > > > > or should be replaced with a concrete branch name? I prefer "branch" > > word. > > > Reasons in previous mail. > > > > NOTE: this affects the individual patch owner. > > > I understand here is the specific branch name. The patch is required > > > to be pushed into the specific branch instead of 'branch'. > > > I think the patch owner should propose which branch to include his > > > patch. He can propose new branch or use the existing branch. > > > > > > > 2. Who owns the staging/master branch sync to edk2/master? > > > > Document says > > > the staging/branch is > > > > based on staging/master but I guess usually staging patch > > > > owner creates > > > staging/branch based on edk2/master. > > > Yes. I think so. > > > > > > Thanks > > > Liming > > > > > > > > Thanks, > > > > Ray > > > > > > > > > -----Original Message----- > > > > > From: Gao, Liming > > > > > Sent: Friday, July 5, 2019 10:49 AM > > > > > To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; > > > > > lersek@redhat.com; Javeed, Ashraf <ashraf.javeed@intel.com> > > > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com> > > > > > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New > > > > > interface, EFI encodings to PCI Plat protocol > > > > > > > > > > Ray: > > > > > Yes. Please see https://github.com/tianocore/edk2-staging > > > > > > > > > > Thanks > > > > > Liming > > > > > >-----Original Message----- > > > > > >From: Ni, Ray > > > > > >Sent: Friday, July 05, 2019 10:39 AM > > > > > >To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io; > > > > > >lersek@redhat.com; Javeed, Ashraf <ashraf.javeed@intel.com> > > > > > >Cc: Kinney, Michael D <michael.d.kinney@intel.com> > > > > > >Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New > > > > > >interface, EFI encodings to PCI Plat protocol > > > > > > > > > > > >Liming, > > > > > >I understand Laszlo's comment requiring repo name in the patch > > > > > >title to tell everyone where the code will be. > > > > > >But before the patch is pushed, the patch owner in theory > > > > > >cannot guarantee the branch can be successfully created after the R-b is > got. > > > > > >Because someone may create a branch with the same name. > > > > > > > > > > > >Is there any public document for the patch which goes to staging repo? > > > > > > > > > > > >Thanks, > > > > > >Ray > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Gao, Liming > > > > > >> Sent: Friday, July 5, 2019 10:13 AM > > > > > >> To: devel@edk2.groups.io; lersek@redhat.com; Javeed, Ashraf > > > > > >> <ashraf.javeed@intel.com> > > > > > >> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray > > > > > >> <ray.ni@intel.com> > > > > > >> Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New > > > > > >> interface, EFI encodings to PCI Plat protocol > > > > > >> > > > > > >> And, please also specify branch name in edk2-staging. > > > > > >> > > > > > >> The subject title likes : [PATCH edk2-staging\BranchName] > > > > > >> [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat > > > > > >> protocol > > > > > >> > > > > > >> >-----Original Message----- > > > > > >> >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On > > > > > >> >Behalf Of Laszlo Ersek > > > > > >> >Sent: Friday, July 05, 2019 12:25 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> > > > > > >> >Subject: Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New > > > > > >> >interface, EFI encodings to PCI Plat protocol > > > > > >> > > > > > > >> >On 07/04/19 15:20, Javeed, Ashraf wrote: > > > > > >> >> Please note that this new feature change would be moved to > > > > > >> >> Edk2-staging > > > > > >> >after obtaining the Reviewed-By. > > > > > >> > > > > > > >> >If the feature targets edk2-staging, then please use the > > > > > >> >following subject prefix: > > > > > >> > > > > > > >> >[PATCH edk2-staging] > > > > > >> > > > > > > >> >rather than just > > > > > >> > > > > > > >> >[PATCH]. > > > > > >> > > > > > > >> >Thanks. > > > > > >> >Laszlo > > > > > >> > > > > > > >> > [-- Attachment #2: 0001-MdePkg-Protocols-New-interface-EFI-encodings-to-PCI-.patch --] [-- Type: application/octet-stream, Size: 24458 bytes --] From d1abb5d18571e10a043ef7a12b0b5fdec33c892d Mon Sep 17 00:00:00 2001 From: Ashraf Javeed <ashraf.javeed@intel.com> Date: Thu, 4 Jul 2019 12:40:11 +0530 Subject: [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1954 New interface added to PCI Platform Protocol / PCI Override Protocol to retrieve device-specific platform policy for the following PCI standard features, like Maximum Payload Size (MPS), Maximum Read Request Size (MRRS),Extended Tags, Relax Order, No-Snoop, Active State Power Management (ASPM),Latency Time Reporting (LTR), AtomicOp, Reference Clock Configuration, Extended SYNCH, PTM support, and Completion Timeout (CTO). New source files added with enhanced definitions are in: MdePkg/Include/Protocol/PciPlatform2.h, MdePkg/Include/Protocol/PciOverride2.h 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> --- MdePkg/Include/Protocol/PciOverride2.h | 46 ++++++++++++++++++++++++++++++++++++++++++++++ MdePkg/Include/Protocol/PciPlatform2.h | 396 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ MdePkg/MdePkg.dec | 6 ++++++ 3 files changed, 448 insertions(+) diff --git a/MdePkg/Include/Protocol/PciOverride2.h b/MdePkg/Include/Protocol/PciOverride2.h new file mode 100644 index 0000000000..cf452d9f8f --- /dev/null +++ b/MdePkg/Include/Protocol/PciOverride2.h @@ -0,0 +1,46 @@ +/** @file + This file declares EFI PCI Override protocol which provides the interface between + the PCI bus driver/PCI Host Bridge Resource Allocation driver and an implementation's + driver to describe the unique features of a platform. + This protocol is optional. + + Copyright (c) 2019, Intel Corporation. All rights reserved.<BR> + This program and the accompanying materials + are licensed and made available under the terms and conditions of the BSD License + which accompanies this distribution. The full text of the license may be found at + http://opensource.org/licenses/bsd-license.php + + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. + + @par Revision Reference: + This Protocol is defined in UEFI Platform Initialization Specification 1.2 + Volume 5: Standards + +**/ + +#ifndef _PCI_OVERRIDE2_H_ +#define _PCI_OVERRIDE2_H_ + +/// +/// EFI_PCI_OVERRIDE_PROTOCOL has the same structure with EFI_PCI_PLATFORM_PROTOCOL +/// +#include <Protocol/PciPlatform2.h> + +/// +/// Global ID for the EFI_PCI_OVERRIDE_PROTOCOL +/// +#define EFI_PCI_OVERRIDE2_GUID \ + { \ + 0xb9d5ea1, 0x66cb, 0x4546, {0xb0, 0xbb, 0x5c, 0x6d, 0xae, 0xd9, 0x42, 0x47} \ + } + +/// +/// Declaration for EFI_PCI_OVERRIDE_PROTOCOL +/// +typedef EFI_PCI_PLATFORM_PROTOCOL2 EFI_PCI_OVERRIDE_PROTOCOL2; + + +extern EFI_GUID gEfiPciOverrideProtocol2Guid; + +#endif diff --git a/MdePkg/Include/Protocol/PciPlatform2.h b/MdePkg/Include/Protocol/PciPlatform2.h new file mode 100644 index 0000000000..3ff41b7754 --- /dev/null +++ b/MdePkg/Include/Protocol/PciPlatform2.h @@ -0,0 +1,396 @@ +/** @file + This file declares PCI Platform Protocol that provide the interface between + the PCI bus driver/PCI Host Bridge Resource Allocation driver and a platform-specific + driver to describe the unique features of a platform. + This protocol is optional. + +Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.<BR> +This program and the accompanying materials are licensed and made available under +the terms and conditions of the BSD License that accompanies this distribution. +The full text of the license may be found at +http://opensource.org/licenses/bsd-license.php. + +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. + + @par Revision Reference: + This Protocol is defined in UEFI Platform Initialization Specification 1.2 + Volume 5: Standards + +**/ + +#ifndef _PCI_PLATFORM2_H_ +#define _PCI_PLATFORM2_H_ + +/// +/// This file must be included because the EFI_PCI_PLATFORM_PROTOCOL2 uses +/// EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PHASE. +/// +#include <Protocol/PciHostBridgeResourceAllocation.h> + +/// +/// Reuse the existing definition to maintain backward compatibility +/// +#include <Protocol/PciPlatform.h> + +/// +/// Global ID for the EFI_PCI_PLATFORM_PROTOCOL2. +/// +#define EFI_PCI_PLATFORM_PROTOCOL2_GUID \ + { \ + 0x787b0367, 0xa945, 0x4d60, {0x8d, 0x34, 0xb9, 0xd1, 0x88, 0xd2, 0xd0, 0xb6} \ + } + +/// +/// As per the present definition and specification of this protocol, the major +/// version is 1, and minor version is 1. Any driver utilizing this protocol +/// shall use these versions number to maintain the backward compatibility as +/// per its specification changes in future. +/// +enum EfiPciPlatformProtocolVersion { + EFI_PCI_PLATFORM_PROTOCOL_MAJOR_VERSION = 1, + EFI_PCI_PLATFORM_PROTOCOL_MINOR_VERSION = 1 +}; + +/// +/// Forward declaration for EFI_PCI_PLATFORM_PROTOCOL2. +/// +typedef struct _EFI_PCI_PLATFORM_PROTOCOL2 EFI_PCI_PLATFORM_PROTOCOL2; + +/// +/// Following are the data types for EFI_PCI_PLATYFORM_EXTENDED_POLICY +/// each for the PCI standard feature and its corresponding bitmask +/// representing the valid combinations of PCI attributes +/// + +/// +/// This data type is to retrieve the PCI device platform policy for the PCI- +/// compliant feature Maximum Payload Size (MPS). Refer to PCI Base Specification +/// 4, (chapter 7.5.3.4) on how to translate the below EFI encodings as per the +/// PCI hardware terminology. If this data member value is returned as 0 than +/// there is no platform policy to override, this feature would be enabled as +/// per its PCI specification based on the device capabilities. Below is it +/// data type and the macro definitions which the driver uses for interpreting +/// the platform policy. +/// +typedef UINT8 EFI_PCI_CONF_MAX_PAYLOAD_SIZE; + +#define EFI_PCI_CONF_MAX_PAYLOAD_SIZE_AUTO 0x00 //No request for override +#define EFI_PCI_CONF_MAX_PAYLOAD_SIZE_128B 0x01 //set to default 128B +#define EFI_PCI_CONF_MAX_PAYLOAD_SIZE_256B 0x02 //set to 256B if applicable +#define EFI_PCI_CONF_MAX_PAYLOAD_SIZE_512B 0x03 //set to 512B if applicable +#define EFI_PCI_CONF_MAX_PAYLOAD_SIZE_1024B 0x04 //set to 1024B if applicable +#define EFI_PCI_CONF_MAX_PAYLOAD_SIZE_2048B 0x05 //set to 2048B if applicable +#define EFI_PCI_CONF_MAX_PAYLOAD_SIZE_4096B 0x06 //set to 4096B if applicable + +/// +/// This data type is to retrieve the PCI device platform policy for the PCI- +/// compliant feature Maximum Read Request Size (MRRS). Refer to PCI Base +/// Specification 4, (chapter 7.5.3.4) on how to translate the below EFI +/// encodings as per the PCI hardware terminology. If this data member value +/// is returned as 0 than there is no platform policy to override, this feature +/// would be enabled as per its PCI specification based on the device capabilities. +/// Below is it data type and the macro definitions which the driver uses for +/// interpreting the platform policy. +/// +typedef UINT8 EFI_PCI_CONF_MAX_READ_REQ_SIZE; + +#define EFI_PCI_CONF_MAX_READ_REQ_SIZE_AUTO 0x00 //No request for override +#define EFI_PCI_CONF_MAX_READ_REQ_SIZE_128B 0x01 //set to default 128B +#define EFI_PCI_CONF_MAX_READ_REQ_SIZE_256B 0x02 //set to 256B if applicable +#define EFI_PCI_CONF_MAX_READ_REQ_SIZE_512B 0x03 //set to 512B if applicable +#define EFI_PCI_CONF_MAX_READ_REQ_SIZE_1024B 0x04 //set to 1024B if applicable +#define EFI_PCI_CONF_MAX_READ_REQ_SIZE_2048B 0x05 //set to 2048B if applicable +#define EFI_PCI_CONF_MAX_READ_REQ_SIZE_4096B 0x06 //set to 4096B if applicable + +/// +/// This data type is to retrieve the PCI device platform policy for the PCI- +/// compliant feature Extended Tags. Refer to PCI Base Specification +/// 4, (chapter 7.5.3.4) on how to translate the below EFI encodings as per the +/// PCI hardware terminology. If this data member value is returned as 0 than +/// there is no platform policy to override, this feature would be enabled as +/// per its PCI specification based on the device capabilities. Below is it +/// data type and the macro definitions which the driver uses for interpreting +/// the platform policy. +/// +typedef UINT8 EFI_PCI_CONF_EXTENDED_TAG; + +#define EFI_PCI_CONF_EXTENDED_TAG_AUTO 0x00 //No request for override +#define EFI_PCI_CONF_EXTENDED_TAG_5BIT 0x01 //set to default 5-bit +#define EFI_PCI_CONF_EXTENDED_TAG_8BIT 0x02 //set to 8-bit if applicable +#define EFI_PCI_CONF_EXTENDED_TAG_10BIT 0x03 //set to 10-bit if applicable + +/// +/// This data type is to retrieve the PCI device platform policy for the PCI- +/// compliant feature PCIe link's Active State Power Mgmt (ASPM). Refer to PCI Base +/// Specification 4, (chapter 7.5.3.7) on how to translate the below EFI +/// encodings as per the PCI hardware terminology. If this data member value +/// is returned as 0 than there is no platform policy to override, this feature +/// would be enabled as per its PCI specification based on the device capabilities. +/// Below is it data type and the macro definitions which the driver uses for +/// interpreting the platform policy. +/// +typedef UINT8 EFI_PCI_CONF_ASPM_SUPPORT; + +#define EFI_PCI_CONF_ASPM_AUTO 0x00 //No request for override +#define EFI_PCI_CONF_ASPM_DISABLE 0x01 //set to default disable state +#define EFI_PCI_CONF_ASPM_L0s_SUPPORT 0x02 //set to L0s state +#define EFI_PCI_CONF_ASPM_L1_SUPPORT 0x03 //set to L1 state +#define EFI_PCI_CONF_ASPM_L0S_L1_SUPPORT 0x04 //set to L0s and L1 state + +/// +/// This data type is to retrieve the PCI device platform policy for the PCI- +/// compliant feature PCIe Device's Relax Ordering enable/disable. Refer to PCI Base +/// Specification 4, (chapter 7.5.3.4) on how to translate the below EFI +/// encodings as per the PCI hardware terminology. If this data member value +/// is returned as 0 than there is no platform policy to override, this feature +/// would be enabled as per its PCI specification based on the device capabilities. +/// Below is it data type and the macro definitions which the driver uses for +/// interpreting the platform policy. +/// +typedef UINT8 EFI_PCI_CONF_RELAX_ORDER; + +#define EFI_PCI_CONF_RO_AUTO 0x00 //No request for override +#define EFI_PCI_CONF_RO_DISABLE 0x01 //set to default disable state +#define EFI_PCI_CONF_RO_ENABLE 0x02 //set to enable state + +/// +/// This data type is to retrieve the PCI device platform policy for the PCI- +/// compliant feature PCIe Device's No-Snoop enable/disable. Refer to PCI Base +/// Specification 4, (chapter 7.5.3.4) on how to translate the below EFI +/// encodings as per the PCI hardware terminology. If this data member value +/// is returned as 0 than there is no platform policy to override, this feature +/// would be enabled as per its PCI specification based on the device capabilities. +/// Below is it data type and the macro definitions which the driver uses for +/// interpreting the platform policy. +/// +typedef UINT8 EFI_PCI_CONF_NO_SNOOP; + +#define EFI_PCI_CONF_NS_AUTO 0x00 //No request for override +#define EFI_PCI_CONF_NS_DISABLE 0x01 //set to default disable state +#define EFI_PCI_CONF_NS_ENABLE 0x02 //set to enable state + +/// +/// This data type is to retrieve the PCI device platform policy for the PCI- +/// compliant feature PCIe link's Clock configuration is common or discrete. +/// Refer to PCI Base Specification 4, (chapter 7.5.3.7) on how to translate the +/// below EFI encodings as per the PCI hardware terminology. If this data member +/// value is returned as 0 than there is no platform policy to override, this +/// feature would be enabled as per its PCI specification based on the device +/// capabilities. Below is its data type and the macro definitions which the +/// driver uses for interpreting the platform policy. +/// +typedef UINT8 EFI_PCI_CONF_COMMON_CLOCK_CFG; + +#define EFI_PCI_CONF_CLK_CFG_AUTO 0x00 //No request for override +#define EFI_PCI_CONF_CLK_CFG_ASYNCH 0x01 //set to default asynchronous clock +#define EFI_PCI_CONF_CLK_CFG_COMMON 0x02 //set to common clock + +/// +/// This data type is to retrieve the PCI device platform policy for the PCI- +/// compliant feature PCIe link's Extended Synch enable or disable. +/// Refer to PCI Base Specification 4, (chapter 7.5.3.7) on how to translate the +/// below EFI encodings as per the PCI hardware terminology. If this data member +/// value is returned as 0 than there is no platform policy to override, this +/// feature would be enabled as per its PCI specification based on the device +/// capabilities. Below is its data type and the macro definitions which the +/// driver uses for interpreting the platform policy. +/// +typedef UINT8 EFI_PCI_CONF_EXTENDED_SYNCH; + +#define EFI_PCI_CONF_EXT_SYNCH_AUTO 0x00 //No request for override +#define EFI_PCI_CONF_EXT_SYNCH_DISABLE 0x01 //set to default disable state +#define EFI_PCI_CONF_EXT_SYNCH_ENABLE 0x02 //set to enable state + +/// +/// This data type is to retrieve the PCI device platform policy for the PCI- +/// compliant feature PCIe Device's AtomicOp Requester enable or disable. +/// Refer to PCI Base Specification 4, (chapter 7.5.3.16) on how to translate the +/// below EFI encodings as per the PCI hardware terminology. If this data member +/// value is returned as 0 than there is no platform policy to override, this +/// feature would be enabled as per its PCI specification based on the device +/// capabilities. Below is its data type and the macro definitions which the +/// driver uses for interpreting the platform policy. +/// +typedef UINT8 EFI_PCI_CONF_ATOMIC_OP; + +#define EFI_PCI_CONF_ATOMIC_OP_AUTO 0x00 //No request for override +#define EFI_PCI_CONF_ATOMIC_OP_DISABLE 0x01 //set to default disable state +#define EFI_PCI_CONF_ATOMIC_OP_ENABLE 0x02 //set to enable state + +/// +/// This data type is to retrieve the PCI device platform policy for the PCI- +/// compliant feature PCIe Device's LTR Mechanism enable/disable. +/// Refer to PCI Base Specification 4, (chapter 7.5.3.16) on how to translate the +/// below EFI encodings as per the PCI hardware terminology. If this data member +/// value is returned as 0 than there is no platform policy to override, this +/// feature would be enabled as per its PCI specification based on the device +/// capabilities. Below is its data type and the macro definitions which the +/// driver uses for interpreting the platform policy. +/// +typedef UINT8 EFI_PCI_CONF_LTR; + +#define EFI_PCI_CONF_LTR_AUTO 0x00 //No request for override +#define EFI_PCI_CONF_LTR_DISABLE 0x01 //set to default disable state +#define EFI_PCI_CONF_LTR_ENABLE 0x02 //set to enable state + +/// +/// This data type is to retrieve the PCI device platform policy for the PCI- +/// compliant feature PCIe Device's Precision Time Measurement (PTM) enable/disable. +/// Refer to PCI Base Specification 4, (chapter 7.5.3.16) on how to translate the +/// below EFI encodings as per the PCI hardware terminology. If this data member +/// value is returned as 0 than there is no platform policy to override, this +/// feature would be enabled as per its PCI specification based on the device +/// capabilities. Below is its data type and the macro definitions which the +/// driver uses for interpreting the platform policy. +/// +typedef UINT8 EFI_PCI_CONF_PTM; + +#define EFI_PCI_CONF_PTM_AUTO 0x00 //No request for override +#define EFI_PCI_CONF_PTM_DISABLE 0x01 //set to default disable state +#define EFI_PCI_CONF_PTM_ENABLE 0x02 //set to enable state only +#define EFI_PCI_CONF_PTM_ROOT_SEL 0x02 //set to root select & enable + +/// +/// This data type is to retrieve the PCI device platform policy for the PCI- +/// compliant feature PCIe Device's Completion Timeout (CTO) set to supported ranges +/// or disable. Refer to PCI Base Specification 4, (chapter 7.5.3.16) on how to +/// translate the below EFI encodings as per the PCI hardware terminology. If this +/// data member value is returned as 0 than there is no platform policy to override, +/// this feature would be enabled as per its PCI specification based on the device +/// capabilities. Below is its data type and the macro definitions which the +/// driver uses for interpreting the platform policy. +/// +typedef UINT8 EFI_PCI_CONF_CTO_SUPPORT; + +#define EFI_PCI_CONF_CTO_AUTO 0x00 //No request for override +#define EFI_PCI_CONF_CTO_DEFAULT 0x01 //set to default range of 5us to 50ms if applicable +#define EFI_PCI_CONF_CTO_RANGE_A1 0x02 //set to range of 50us to 100us if applicable +#define EFI_PCI_CONF_CTO_RANGE_A2 0x03 //set to range of 1ms to 10ms if applicable +#define EFI_PCI_CONF_CTO_RANGE_B1 0x04 //set to range of 16ms to 55ms if applicable +#define EFI_PCI_CONF_CTO_RANGE_B2 0x05 //set to range of 65ms to 210ms if applicable +#define EFI_PCI_CONF_CTO_RANGE_C1 0x06 //set to range of 260ms to 900ms if applicable +#define EFI_PCI_CONF_CTO_RANGE_C2 0x07 //set to range of 1s to 3.5s if applicable +#define EFI_PCI_CONF_CTO_RANGE_D1 0x08 //set to range of 4s to 13s if applicable +#define EFI_PCI_CONF_CTO_RANGE_D2 0x09 //set to range of 17s to 64s if applicable +#define EFI_PCI_CONF_CTO_DET_DISABLE 0x10 //set to CTO detection disable if applicable + +/// +/// Reserves for future use +/// +typedef UINT8 EFI_PCI_CONF_RESERVES; + +/// +/// The EFI_PCI_PLATYFORM_EXTENDED_POLICY is altogether 128-byte size, with each +/// byte field representing one PCI standerd feature defined in the PCI Express Base +/// Specification 4.0, version 1.0. +/// +typedef struct { + EFI_PCI_CONF_MAX_PAYLOAD_SIZE DeviceCtlMPS; + EFI_PCI_CONF_MAX_READ_REQ_SIZE DeviceCtlMRRS; + EFI_PCI_CONF_EXTENDED_TAG DeviceCtlExtTag; + EFI_PCI_CONF_RELAX_ORDER DeviceCtlRelaxOrder; + EFI_PCI_CONF_NO_SNOOP DeviceCtlNoSnoop; + EFI_PCI_CONF_ASPM_SUPPORT LinkCtlASPMState; + EFI_PCI_CONF_COMMON_CLOCK_CFG LinkCtlCommonClkCfg; + EFI_PCI_CONF_EXTENDED_SYNCH LinkCtlExtSynch; + EFI_PCI_CONF_ATOMIC_OP DeviceCtl2AtomicOp; + EFI_PCI_CONF_LTR DeviceCtl2LTR; + EFI_PCI_CONF_PTM PTMControl; + EFI_PCI_CONF_CTO_SUPPORT CTOsupport; + EFI_PCI_CONF_RESERVES Reserves[116]; +} EFI_PCI_PLATFORM_EXTENDED_POLICY; + +/** + Retrieves the PCI device-specific platform policy regarding enumeration. + + The PCI Bus driver and PCI Host Bridge Resource Allocation Protocol drivers + can call this member function to retrieve the platform policies specific to + PCI device, regarding the PCI enumeration. + + The GetDevicePolicy() function retrieves the platform policy for a particular + component regarding PCI enumeration. The PCI bus driver and the PCI Host Bridge + Resource Allocation Protocol driver can call this member function to retrieve + the policy. + The existing GetPlatformPolicy() member function is used by the PCI Bus driver + to program the legacy ranges, the data that is returned by that member function + determines the supported attributes that are returned by the + EFI_PCI_IO_PROTOCOL.Attributes() function. + The GetDevicePolicy() member function is meant to return data about other PCI + compliant features which would be supported by the PCI Bus driver in future; + like for example the MPS, MRRS, Extended Tag, ASPM, etc. The details about + this PCI features can be obtained from the PCI Base Specification 4.x. The + EFI encodings for these feature are defined in the + EFI_PCI_PLATFORM_EXTENDED_POLICY, see the Related Definition section for this. + This member function will use the associated EFI handle of the PCI IO Protocol + to determine the physical PCI device within the chipset, to return its + device-specific platform policies. + + @param[in] This Pointer to the EFI_PCI_PLATFORM_PROTOCOL2 instance. + @param[in] PciDevice The associated PCI IO Protocol handle of the PCI + device. Type EFI_HANDLE is defined in + InstallProtocolInterface() in the UEFI 2.1 + Specification + @param[in] PciExtPolicy The platform policy with respect to other PCI features + like, the MPS, MRRS, etc. Type EFI_PCI_PLATFORM_EXTENDED_POLICY + is defined in "Related Definitions" below. + + + @retval EFI_SUCCESS The function completed successfully, may returns + platform policy data for the given PCI component + @retval EFI_UNSUPPORTED PCI component belongs to PCI topology but not + part of chipset to provide the platform policy + @retval EFI_INVALID_PARAMETER If any of the input parameters are passed with + invalid data + + **/ +typedef +EFI_STATUS +(EFIAPI * EFI_PCI_PLATFORM_GET_DEVICE_POLICY) ( + IN CONST EFI_PCI_PLATFORM_PROTOCOL2 *This, + IN EFI_HANDLE PciDevice, + OUT EFI_PCI_PLATFORM_EXTENDED_POLICY *PciExtPolicy +); + +/// +/// This protocol provides the interface between the PCI bus driver/PCI Host +/// Bridge Resource Allocation driver and a platform-specific driver to describe +/// the unique features of a platform. +/// +struct _EFI_PCI_PLATFORM_PROTOCOL2 { + /// + /// The notification from the PCI bus enumerator to the platform that it is about to + /// enter a certain phase during the enumeration process. + /// + EFI_PCI_PLATFORM_PHASE_NOTIFY PlatformNotify; + /// + /// The notification from the PCI bus enumerator to the platform for each PCI + /// controller at several predefined points during PCI controller initialization. + /// + EFI_PCI_PLATFORM_PREPROCESS_CONTROLLER PlatformPrepController; + /// + /// Retrieves the platform policy regarding enumeration. + /// + EFI_PCI_PLATFORM_GET_PLATFORM_POLICY GetPlatformPolicy; + /// + /// Gets the PCI device's option ROM from a platform-specific location. + /// + EFI_PCI_PLATFORM_GET_PCI_ROM GetPciRom; + /// + /// Retrieves the PCI device-specific platform policy regarding enumeration. + /// + EFI_PCI_PLATFORM_GET_DEVICE_POLICY GetDevicePolicy; + /// + /// The major version of this PCI Platform Protocol + /// + UINT8 MajorVersion; + /// + /// The minor version of this PCI Platform Protocol + /// + UINT8 MinorVersion; + +}; + +extern EFI_GUID gEfiPciPlatformProtocol2Guid; + +#endif diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index 6c563375ee..2448d2ab5d 100644 --- a/MdePkg/MdePkg.dec +++ b/MdePkg/MdePkg.dec @@ -1013,6 +1013,12 @@ ## Include/Protocol/PciOverride.h gEfiPciOverrideProtocolGuid = { 0xb5b35764, 0x460c, 0x4a06, {0x99, 0xfc, 0x77, 0xa1, 0x7c, 0x1b, 0x5c, 0xeb }} + ## Include/Protocol/PciPlatform2.h + gEfiPciPlatformProtocol2Guid = { 0x787b0367, 0xa945, 0x4d60, { 0x8d, 0x34, 0xb9, 0xd1, 0x88, 0xd2, 0xd0, 0xb6 }} + + ## Include/Protocol/PciOverride2.h + gEfiPciOverrideProtocol2Guid = { 0xb9d5ea1, 0x66cb, 0x4546, { 0xb0, 0xbb, 0x5c, 0x6d, 0xae, 0xd9, 0x42, 0x47 }} + ## Include/Protocol/PciEnumerationComplete.h gEfiPciEnumerationCompleteProtocolGuid = { 0x30cfe3e7, 0x3de1, 0x4586, {0xbe, 0x20, 0xde, 0xab, 0xa1, 0xb3, 0xb7, 0x93}} -- 2.21.0.windows.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
[parent not found: <15AE7E6E11B2DE53.4080@groups.io>]
* Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol [not found] ` <15AE7E6E11B2DE53.4080@groups.io> @ 2019-07-12 13:38 ` Javeed, Ashraf 0 siblings, 0 replies; 12+ messages in thread From: Javeed, Ashraf @ 2019-07-12 13:38 UTC (permalink / raw) To: devel@edk2.groups.io, Javeed, Ashraf, Ni, Ray, Gao, Liming, lersek@redhat.com Cc: Kinney, Michael D I am anxiously waiting for the review comments. Thanks Ashraf > -----Original Message----- > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Javeed, > Ashraf > Sent: Friday, July 5, 2019 4:42 PM > To: Ni, Ray <ray.ni@intel.com>; Gao, Liming <liming.gao@intel.com>; > devel@edk2.groups.io; lersek@redhat.com > Cc: Kinney, Michael D <michael.d.kinney@intel.com> > Subject: Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI > encodings to PCI Plat protocol > > Please let me know if this is good enough? > > Thanks > Ashraf > > > -----Original Message----- > > From: Ni, Ray > > Sent: Friday, July 5, 2019 4:02 PM > > To: Javeed, Ashraf <ashraf.javeed@intel.com>; Gao, Liming > > <liming.gao@intel.com>; devel@edk2.groups.io; lersek@redhat.com > > Cc: Kinney, Michael D <michael.d.kinney@intel.com> > > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, > > EFI encodings to PCI Plat protocol > > > > Ashraf, > > Can you please attach the patch in the mail? > > I failed to extract the patch content from the mail. > > > > Thanks, > > Ray > > > > > -----Original Message----- > > > From: Javeed, Ashraf > > > Sent: Friday, July 5, 2019 1:24 PM > > > To: Gao, Liming <liming.gao@intel.com>; Ni, Ray <ray.ni@intel.com>; > > > devel@edk2.groups.io; lersek@redhat.com > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com> > > > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, > > > EFI encodings to PCI Plat protocol > > > > > > Hi, > > > Please note that these 2 tags are automatically added when the mail > > > is sent with the formatted patch of the commit.... > > > [edk2-devel] [PATCH] > > > > > > I could add the branch name tag when I sent the commit in the > > > Edk2-staging branch for review with the community - > > > [Edk2-staging\Branch name]. This tags will be preceded with the > > > above > > > 2 tags in the subject line of that mail (too many prefix tags). > > > > > > Can I get Reviewed-By to move this in to the Edk2-staging branch? > > > Please note that this would require a PI Spec update. > > > > > > Thanks > > > Ashraf > > > > > > > -----Original Message----- > > > > From: Gao, Liming > > > > Sent: Friday, July 5, 2019 8:53 AM > > > > To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; > > > > lersek@redhat.com; Javeed, Ashraf <ashraf.javeed@intel.com> > > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com> > > > > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New > > > > interface, EFI encodings to PCI Plat protocol > > > > > > > > Ray: > > > > > > > > > -----Original Message----- > > > > > From: Ni, Ray > > > > > Sent: Friday, July 5, 2019 11:14 AM > > > > > To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io; > > > > > lersek@redhat.com; Javeed, Ashraf <ashraf.javeed@intel.com> > > > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com> > > > > > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New > > > > > interface, EFI encodings to PCI Plat protocol > > > > > > > > > > Some unclear parts in the document: > > > > > 1. Document says title begins with "staging/branch". The "branch" > > > > > means the > > > > "branch" word itself > > > > > or should be replaced with a concrete branch name? I prefer "branch" > > > word. > > > > Reasons in previous mail. > > > > > NOTE: this affects the individual patch owner. > > > > I understand here is the specific branch name. The patch is > > > > required to be pushed into the specific branch instead of 'branch'. > > > > I think the patch owner should propose which branch to include his > > > > patch. He can propose new branch or use the existing branch. > > > > > > > > > 2. Who owns the staging/master branch sync to edk2/master? > > > > > Document says > > > > the staging/branch is > > > > > based on staging/master but I guess usually staging patch > > > > > owner creates > > > > staging/branch based on edk2/master. > > > > Yes. I think so. > > > > > > > > Thanks > > > > Liming > > > > > > > > > > Thanks, > > > > > Ray > > > > > > > > > > > -----Original Message----- > > > > > > From: Gao, Liming > > > > > > Sent: Friday, July 5, 2019 10:49 AM > > > > > > To: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; > > > > > > lersek@redhat.com; Javeed, Ashraf <ashraf.javeed@intel.com> > > > > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com> > > > > > > Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New > > > > > > interface, EFI encodings to PCI Plat protocol > > > > > > > > > > > > Ray: > > > > > > Yes. Please see https://github.com/tianocore/edk2-staging > > > > > > > > > > > > Thanks > > > > > > Liming > > > > > > >-----Original Message----- > > > > > > >From: Ni, Ray > > > > > > >Sent: Friday, July 05, 2019 10:39 AM > > > > > > >To: Gao, Liming <liming.gao@intel.com>; devel@edk2.groups.io; > > > > > > >lersek@redhat.com; Javeed, Ashraf <ashraf.javeed@intel.com> > > > > > > >Cc: Kinney, Michael D <michael.d.kinney@intel.com> > > > > > > >Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New > > > > > > >interface, EFI encodings to PCI Plat protocol > > > > > > > > > > > > > >Liming, > > > > > > >I understand Laszlo's comment requiring repo name in the > > > > > > >patch title to tell everyone where the code will be. > > > > > > >But before the patch is pushed, the patch owner in theory > > > > > > >cannot guarantee the branch can be successfully created after > > > > > > >the R-b is > > got. > > > > > > >Because someone may create a branch with the same name. > > > > > > > > > > > > > >Is there any public document for the patch which goes to staging > repo? > > > > > > > > > > > > > >Thanks, > > > > > > >Ray > > > > > > > > > > > > > >> -----Original Message----- > > > > > > >> From: Gao, Liming > > > > > > >> Sent: Friday, July 5, 2019 10:13 AM > > > > > > >> To: devel@edk2.groups.io; lersek@redhat.com; Javeed, Ashraf > > > > > > >> <ashraf.javeed@intel.com> > > > > > > >> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Ni, Ray > > > > > > >> <ray.ni@intel.com> > > > > > > >> Subject: RE: [edk2-devel] [PATCH] [MdePkg/Protocols]: New > > > > > > >> interface, EFI encodings to PCI Plat protocol > > > > > > >> > > > > > > >> And, please also specify branch name in edk2-staging. > > > > > > >> > > > > > > >> The subject title likes : [PATCH edk2-staging\BranchName] > > > > > > >> [MdePkg/Protocols]: New interface, EFI encodings to PCI > > > > > > >> Plat protocol > > > > > > >> > > > > > > >> >-----Original Message----- > > > > > > >> >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] > > > > > > >> >On Behalf Of Laszlo Ersek > > > > > > >> >Sent: Friday, July 05, 2019 12:25 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> > > > > > > >> >Subject: Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New > > > > > > >> >interface, EFI encodings to PCI Plat protocol > > > > > > >> > > > > > > > >> >On 07/04/19 15:20, Javeed, Ashraf wrote: > > > > > > >> >> Please note that this new feature change would be moved > > > > > > >> >> to Edk2-staging > > > > > > >> >after obtaining the Reviewed-By. > > > > > > >> > > > > > > > >> >If the feature targets edk2-staging, then please use the > > > > > > >> >following subject prefix: > > > > > > >> > > > > > > > >> >[PATCH edk2-staging] > > > > > > >> > > > > > > > >> >rather than just > > > > > > >> > > > > > > > >> >[PATCH]. > > > > > > >> > > > > > > > >> >Thanks. > > > > > > >> >Laszlo > > > > > > >> > > > > > > > >> > > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol 2019-07-05 5:23 ` Javeed, Ashraf 2019-07-05 10:31 ` Ni, Ray @ 2019-07-05 15:35 ` Laszlo Ersek 1 sibling, 0 replies; 12+ messages in thread From: Laszlo Ersek @ 2019-07-05 15:35 UTC (permalink / raw) To: Javeed, Ashraf, Gao, Liming, Ni, Ray, devel@edk2.groups.io Cc: Kinney, Michael D On 07/05/19 07:23, Javeed, Ashraf wrote: > Hi, > Please note that these 2 tags are automatically added when the mail is sent with the formatted patch of the commit.... > [edk2-devel] [PATCH] (1) The [edk2-devel] prefix is prepended by groups.io (i.e. by the mailing list software) when it reflects your patch email to subscribers. Indeed you cannot change that -- but the request was not for you to change that. (2) The [PATCH] prefix is generated locally on your end, and you *can* change it. Just pass the following option to git-format-patch: --subject-prefix='PATCH edk2-staging/branch' the result will be [PATCH edk2-staging/branch]. (3) If you need to send v2, v3 and so on, just add -v2 and similar to the git-format-patch command line. (4) The [MdePkg/Protocols] part is superfluous, or at least incorrectly formatted. I'd suggest, as the actual title of the git commit: MdePkg: introduce EFI_PCI_PLATFORM_PROTOCOL2 Thanks Laszlo ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-07-12 13:38 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <15AE3668F84BF3B8.28761@groups.io>
2019-07-04 13:20 ` [edk2-devel] [PATCH] [MdePkg/Protocols]: New interface, EFI encodings to PCI Plat protocol Javeed, Ashraf
2019-07-04 16:25 ` Laszlo Ersek
2019-07-05 2:13 ` Liming Gao
2019-07-05 2:38 ` Ni, Ray
2019-07-05 2:48 ` Liming Gao
2019-07-05 3:13 ` Ni, Ray
2019-07-05 3:23 ` Liming Gao
2019-07-05 5:23 ` Javeed, Ashraf
2019-07-05 10:31 ` Ni, Ray
2019-07-05 11:12 ` Javeed, Ashraf
[not found] ` <15AE7E6E11B2DE53.4080@groups.io>
2019-07-12 13:38 ` Javeed, Ashraf
2019-07-05 15:35 ` Laszlo Ersek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox