PciIoMap () need to feedback the status of
mIoMmuProtocol->SetAttribute () return value.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4652
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Huang Jenny <jenny.huang@intel.com>
Cc: Chiang Chris <chris.chiang@intel.com>
Signed-off-by: Sheng Wei <w.sheng@intel.com>
A faulty PCI device has the Option ROM image size set to 0. UEFI reads
two headers PCI_EXPANSION_ROM_HEADER and PCI_DATA_STRUCTURE to get the
Option ROM information. Because the image size is 0, the Option ROM
header address never changes. As a result, UEFI keeps reading the same
two headers definitely. This patch is intended to fix it.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Nhi Pham <nhi@os.amperecomputing.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
MdeModulePkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
In V4: Update the copyright to 2023.
In V3: Add AMD copyright.
In V2: Remove the signed-off-by: Abner Chang
Display PCIe Vendor ID and Device ID in DEBUG message.
Signed-off-by: Jiangang He <jiangang.he@amd.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Garrett Kirkendall <garrett.kirkendall@amd.com>
Cc: Abner Chang <abner.chang@amd.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
If a device which support both features SR-IOV/ARI has multi
functions, which maybe support 8-255. After enable ARI forwarding in
the root port and ARI Capable Hierarchy in the SR-IOV PF0.
The device will support and expose multi functions(0-255) with ARI ID routing.
In next device loop in below for() code, actually it still be in the
same SR-IOV device, and just some PF which is over 8 or higher
one(n*8), PciAllocateBusNumber() will allocate bus
number(ReservedBusNum - TempReservedBusNum)) for this PF. if reset
TempReservedBusNum as 0 in this case,it will allocate wrong bus number
for this PF because TempReservedBusNum should be total previous PF's
reserved bus numbers.
code:
for (Device = 0; Device <= PCI_MAX_DEVICE; Device++) {
TempReservedBusNum = 0;
for (Func = 0; Func <= PCI_MAX_FUNC; Func++) {
//
// Check to see whether a pci device is present
//
Status = PciDevicePresent (
PciRootBridgeIo,
&Pci,
StartBusNumber,
Device,
Func
);
...
Status = PciAllocateBusNumber (PciDevice, *SubBusNumber,
(UINT8)(PciDevice->ReservedBusNum - TempReservedBusNum), SubBusNumber);
The solution is add a new flag IsAriEnabled to help handle this case.
if ARI is enabled, then TempReservedBusNum will not be reset again
during all functions(1-255) scan with checking flag IsAriEnabled.
Signed-off-by: Foster Nong <foster.nong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Below code will calculate the reserved bus number for the each PF.
Based on the VF routing ID algorithm, PFRid and LastVF in below code
already sure that "All VFs and PFs must have distinct Routing IDs".
PF will be assigned Routing ID based on secBusNumber, ReservedBusNum
will add into SubBusNumber directly. So the SR-IOV device will be
assigned bus range as SecBusNumber ~ (SubBusNumber=(SecBusNumber +
ReservedBusNum)).
Thus "+1" in below code will cause extra 1 bus, and introduce a bus hole.
PFRid = EFI_PCI_RID (Bus, Device, Func);
LastVF = PFRid + FirstVFOffset + (PciIoDevice->InitialVFs - 1) * VFStride;
PciIoDevice->ReservedBusNum = (UINT16)(EFI_PCI_BUS_OF_RID (LastVF) -
Bus + 1);
In SR-IOV spec, there is a note in section 2.1.2:
Note: Bus Numbers are a constrained resource. Devices are strongly
encouraged to avoid leaving ?holes? in their Bus Number usage to avoid
wasting Bus Numbers
So the issue can be fixed with below code change.
PciIoDevice->ReservedBusNum = (UINT16)(EFI_PCI_BUS_OF_RID (LastVF) -
Bus);
https://bugzilla.tianocore.org/show_bug.cgi?id=4069
Signed-off-by: Foster Nong <foster.nong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Per the section 3.3.5 SR-IOV spec v1.1, InitialVFs (0ch).
InitialVFs indicates to SR-PCIM the number of VFs that are initially associated with the PF.
The minimum value of InitialVFs is 0.
Below code is used to calculate SR-IOV reserved bus number,
if InitialVFs =0, it maybe calculate the wrong bus number in this case.
LastVF = PFRid + FirstVFOffset + (PciIoDevice->InitialVFs - 1) * VFStride
we can fix it with below code:
if (PciIoDevice->InitialVFs == 0) {
PciIoDevice->ReservedBusNum = 0;
} else {
PFRid = EFI_PCI_RID (Bus, Device, Func);
LastVF = PFRid + FirstVFOffset + (PciIoDevice->InitialVFs - 1) * VFStride;
//
// Calculate ReservedBusNum for this PF
//
PciIoDevice->ReservedBusNum = (UINT16)(EFI_PCI_BUS_OF_RID (LastVF) - Bus + 1);
//
// Calculate ReservedBusNum for this PF
//
PciIoDevice->ReservedBusNum = (UINT16)(EFI_PCI_BUS_OF_RID (LastVF) - Bus + 1);
}
https://bugzilla.tianocore.org/show_bug.cgi?id=4069
Signed-off-by: Foster Nong <foster.nong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Ref:https://bugzilla.tianocore.org/show_bug.cgi?id=4000
Change flow to bus scan all root bridge instances even when any
one root bridge meet bus resource OUT_OF_RESOURCE case.
thus platform handler of "EfiPciHostBridgeEndBusAllocation" has
an chance to do relative pci bus rebalance to handle this case.
Signed-off-by: Foster Nong <foster.nong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
Function of UpdatePciInfo() in PciEnumeratorSupport.c is used to update
the bar information for those incompatible PCI device. It is the right
place to check if the OptionRom need to be ignored.
According to "Table 20. ACPI 2.0 & 3.0 QWORD Address Space Descriptor
Usage" in PI Spec 1.7, Type-specific flags can be set to 0 when Address
Translation Offset == 6 to skip device option ROM (do not probe option
rom BAR).
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3811
Remove ASSERT() statements that are triggered if a platform provides
an override of PCI ROM attached to a PCI Controller. The PCI Platform
Protocol allows the platform to provide a PCI ROM image for a PCI
Controller. This works for PCI Controllers that do not have an attached
PCI ROM, but the platform is not allowed to replace the PCI ROM for a
PCI Controller that has its own PCI ROM. Removing these ASSERT()
statements enables this additional use case.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Before trying to access parent root port to check ARI capabilities,
enumerator should see if Endpoint device is not Root Complex integrated
to avoid undefined parent register accesses.
Signed-off-by: Damian Bassa <damian.bassa@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737
Apply uncrustify changes to .c/.h files in the MdeModulePkg package
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3760
Update all use of ', OPTIONAL' to ' OPTIONAL,' for function params.
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3739
Update all use of EFI_D_* defines in DEBUG() macros to DEBUG_* defines.
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
https://bugzilla.tianocore.org/show_bug.cgi?id=3635
Currently, in order to test the supported attributes,
the PciTestSupportedAttribute() will set the command register
to 0x27 (EFI_PCI_COMMAND_IO_SPACE, EFI_PCI_COMMAND_MEMORY_SPACE,
EFI_PCI_COMMAND_BUS_MASTER, EFI_PCI_COMMAND_VGA_PALETTE_SNOOP) firstly,
and then read back to check whether these attributes are
set successfully in the device.
This will cause the other enabled bits
(other than EFI_PCI_COMMAND_IO_SPACE,EFI_PCI_COMMAND_MEMORY_SPACE,
EFI_PCI_COMMAND_BUS_MASTER,EFI_PCI_COMMAND_VGA_PALETTE_SNOOP)
be cleared for a short of time
This patch fixes this issue by keeping the origina
enabled bits when setting 0x27.
Signed-off-by: xueshengfeng <xueshengfeng@byosoft.com.cn>
Reviewed-by: Ray <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2989
Long times spent on shadowing oprom from graphics card to system memory.
We are currently using 8 bit read cycles. This needs to be wider,
at least 32bit reads to reduce the time for oprom shadow.
Signed-off-by: Sumana Venur <sumana.venur@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
If the function gets invalid value for the `ResizableBarOp` parameter
and asserts are disabled, `Bit` can be used uninitialized.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Sergei Dmitrouk <sergei@posteo.net>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
The ProcessOptionRomLight() assumes that OpRom has already been
processed in the previous full enumeration and updates
AllOpRomProcessed flag to TRUE by default. However, this may not
be applicable with other pre-stage boot firmwares.
This will update AllOpRomProcessed flag properly by checking
PciRomGetImageMapping().
Signed-off-by: Aiden Park <aiden.park@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3149
Address MEM64 BAR in type unknown if sizing fail in high 32bit.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Zarcd Zhong <zarcd.zhong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=313
Add PcdPcieResizableBarSupport to enable/disable PCIe Resizable
BAR Capability fearture.
Program the Resizable BAR Register if the device suports PCIe Resizable
BAR Capability and PcdPcieResizableBarSupport is TRUE.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Heng Luo <heng.luo@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2515
Change the MdeModulePkg to match the ECC check rule
Signed-off-by: GuoMinJ <newexplorerj@gmail.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303
Whenever a PCI device is discovered, PCI bus calls the
EDKII_DEVICE_SECURITY_PROTOCOL to authenticate it.
If the function returns success, the PCI bus allocates
the resource and installs the PCI_IO for the device.
If the function returns fail, the PCI bus skips the device.
It is similar to EFI_SECURITY_ARCH_PROTOCOL, which
is used to verify an EFI image.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Yun Lou <yun.lou@intel.com>
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
an (EFI_HANDLE*) as first parameter, the
UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
first parameter.
These are actual bugs. They must have remained hidden until now because
they are on error paths. Fix the UninstallMultipleProtocolInterfaces()
calls.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=1796
Bug fixed in PciBusDxe\PciLib.c.
Removed the redundant second call to PciSearchDevice sub-routine when the
PCD for the Hot-Plug support is disabled.
Signed-off-by: Ashraf Javeed <Ashraf.javeed@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
When assigning a physical PCIe device to a QEMU/KVM guest, PciBusDxe may
find that the extended config space is not (fully) implemented. In
LocatePciExpressCapabilityRegBlock(), "CapabilityEntry" may be read as
0xFFFF_FFFF at a given config space offset, after which the loop gets
stuck spinning on offset 0xFFC (the read at offset 0xFFC returns
0xFFFF_FFFF most likely as well).
Another scenario (not related to virtualization) for triggering the above
is when a Conventional PCI bus -- exposed by a PCIe-to-PCI bridge in the
topology -- intervenes between a PCI Express Root Port and a PCI Express
Endpoint. The Conventional PCI bus limits the accessible config space of
the PCI Express Endpoint, even though the endpoint advertizes the PCI
Express capability. Here's a diagram, courtesy of Alex Williamson:
[PCIe Root Port]--[PCIe-to-PCI]--[PCI-to-PCIe]--[PCIe EP]
->| |<- Conventional PCI bus
Catch reads of 0xFFFF_FFFF in LocatePciExpressCapabilityRegBlock(), and
break out of the scan with a warning message. The function will return
EFI_NOT_FOUND.
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Delete the explicit machine type check for option ROM images, and instead,
rely on the LoadImage() boot service to decide whether an option ROM can
be dispatched or not. This permits platforms to ship with emulators to
execute option ROMs that are not native to the processor architecture.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1505
When a device under PPB contains option ROM but doesn't require 32bit
MMIO, ProgrameUpstreamBridgeForRom() cannot correctly restore the
PPB MEM32 RANGE BAR. It causes the 32bit MMIO conflict which may
cause system hangs in boot.
The root cause is when ProgrameUpstreamBridgeForRom() calls
ProgramPpbApperture() to restore the PPB MEM32 RANGE BAR, the
ProgramPpbApperture() skips to program the BAR when the resource
length is 0.
This patch fixes this issue by not calling ProgramPpbApperture().
Instead, it directly programs the PPB MEM32 RANGE BAR.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Per PCI Spec, the option ROM BAR is 32bit so the maximum option ROM
size can be hold by UINT32 type.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1394
When there is no PCI option ROM exists, today's logic still creates
virtual BAR for option ROM using Length = 0, Alignment = (-1).
It causes the final MEM32 alignment requirement is as big as
0xFFFFFFFF_FFFFFFFF.
The patch fixes this issue by only creating virtual BAR for option
ROM when there is PCI option ROM.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Chiu Chasel <chasel.chiu@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1376
Today's implementation reuses the 32bit MMIO resource requested by
all PCI devices MMIO BARs when shadowing the option ROM.
Take a simple example, a system has only one PCI device. It requires
8MB 32bit MMIO and contains a 4MB option ROM. Today's implementation
only requests 8MB (max of 4M and 8M) 32bit MMIO from
PciHostBridgeResourceAllocation protocol. Let's assume the MMIO range
[3GB, 3GB+8MB) is allocated. The 3GB base address is firstly
programmed to the option ROM BAR for option ROM shadow. Then the
option ROM decoding is turned off and 3GB base address is programmed
to the 32bit MMIO BAR.
It doesn't cause issues when the device doesn't request too much
MMIO.
But when the device contains a 64bit MMIO BAR which requests 4GB MMIO
and a 4MB option ROM. Let's assume [3GB, 3GB+8MB) 32bit MMIO range is
allocated for the option ROM. When the option ROM is being shadowed,
64bit MMIO BAR is programmed to value 0, which means [0, 4GB) MMIO is
given to the 64bit BAR.
The range overlaps with the option ROM range which may cause the
device malfunction (e.g.: option ROM cannot be read out) when the
device has two separate decoders: one for MMIO BAR, the other for
option ROM.
The patch requests dedicated MEM32 resource for Option ROMs and
moves the Option ROM shadow logic after all MMIO BARs are programmed.
The MMIO BAR setting to 0 when shadowing Option ROM is also skipped
because the MMIO BAR already contains the correct value.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Removing rules for Ipf sources file:
* Remove the source file which path with "ipf" and also listed in
[Sources.IPF] section of INF file.
* Remove the source file which listed in [Components.IPF] section
of DSC file and not listed in any other [Components] section.
* Remove the embedded Ipf code for MDE_CPU_IPF.
Removing rules for Inf file:
* Remove IPF from VALID_ARCHITECTURES comments.
* Remove DXE_SAL_DRIVER from LIBRARY_CLASS in [Defines] section.
* Remove the INF which only listed in [Components.IPF] section in DSC.
* Remove statements from [BuildOptions] that provide IPF specific flags.
* Remove any IPF sepcific sections.
Removing rules for Dec file:
* Remove [Includes.IPF] section from Dec.
Removing rules for Dsc file:
* Remove IPF from SUPPORTED_ARCHITECTURES in [Defines] section of DSC.
* Remove any IPF specific sections.
* Remove statements from [BuildOptions] that provide IPF specific flags.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chen A Chen <chen.a.chen@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1109
Today's restriction of VGA device is to have only one VGA device
enabled per PCI segment. It's not correct because several segments
may share one IO / MMIO address space.
We should restrict to have one VGA per Host Bridge because each
Host Bridge has its only IO / MMIO address space.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1109
The patch doesn't change any behavior of this function.
It just renames the function to LocateVgaDevice() and renames
some parameters and local variables.
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 functions that are never called have been removed.
They are UpStreamBridgesAttributes and GetHpcPciAddressFromRootBridge.
https://bugzilla.tianocore.org/show_bug.cgi?id=1062
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: shenglei <shenglei.zhang@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
When cleaning the PciIoDevice, also free the BusNumberRange
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Thomas Palmer <thomas.palmer@hpe.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
1. Do not use tab characters
2. No trailing white space in one line
3. All files must end with CRLF
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Per PCIE spec, Memory Write and Invalidate is hardwired to 0b so
PciBus driver shouldn't write 1b to it.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
CreatePciIoDevice() detects whether the PCI device is a PCI Express
device and remembers the device type in PciIoDevice->IsPciExp.
RegisterPciDevice() detects the device type again which is
unnecessary. The detection logic can be removed.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Current code assumes the max bus(0xFF) is under this P2P bridge and
temporarily set it as subordinate bus.
It may cause silicon hangs during PCI enumeration in some specific
case.
Instead, it should get the max bus number from the bus number
resources returned from
PCI_HOST_BRIDGE_RESOURCE_ALLOCATION.StartBusEnumeration() and set it
as subordinate bus.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
According to UEFI spec 2.7, PciIo->GetBarAttributes should return host
address (CPU view ddress) rather than device address (PCI view
address), and
device address = host address + address translation offset,
so we subtract translation from device address before returning.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Signed-off-by: Yi Li <phoenix.liyi@huawei.com>
Reviewed-by: Ni Ruiyu <ruiyu.ni@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
According to UEFI spec 2.7, PciRootBridgeIo->Configuration() should
return host address (CPU view ddress) rather than device address
(PCI view address), so in function GetMmioAddressTranslationOffset we
need to convert the range to device address before comparing.
And device address = host address + translation offset.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Signed-off-by: Yi Li <phoenix.liyi@huawei.com>
Reviewed-by: Ni Ruiyu <ruiyu.ni@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Initialize local variable to suppress warning C4703:
potentially uninitialized local pointer variable.
Both reads (dereferences) of "PciRootBridgeIo" in
PciBusDriverBindingStart() are only reached if
"gFullEnumeration" is TRUE on entry *and* we successfully
open the EfiPciRootBridgeIoProtocol interface.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Per PI spec, the PciEnumerationComplete protocol installation
should be after PciIo installation.
Today's implementation installs the PciEnumerationComplete
after hardware enumeration is completed, but before PciIo
installation.
The change corrects the spec/implementation gap.
The change also benefits certain implementation that depends on
the PciIo handle in PciEnumerationComplete callback.
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 is just a code cleanup with no functionality impact.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
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>
Sheng Wei
Nhi Pham
Rebecca Cran
Michael Kubacki
Abner Chang
Foster Nong
Min Xu
Michael D Kinney
Ray Ni
xueshengfeng
Sumana Venur
Sergei Dmitrouk
Aiden Park
Zarcd Zhong
Luo, Heng
GuoMinJ
Jiewen Yao
Laszlo Ersek
Javeed, Ashraf
Ard Biesheuvel
Ruiyu Ni
Chen A Chen
shenglei
Thomas Palmer
Liming Gao
Heyi Guo
Dandan Bi