REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2218
Stopping the SD clock before switching host controller
bus timing is only necessary if preset value enable is
set in host controller. Code that performs switch to
HS200 doesn't check this condition right now and we also
don't do the SD clock stop before any other bus timing switch
in host controller. Since the driver is generally not ready to support
host controller with preset value enable set we removed this
code.
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Tested-by: Hao A Wu <hao.a.wu@intel.com>
Tested-by: Marcin Wojtas <mw@semihalf.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>
https://bugzilla.tianocore.org/show_bug.cgi?id=1882
Implement support for GetOperatingParamters notify phase
in SdMmcHcDxe driver. GetOperatingParameters notify phase
is signaled before we start card detection and initialization.
Code has been updated for both eMMC and SD card controllers to
take into consideration those new parameters. Initialization process
has been divided into 2 steps. In the first step we bring the link
up to the point where we can get card identification data(Extended
CSD in eMMC case and SWITCH command response in SD card case). This
data is later used along with controller capabilities and operating
parameters passed in GetOperatingParameters phase to choose preferred
bus settings in GetTargetBusSettings function. Those settings are later
on to start bus training to high speeds. If user passes incompatible
setting with selected bus timing driver will assume it's standard behavior
with respect to that setting. For instance if HS400 has been selected as a
target bus timing due to card and controller support bus width setting of
4 and 1 bit won't be respected and 8 bit setting will be chosen instead.
Tests on Marvell boards were also performed by Marcin Wojtas
<mw@semihalf.com>:
https://edk2.groups.io/g/devel/message/42999
Board 1 (out of tree): SD - OK, MMC - OK
Board 2: (Armada80x0McBin): SD - OK, MMC - OK
Board 3: (Armada70x0Db): SD - problems, MMC - OK
Please note that the problem on Armada70x0Db SD devices are introduced by
adding new types of SD bus modes, a subsequent patch within edk2-platforms
repository will be proposed to address it.
(More details can be referred from the above link.)
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Regression-tested-by: Sumit Garg <sumit.garg@linaro.org>
https://bugzilla.tianocore.org/show_bug.cgi?id=1879
This commit will add codes to produce the NVM Express PassThru PPI.
Signed-off-by: Maggie Chu <maggie.chu@intel.com>
Reviewed-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>
Cc: Star Zeng <star.zeng@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>
DEPEX from PEI storage stack.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1777
BootInRecoveryMode Ppi dependency should be removed from PEI storage stack
drivers. Besides recovery, more features are using the storage stack.
Platform can apply Ppi dependency in Recovery FV which contains full
storage driver stack. Platform storage stack modules, such as host
controller init PEI module, should also remove this dependency.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1460
Refer to Uefi spec 2.8, the ResetData is valid while ResetStatus
is EFI_SUCCESS regardless of the ResetType is EfiResetPlatformSpecific
or not. So change the comments of NvmeShutdownAllControllers.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael Turner <Michael.Turner@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@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>
Driver was supporting only 32b DMA support for V3 controllers. Add
support for 64b DMA as well for completeness.
For V4.0 64b support, driver was looking at incorrect capability
register bit. Fix for that is present as well.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1583
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Tested-by: Eugene Cohen <eugene@hp.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409
For the NvmExpressPei driver, this commit will update the driver to
consume the S3StorageDeviceInitList LockBox in S3 phase. The purpose is to
perform an on-demand (partial) NVM Express device
enumeration/initialization to benefit the S3 resume performance.
Cc: Jian J Wang <jian.j.wang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409
For the NvmExpressPei driver, this commit will add codes to produce the
Storage Security Command PPI if the underlying NVM Express controller
supports the Security Send and Security Receive commands.
Cc: Jian J Wang <jian.j.wang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
This commit is out of the scope for BZ-1409. The commit will remove the
call of RegisterForShadow() at the entry point of the driver. By doing so,
the driver is now possible to be executed without being re-loaded into
permanent memory.
Thus, this commit will update the NvmExpressPei driver to avoid updating
the content of a global variable.
Cc: Jian J Wang <jian.j.wang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1537
Use 16-bit and 32-bit IO widths for SDMMC MMIO to prevent all register
accesses from being split up into 8-bit accesses.
The SDHCI specification states that the registers shall be accessible in
byte, word, and double word accesses. (SD Host Controller Simplified
Specification 4.20 Section 1.2)
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140
In eMMC HS400 switch sequence flow eMMC driver attempted
to execute SEND_STATUS just after switching bus timing to high
speed and before downgrading clock frequency to 52MHz. Since link
was at that time in incorrect state SEND_STATUS was failing which
made driver think switch to HS400 failed.
This change makes driver always change clock frequency after
switching bus timing and before executing SEND_STATUS.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Albecki Mateusz <mateusz.albecki@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=1408
According to the information of the above BZ-1408 and other platform
owners, NVM Express devices are becoming more likely to be a critical
part during the boot process.
This commit will add the calls to 'REPORT_STATUS_CODE' when there is a
failure happens during the NVM Express controller/device initialization
process.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <brbarkel@microsoft.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1441
This commit will update the file-level comments within the SdMmcPciHcDxe
to reflect the latest specification compliance status of the driver.
Cc: Ray Ni <ray.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1422
if (Attributes) {
if ((Attributes & (~(DEV_SUPPORTED_ATTRIBUTES))) != 0) {
return EFI_UNSUPPORTED;
}
}
In above code block,
"If ((Attributes & (~(DEV_SUPPORTED_ATTRIBUTES))) != 0)" is TRUE,
the Attributes must be not 0. So we can remove the redundant
check "if (Attributes)".
Cc: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1425
This commit will resolve the VS2015 IA32 NOOPT build failure within
SdMmcPciHcDxe.
More specifically, this commit will use BaseLib API RShiftU64() to perform
right-shift operations for UINT64 type operators.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Bi Dandan <dandan.bi@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Add SDMA, ADMA2 and 26b data length support.
If V4 64 bit address mode is supported in capabilities register,
program controller to enable V4 host mode and use appropriate
SDMA registers supporting 64 bit addresses.
If V4 64 bit address mode is supported in capabilities register,
program controller to enable V4 host mode and use appropriate
ADMA descriptors supporting 64 bit addresses.
If host controller version is above V4.0, enable ADMA2 with 26b data
length support for better performance. HC 2 register is configured to
use 26 bit data lengths and ADMA2 descriptors are configured appropriately.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1359
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.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>
UEFI SCT crashed and failed in NonDiscoverablePciDeviceDxe becase
required checks were not performed. Perform parameters validation in
NonDiscoverablePciDeviceDxe.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
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>
Some SdMmc host controllers are run by clocks with different
frequency than it is reflected in Capabilities Register 1.
It is allowed by SDHCI specification ver. 4.2 - if BaseClkFreq
field value of the Capability Register 1 is zero, the clock
frequency must be obtained via another method.
Because the bitfield is only 8 bits wide, a maximum value
that could be obtained from hardware is 255MHz.
In case the actual frequency exceeds 255MHz, the 8-bit BaseClkFreq
member of SD_MMC_HC_SLOT_CAP structure occurs to be not sufficient
to be used for setting the clock speed in SdMmcHcClockSupply
function.
This patch adds new UINT32 array ('BaseClkFreq[]') to
SD_MMC_HC_PRIVATE_DATA structure for specifying
the input clock speed for each slot of the host controller.
All routines that are used for clock configuration are
updated accordingly.
This patch also adds new IN OUT BaseClockFreq field
in the Capability callback of the SdMmcOverride,
protocol which allows to update BaseClkFreq value.
The patch reuses original commit from edk2-platforms:
20f6f144d3a8 ("Marvell/Drivers: XenonDxe: Allow overriding base clock
frequency")
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Some SD Host Controlers need to do additional operations after clock
frequency switch.
This patch add new callback type to NotifyPhase of the SdMmcOverride
protocol. It is called after SdMmcHcClockSupply.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Some SD Host Controllers use different values in Host Control 2 Register
to select UHS Mode. This patch adds a new UhsSignaling type routine to
the NotifyPhase of the SdMmcOverride protocol.
UHS signaling configuration is moved to a common, default routine
(SdMmcHcUhsSignaling). After it is executed, the protocol producer
can override the values if needed.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
In order to ensure bigger flexibility in the NotifyPhase
routine of the SdMmcOverride protocol, enable using an
optional phase-specific data. This will allow to exchange
more information between the protocol producer driver
and SdMmcPciHcDxe in the newly added callbacks.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1142
The fix is similar to commit ebb6c7633b.
We found that a similar fix should be applied to the NVMe PEI driver as
well. Hence, this one is for the PEI counterpart driver.
According to the the NVM Express spec Revision 1.1, for some commands
(like Get/Set Feature Command, Figure 89 & 90 of the spec), the Memory
Buffer maybe optional although the command opcode indicates there is a
data transfer between host & controller (Get/Set Feature Command, Figure
38 of the spec).
Hence, this commit refine the checks for the 'TransferLength' and
'TransferBuffer' field of the
EDKII_PEI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET structure to address this
issue.
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jiewen Yao <Jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
There is concern at the thread
https://lists.01.org/pipermail/edk2-devel/2018-November/031951.html.
And the time point is a little sensitive as it is near edk2-stable201811.
This reverts commit 7779209971.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
There is concern at the thread
https://lists.01.org/pipermail/edk2-devel/2018-November/031951.html.
And the time point is a little sensitive as it is near edk2-stable201811.
This reverts commit 0cd6452503.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1274
In current code, EhcMonitorAsyncRequests (timer handler) will do
unmap and map operations for AsyncIntTransfers to "Flush data from
PCI controller specific address to mapped system memory address".
EhcMonitorAsyncRequests
EhcFlushAsyncIntMap
PciIo->Unmap
IoMmu->SetAttribute
PciIo->Map
IoMmu->SetAttribute
This may impact the boot performance.
Since the data buffer for EhcMonitorAsyncRequests is internal
buffer, we can allocate common buffer by PciIo->AllocateBuffer
and map the buffer with EfiPciIoOperationBusMasterCommonBuffer,
then the unmap and map operations can be removed.
///
/// Provides both read and write access to system memory by
/// both the processor and a bus master. The buffer is coherent
/// from both the processor's and the bus master's point of view.
///
EfiPciIoOperationBusMasterCommonBuffer,
Test done:
USB KB works normally.
USB disk read/write works normally.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
V3:
Call XhcFreeUrb after XhcCreateTransferTrb fails in XhcCreateTrb.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1274
In current code, XhcMonitorAsyncRequests (timer handler) will do
unmap and map operations for AsyncIntTransfers to "Flush data from
PCI controller specific address to mapped system memory address".
XhcMonitorAsyncRequests
XhcFlushAsyncIntMap
PciIo->Unmap
IoMmu->SetAttribute
PciIo->Map
IoMmu->SetAttribute
This may impact the boot performance.
Since the data buffer for XhcMonitorAsyncRequests is internal
buffer, we can allocate common buffer by PciIo->AllocateBuffer
and map the buffer with EfiPciIoOperationBusMasterCommonBuffer,
then the unmap and map operations can be removed.
///
/// Provides both read and write access to system memory by
/// both the processor and a bus master. The buffer is coherent
/// from both the processor's and the bus master's point of view.
///
EfiPciIoOperationBusMasterCommonBuffer,
Test done:
USB KB works normally.
USB disk read/write works normally.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
V3:
Match function parameter name and description between
EhciSched.c and EhciSched.h.
V2:
Add the missing "gBS->FreePool (Data);".
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1274
Extract new EhciInsertAsyncIntTransfer function from
EhcAsyncInterruptTransfer.
It is code preparation for following patch,
no essential functional change.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
V3:
Match function parameter name and description between
XhciSched.c and XhciSched.h.
V2:
Add the missing "FreePool (Data);".
Remove the unnecessary indentation change.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1274
Extract new XhciInsertAsyncIntTransfer function from
XhcAsyncInterruptTransfer.
It is code preparation for following patch,
no essential functional change.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1260
For the PassThru() service of NVM Express Pass Through Protocol, the
current implementation (function NvmExpressPassThru()) will only use the
IO Completion/Submission queues created internally by this driver during
the controller initialization process. Any other IO queues created will
not be consumed.
So the value is little to accept external IO Completion/Submission queue
creation request. This commit will refine the behavior of function
NvmExpressPassThru(), it will only accept driver internal IO queue
creation commands and will return "EFI_UNSUPPORTED" for external ones.
Cc: Jiewen Yao <Jiewen.yao@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1259
According to the the NVM Express spec Revision 1.1, for some commands,
command-related information will be stored in the Dword 0 of the
completion queue entry.
One case is for the Get Features Command (Section 5.9.2 of the spec),
Dword 0 of the completion queue entry may contain feature information.
Hence, this commit will always copy the content of completion queue entry
to the PassThru packet regardless of the execution result of the command.
Cc: Liangcheng Tang <liangcheng.tang@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1142
According to the the NVM Express spec Revision 1.1, for some commands
(like Get/Set Feature Command, Figure 89 & 90 of the spec), the Memory
Buffer maybe optional although the command opcode indicates there is a
data transfer between host & controller (Get/Set Feature Command, Figure
38 of the spec).
Hence, this commit refine the checks for the 'TransferLength' and
'TransferBuffer' field of the EFI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET
structure to address this issue.
Cc: Liangcheng Tang <liangcheng.tang@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1267
The value 5 Port Speed field of PORTSC is new defined in
XHCI 1.1 spec November 2017.
This patch updates XhciDxe and XhciPei to handle it, otherwise
the USB 3.1 device may not be recognized with the XHCI controller
following XHCI 1.1 spec November 2017.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Current hard code Usb2Hc.XXXRevision may be not accurate.
This patch updates code to assign Usb2Hc.XXXRevision based on
SBRN (Serial Bus Release Number, PCI configuration space offset
0x60) although there is no code consuming them.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Clock control is similar in SDHCI versions greater then version 2. Add
support for more recent versions of the controller specification.
SD card support for 1.8V is also present in controller versions 3 and
greater.
https://bugzilla.tianocore.org/show_bug.cgi?id=1233
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Add SDHCI controller defines, this is useful as the version in the
register does not explictly map to a specification version. For example
vesion 4.10 of the specification is version 0x04.
https://bugzilla.tianocore.org/show_bug.cgi?id=1233
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Currently, the implementation of EFI_PCI_IO_PROTOCOL::GetLocation()
in NonDiscoverablePciDeviceDxe returns the same set of dummy values
for each instance of the NON_DISCOVERABLE_DEVICE protocol that it
attaches itself to. However, this turns out to be causing problems
in cases where software (such as the ARM Compliance Test Suite [ACS])
attempts to use these values to uniquely identify controllers, since
the collisions create ambiguity in this regard.
So let's modify GetLocation() to return an arbitrary bus/device tuple
on segment 0xff instead. This is guaranteed not to clash with other
non-discoverable PCI devices, and highly unlikely to clash with real
PCIe devices.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
The change doesn't have functionality impact.
It just renames the mIoMmuProtocol to mIoMmu and moves the
declaration from PciRootBridgeIo.c to PciHostBridge.h.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Suggested-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1196
RootBridgeIoCheckParameter() verifies that the requested MMIO access
can fit in any of the MEM/PMEM 32/64 ranges. But today's logic
somehow only checks the requested access against MEM 32/64 ranges.
It should also check the requested access against PMEM 32/64 ranges.
The patch fixes this issue.
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: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Garrett Kirkendall <garrett.kirkendall@amd.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1182
Some devices can be non removable (such as eMMC) and checking
Present State Register on host controller may falsely return
an information that device is not present. Execute this
check conditionally on the SloType field value.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1185
SdMmcHcReset used to set all bits of Software Reset Register to 1
including reserved ones, which on some controllers may result in
timeout.
Now only first bit is set, which means "Software Reset for All".
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1167
When the HSEE in the USBCMD bit is a ‘1’ and the HSE bit in the
USBSTS register is a ‘1’, the xHC shall assert out-of-band error
signaling to the host and assert the SERR# pin.
To prevent masking any potential issues with SERR, this patch is
to set USBCMD Host System Error Enable(HSEE) Bit if PCICMD SERR#
Enable Bit is set.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Fei1 Wang <fei1.wang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
The EhcReset(), EhcGetRootHubPortStatus() and EhcDriverBindingStart()
functions need to see whether the host controller (or a specific port on
the host controller) can be accessed, dependent on the controller having
(or the specific port being) an in-use debug port. Because the condition
isn't simple, extract it to a separate function.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Suggested-by: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@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>
Commit 09943f5ecc ("MdeModulePkg: Skip to manage usb debug port in EDKII
EHCI driver if it's used by usb debug port driver", 2012-04-28) made the
host controller reset in EhcDriverBindingStart() conditional. The intent
was to avoid the reset when
- one of the USB ports on the host controller was a Debug Port, AND
- the Debug Port was in use.
This translates to the following positive condition: reset the controller
only if:
- no USB port on the host controller is a Debug Port, OR
- the Debug Port is not in use.
Commit 09943f5ecc failed to implement the first subcondition, and thus
the result is too strict now (for resetting the host controller). Relax it
to the correct condition.
This issue was found by Steven Shi on QEMU. QEMU's EHCI device model does
not have a Debug Port. In repeated disconnect / connect cycles, the
controller is never reset in EhcDriverBindingStart(), therefore the
devices on the controller are never re-enumerated after a disconnect.
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Reported-by: Steven Shi <steven.shi@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1129
Fixes: 09943f5ecc
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Tested-by: Steven Shi <steven.shi@intel.com>
The function UsbHcUnlinkMemBlock that is never called
and its related comments have been removed.
It is missed in the patch series according to the log in
https://bugzilla.tianocore.org/show_bug.cgi?id=1062
v2:Update the title.
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: 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 XhcPeiReadDoorBellReg and UsbHcUnlinkMemBlock.
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: Star Zeng <star.zeng@intel.com>
The functions that are never called have been removed.
They are XhcReadDoorBellReg and XhcWriteOpReg16.
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>
The functions that are never called have been removed.
They are IoMmuFreeBuffer,DelinkMemoryBlock,IsMemoryBlockEmptied
,IsTDLinkPtrQHOrTD,GetCurrentFrameNumber,GetQHHorizontalLinkPtr
and GetQHHorizontalValidorInvalid.
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: Star Zeng <star.zeng@intel.com>
The functions that are never called have been removed.
They are SdCardGetCsd and SdCardGetScr.
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: Star Zeng <star.zeng@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@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>
The functions that are never called have been removed.
They are ReadNvmeAdminSubmissionQueueBaseAddress,
ReadNvmeAdminCompletionQueueBaseAddress and ReadNvmeAdminQueueAttributes
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: Star Zeng <star.zeng@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
The functions that are never called have been removed.
They are EhcDumpRegs,EhcDisableAsyncSchd and EhcDisablePeriodSchd
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: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.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>
Use compare logic in if condition to fix ECC issue.
It is caused by aa4240edff.
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Current code calculates ChannelCount based on CAP(NP) value.
It only works when the ports implemented number are <= CAP(NP),
for example, platform has CAP(NP) = 5 (means 6 ports) and ports
implemented are 0, 1, 2, 3, 4 and 5.
But we have some platform that has CAP(NP) = 1 (means 2 ports) and
ports implemented are 1 and 2, and has no port 0 implemented, then
current code does not work.
This patch updates the code to calculate ChannelCount based on PI value.
Cc: Amy Chan <amy.chan@intel.com>
Cc: Hong-chihX Hsueh <hong-chihx.hsueh@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Tested-by: Hong-chihX Hsueh <hong-chihx.hsueh@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>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=256
This commit adds the PEI BlockIo support for NVM Express devices.
The driver will consume the EDKII_NVM_EXPRESS_HOST_CONTROLLER_PPI for NVM
Express host controllers within the system. And then produces the
BlockIo(2) PPIs for each controller.
The implementation of this driver is currently based on the NVM Express 1.1
Specification, which is available at:
http://nvmexpress.org/resources/specifications/
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
The SATA controller driver crashes while accessing the
PCI memory [AHCI Base Registers (ABAR)], as the PCI memory
space is not enabled.
Enable the PCI memory space access to prevent the SATA
Controller driver from crashing.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Per PI spec, the Length value is the length of the ACPI descriptor
in bytes, excluding the first two fields.
The patch fixes the code to report the correct descriptor length
by excluding 3-byte first two fields.
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=980
Adjust the DEBUG prints within function:
NvmeRead(), NvmeWrite(), AsyncNvmeRead() and AsyncNvmeWrite()
to DEBUG_BLKIO for the consistency with other storage device drivers
(e.g. ATA, USB and etc.).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@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>
RootBridgeIo.PollMem()/PollIo() originally don't count the IO/MMIO
access overhead when delaying.
The patch changes the implementation to count the access overhead
so that the actually delay equals to user required delay.
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: Chasel Chiu <chasel.chiu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=937
In NvmeExpressPassthru.c near line 659:
Prp = NvmeCreatePrpList (
PciIo,
PhyAddr,
EFI_SIZE_TO_PAGES(Offset + Bytes) - 1,
&PrpListHost,
&PrpListNo,
&MapPrpList
);
if (Prp == NULL) {
goto EXIT;
}
Status is not set to an error code - Status is initialized to
EFI_SUCCESS, or set by a PciIo->Map to EFI_SUCCESS above this
code. This error path should set Status to an error code before
goto EXIT.
Change-Id: I8a5cdf981aa609534c205d3676395805ac60a003
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Michael Turner <Michael.Turner@microsoft.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@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>
PCI address translation is necessary for some non-x86 platforms. On
such platforms, address value (denoted as "device address" or "address
in PCI view") set to PCI BAR registers in configuration space might be
different from the address which is used by CPU to access the
registers in memory BAR or IO BAR spaces (denoted as "host address" or
"address in CPU view"). The difference between the two addresses is
called "Address Translation Offset" or simply "translation", and can
be represented by "Address Translation Offset" in ACPI QWORD Address
Space Descriptor (Offset 0x1E). However UEFI and ACPI differs on the
definitions of QWORD Address Space Descriptor, and we will follow UEFI
definition on UEFI protocols, such as PCI root bridge IO protocol and
PCI IO protocol. In UEFI 2.7, "Address Translation Offset" is "Offset
to apply to the Starting address to convert it to a PCI address". This
means:
1. Translation = device address - host address.
2. PciRootBridgeIo->Configuration should return CPU view address, as
well as PciIo->GetBarAttributes.
Summary of addresses used in protocol interfaces and internal
implementations:
1. *Only* the following protocol interfaces assume Address is Device
Address:
(1). PciHostBridgeResourceAllocation.GetProposedResources()
Otherwise PCI bus driver cannot set correct address into PCI
BARs.
(2). PciRootBridgeIo.Mem.Read() and PciRootBridgeIo.Mem.Write()
(3). PciRootBridgeIo.CopyMem()
UEFI and PI spec have clear statements for all other protocol
interfaces about the address type.
2. Library interfaces and internal implementation:
(1). Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address.
It is easy to check whether the address is below 4G or above 4G.
(2). Addresses in PCI_ROOT_BRIDGE_INSTANCE.ResAllocNode are host
address, for they are allocated from GCD.
(3). Address passed to PciHostBridgeResourceConflict is host address,
for it comes from PCI_ROOT_BRIDGE_INSTANCE.ResAllocNode.
RESTRICTION: to simplify the situation, we require the alignment of
Translation must be larger than any BAR alignment in the same root
bridge, so that resource allocation alignment can be applied to both
device address and host address.
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>
Invoke the newly introduced SD/MMC override protocol to override
the capabilities register after reading it from the device registers,
and to call the pre/post host init and reset hooks at the appropriate
times.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Within function NvmExpressPassThru():
The data buffer for the below 2 Admin command:
Create I/O Completion Queue command (Opcode 01h)
Create I/O Submission Queue command (Opcode 05h)
are not mapped to the PCI controller specific addresses.
But the current code logic also prevents the below NVM command:
Write (Opcode 01h)
from mapping its data buffer.
Hence, this commit refine the logic to resolve this issue.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.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>
It didn't cause big issues when VT-d was disabled.
But in VT-d enabled platform, lack of EhcFreeUrb call caused
the DMA data was not moved back to user's buffer.
It caused the correct data cannot be got through sync interrupt
transfer.
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>
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>
Commit f6b139b added return status handling to PciIo->Mem.Write.
However, the second status handling will override EFI_DEVICE_ERROR
returned in this branch:
//
// Check the NVMe cmd execution result
//
if (Status != EFI_TIMEOUT) {
if ((Cq->Sct == 0) && (Cq->Sc == 0)) {
Status = EFI_SUCCESS;
} else {
Status = EFI_DEVICE_ERROR;
^^^^^^^^^^^^^^^^
Since PciIo->Mem.Write will probably return SUCCESS, it causes
NvmExpressPassThru to return SUCCESS even when DEVICE_ERROR occurs.
Callers of NvmExpressPassThru will then continue executing which may
cause further unexpected results, e.g. DiscoverAllNamespaces couldn't
break out the loop.
So we save previous status before calling PciIo->Mem.Write and restore
the previous one if it already contains error.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Update the UhciPei driver to consume IOMMU_PPI to allocate DMA buffer.
If no IOMMU_PPI exists, this driver still calls PEI service to allocate
DMA buffer, with assumption that DRAM==DMA.
Cc: Jiewen Yao <jiewen.yao@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>
This patch is following 2c656af04d.
1. Fix typo "XHC" to "EHC".
2. Reinitialize Request(Phy/Map) and Data(Phy/Map)
in Urb, otherwise the last time value of them may
be used in error handling when error happens.
Cc: Jiewen Yao <jiewen.yao@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>
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>
1. Call IoMmuInit() after locating gPeiUsbControllerPpiGuid.
2. Call XhcPeiFreeSched() to do cleanup in XhcEndOfPei.
Cc: Jiewen Yao <jiewen.yao@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>
V2: Halt HC at EndOfPei.
Update the EhciPei driver to consume IOMMU_PPI to allocate DMA buffer.
If no IOMMU_PPI exists, this driver still calls PEI service to allocate
DMA buffer, with assumption that DRAM==DMA.
Cc: Jiewen Yao <jiewen.yao@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>
For PciIoPciRead interface, memory prior to Buffer would be written
with zeros if Offset was larger than sizeof (Dev->ConfigSpace), which
would cause serious system exception.
So we add a pre-check branch to avoid memory override.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
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>
Currently, we complete a synchronous operation without unmapping the
DMA mappings, and free the pages using FreePages () rather than calling
EFI_PCI_IO_PROTOCOL::FreeBuffer. This is simply incorrect, but it also
breaks non-coherent DMA as well as DMA protection and/or memory encryption
so let's do it correctly and call SdMmcFreeTrb() instead.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.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>
Existing code forgot to set Descriptor->SpecificFlag to 0 when
the resource type is non-prefetchable MMIO.
The patch adds the missing assignment.
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>
Update XHCI driver to consume IOMMU_PPI to allocate DMA buffer.
If no IOMMU_PPI exists, this driver still calls PEI service
to allocate DMA buffer, with assumption that DRAM==DMA.
This is a compatible change.
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=653
Correct description of Timeout param in XhciReg.h to be matched with
XhciReg.c.
Cc: Alexei Fedorov <Alexei.Fedorov@arm.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: Ruiyu Ni <ruiyu.ni@intel.com>
We found there are loops of *2* Maps and only *1* Unmap and
the DMA buffer address is decreasing.
It is caused by the below code flow.
XhcAsyncInterruptTransfer ->
XhcCreateUrb ->
XhcCreateTransferTrb ->
Map Urb->DataMap (1)
Timer: loops of *2* Maps and only *1* Unmap
XhcMonitorAsyncRequests ->
XhcFlushAsyncIntMap ->
Unmap and Map Urb->DataMap (2)
XhcUpdateAsyncRequest ->
XhcCreateTransferTrb ->
Map Urb->DataMap (3)
This patch is to eliminate (3).
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Per NVM Express Spec, software should notify NVME HW when shutdown
occurs.
The NVME controller requires notification for shutdown as part of
its management of internal structures. Even with FUA, failing to
notify the NVME controller to shutdown power off causes the NVME
controller to take quite some time to organize its tables on the
next power on. This time exceeds the normal timeout, so we would
fail to boot the NVME disk.
The host should set the Shutdown Notification (CC.SHN) field to 01b
to indicate a normal shutdown operation. The controller indicates
when shutdown processing is completed by updating the Shutdown Status
(CSTS.SHST) field to 10b.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@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>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=644
According to XHCI spec:
4.10.2.1 Stall Error
4.10.2.4 Babble Detected Error
When a device transmits more data on the USB than the host controller
is expecting for a transaction, it is defined to be babbling.
In general, this is called a Babble Error. When a device sends more
data than the TD Transfer Size bytes (TD Babble), unexpected activity
that persists beyond a specified point in a (micro)frame (Frame Babble),
or a packet greater than Max Packet Size (Packet Babble), the host
controller shall set the Babble Detected Error in the Completion Code
field of the TRB, generate an Error Event, and halt the endpoint
(refer to Section 4.10.2.1).
This patch is to also check for EFI_USB_ERR_BABBLE error returned as
a TransferResult and then proceed to XhcRecoverhaltedEndPoint.
Cc: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=433
When a blocking NVMe PassThru request experiences timeout, the current
codes in function NvmExpressPassThru() do not abort the timeout request
while advancing synchronous Submission Queue tail. Therefore, it is
possible to submit a new blocking PassThru request when the synchronous
Submission Queue is full.
The commit adds logic to abort the timeout request by resetting the NVMe
controller when a timeout occurs for a blocking PassThru request.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
This fixes BULK data loss when transfer is detected as timeout but
finished just before stopping endpoint.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
The patch separates the common logic in XhcControlTransfer,
XhcBulkTransfer and XhcSyncIntTransfer to a sub-routine
XhcTransfer. It doesn't have functionality impact.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Current implementation of IsTransferRingTrb only checks whether
the TRB is in the RING of the URB.
The patch enhanced the logic to check that whether the TRB belongs
to the transaction of URB.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Some USB devices don't report data periodically through Int
Transfer. They report data only when be asked. If the TRB
is not removed from the XHCI HW, when next time HOST asks
data again, the data is reported but consumed by the previous
TRB, which results the HOST thinks data never comes.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=510
The commit fills the 'Interval' field of the Endpoint Context data for
isochronous endpoints. It will resolve the error when a Configure
Endpoint Command is sent to an isochronous endpoint.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@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>
If IOMMU protocol is installed, PciHostBridge just calls
IOMMU AllocateBuffer/FreeBuffer/Map/Unmap.
PciHostBridge does not set IOMMU access attribute,
because it does not know which device request the DMA.
This work is done by PciBus driver.
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>
In function UfsHcDriverBindingStart(), the return value 'Status' may be
overridden during the original PCI attributes restore process.
This commit refines the logic to avoid such override.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
The commit removes the unused field 'EFI_HANDLE Handle' in Ufs host
controller private data structure 'UFS_HOST_CONTROLLER_PRIVATE_DATA'.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
In case of an async command if updating the submission queue tail
doorbell fails then the command will not be picked up by device and
no completion response will be created. This scenario has to be handled.
Also if we create an AsyncRequest element and insert in the async queue,
it will never receive a completion so in the timer routine this element
won't be freed, resulting in memory leak. Also in case of blocking calls
we should capture the status of updating completion queue head doorbell
register and return it to caller of PassThru.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Suman Prakash <suman.p@samsung.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
In function ReadCapacity(), the following expression:
MediaInfo->LastBlock = (Data.LastLba3 << 24) |
(Data.LastLba2 << 16) |
(Data.LastLba1 << 8) |
Data.LastLba0;
(There is also a similar case in this function.)
will involve undefined behavior in signed left shift operations.
Since Data.LastLbaX is of type UINT8, and MediaInfo->LastBlock is of type
UINTN. Therefore, Data.LastLbaX will be promoted to int (32 bits, signed)
first, and then perform the left shift operation.
According to the C11 spec, Section 6.5.7:
4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
bits are filled with zeros. If E1 has an unsigned type, the value
of the result is E1 * 2^E2 , reduced modulo one more than the
maximum value representable in the result type. If E1 has a signed
type and nonnegative value, and E1 * 2^E2 is representable in the
result type, then that is the resulting value; otherwise, the
behavior is undefined.
So if bit 7 of Data.LastLba3 is 1, (Data.LastLba3 << 24) will be out of
the range within int type. The undefined behavior of the signed left shift
will lead to a potential of setting the high 32 bits of
MediaInfo->LastBlock to 1 during the cast from type int to type UINT64
for X64 builds.
This commit will add an explicit UINT32 type cast for Data.LastLba3 to
resolve this issue.
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 async commands, the buffer allocated for Prp list is
not getting freed, which will cause memory leak for async
read write command. For example testing async command flow
with custom application to send multiple read write commands
were resulting in decrease of available memory page in memmap,
which eventually resulted in system hang. Hence freeing
AsyncRequest->MapData, AsyncRequest->MapMeta, AsyncRequest->MapPrpList and
AsyncRequest->PrpListHost when async command is completed.
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Suman Prakash <suman.p@samsung.com.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
At worst case, OCR register may always not set BIT31. It will cause
original code enter to dead loop. Adding a break for such case.
Cc: Hao Wu <hao.a.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.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>
When the VendorId/DeviceId/RevisionId/SubsystemVendorId
/SubsystemDeviceId is MAX_UINTN, IncompatiblePciDeviceSupport
driver doesn't use it to match any IDs.
The patch fixes this bug.
Since PciBus driver always calls IncompatiblePciDeviceSupport
using IDs read from HW, MAX_UINTN is never passed to this
driver.
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 patch replaces the following macros:
DEVICE_ID_NOCARE (0xFF) --> MAX_UINT64
PCI_ACPI_UNUSED (0) --> 0
PCI_BAR_ALL (0xFF) --> MAX_UINT64
PCI_BAR_NOCHANGE (0) --> 0
PCI_BAR_EVEN_ALIGN --> EVEN_ALIGN (local definition)
Since the PciBus driver was updated to accept Spec defined values
in previous commit, the above replacements don't impact
functionality.
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>
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>
When BarIndex equals to 0xFF, default value 0 is used as the BAR
index. Though PCI_BAR_ALL and MAX_UINT8 shares the same value,
using PCI_BAR_ALL is like to match any BAR not BAR 0, it's more
proper to use MAX_UINT8 here.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
If the code eventually returns "Status" anyway, it does not make
sense to explicitly return "Status" in case of an error, too.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Refine the codes to compare the definition 'SIZE_4GB' with type
EFI_PHYSICAL_ADDRESS.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Albecki, Mateusz
Javeed, Ashraf
Maggie Chu
Laszlo Ersek
xuwei6
Zhichao Gao
Ard Biesheuvel
Michael D Kinney
Ashish Singhal
Hao Wu
Edgar Handal
Albecki, Mateusz
Ray Ni
Sean Brogan
Dandan Bi
Ruiyu Ni
Vladimir Olovyannikov
Marcin Wojtas
Tomasz Michalec
Star Zeng
Jeff Brasen
Chen A Chen
shenglei
Thomas Palmer
Liming Gao
Sami Mujawar
Heyi Guo
Jiewen Yao
Bi, Dandan
Suman Prakash
Feng Tian
Thomas Huth