Sorry, I didn't want to make an impression that I expected solution to be
delivered, I was merely trying to explain some of the complexity we are trying
to handle on our side and why we didn't went for SerialDxe and instead opted to
make PciSioSerialDxe work for our use case. Anyway thanks for t
Is the idea to refactor PciSioSerialDxe to extract functions that access the HW
and wrap it in the SerialPortLib instance? That solution would still save us
some maintenance cost. However exploring the idea further I see following
problems:
1. Relying on driver binding produces a fairly nice fl
1. Using SerialDxe instead of PciSioSerialDxe - from our perspective the main
idea is to avoid maintaining our own implementation of functions that actually
communicate with UART controller. To use SerialDxe we would have to still
maintain our own SerialPortLib that actually goes and sends data
Hi,
I was originally responsible for suggesting this change internally(more
specifically - to switch from Intel specific LPSS UART driver to EDK2 driver
which on inspection seemed to cover all relevant modes of operations of LPSS
UART).
First I would like to explain how exactly we are using th
This commit adds host-based unit tests for device path lib.
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
Signed-off-by: Mateusz Albecki
---
MdePkg/MdePkg.ci.yaml | 5 +-
MdePkg/Test/MdePkgHostTest.dsc| 2 +
.../Library/DevicePathLib/TestDev
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4555
Add logic that checks if the code doesn't overflow
ACPI_EXTENDED_HID_DEVICE_PATH node when searching for optional
strings. If the string is not provided in the device path node
default value of "\0" is used.
Cc: Michael D Kinney
Cc: Liming
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4555
Github PR: https://github.com/tianocore/edk2/pull/4865
Fix for buffer overlows that arise in DevPathToTextAcpiEx when device path node
producer doesn't specify all of the optional strings.
Changes in v2:
- Fix AcpiExp print logic that got b
This patch has a bug related to AcpiExp device path. I will resend the fixed
version along with unit tests to cover AcpiExp cases.
Thanks,
Mateusz
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109120): https://edk2.groups.io/g/devel/me
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4555
Add logic that checks if the code doesn't overflow
ACPI_EXTENDED_HID_DEVICE_PATH node when searching for optional
strings. If the string is not provided in the device path node
default value of "\0" is used.
Cc: Michael D Kinney
Cc: Liming
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4555
Github PR: https://github.com/tianocore/edk2/pull/4865
Fix for buffer overlows that arise in DevPathToTextAcpiEx when device path node
producer doesn't specify all of the optional strings.
Tests:
- Booted the platform and confirmed that pla
GCC is throwing a warning during BaseTools compilation which leads
to build errors when Wall is set. This commit removes all conditions
which are always true/false(Waddress warning) and wraps one snprintf
in compiler pragma to disable format-truncation warning.
Cc: Bob Feng
Cc: Liming Gao
Cc: Yu
Currently AHCI driver will try to retry all failed packets
regardless of the failure cause. This is a problem in password
unlock flow where number of password retries is tracked by the
device. If user passes a wrong password Ahci driver will try
to send the wrong password multiple times which will
Fix for the recovery logic which causes hdd unlock to fail if user supplies
incorrect
password. Every failed packet used to be recovered which is causing the
incorrect password to be tried multiple times. This patch series fixes the logic
to only retry commands that failed due to CRC error.
BZ: h
Seems like a code formatting issue. I will address it tomorrow.
Regards,
Mateusz
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#101698): https://edk2.groups.io/g/devel/message/101698
Mute This Topic: https://groups.io/mt/97764094/21656
G
bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4011
Currently AHCI driver will try to retry all failed packets
regardless of the failure cause. This is a problem in password
unlock flow where number of password retries is tracked by the
device. If user passes a wrong password Ahci driver
Fix for the recovery logic which causes hdd unlock to fail if user supplies
incorrect
password. Every failed packet used to be recovered which is causing the
incorrect password to be tried multiple times. This patch series fixes the logic
to only retry commands that failed due to CRC error.
BZ: h
Hello,
I've done some investigation into the password issue and I think I have the
proposition on how to solve it. The issue arises due to the driver checking the
PxIS.TFES(task file error status) and if TFES is set it performs recovery
steps(this is correct according to AHCI spec 6.2.2) and re
Hello,
Really sorry for missing the mails. Seems like my mail was misconfigured and I
didn't get the messages(had to check the group site).
"I cannot remember why EFI_SUCCESS is eventually returned for the above error
case. Could you help to remind me of the details? Thanks."
To answer this -
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=4016
AtaAtapiPassThru driver was reporting recovery status on failed command
packets which led to incorrect flows in upper layers and to SCT tests
fails. This commit will change the logic to report command status.
Cc: Hao A Wu
Cc: Ray Ni
/sata_abort_completion)
- it should be noted that qemu doesn't really support trust protocol on SATA
drive but for the purposes of the test it should be enough.
Cc: Hao A Wu
Cc: Ray Ni
Signed-off-by: Mateusz Albecki
Mateusz Albecki (1):
MdeModulePkg/Ata: Fix command status reporting
.../Bu
DevicePathLib utilities are useful in PEI to locate the devices which need
an opal unlock on S3 resume. This commit reuses the implementation done
for standalone MM support and makes the StandaloneMm library Base.
Signed-off-by: Mateusz Albecki
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang
This patch adds support for PEIMs in UefiDevicePathLib. Although this library
and DEVICE_PATH_PROTOCOL
itself was initially intended for DXE the use case of unlocking opal-locked
storage devices during S3
resume makes it useful in PEI.
As it is the change will break the users who will need to ch
Hi,
I think it would be better to avoid using PEI and PPI in the structure names.
This would allow us to install this structure as protocol in DXE/SMM and
potentially use it in a common code.
Thanks,
Mateusz
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
On Mon, May 23, 2022 at 11:24 PM, Gerd Hoffmann wrote:
>
> On Mon, May 23, 2022 at 04:48:05AM -0700, Albecki, Mateusz wrote:
>
>> @Ni, Ray
>>
>> I think EDK2 needs to provide a way for root port to operate without IO
>> space assigned in a platform-independent
DevicePathLib utilities are useful in PEI to locate the devices which need
an opal unlock on S3 resume. This commit reuses the implementation done
to support Standalone MM for PEI.
Signed-off-by: Mateusz Albecki
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
---
.../Library/UefiDeviceP
@Ni, Ray
I think EDK2 needs to provide a way for root port to operate without IO space
assigned in a platform-independent way. I can think of the following cases when
root port didn't get IO space:
1. We have run out of IO space but it's fine since the device under the root
port doesn't use IO
Thanks Mike I will send a new patch with inf file name untouched.
Mateusz
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#89201): https://edk2.groups.io/g/devel/message/89201
Mute This Topic: https://groups.io/mt/88346995/21656
Group Owne
DevicePathLib utilities are useful in PEI to locate the devices which need
an opal unlock on S3 resume. This commit reuses the implementation done
to support Standalone MM for PEI.
Signed-off-by: Mateusz Albecki
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
---
...iesStandaloneMm.c =>
This patch adds support for PEIMs in UefiDevicePathLib. Although this library
and DEVICE_PATH_PROTOCOL
itself was initially intended for DXE the use case of unlocking opal-locked
storage devices during S3
resume makes it useful in PEI.
As it is the change will break the users who will need to ch
:31 AM
To: Kinney, Michael D
Cc: devel@edk2.groups.io; Wu, Hao A ; Ni, Ray
; Wang, Jian J ; Albecki, Mateusz
; Laszlo Ersek
Subject: Re: [edk2-devel] [PATCH 1/2] MdeModulePkg/SataControllerDxe: Add
support for drives in RAID mode
Mike,
That’s right. And due to that interface being vendor
To allow for easier debug of failing commands we
have added a capability to print TRB and command
packet when we start execution of the TRB(on
DEBUG_VERBOSE level) and when the TRB failed to
execute correctly(on DEBUG_ERROR level). Additionally
we will also print error interrupt status and interrup
This patch series aims to refactor command processing to achieve following
- Trace the failing TRB packets to see what commands are failing and for what
reasons
- Get the response data even if data transfer timed out to allow easier
debugging
- Fix the PIO mode which is currently completely brok
SdMmcPciHcDxe driver used to read response only after
command and data transfer completed. According to SDHCI
specification response data is ready after the command
complete status is set by the host controller. Getting
the response data early will help debugging the cases
when command completed bu
Current driver does not support PIO transfer mode for
commands other then tuning. This change adds the code
to transfer PIO data.
Cc: Hao A Wu
Cc: Marcin Wojtas
Cc: Zhichao Gao
Cc: Liming Gao
Signed-off-by: Mateusz Albecki
---
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 3 +
MdeM
This patch refactors the way in which the driver will check
the data transfer completion. Data transfer related
functionalities have been moved to separate function.
Cc: Hao A Wu
Cc: Marcin Wojtas
Cc: Zhichao Gao
Cc: Liming Gao
Signed-off-by: Mateusz Albecki
---
MdeModulePkg/Bus/Pci/SdMmcPc
Driver code used to map memory for DMA transfer even if host doesn't
support DMA. This is causing memory corruption when driver transfers
data using PIO. This change refactors the code to skip call to
PciIo->Map for non DMA transfers.
Cc: Hao A Wu
Cc: Marcin Wojtas
Cc: Zhichao Gao
Cc: Liming Ga
This patch series aims to increase the reliability of the eMMC detection by
exectuing the SEND_STATUS after SWITCH command on the lower frequency.
Currently the driver will first switch the frequency to the new target and then
execute SEND_STATUS to see if SWITCH was a success. While this behavi
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140
To avoid stability issues on some designs the driver
will now send SEND_STATUS at previous, lower, frequency
when upgrading the bus timing.
Cc: Hao A Wu
Cc: Marcin Wojtas
Cc: Zhichao Gao
Cc: Liming Gao
Signed-off-by: Mateusz Albecki
-
ove the extra check after I have found out that is not the case.
Thanks,
Mateusz
> -Original Message-
> From: Wu, Hao A
> Sent: Monday, February 24, 2020 8:01 AM
> To: Albecki, Mateusz ; devel@edk2.groups.io
> Cc: Marcin Wojtas ; Gao, Zhichao
> ; Gao, Liming
>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140
To avoid stability issues on some designs the driver
will now send SEND_STATUS at previous, lower, frequency
when upgrading the bus timing.
Cc: Hao A Wu
Cc: Marcin Wojtas
Cc: Zhichao Gao
Cc: Liming Gao
Signed-off-by: Mateusz Albecki
-
This patch series aims to increase the reliability of the eMMC detection by
exectuing the SEND_STATUS after SWITCH command on the lower frequency. Currently
the driver will first switch the frequency to the new target and then execute
SEND_STATUS to see if SWITCH was a success. While this behavior
,
Mateusz
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Albecki,
> Mateusz
> Sent: Thursday, February 20, 2020 1:36 PM
> To: Wu, Hao A ; devel@edk2.groups.io
> Cc: Marcin Wojtas ; Gao, Zhichao
> ; Gao, Liming
> Subject: Re: [edk2-devel] [PATCHv2 0/4] Md
.
Regarding the push - I am fine with this change making it to master after the
stable tag.
Thanks,
Mateusz
> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, February 20, 2020 1:40 AM
> To: Albecki, Mateusz ; devel@edk2.groups.io
> Cc: Marcin Wojtas ; Gao, Zhichao
This patch series aims to refactor command processing to achieve following
- Trace the failing TRB packets to see what commands are failing and for what
reasons
- Get the response data even if data transfer timed out to allow easier
debugging
- Fix the PIO mode which is currently completely brok
This patch refactors the way in which the driver will check
the data transfer completion. Data transfer related
functionalities have been moved to separate function.
Cc: Hao A Wu
Cc: Marcin Wojtas
Cc: Zhichao Gao
Cc: Liming Gao
Signed-off-by: Mateusz Albecki
---
MdeModulePkg/Bus/Pci/SdMmcPc
Current driver does not support PIO transfer mode for
commands other then tuning. This change adds the code
to transfer PIO data.
Cc: Hao A Wu
Cc: Marcin Wojtas
Cc: Zhichao Gao
Cc: Liming Gao
Signed-off-by: Mateusz Albecki
---
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 3 +
MdeM
To allow for easier debug of failing commands we
have added a capability to print TRB and command
packet when we start execution of the TRB(on
DEBUG_VERBOSE level) and when the TRB failed to
execute correctly(on DEBUG_ERROR level). Additionally
we will also print error interrupt status and interrup
SdMmcPciHcDxe driver used to read response only after
command and data transfer completed. According to SDHCI
specification response data is ready after the command
complete status is set by the host controller. Getting
the response data early will help debugging the cases
when command completed bu
fix
it in v2.
Thanks,
Mateusz
> -Original Message-
> From: Wu, Hao A
> Sent: Wednesday, February 5, 2020 4:16 AM
> To: devel@edk2.groups.io; Albecki, Mateusz
> Cc: Marcin Wojtas ; Gao, Zhichao
> ; Gao, Liming
> Subject: RE: [edk2-devel] [PATCH 4/4] MdeModulePkg/SdM
Hi,
As in the patch 2/4 section 3.7.1.2 recommends that we clear the transfer
complete(step 6) just after reading it(step 5).
Thanks,
Mateusz
> -Original Message-
> From: Wu, Hao A
> Sent: Wednesday, February 5, 2020 4:16 AM
> To: devel@edk2.groups.io; Albecki, Mateusz
age-
> From: Wu, Hao A
> Sent: Wednesday, February 5, 2020 4:16 AM
> To: devel@edk2.groups.io; Albecki, Mateusz
> Cc: Marcin Wojtas ; Gao, Zhichao
> ; Gao, Liming
> Subject: RE: [edk2-devel] [PATCH 2/4] MdeModulePkg/SdMmcPciHcDxe:
> Read response on command completion
SdMmcPciHcDxe driver used to read response only after
command and data transfer completed. According to SDHCI
specification response data is ready after the command
complete status is set by the host controller. Getting
the response data early will help debugging the cases
when command completed bu
Current driver does not support PIO transfer mode for
commands other then tuning. This change adds the code
to transfer PIO data.
Cc: Hao A Wu
Cc: Marcin Wojtas
Cc: Zhichao Gao
Cc: Liming Gao
Signed-off-by: Mateusz Albecki
---
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 3 +
MdeM
This patch refactors the way in which the driver will check
the data transfer completion. Data transfer related
functionalities have been moved to separate function.
Cc: Hao A Wu
Cc: Marcin Wojtas
Cc: Zhichao Gao
Cc: Liming Gao
Signed-off-by: Mateusz Albecki
---
MdeModulePkg/Bus/Pci/SdMmcPc
To allow for easier debug of failing commands we
have added a capability to print TRB and command
packet when we start execution of the TRB(on
DEBUG_VERBOSE level) and when the TRB failed to
execute correctly(on DEBUG_ERROR level). Additionally
we will also print error interrupt status and interrup
This patch series aims to refactor command processing to achieve following
1. Trace the failing TRB packets to see what commands are failing and for what
reasons
2. Get the response data even if data transfer timed out to allow easier
debugging
3. Fix the PIO mode which is currently completely b
This patch adds retries for async execution for commands that
failed due to the CRC errors.
Cc: Hao A Wu
Cc: Marcin Wojtas
Cc: Zhichao Gao
Cc: Liming Gao
Signed-off-by: Mateusz Albecki
---
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 6 --
1 file changed, 4 insertions(+), 2 dele
performed:
-Boot eMMC in HS400
-Boot eMMC in HS400 with simulated CRC error on every first CMD13
Cc: Hao A Wu
Cc: Marcin Wojtas
Cc: Zhichao Gao
Cc: Liming Gao
Signed-off-by: Mateusz Albecki
Mateusz Albecki (4):
MdeModulePkg/SdMmcPciHcDxe: Fix DAT lane SW reset
MdeModulePkg/SdMmcPciHcDxe
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140
Error detection function will now check if the command
failure has been caused by one of the errors that can
appear randomly on link(CRC error + end bit error). If
such an error has been a cause of failure, function will
return EFI_CRC_ERROR
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140
To increase the resiliency driver will now attempt to
retry the commands that failed due to the CRC error up
to 5 times. This should address the problems with the commands
that fail due to random condition on links. This should also
help the
Driver used to reset the DAT lane on a current error which
is not required according to SD specification(it's not going
to help). This patch will reset the DAT lane only on DAT
lane specific errors.
Cc: Hao A Wu
Cc: Marcin Wojtas
Cc: Zhichao Gao
Cc: Liming Gao
Signed-off-by: Mateusz Albecki
8 AM
> To: Albecki, Mateusz ; devel@edk2.groups.io
> Cc: Marcin Wojtas ; Gao, Zhichao
> ; Gao, Liming
> Subject: RE: [PATCH 1/3] MdeModulePkg/SdMmcPciHcDxe: Refactor
> command error detection
>
> Hello Mateusz,
>
> Some inline comments below:
>
>
> > -
Changed @rtval to @retval in SdMmcHcStartSdClock
function description.
Cc: Hao A Wu
Signed-off-by: Mateusz Albecki
---
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 2 +-
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
lbecki, Mateusz
> Sent: Tuesday, January 7, 2020 12:06 PM
> To: devel@edk2.groups.io
> Cc: Albecki, Mateusz ; Wu, Hao A
> ; Marcin Wojtas ; Gao, Zhichao
> ; Gao, Liming
> Subject: [PATCH 0/3] MdeModulePkg/SdMmcPciHcDxe: Retry the
> commands that failed due to CRC error
>
> RE
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140
Error detection function will now check if the command
failure has been caused by one of the errors that can
appear randomly on link(CRC error + end bit error). If
such an error has been a cause of failure function will
return EFI_CRC_ERROR
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140
To increase the resiliency driver will now attempt to
retry the commands that failed due to the CRC error up
to 5 times. This should address the problems with the commands
that fail due to random condition on links. This should also
help the
This patch adds retries for async execution for commands that
failed due to the CRC errors.
Cc: Hao A Wu
Cc: Marcin Wojtas
Cc: Zhichao Gao
Cc: Liming Gao
Signed-off-by: Mateusz Albecki
---
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 6 --
1 file changed, 4 insertions(+), 2 dele
HS400 with simulated CRC error on every first CMD13
Cc: Hao A Wu
Cc: Marcin Wojtas
Cc: Zhichao Gao
Cc: Liming Gao
Signed-off-by: Mateusz Albecki
Mateusz Albecki (3):
MdeModulePkg/SdMmcPciHcDxe: Refactor command error detection
MdeModulePkg/SdMmcPciHcDxe: Add retries for sync commands
No problem with new subject from my side.
> -Original Message-
> From: Wu, Hao A
> Sent: Tuesday, December 24, 2019 3:52 AM
> To: Albecki, Mateusz ; devel@edk2.groups.io
> Cc: Marcin Wojtas ; Gao, Zhichao
> ; Gao, Liming ; Ard
> Biesheuvel
> Subject: RE: [PATCH
For eMMC modules we used to notify the platform about frequency
change only after sending CMD13 which meant that platform
might not get a chance to apply required post frequency
change fixes to get the clock stable. To fix this
notification has been moved to SdMmcHcClockSupply function
just after w
In SD card voltage switch flow we used to redo the
entire internal clock setup after voltage switch.
Since internal clock has already been setup this
is wasting time on polling the internal clock stable.
This commit changes it to only start the SD clock.
Cc: Hao A Wu
Cc: Marcin Wojtas
Cc: Zhicha
The first patch refactors the SdMmcClockSupply function with a goal
of sending the EdkiiSdMmcSwitchClockFreq notification before we send the
CMD13 to check the switch status in eMMC init flow. This is required to
avoid sending the CMD13 on link that still has not been fixed by platform.
To avoid c
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2218
Stopping the SD clock before switching host controller
bus timing is only neccessary 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 cloc
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2218
There is a bug in current driver code that makes
it impossible for it to work with devices that
only work in legacy speed mode since the function
EmmcSwitchToHighSpeed will return with EFI_INVALID_ARGUMENT
for such bus mode. Since the logic
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2218
SD specification recommends switching card bus timing before
switching bus timing in controller. Emmc driver used to do
this switch other way around. This commit adds controller
timing switch in EmmcSwitchBusTiming function to enforce this
o
eed. I suspect it is a hardware problem.
Tests performed on patch series v2:
-eMMC enumeration and OS boot in backwards compatible legacy timing.
Performed on single host controller and 2 eMMC devices(Samsung and SanDisk)
Cc: Hao A Wu
Cc: Marcin Wojtas
Albecki, Mateusz (3):
MdeModulePkg/S
> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, September 26, 2019 3:36 AM
> To: Albecki, Mateusz ; devel@edk2.groups.io
> Cc: Marcin Wojtas
> Subject: RE: [PATCH 1/1] MdeModulePkg/SdMmcPciHcDxe: Fix bus timing
> switch sequence
>
> > -
> -Original Message-
> From: Wu, Hao A
> Sent: Wednesday, September 25, 2019 5:34 AM
> To: Albecki, Mateusz ; devel@edk2.groups.io
> Cc: Marcin Wojtas
> Subject: RE: [PATCH 1/1] MdeModulePkg/SdMmcPciHcDxe: Fix bus timing
> switch sequence
>
> > -
SD specification recommends switching card bus timing before
switching bus timing in controller. Emmc driver used to do
this switch other way around. This commit adds controller
timing switch in EmmcSwitchBusTiming function to enforce this
order and removes all controller timing programing from
Emm
d. I suspect it is a hardware problem.
Cc: Hao A Wu
Cc: Marcin Wojtas
Albecki, Mateusz (1):
MdeModulePkg/SdMmcPciHcDxe: Fix bus timing switch sequence
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c | 54 +++--
1 file changed, 5 insertions(+), 49 deletions(-)
https://bugzilla.tianocore.org/show_bug.cgi?id=1343
Private data has been refactored to use EDKII_UFS_HC_INFO structure
to store host controller capabilities and version
information. Getting host controller data has been moved
into single place and is done before host controller enable.
Cc: Hao A
https://bugzilla.tianocore.org/show_bug.cgi?id=1343
This commit adds EDKII_UFS_HC_PLATFORM_PROTOCOL implementation
in UfsPassThruDxe driver in version 1. Driver assumes that at
most one instance of the protocol exists in the system. Presence
of the protocol is not mandatory.
Cc: Hao A Wu
Signed-
https://bugzilla.tianocore.org/show_bug.cgi?id=1343
UfsExecUicCommand function has been refactored to allow
the caller to check the command results which is important
for commands such as UIC read.
Cc: Hao A Wu
Signed-off-by: Mateusz Albecki
---
MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.
https://bugzilla.tianocore.org/show_bug.cgi?id=1343
EDKII_UFS_HC_PLATFORM_PROTOCOL will allow the platform to inject
platform specific logic into standard UFS flows. Right now we
support callbacks pre and post host controller enable and pre
and post link startup. Provided callbacks allow the platf
To cover additional host controller programming mentioned in the UFS
specification we have added an additional protocol that allows the UEFI driver
to give control to platform driver. This allows the platform to perform any
additional steps needed for the stable operation.
Changes in v3:
- UFS
Hi,
Please ignore this series. I have used wrong branch when generating patches. V3
will contain the fixes.
Thanks,
Mateusz
> -Original Message-
> From: Albecki, Mateusz
> Sent: Friday, August 9, 2019 2:21 PM
> To: devel@edk2.groups.io
> Cc: Albecki, Mateusz ; Wu, Hao
https://bugzilla.tianocore.org/show_bug.cgi?id=1343
This commit adds EDKII_UFS_HC_PLATFORM_PROTOCOL implementation
in UfsPassThruDxe driver in version 1. Driver assumes that at
most one instance of the protocol exists in the system. Presence
of the protocol is not mandatory.
Cc: Hao A Wu
Signed-
https://bugzilla.tianocore.org/show_bug.cgi?id=1343
EDKII_UFS_HC_PLATFORM_PROTOCOL will allow the platform to inject
platform specific logic into standard UFS flows. Right now we
support callbacks pre and post host controller enable and pre
and post link startup. We also allow the platform to over
https://bugzilla.tianocore.org/show_bug.cgi?id=1343
Private data has been refactored to use EDKII_UFS_HC_INFO structure
to store host controller capabilities and version
information. Getting host controller data has been moved
into single place and is done before host controller enable.
Cc: Hao A
https://bugzilla.tianocore.org/show_bug.cgi?id=1343
UfsExecUicCommand function has been refactored to allow
the caller to check the command results which is important
for commands such as UIC read.
Cc: Hao A Wu
Signed-off-by: Mateusz Albecki
---
MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.
To cover additional host controller programming mentioned in the UFS
specification we have added an additional protocol
that allows the UEFI driver to give control to platform driver. This allows the
platform to perform any additional
steps needed for the stable operation.
Changes in v2:
- UFS d
Hi,
Yes that is bug. It should be placed before return EFI_SUCCESS. I will fix it
in v2.
Thanks,
Mateusz
> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, August 8, 2019 4:37 AM
> To: Albecki, Mateusz ; devel@edk2.groups.io
> Subject: RE: [PATCH 4/4] MdeModulePkg
Hi,
Sure I agree. That was my original intention and then I forgot to add goto
Error.
Thanks,
Mateusz
> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, August 8, 2019 4:37 AM
> To: devel@edk2.groups.io; Albecki, Mateusz
> Subject: RE: [edk2-devel] [PATCH 3/
https://bugzilla.tianocore.org/show_bug.cgi?id=1343
This commit adds EDKII_UFS_HC_PLATFORM_PROTOCOL implementation
in UfsPassThruDxe driver in version 1. Driver assumes that at
most one instance of the protocol exists in the system. Presence
of the protocol is not mandatory.
Cc: Hao A Wu
Signed-
https://bugzilla.tianocore.org/show_bug.cgi?id=1343
UfsExecUicCommand function has been refactored to allow
the caller to check the command results which is important
for commands such as UIC read.
Cc: Hao A Wu
Signed-off-by: Mateusz Albecki
---
MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.
https://bugzilla.tianocore.org/show_bug.cgi?id=1343
Private data has been refactored to use EDKII_UFS_HC_INFO structure
to store host controller capabilities and version
information. Getting host controller data has been moved
into single place and is done before host controller enable.
Cc: Hao A
https://bugzilla.tianocore.org/show_bug.cgi?id=1343
EDKII_UFS_HC_PLATFORM_PROTOCOL will allow the platform to inject
platform specific logic into standard UFS flows. Right now we
support callbacks pre and post host controller enable and pre
and post link startup. Provided callbacks allow the platf
To cover additional host controller programming mentioned in the UFS
specification
we have added an additional protocol that allows the UEFI driver to give control
to platform driver. This allows the platform to perform any additional steps
needed for the stable operation.
Test coverage:
Tested o
.groups.io] On Behalf Of Marcin
Wojtas
Sent: Friday, June 28, 2019 9:42 AM
To: Wu, Hao A
Cc: Albecki, Mateusz ; Sumit Garg
; Ard Biesheuvel ;
edk2-devel-groups-io
Subject: Re: [edk2-devel] [PATCH v4 0/2] MdeModulePkg/SdMmcHcDxe: Implement
revision 3 of SdMmcOverrideProtocol
Hi Hao,
pt., 28 cze
https://bugzilla.tianocore.org/show_bug.cgi?id=1882
The new notify phase allows platform to configure additional
bus paramters in addition to parameters that can already be configured
with capability override. Specifically we allow to configure bus width,
clock frequency and driver strength. If pl
1 - 100 of 123 matches
Mail list logo
