EBC compiler doesn't treat EFI_xxx as constant due to these macros
are UINT64 type in 64bit env and UINT32 type in 32bit env.
So it reports error when "case EFI_xxx" is used.
The patch changes to use if-else to fix EBC build failure.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
DUAL_ADDRESS_CYCLE is missing in the EFI_UNSUPPORTED
return status description.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
This reverts commit 5db417ed25.
"MdeModulePkg/PciBusDxe: Enable Bus Master on P2P bridges on demand"
We met some compatibility issues when doing Windows S4 resume.
Reverting the BME disabling patches to fix the S4 resume issue.
Signed-off-by: Ruiyu Ni <Ruiyu.ni@intel.com>
Signed-off-by: Michael Turner <michael.turner@microsoft.com>
Cc: Michael D Kinney <Michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
This reverts commit 050763db07.
"MdeModulePkg/PciBus: Disable BME of all devices when entering RT"
We met some compatibility issues when doing Windows S4 resume.
Reverting the BME disabling patches to fix the S4 resume issue.
Signed-off-by: Ruiyu Ni <Ruiyu.ni@intel.com>
Signed-off-by: Michael Turner <michael.turner@microsoft.com>
Cc: Michael D Kinney <Michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The patch ensures all DMA transactions are blocked after
ExitBootService.
If a platform enables IOMMU before and needs disable IOMMU after
ExitBootService, the IOMMU should be disabled after PCI bus driver
disables BME.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael Turner <michael.turner@microsoft.com>
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jeff Fan <vanjeff_919@hotmail.com>
It's a regression of below commit:
SHA-1: 8be37a5cee
* MdeModulePkg/SecurityStubDxe: Defer 3rd party image before EndOfDxe
When PciBus driver fails to load the Option ROM, it doesn't produce
BusOverride protocol. It was a correct behavior before the above
commit. But due to the above commit, BusOverride protocol never is
produced by PciBus driver.
The patch fixes this issue using the following solution:
1. PciBus records the image device path when LoadImage fails.
2. Override.GetDriver() tries to look for the image handle using
the stored image device path.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
The patch shouldn't impact functionality.
Original code records the ImageHandle of Option ROM by creating a
new entry. It's not necessary.
The patch updates the ImageHandle in the old entry.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
The patch doesn't impact real functionality.
It only renames EFI_PCI_ROM_IMAGE_MAPPING to PCI_ROM_IMAGE,
and changes prototype of PciRomAddImageMapping so that
no explicit type cast is needed when calling this function.
It also removes unused field RomBase from PCI_IO_DEVICE structure.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
The bug was caused by 728d74973c
"MdeModulePkg/PciBus: Count multiple hotplug resource paddings".
The patch firstly updated the Bridge->Alignment to the maximum
alignment of all devices under the bridge, then aligned the
Bridge->Length to Bridge->Alignment.
It caused too much resources were claimed.
The new patch firstly aligns Bridge->Length to Bridge->Alignment,
then updates the Bridge->Alignment to the maximum alignment of all
devices under the bridge.
Because the step to update the Bridge->Alignment is to make sure
the resource allocated to the bus under the Bridge meets all
devices alignment. But the Bridge->Length doesn't have to align
to the maximum alignment.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=720
The current implementation assumes there is only one hotplug resource
padding for each resource type. It's not true considering
DegradeResource(): MEM64 resource could be degraded to MEM32
resource.
The patch treat the resource paddings using the same logic as
treating typical/actual resources and the total resource of a bridge
is set to the MAX of typical/actual resources and resource paddings.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
The patch dynamically enables Bus Master on P2P bridges only
when requested by a device driver through PciIo.Attribute() to enable
the Bus Master.
Signed-off-by: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
PciScanBus() assumes the GetResourcePadding() puts BUS descriptor
in the very beginning, if it's not, the Descriptors will be updated
to point to middle of the pool buffer, which can cause
FreePool(Descriptors) hang in DEBUG image.
No functionality impact to RELEASE image.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
If IOMMU protocol is installed, PciBus need call IOMMU
to set access attribute for the PCI device in Map/Ummap.
Only after the access attribute is set, the PCI device can
access the DMA memory.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Leo Duran <leo.duran@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Previous patch Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Previous patch Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Leo Duran <leo.duran@amd.com>
There are cases that the operands of an expression are all with rank less
than UINT64/INT64 and the result of the expression is explicitly cast to
UINT64/INT64 to fit the target size.
An example will be:
UINT32 a,b;
// a and b can be any unsigned int type with rank less than UINT64, like
// UINT8, UINT16, etc.
UINT64 c;
c = (UINT64) (a + b);
Some static code checkers may warn that the expression result might
overflow within the rank of "int" (integer promotions) and the result is
then cast to a bigger size.
The commit refines codes by the following rules:
1). When the expression is possible to overflow the range of unsigned int/
int:
c = (UINT64)a + b;
2). When the expression will not overflow within the rank of "int", remove
the explicit type casts:
c = a + b;
3). When the expression will be cast to pointer of possible greater size:
UINT32 a,b;
VOID *c;
c = (VOID *)(UINTN)(a + b); --> c = (VOID *)((UINTN)a + b);
4). When one side of a comparison expression contains only operands with
rank less than UINT32:
UINT8 a;
UINT16 b;
UINTN c;
if ((UINTN)(a + b) > c) {...} --> if (((UINT32)a + b) > c) {...}
For rule 4), if we remove the 'UINTN' type cast like:
if (a + b > c) {...}
The VS compiler will complain with warning C4018 (signed/unsigned
mismatch, level 3 warning) due to promoting 'a + b' to type 'int'.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
For pointer subtraction, the result is of type "ptrdiff_t". According to
the C11 standard (Committee Draft - April 12, 2011):
"When two pointers are subtracted, both shall point to elements of the
same array object, or one past the last element of the array object; the
result is the difference of the subscripts of the two array elements. The
size of the result is implementation-defined, and its type (a signed
integer type) is ptrdiff_t defined in the <stddef.h> header. If the result
is not representable in an object of that type, the behavior is
undefined."
In our codes, there are cases that the pointer subtraction is not
performed by pointers to elements of the same array object. This might
lead to potential issues, since the behavior is undefined according to C11
standard.
Also, since the size of type "ptrdiff_t" is implementation-defined. Some
static code checkers may warn that the pointer subtraction might underflow
first and then being cast to a bigger size. For example:
UINT8 *Ptr1, *Ptr2;
UINTN PtrDiff;
...
PtrDiff = (UINTN) (Ptr1 - Ptr2);
The commit will refine the pointer subtraction expressions by casting each
pointer to UINTN first and then perform the subtraction:
PtrDiff = (UINTN) Ptr1 - (UINTN) Ptr2;
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Compiler calculates the PciBar[BarIndex] using
sizeof (PciBar[0]) * BarIndex, when BarIndex is type of UINT64,
the above calculation generates assembly code using _allmul.
Change BarIndex to UINTN to avoid the build failure.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
PI spec IncompatiblePciSupport part defines (UINT64)-1 as all BARs
and 0 to use existing alignment. PciBus driver didn't accept these
values. It treated 0xFF as all BARs and 0xFFFFFFFFFFFFFFFFULL to use
existing alignment.
The patch changes the code to still accept old values while also
accept values defined in PI spec. So that the driver can provide
backward compatibility and follow spec.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
The 'universal' PCI bus driver in MdeModulePkg contains a quirk to
degrade 64-bit PCI MMIO BARs to 32-bit in the presence of an option
ROM on the same PCI controller.
This quirk is highly specific to not just the X64 architecture in general,
but to the PC platform in particular, given that only X64 platforms that
require legacy PC BIOS compatibility require it. However, making the
quirk dependent on the presence of the legacy BIOS protocol met with
resistance, due to the fact that it introduces a dependency on the
IntelFrameworkModulePkg package.
So instead, make the quirk configurable, by introducing a feature flag PCD
'PcdPciDegradeResourceForOptionRom' which defaults to TRUE only for X64.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Section 7.8.2 of the PCI Express specification (r4.0 v0.3), entitled "PCI
Express Capabilities Register (Offset 02h)", and section 7.8.9 "Slot
Capabilities Register (Offset 14h)" of the same, describe the conditions
when a PCIe port should be considered "supporting hotplug":
- it should be a root complex port or a switch downstream port, and
- it should have the "Slot Implemented" bit set in the Express
Capabilities Register, and
- it should have the "Hot-Plug Capable" bit set in the Slot Capabilities
Register.
The first two sub-conditions are already implemented in at least two open
source projects I could find:
- in SeaBIOS by Marcel Apfelbaum: "hw/pci: reserve IO and mem for pci
express downstream ports with no devices attached"
<https://code.coreboot.org/p/seabios/source/commit/3aa31d7d6375>,
- in edk2 itself, in the implementation of the "PCI" UEFI Shell command:
see the "PcieExplainTypeSlot" case label in function
PciExplainPciExpress(), file
"ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c".
PciBusDxe recognizes such PCIe ports as bridges, but it doesn't realize
they support hotplug. In turn PciBusDxe omits getting any resource padding
information from the platform's EFI_PCI_HOT_PLUG_INIT_PROTOCOL for these
bridges:
GatherPpbInfo() [PciEnumeratorSupport.c]
GetResourcePaddingPpb() [PciResourceSupport.c]
GetResourcePaddingForHpb() [PciHotPlugSupport.c]
IsPciHotPlugBus() [PciHotPlugSupport.c]
//
// returns FALSE
//
//
// the following is not reached:
//
gPciHotPlugInit->GetResourcePadding()
Implement a function called SupportsPcieHotplug() for identifying such
ports, and call it from IsPciHotPlugBus() (after the call to IsSHPC()).
Cc: "Johnson, Brian J." <bjohnson@sgi.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <Ruiyu.ni@intel.com>
The PCI Hot Plug capability register block is marked with capability ID
0x0C (EFI_PCI_CAPABILITY_ID_SHPC), not 0x06
(EFI_PCI_CAPABILITY_ID_HOTPLUG).
This bug prevents PciBusDxe from recognizing whether a PCI-to-PCI bridge
supports hotplug. In turn the platform's EFI_PCI_HOT_PLUG_INIT_PROTOCOL is
not consulted for resource padding information:
GatherPpbInfo() [PciEnumeratorSupport.c]
GetResourcePaddingPpb() [PciResourceSupport.c]
GetResourcePaddingForHpb() [PciHotPlugSupport.c]
IsPciHotPlugBus() [PciHotPlugSupport.c]
IsSHPC() [PciHotPlugSupport.c]
//
// returns FALSE
//
//
// the following is not reached:
//
gPciHotPlugInit->GetResourcePadding()
Look for the correct capability ID.
Cc: "Johnson, Brian J." <bjohnson@sgi.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <Ruiyu.ni@intel.com>
- abstrated to abstracted
- accessibla to accessible
- addres to address
- apropriate to appropriate
- arry to array
- availabe to available
- avaliable to available
- becasue to because
- correponding to corresponding
- etablished to established
- exeuction to execution
- extensiable to extensible
- fileds to fields
- loadding to loading
- ptototypes to prototypes
- prococol protocol
- requried to required
- resoruce to resource
- runing to running
- uild to build
Cc: Star Zeng <star.zeng@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
PciBus driver originally always degrade (64->32) the MMIO resource
for PCI BAR when the PCI device contains option ROM.
But the degrade causes the PCI device can only use resource below 4GB
which makes the resource allocation fails when the PCI device wants
very big MMIO.
The patch follows the PI spec (ECR 1529) to honor the granularity
setting for PCI BAR from IncompatiblePciDeviceSupport so that even
for PCI device which contains option ROM, the degrade doesn't happen
if IncompatiblePciDeviceSupport returns 64 as granularity.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Remove "Efi" from gEfiIncompatiblePciDeviceSupport to shorten
the global variable name.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
When PcdPciDisableBusEnumeration is enabled, the PciBus driver
might get into a dead loop if the secondary bus register on PCI
bridge is not programmed or programmed improperly. Adding this
check to avoid any potential dead loop caused by this.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Maurice Ma <maurice.ma@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Lee Leahy <Leroy.p.leahy@intel.com>
If the current PCI configuration requires no resources to be allocated at
all (i.e., unpopulated bus), the PCI enumeration code creates a single
ACPI_ADDRESS_SPACE_DESCRIPTOR memory descriptor with all fields cleared.
This is rejected by the SubmitResources() implementation of the generic
PciHostBridgeDxe in the following way:
PciHostBridge: SubmitResources for PcieRoot(0x0)
Mem: Granularity/SpecificFlag = 0 / 00
Length/Alignment = 0x0 / 0x0
PciBus: HostBridge->SubmitResources() - Invalid Parameter
ASSERT_EFI_ERROR (Status = Invalid Parameter)
ASSERT [PciBusDxe] .../PciBusDxe/PciLib.c(561): !EFI_ERROR (Status)
So instead, create the empty configuration as a single entry of type
EFI_ACPI_END_TAG_DESCRIPTOR.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
When there is no bridge before the HPC (hot plug controller),
the issue cannot be seen.
But when there are bridges before the HPC, the PciBus will only
use the value (= <CurrentBusNumber> + <ReservedBusNumber>) as the
sub-ordinary bus number for HPC.
The correct sub-ordinary bus number should be:
<CurrentBusNumber> + <OccupiedBusNumber>(by earlier bridges) +
<ReservedBusNumber>.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Some platform doesn't use CPU(HOST)/Device 1:1 mapping for PCI Bus.
But PCI IO doesn't have interface to tell caller (device driver)
whether the address returned by GetBarAttributes() is HOST address
or device address.
UEFI Spec 2.6 addresses this issue by clarifying the address returned
is HOST address and caller can use AddrTranslationOffset to calculate
the device address.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
For a hot plug bridge with device attached, PciBusDxe driver reserves
the resources which equal to the total amount of padding resource
returned from HotPlug->GetResourcePadding() and the actual occupied
resource by the attached device. The behavior is incorrect.
Correct behavior is to reserve the bigger one between the padding
resource and the actual occupied resource.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18719 6f19259b-4bc3-4df7-8a09-765794883524
The resource dumping logic contains a bug which cannot dump the
resource for hot plug controller correctly. The patch fixes this
bug.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18718 6f19259b-4bc3-4df7-8a09-765794883524
Leif suggested to split the big patch to smaller ones.
This reverts commit 73b7f115c653c807b9d0be97bf516871d8aff7ba.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18717 6f19259b-4bc3-4df7-8a09-765794883524
Add a check for ResourcePaddingDescriptors being a valid pointer in
DumpPpbPaddingResource() to prevent looping on memory not owned by
PciBusDxe. The ResourcePaddingDescriptors is initialized to NULL
when the PCI_IO_DEVICE structure is allocated and remains NULL if
no PCI hot plug controllers are present. This issue is only
observed when DEBUG_CODE() macros are enabled and was introduced
by the following patch:
[edk2] [Patch] MdeModulePkg: Fix a PciBusDxe hot plug bug
SVN revsion 18658
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Kinney Michael <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18696 6f19259b-4bc3-4df7-8a09-765794883524
For a hot plug bridge with device attached, PciBusDxe driver reserves
the resources which equal to the total amount of padding resource
returned from HotPlug->GetResourcePadding() and the actual occupied
resource by the attached device. The behavior is incorrect.
Correct behavior is to reserve the bigger one between the padding
resource and the actual occupied resource.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18658 6f19259b-4bc3-4df7-8a09-765794883524
When looping through all PCI functions, code should not look for functions
1-7 if function 0 is not present or if function 0 indicates the device is
not multifunction. Prior to this fix the code would use stale data in a
buffer to determine if a device is multifunction even if function 0 is not
present. This fixes a code bug and provides very small performance
improvements.
PCI 2.3 Specification states: They [multifunction devices] are also
required to always implement function 0 in the device. Implementing other
functions is optional and may be assigned in any order.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Joseph Shifflett <joseph.shifflett@hpe.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18574 6f19259b-4bc3-4df7-8a09-765794883524
Certain PCI device may have capability pointing to itself.
Update LocateCapabilityRegBlock() to break when detecting such loop.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18473 6f19259b-4bc3-4df7-8a09-765794883524
According to the PCI spec, when software writes all-one to BAR for size probing,
the value read back should be 0b1...10...0 after masking the BAR type bits.
But in real world, it's possible that certain device returns 0b0...01...10...0
for MEM64 BAR size probing: some bits in the high 32bit may be 0.
PciBus driver has the code to handle such case. However, it doesn't handle the
case that the high 32bit is totally 0. The patch is to handle the special case.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18114 6f19259b-4bc3-4df7-8a09-765794883524
The logic in an if statement in PciIo is too complex and hard to understand
and make VS2015 build failure. The fix simplifies the logic.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18109 6f19259b-4bc3-4df7-8a09-765794883524
LocatePciExpressCapabilityRegBlock () doesn't check the return status of Pci.Read().
Certain platform's PciRootBridge.Pci.Read() doesn't support PCIE access causing the CapabilityEntry not updated.
If the uninitialized CapabilityEntry equals to a big enough initial value, the while-loop will never end.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Maurice Ma <maurice.ma@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17513 6f19259b-4bc3-4df7-8a09-765794883524
Ruiyu Ni
Star Zeng
Dandan Bi
Jiewen Yao
Hao Wu
Laszlo Ersek
Gary Lin
Ard Biesheuvel
Giri P Mudusuru
Ma, Maurice
Jordan Justen
Joseph Shifflett
Michael D Kinney
Olivier Martin