REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409
This commit will add the AHCI mode ATA device support in the PEI phase.
More specifically, the newly add AhciPei driver will consume the ATA AHCI
host controller PPI for ATA controllers working under AHCI code within the
system. And then produces the below PPIs for each controller:
EDKII PEI ATA PassThru PPI
Storage Security Command PPI
Also, the driver will consume the S3StorageDeviceInitList LockBox in S3
phase. The purpose is to perform an on-demand (partial) ATA device
enumeration/initialization on each controller to benefit the S3 resume
performance.
The implementation of this driver is currently based on the below
specifications:
Serial ATA Revision 2.6
Serial ATA Advanced Host Controller Interface (AHCI) 1.3.1
AT Attachment with Packet Interface - 6 (ATA/ATAPI-6)
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 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>
SdReadWrite can be called with a NULL Token for synchronous operations.
Add guard for DEBUG print to only print event pointer with Token is not
NULL.
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=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>
The recent changes in these three source files introduce the trailing space.
This patch removes them to follow edk2 coding style.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
When (Len < Offset) is TRUE, indicating the data to visit is beyond
the boundary, the error message is printed but the function doesn't
return NULL.
It's a typo when modifying the commit 4c034bf62.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Today's implementation doesn't check whether the length of
descriptor is valid before using it.
The patch fixes this issue by syncing the similar fix to UsbBusDxe.
70c3c2370a
*MdeModulePkg/UsbBus: Reject descriptor whose length is bad
Additionally the patch also rejects the data when length is
larger than sizeof (PeiUsbDevice->ConfigurationData).
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: Jiewen Yao <jiewen.yao@intel.com>
Today's implementation reads the Type/Length field in the USB
descriptors data without checking whether the offset to read is
beyond the data boundary.
The patch fixes this issue by syncing the fix in commit
4c034bf62c
*MdeModulePkg/UsbBus: Fix out-of-bound read access to descriptors
ParsedBytes in UsbBusPei.GetExpectedDescriptor() is different from
Consumed in UsbBusDxe.UsbCreateDesc().
ParsedBytes is the offset of found descriptor while Consumed is
offset of next descriptor of found one.
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: Jiewen Yao <jiewen.yao@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>
Commit e59db6a732
* MdeModulePkg/UsbMass: Merge UsbBoot(Read|Write)Blocks(16)
introduces a bug that causes writing to USB key always fails.
When that patch is verified, only reading was verified.
The root cause is when the writing operation is performed,
the data direction EfiUsbDataIn is wrongly used. Instead, it
should be EfiUsbDataOut.
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=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>
This commit adds checks to make sure the UFS devices do not return more
data than the driver expected.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
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: Star Zeng <star.zeng@intel.com>
Per USB HID spec, the buffer holding key codes should at least 3-byte
long.
Today's code assumes that the key codes buffer length is longer than
3-byte and unconditionally accesses the key codes buffer.
It's incorrect.
The patch fixes the issue by returning Device Error when the
length is less than 3-byte.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Per USB HID spec, the buffer holding key codes should at least 3-byte
long.
Today's code assumes that the key codes buffer length is longer than
3-byte and unconditionally accesses the key codes buffer.
It's incorrect.
The patch fixes the issue by returning Device Error when the
length is less than 3-byte.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Per USB HID spec, the buffer holding key codes should be 8-byte
long.
Today's code assumes that the key codes buffer length is 8-byte
long and unconditionally accesses the key codes buffer.
It's incorrect.
The patch fixes the issue by returning Device Error when the
length is less than 8-byte.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Today's implementation doesn't check whether the length of
descriptor is valid before using it.
The patch fixes this issue.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Today's implementation reads the Type/Length field in the USB
descriptors data without checking whether the offset to read is
beyond the data boundary.
The patch fixes this issue.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
UsbBootReadWriteBlocks() and UsbBootReadWriteBlocks16() use a UINT16
local variable to hold the value of
USB_BOOT_MAX_CARRY_SIZE (=0x10000) / BlockSize.
When BlockSize is 1, the UINT16 local variable is set to 0x10000
but the high-16 bits are truncated resulting the final value be 0.
It causes the while-loop in the two functions accesses 0 block in
each loop, resulting the loop never ends.
The patch fixes the two functions to make sure no integer overflow
happens.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>