[RFC PATCH 0/2] quirks handling for SDHCI controllers

[RFC PATCH 0/2] quirks handling for SDHCI controllers

[Ard Biesheuvel]

Many SDHCI implementations exist that are almost spec complicant, and
could be driver by the generic SD/MMC host controller driver except
for some minimal necessary init time tweaks.

Adding such tweaks to the generic driver is undesirable. On the other
hand, forking the driver for every platform that has such a SDHCI
controller is problematic when it comes to upstreaming and ongoing
maintenance (which is arguably the point of upstreaming in the first
place).

So these patches propose a workaround that is minimally invasive on the
EDK2 side, but gives platforms a lot of leeway when it comes to applying
SDHCI quirks.

Ard Biesheuvel (2):
  MdeModulePkg: introduce SD/MMC override protocol
  MdeModulePkg/SdMmcPciHcDxe: allow HC capabilities to be overridden

 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c   | 111 +++++++++++++++++++-
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h   |   6 ++
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf |   2 +
 MdeModulePkg/Include/Protocol/SdMmcOverride.h        |  95 +++++++++++++++++
 MdeModulePkg/MdeModulePkg.dec                        |   3 +
 5 files changed, 212 insertions(+), 5 deletions(-)
 create mode 100644 MdeModulePkg/Include/Protocol/SdMmcOverride.h

-- 
2.11.0

[RFC PATCH 1/2] MdeModulePkg: introduce SD/MMC override protocol

[Ard Biesheuvel]

Many ARM based SoCs have integrated SDHCI controllers, and often,
these implementations deviate in subtle ways from the pertinent
specifications. On the one hand, these deviations are quite easy
to work around, but on the other hand, having a collection of SoC
specific workarounds in the generic driver stack is undesirable.

So let's introduce an optional SD/MMC override protocol that we
can invoke at the appropriate moments in the device initialization.
That way, the workaround itself remains platform specific, but we
can still use the generic driver stack on such platforms.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 MdeModulePkg/Include/Protocol/SdMmcOverride.h | 95 ++++++++++++++++++++
 MdeModulePkg/MdeModulePkg.dec                 |  3 +
 2 files changed, 98 insertions(+)

diff --git a/MdeModulePkg/Include/Protocol/SdMmcOverride.h b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
new file mode 100644
index 000000000000..95fc48bb8dee
--- /dev/null
+++ b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
@@ -0,0 +1,95 @@
+/** @file
+  Protocol to describe overrides required to support non-standard SDHCI
+  implementations
+
+  Copyright (c) 2017, Linaro, Ltd. All rights reserved.<BR>
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD License
+  which accompanies this distribution.  The full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __SD_MMC_OVERRIDE_H__
+#define __SD_MMC_OVERRIDE_H__
+
+#define EDKII_SD_MMC_OVERRIDE_PROTOCOL_GUID \
+  { 0xeaf9e3c1, 0xc9cd, 0x46db, { 0xa5, 0xe5, 0x5a, 0x12, 0x4c, 0x83, 0x23, 0x23 } }
+
+#define EDKII_SD_MMC_OVERRIDE_PROTOCOL_VERSION    0x1
+
+typedef struct _SD_MMC_OVERRIDE SD_MMC_OVERRIDE;
+
+typedef enum {
+  SD_MMC_OVERRIDE_RESET_PRE_HOOK,
+  SD_MMC_OVERRIDE_RESET_POST_HOOK,
+  SD_MMC_OVERRIDE_INIT_HOST_PRE_HOOK,
+  SD_MMC_OVERRIDE_INIT_HOST_POST_HOOK,
+} SD_MMC_OVERRIDE_HOOK;
+
+/**
+
+  Override function for SDHCI capability bits
+
+  @param[in]      ControllerHandle          The EFI_HANDLE of the controller.
+  @param[in]      Slot                      The 0 based slot index.
+  @param[in,out]  SdMmcHcSlotCapability     The SDHCI capability structure.
+
+  @retval EFI_SUCCESS           The override function completed successfully.
+  @retval EFI_NOT_FOUND         The specified controller or slot does not exist.
+  @retval EFI_INVALID_PARAMETER SdMmcHcSlotCapability is NULL
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI * SD_MMC_OVERRIDE_CAPABILITY) (
+  IN      EFI_HANDLE              ControllerHandle,
+  IN      UINT8                   Slot,
+  IN  OUT VOID                    *SdMmcHcSlotCapability
+  );
+
+/**
+
+  Override function for SDHCI controller operations
+
+  @param[in]      ControllerHandle    The EFI_HANDLE of the controller.
+  @param[in]      Slot                The 0 based slot index.
+  @param[in,out]  HookType            The type of operation and whether the
+                                      hook is invoked right before (pre) or
+                                      right after (post)
+
+  @retval EFI_SUCCESS           The override function completed successfully.
+  @retval EFI_NOT_FOUND         The specified controller or slot does not exist.
+  @retval EFI_INVALID_PARAMETER HookType is invalid
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI * SD_MMC_OVERRIDE_INVOKE_HOOK) (
+  IN      EFI_HANDLE              ControllerHandle,
+  IN      UINT8                   Slot,
+  IN      SD_MMC_OVERRIDE_HOOK    HookType
+  );
+
+struct _SD_MMC_OVERRIDE {
+  //
+  // Protocol version of this implementation
+  //
+  UINTN                           Version;
+  //
+  // Callback to override SD/MMC host controller capability bits
+  //
+  SD_MMC_OVERRIDE_CAPABILITY      OverrideCapability;
+  //
+  // Callback to invoke SD/MMC override hooks
+  //
+  SD_MMC_OVERRIDE_INVOKE_HOOK     InvokeHook;
+};
+
+extern EFI_GUID gEdkiiSdMmcOverrideProtocolGuid;
+
+#endif
diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 92ee02708013..d14326199591 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -559,6 +559,9 @@ [Protocols]
   ## Include/Protocol/SmmEndofS3Resume.h
   gEdkiiSmmEndOfS3ResumeProtocolGuid = { 0x96f5296d, 0x05f7, 0x4f3c, {0x84, 0x67, 0xe4, 0x56, 0x89, 0x0e, 0x0c, 0xb5 } }
 
+  ## Include/Protocol/SdMmcOverride.h
+  gEdkiiSdMmcOverrideProtocolGuid = { 0xeaf9e3c1, 0xc9cd, 0x46db, { 0xa5, 0xe5, 0x5a, 0x12, 0x4c, 0x83, 0x23, 0x23 } }
+
 #
 # [Error.gEfiMdeModulePkgTokenSpaceGuid]
 #   0x80000001 | Invalid value provided.
-- 
2.11.0

[RFC PATCH 2/2] MdeModulePkg/SdMmcPciHcDxe: allow HC capabilities to be overridden

[Ard Biesheuvel]

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>
---
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c   | 111 +++++++++++++++++++-
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h   |   6 ++
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf |   2 +
 3 files changed, 114 insertions(+), 5 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
index 0be8828abfcc..d328e9f867c4 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
@@ -60,7 +60,8 @@ SD_MMC_HC_PRIVATE_DATA gSdMmcPciHcTemplate = {
   {                                 // MaxCurrent
     0,
   },
-  0                                 // ControllerVersion
+  0,                                // ControllerVersion
+  NULL                              // Override
 };
 
 SD_DEVICE_PATH    mSdDpTemplate = {
@@ -213,6 +214,88 @@ Done:
   return;
 }
 
+STATIC
+EFI_STATUS
+SdMmcPciHcResetHost (
+  IN  SD_MMC_HC_PRIVATE_DATA          *Private,
+  IN  UINT8                           Slot
+  )
+{
+  EFI_STATUS    Status;
+
+  if (Private->Override != NULL &&
+      Private->Override->InvokeHook != NULL) {
+    Status = Private->Override->InvokeHook (
+                                  Private->ControllerHandle,
+                                  Slot,
+                                  SD_MMC_OVERRIDE_RESET_PRE_HOOK);
+    if (EFI_ERROR (Status)) {
+      DEBUG ((DEBUG_WARN, "%a: SD/MMC pre reset hook failed - %r\n",
+        __FUNCTION__, Status));
+      return Status;
+    }
+  }
+
+  Status = SdMmcHcReset (Private->PciIo, Slot);
+  if (EFI_ERROR (Status)) {
+    return Status;
+  }
+
+  if (Private->Override != NULL &&
+      Private->Override->InvokeHook != NULL) {
+    Status = Private->Override->InvokeHook (
+                                  Private->ControllerHandle,
+                                  Slot,
+                                  SD_MMC_OVERRIDE_RESET_POST_HOOK);
+    if (EFI_ERROR (Status)) {
+      DEBUG ((DEBUG_WARN, "%a: SD/MMC post reset hook failed - %r\n",
+        __FUNCTION__, Status));
+    }
+  }
+  return Status;
+}
+
+STATIC
+EFI_STATUS
+SdMmcPciHcInitHost (
+  IN  SD_MMC_HC_PRIVATE_DATA          *Private,
+  IN  UINT8                           Slot
+  )
+{
+  EFI_STATUS    Status;
+
+  if (Private->Override != NULL &&
+      Private->Override->InvokeHook != NULL) {
+    Status = Private->Override->InvokeHook (
+                                  Private->ControllerHandle,
+                                  Slot,
+                                  SD_MMC_OVERRIDE_INIT_HOST_PRE_HOOK);
+    if (EFI_ERROR (Status)) {
+      DEBUG ((DEBUG_WARN, "%a: SD/MMC pre init hook failed - %r\n",
+        __FUNCTION__, Status));
+      return Status;
+    }
+  }
+
+  Status = SdMmcHcInitHost (Private->PciIo, Slot, Private->Capability[Slot]);
+  if (EFI_ERROR (Status)) {
+    return Status;
+  }
+
+  if (Private->Override != NULL &&
+      Private->Override->InvokeHook != NULL) {
+    Status = Private->Override->InvokeHook (
+                                  Private->ControllerHandle,
+                                  Slot,
+                                  SD_MMC_OVERRIDE_INIT_HOST_POST_HOOK);
+    if (EFI_ERROR (Status)) {
+      DEBUG ((DEBUG_WARN, "%a: SD/MMC post init hook failed - %r\n",
+        __FUNCTION__, Status));
+    }
+  }
+  return Status;
+}
+
 /**
   Sd removable device enumeration callback function when the timer event is signaled.
 
@@ -281,14 +364,14 @@ SdMmcPciHcEnumerateDevice (
         //
         // Reset the specified slot of the SD/MMC Pci Host Controller
         //
-        Status = SdMmcHcReset (Private->PciIo, Slot);
+        Status = SdMmcPciHcResetHost (Private, Slot);
         if (EFI_ERROR (Status)) {
           continue;
         }
         //
         // Reinitialize slot and restart identification process for the new attached device
         //
-        Status = SdMmcHcInitHost (Private->PciIo, Slot, Private->Capability[Slot]);
+        Status = SdMmcPciHcInitHost (Private, Slot);
         if (EFI_ERROR (Status)) {
           continue;
         }
@@ -601,6 +684,12 @@ SdMmcPciHcDriverBindingStart (
     goto Done;
   }
 
+  Status = gBS->HandleProtocol (Controller, &gEdkiiSdMmcOverrideProtocolGuid,
+                  (VOID **)&Private->Override);
+  if (!EFI_ERROR (Status)) {
+    DEBUG ((DEBUG_INFO, "%a: using SD/MMC override protocol\n", __FUNCTION__));
+  }
+
   Support64BitDma = TRUE;
   for (Slot = FirstBar; Slot < (FirstBar + SlotNum); Slot++) {
     Private->Slot[Slot].Enable = TRUE;
@@ -609,6 +698,18 @@ SdMmcPciHcDriverBindingStart (
     if (EFI_ERROR (Status)) {
       continue;
     }
+    if (Private->Override != NULL &&
+        Private->Override->OverrideCapability != NULL) {
+      Status = Private->Override->OverrideCapability (
+                                    Controller,
+                                    Slot,
+                                    &Private->Capability[Slot]);
+      if (EFI_ERROR (Status)) {
+        DEBUG ((DEBUG_WARN, "%a: Failed to override capability - %r\n",
+          __FUNCTION__, Status));
+        continue;
+      }
+    }
     DumpCapabilityReg (Slot, &Private->Capability[Slot]);
 
     Support64BitDma &= Private->Capability[Slot].SysBus64;
@@ -627,7 +728,7 @@ SdMmcPciHcDriverBindingStart (
     //
     // Reset the specified slot of the SD/MMC Pci Host Controller
     //
-    Status = SdMmcHcReset (PciIo, Slot);
+    Status = SdMmcPciHcResetHost (Private, Slot);
     if (EFI_ERROR (Status)) {
       continue;
     }
@@ -642,7 +743,7 @@ SdMmcPciHcDriverBindingStart (
       continue;
     }
 
-    Status = SdMmcHcInitHost (PciIo, Slot, Private->Capability[Slot]);
+    Status = SdMmcPciHcInitHost (Private, Slot);
     if (EFI_ERROR (Status)) {
       continue;
     }
diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
index 6a2a27969936..b51e0529f885 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
@@ -35,6 +35,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 #include <Protocol/DriverBinding.h>
 #include <Protocol/ComponentName.h>
 #include <Protocol/ComponentName2.h>
+#include <Protocol/SdMmcOverride.h>
 #include <Protocol/SdMmcPassThru.h>
 
 #include "SdMmcPciHci.h"
@@ -115,6 +116,11 @@ typedef struct {
   UINT64                              MaxCurrent[SD_MMC_HC_MAX_SLOT];
 
   UINT32                              ControllerVersion;
+
+  //
+  // Optional protocol to deal with non-standard SDHCI implementations
+  //
+  SD_MMC_OVERRIDE                     *Override;
 } SD_MMC_HC_PRIVATE_DATA;
 
 #define SD_MMC_HC_TRB_SIG             SIGNATURE_32 ('T', 'R', 'B', 'T')
diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf
index e26e6a098c17..154ce45d8223 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf
@@ -48,6 +48,7 @@ [Sources]
 
 [Packages]
   MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
 
 [LibraryClasses]
   DevicePathLib
@@ -61,6 +62,7 @@ [LibraryClasses]
   DebugLib
 
 [Protocols]
+  gEdkiiSdMmcOverrideProtocolGuid               ## SOMETIMES_CONSUMES
   gEfiDevicePathProtocolGuid                    ## TO_START
   gEfiPciIoProtocolGuid                         ## TO_START
   gEfiSdMmcPassThruProtocolGuid                 ## BY_START
-- 
2.11.0

Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers

[Zeng, Star]

Hao,

Could you help do the evaluation on this RFC?


Thanks,
Star
-----Original Message-----
From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] 
Sent: Friday, November 10, 2017 9:59 PM
To: edk2-devel@lists.01.org; leif.lindholm@linaro.org; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>; Tian, Feng <feng.tian@intel.com>; Dong, Eric <eric.dong@intel.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: [RFC PATCH 0/2] quirks handling for SDHCI controllers

Many SDHCI implementations exist that are almost spec complicant, and could be driver by the generic SD/MMC host controller driver except for some minimal necessary init time tweaks.

Adding such tweaks to the generic driver is undesirable. On the other hand, forking the driver for every platform that has such a SDHCI controller is problematic when it comes to upstreaming and ongoing maintenance (which is arguably the point of upstreaming in the first place).

So these patches propose a workaround that is minimally invasive on the
EDK2 side, but gives platforms a lot of leeway when it comes to applying SDHCI quirks.

Ard Biesheuvel (2):
  MdeModulePkg: introduce SD/MMC override protocol
  MdeModulePkg/SdMmcPciHcDxe: allow HC capabilities to be overridden

 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c   | 111 +++++++++++++++++++-
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h   |   6 ++
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf |   2 +
 MdeModulePkg/Include/Protocol/SdMmcOverride.h        |  95 +++++++++++++++++
 MdeModulePkg/MdeModulePkg.dec                        |   3 +
 5 files changed, 212 insertions(+), 5 deletions(-)  create mode 100644 MdeModulePkg/Include/Protocol/SdMmcOverride.h

--
2.11.0

Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers

[Wu, Hao A]

> -----Original Message-----
> From: Zeng, Star
> Sent: Monday, November 13, 2017 11:32 AM
> To: Wu, Hao A; Ard Biesheuvel; edk2-devel@lists.01.org;
> leif.lindholm@linaro.org; Kinney, Michael D
> Cc: Gao, Liming; Tian, Feng; Dong, Eric; Zeng, Star
> Subject: RE: [RFC PATCH 0/2] quirks handling for SDHCI controllers
> 
> Hao,
> 
> Could you help do the evaluation on this RFC?

Sure, I will take a look on this.

Best Regards,
Hao Wu

> 
> 
> Thanks,
> Star
> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: Friday, November 10, 2017 9:59 PM
> To: edk2-devel@lists.01.org; leif.lindholm@linaro.org; Kinney, Michael D
> <michael.d.kinney@intel.com>
> Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>;
> Tian, Feng <feng.tian@intel.com>; Dong, Eric <eric.dong@intel.com>; Ard
> Biesheuvel <ard.biesheuvel@linaro.org>
> Subject: [RFC PATCH 0/2] quirks handling for SDHCI controllers
> 
> Many SDHCI implementations exist that are almost spec complicant, and could
> be driver by the generic SD/MMC host controller driver except for some
> minimal necessary init time tweaks.
> 
> Adding such tweaks to the generic driver is undesirable. On the other hand,
> forking the driver for every platform that has such a SDHCI controller is
> problematic when it comes to upstreaming and ongoing maintenance (which is
> arguably the point of upstreaming in the first place).
> 
> So these patches propose a workaround that is minimally invasive on the
> EDK2 side, but gives platforms a lot of leeway when it comes to applying SDHCI
> quirks.
> 
> Ard Biesheuvel (2):
>   MdeModulePkg: introduce SD/MMC override protocol
>   MdeModulePkg/SdMmcPciHcDxe: allow HC capabilities to be overridden
> 
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c   | 111
> +++++++++++++++++++-
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h   |   6 ++
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf |   2 +
>  MdeModulePkg/Include/Protocol/SdMmcOverride.h        |  95
> +++++++++++++++++
>  MdeModulePkg/MdeModulePkg.dec                        |   3 +
>  5 files changed, 212 insertions(+), 5 deletions(-)  create mode 100644
> MdeModulePkg/Include/Protocol/SdMmcOverride.h
> 
> --
> 2.11.0

Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers

[Ard Biesheuvel]

On 13 November 2017 at 03:37, Wu, Hao A <hao.a.wu@intel.com> wrote:
>> -----Original Message-----
>> From: Zeng, Star
>> Sent: Monday, November 13, 2017 11:32 AM
>> To: Wu, Hao A; Ard Biesheuvel; edk2-devel@lists.01.org;
>> leif.lindholm@linaro.org; Kinney, Michael D
>> Cc: Gao, Liming; Tian, Feng; Dong, Eric; Zeng, Star
>> Subject: RE: [RFC PATCH 0/2] quirks handling for SDHCI controllers
>>
>> Hao,
>>
>> Could you help do the evaluation on this RFC?
>
> Sure, I will take a look on this.
>

Any feedback?

Thanks,
Ard.

Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers

[Wu, Hao A]

> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: Thursday, November 23, 2017 6:11 PM
> To: Wu, Hao A
> Cc: Zeng, Star; edk2-devel@lists.01.org; leif.lindholm@linaro.org; Kinney,
> Michael D; Gao, Liming; Tian, Feng; Dong, Eric
> Subject: Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers
> 
> On 13 November 2017 at 03:37, Wu, Hao A <hao.a.wu@intel.com> wrote:
> >> -----Original Message-----
> >> From: Zeng, Star
> >> Sent: Monday, November 13, 2017 11:32 AM
> >> To: Wu, Hao A; Ard Biesheuvel; edk2-devel@lists.01.org;
> >> leif.lindholm@linaro.org; Kinney, Michael D
> >> Cc: Gao, Liming; Tian, Feng; Dong, Eric; Zeng, Star
> >> Subject: RE: [RFC PATCH 0/2] quirks handling for SDHCI controllers
> >>
> >> Hao,
> >>
> >> Could you help do the evaluation on this RFC?
> >
> > Sure, I will take a look on this.
> >
> 
> Any feedback?
> 

Hi Ard,

Sorry for the delayed response.

I am still collecting feedbacks internally to see if there are additional hook
points needed or other features/services that can be added to the SD/MMC
override protocol.

I think it would be better for this protocol to be general when it is
introduced, which might avoid changing the protocol frequently later.

What is your thought on this? Thanks in advance.

Best Regards,
Hao Wu

> Thanks,
> Ard.

Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers

[Ard Biesheuvel]

On 23 November 2017 at 12:55, Wu, Hao A <hao.a.wu@intel.com> wrote:
>> -----Original Message-----
>> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
>> Sent: Thursday, November 23, 2017 6:11 PM
>> To: Wu, Hao A
>> Cc: Zeng, Star; edk2-devel@lists.01.org; leif.lindholm@linaro.org; Kinney,
>> Michael D; Gao, Liming; Tian, Feng; Dong, Eric
>> Subject: Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers
>>
>> On 13 November 2017 at 03:37, Wu, Hao A <hao.a.wu@intel.com> wrote:
>> >> -----Original Message-----
>> >> From: Zeng, Star
>> >> Sent: Monday, November 13, 2017 11:32 AM
>> >> To: Wu, Hao A; Ard Biesheuvel; edk2-devel@lists.01.org;
>> >> leif.lindholm@linaro.org; Kinney, Michael D
>> >> Cc: Gao, Liming; Tian, Feng; Dong, Eric; Zeng, Star
>> >> Subject: RE: [RFC PATCH 0/2] quirks handling for SDHCI controllers
>> >>
>> >> Hao,
>> >>
>> >> Could you help do the evaluation on this RFC?
>> >
>> > Sure, I will take a look on this.
>> >
>>
>> Any feedback?
>>
>
> Hi Ard,
>
> Sorry for the delayed response.
>
> I am still collecting feedbacks internally to see if there are additional hook
> points needed or other features/services that can be added to the SD/MMC
> override protocol.
>
> I think it would be better for this protocol to be general when it is
> introduced, which might avoid changing the protocol frequently later.
>
> What is your thought on this?

Thank you for bringing this up internally. I agree that we should
carefully consider potential use cases now and not later.

Thanks,
Ard.

Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers

[Wu, Hao A]

> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: Thursday, November 23, 2017 8:57 PM
> To: Wu, Hao A
> Cc: Zeng, Star; edk2-devel@lists.01.org; leif.lindholm@linaro.org; Kinney,
> Michael D; Gao, Liming; Tian, Feng; Dong, Eric
> Subject: Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers
> 
> On 23 November 2017 at 12:55, Wu, Hao A <hao.a.wu@intel.com> wrote:
> >> -----Original Message-----
> >> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> >> Sent: Thursday, November 23, 2017 6:11 PM
> >> To: Wu, Hao A
> >> Cc: Zeng, Star; edk2-devel@lists.01.org; leif.lindholm@linaro.org; Kinney,
> >> Michael D; Gao, Liming; Tian, Feng; Dong, Eric
> >> Subject: Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers
> >>
> >> On 13 November 2017 at 03:37, Wu, Hao A <hao.a.wu@intel.com> wrote:
> >> >> -----Original Message-----
> >> >> From: Zeng, Star
> >> >> Sent: Monday, November 13, 2017 11:32 AM
> >> >> To: Wu, Hao A; Ard Biesheuvel; edk2-devel@lists.01.org;
> >> >> leif.lindholm@linaro.org; Kinney, Michael D
> >> >> Cc: Gao, Liming; Tian, Feng; Dong, Eric; Zeng, Star
> >> >> Subject: RE: [RFC PATCH 0/2] quirks handling for SDHCI controllers
> >> >>
> >> >> Hao,
> >> >>
> >> >> Could you help do the evaluation on this RFC?
> >> >
> >> > Sure, I will take a look on this.
> >> >
> >>
> >> Any feedback?
> >>
> >
> > Hi Ard,
> >
> > Sorry for the delayed response.
> >
> > I am still collecting feedbacks internally to see if there are additional hook
> > points needed or other features/services that can be added to the SD/MMC
> > override protocol.
> >
> > I think it would be better for this protocol to be general when it is
> > introduced, which might avoid changing the protocol frequently later.
> >
> > What is your thought on this?
> 
> Thank you for bringing this up internally. I agree that we should
> carefully consider potential use cases now and not later.

Hi Ard,

Could you help to share an code example of the consumer of this protocol
for reference?

Also, we think that it might be helpful to pass the pointer of the
EFI_SD_MMC_PASS_THRU_PROTOCOL to the SD_MMC_OVERRIDE_INVOKE_HOOK service
as an additional input parameter:

typedef
EFI_STATUS
(EFIAPI * SD_MMC_OVERRIDE_INVOKE_HOOK) (
  IN      EFI_HANDLE                       ControllerHandle,
  IN      UINT8                            Slot,
  IN      SD_MMC_OVERRIDE_HOOK             HookType,
  IN      EFI_SD_MMC_PASS_THRU_PROTOCOL    PassThru
  );

The implementation of the service can decide whether to use the PassThru
protocol.

If more hook points will be later added to the SDHCI override protocol,
they may use the EFI_SD_MMC_PASS_THRU_PROTOCOL to send additional commands
to the host controller during initialization.

Best Regards,
Hao Wu

> 
> Thanks,
> Ard.

Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers

[Wu, Hao A]

Fix one typo in previous reply.

Best Regards,
Hao Wu

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Wu,
> Hao A
> Sent: Thursday, November 30, 2017 10:11 AM
> To: Ard Biesheuvel
> Cc: Tian, Feng; Dong, Eric; edk2-devel@lists.01.org; Gao, Liming;
> leif.lindholm@linaro.org; Kinney, Michael D; Zeng, Star
> Subject: Re: [edk2] [RFC PATCH 0/2] quirks handling for SDHCI controllers
> 
> > -----Original Message-----
> > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> > Sent: Thursday, November 23, 2017 8:57 PM
> > To: Wu, Hao A
> > Cc: Zeng, Star; edk2-devel@lists.01.org; leif.lindholm@linaro.org; Kinney,
> > Michael D; Gao, Liming; Tian, Feng; Dong, Eric
> > Subject: Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers
> >
> > On 23 November 2017 at 12:55, Wu, Hao A <hao.a.wu@intel.com> wrote:
> > >> -----Original Message-----
> > >> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> > >> Sent: Thursday, November 23, 2017 6:11 PM
> > >> To: Wu, Hao A
> > >> Cc: Zeng, Star; edk2-devel@lists.01.org; leif.lindholm@linaro.org; Kinney,
> > >> Michael D; Gao, Liming; Tian, Feng; Dong, Eric
> > >> Subject: Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers
> > >>
> > >> On 13 November 2017 at 03:37, Wu, Hao A <hao.a.wu@intel.com> wrote:
> > >> >> -----Original Message-----
> > >> >> From: Zeng, Star
> > >> >> Sent: Monday, November 13, 2017 11:32 AM
> > >> >> To: Wu, Hao A; Ard Biesheuvel; edk2-devel@lists.01.org;
> > >> >> leif.lindholm@linaro.org; Kinney, Michael D
> > >> >> Cc: Gao, Liming; Tian, Feng; Dong, Eric; Zeng, Star
> > >> >> Subject: RE: [RFC PATCH 0/2] quirks handling for SDHCI controllers
> > >> >>
> > >> >> Hao,
> > >> >>
> > >> >> Could you help do the evaluation on this RFC?
> > >> >
> > >> > Sure, I will take a look on this.
> > >> >
> > >>
> > >> Any feedback?
> > >>
> > >
> > > Hi Ard,
> > >
> > > Sorry for the delayed response.
> > >
> > > I am still collecting feedbacks internally to see if there are additional hook
> > > points needed or other features/services that can be added to the SD/MMC
> > > override protocol.
> > >
> > > I think it would be better for this protocol to be general when it is
> > > introduced, which might avoid changing the protocol frequently later.
> > >
> > > What is your thought on this?
> >
> > Thank you for bringing this up internally. I agree that we should
> > carefully consider potential use cases now and not later.
> 
> Hi Ard,
> 
> Could you help to share an code example of the consumer of this protocol

Producer (not consumer) of the protocol actually.

> for reference?
> 
> Also, we think that it might be helpful to pass the pointer of the
> EFI_SD_MMC_PASS_THRU_PROTOCOL to the
> SD_MMC_OVERRIDE_INVOKE_HOOK service
> as an additional input parameter:
> 
> typedef
> EFI_STATUS
> (EFIAPI * SD_MMC_OVERRIDE_INVOKE_HOOK) (
>   IN      EFI_HANDLE                       ControllerHandle,
>   IN      UINT8                            Slot,
>   IN      SD_MMC_OVERRIDE_HOOK             HookType,
>   IN      EFI_SD_MMC_PASS_THRU_PROTOCOL    PassThru
>   );
> 
> The implementation of the service can decide whether to use the PassThru
> protocol.
> 
> If more hook points will be later added to the SDHCI override protocol,
> they may use the EFI_SD_MMC_PASS_THRU_PROTOCOL to send additional
> commands
> to the host controller during initialization.
> 
> Best Regards,
> Hao Wu
> 
> >
> > Thanks,
> > Ard.
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers

[Zeng, Star]

Hao,

  IN      EFI_SD_MMC_PASS_THRU_PROTOCOL    *PassThru

Right?

Thanks,
Star
-----Original Message-----
From: Wu, Hao A 
Sent: Thursday, November 30, 2017 10:11 AM
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Zeng, Star <star.zeng@intel.com>; edk2-devel@lists.01.org; leif.lindholm@linaro.org; Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming <liming.gao@intel.com>; Tian, Feng <feng.tian@intel.com>; Dong, Eric <eric.dong@intel.com>
Subject: RE: [RFC PATCH 0/2] quirks handling for SDHCI controllers

> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: Thursday, November 23, 2017 8:57 PM
> To: Wu, Hao A
> Cc: Zeng, Star; edk2-devel@lists.01.org; leif.lindholm@linaro.org; 
> Kinney, Michael D; Gao, Liming; Tian, Feng; Dong, Eric
> Subject: Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers
> 
> On 23 November 2017 at 12:55, Wu, Hao A <hao.a.wu@intel.com> wrote:
> >> -----Original Message-----
> >> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> >> Sent: Thursday, November 23, 2017 6:11 PM
> >> To: Wu, Hao A
> >> Cc: Zeng, Star; edk2-devel@lists.01.org; leif.lindholm@linaro.org; 
> >> Kinney, Michael D; Gao, Liming; Tian, Feng; Dong, Eric
> >> Subject: Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers
> >>
> >> On 13 November 2017 at 03:37, Wu, Hao A <hao.a.wu@intel.com> wrote:
> >> >> -----Original Message-----
> >> >> From: Zeng, Star
> >> >> Sent: Monday, November 13, 2017 11:32 AM
> >> >> To: Wu, Hao A; Ard Biesheuvel; edk2-devel@lists.01.org; 
> >> >> leif.lindholm@linaro.org; Kinney, Michael D
> >> >> Cc: Gao, Liming; Tian, Feng; Dong, Eric; Zeng, Star
> >> >> Subject: RE: [RFC PATCH 0/2] quirks handling for SDHCI 
> >> >> controllers
> >> >>
> >> >> Hao,
> >> >>
> >> >> Could you help do the evaluation on this RFC?
> >> >
> >> > Sure, I will take a look on this.
> >> >
> >>
> >> Any feedback?
> >>
> >
> > Hi Ard,
> >
> > Sorry for the delayed response.
> >
> > I am still collecting feedbacks internally to see if there are 
> > additional hook points needed or other features/services that can be 
> > added to the SD/MMC override protocol.
> >
> > I think it would be better for this protocol to be general when it 
> > is introduced, which might avoid changing the protocol frequently later.
> >
> > What is your thought on this?
> 
> Thank you for bringing this up internally. I agree that we should 
> carefully consider potential use cases now and not later.

Hi Ard,

Could you help to share an code example of the consumer of this protocol for reference?

Also, we think that it might be helpful to pass the pointer of the EFI_SD_MMC_PASS_THRU_PROTOCOL to the SD_MMC_OVERRIDE_INVOKE_HOOK service as an additional input parameter:

typedef
EFI_STATUS
(EFIAPI * SD_MMC_OVERRIDE_INVOKE_HOOK) (
  IN      EFI_HANDLE                       ControllerHandle,
  IN      UINT8                            Slot,
  IN      SD_MMC_OVERRIDE_HOOK             HookType,
  IN      EFI_SD_MMC_PASS_THRU_PROTOCOL    PassThru
  );

The implementation of the service can decide whether to use the PassThru protocol.

If more hook points will be later added to the SDHCI override protocol, they may use the EFI_SD_MMC_PASS_THRU_PROTOCOL to send additional commands to the host controller during initialization.

Best Regards,
Hao Wu

> 
> Thanks,
> Ard.

Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers

[Wu, Hao A]

> -----Original Message-----
> From: Zeng, Star
> Sent: Thursday, November 30, 2017 10:15 AM
> To: Wu, Hao A; Ard Biesheuvel
> Cc: edk2-devel@lists.01.org; leif.lindholm@linaro.org; Kinney, Michael D; Gao,
> Liming; Tian, Feng; Dong, Eric; Zeng, Star
> Subject: RE: [RFC PATCH 0/2] quirks handling for SDHCI controllers
> 
> Hao,
> 
>   IN      EFI_SD_MMC_PASS_THRU_PROTOCOL    *PassThru
> 
> Right?

Yes. Sorry for the typo.

Best Regards,
Hao Wu

> 
> Thanks,
> Star
> -----Original Message-----
> From: Wu, Hao A
> Sent: Thursday, November 30, 2017 10:11 AM
> To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Zeng, Star <star.zeng@intel.com>; edk2-devel@lists.01.org;
> leif.lindholm@linaro.org; Kinney, Michael D <michael.d.kinney@intel.com>;
> Gao, Liming <liming.gao@intel.com>; Tian, Feng <feng.tian@intel.com>; Dong,
> Eric <eric.dong@intel.com>
> Subject: RE: [RFC PATCH 0/2] quirks handling for SDHCI controllers
> 
> > -----Original Message-----
> > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> > Sent: Thursday, November 23, 2017 8:57 PM
> > To: Wu, Hao A
> > Cc: Zeng, Star; edk2-devel@lists.01.org; leif.lindholm@linaro.org;
> > Kinney, Michael D; Gao, Liming; Tian, Feng; Dong, Eric
> > Subject: Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers
> >
> > On 23 November 2017 at 12:55, Wu, Hao A <hao.a.wu@intel.com> wrote:
> > >> -----Original Message-----
> > >> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> > >> Sent: Thursday, November 23, 2017 6:11 PM
> > >> To: Wu, Hao A
> > >> Cc: Zeng, Star; edk2-devel@lists.01.org; leif.lindholm@linaro.org;
> > >> Kinney, Michael D; Gao, Liming; Tian, Feng; Dong, Eric
> > >> Subject: Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers
> > >>
> > >> On 13 November 2017 at 03:37, Wu, Hao A <hao.a.wu@intel.com> wrote:
> > >> >> -----Original Message-----
> > >> >> From: Zeng, Star
> > >> >> Sent: Monday, November 13, 2017 11:32 AM
> > >> >> To: Wu, Hao A; Ard Biesheuvel; edk2-devel@lists.01.org;
> > >> >> leif.lindholm@linaro.org; Kinney, Michael D
> > >> >> Cc: Gao, Liming; Tian, Feng; Dong, Eric; Zeng, Star
> > >> >> Subject: RE: [RFC PATCH 0/2] quirks handling for SDHCI
> > >> >> controllers
> > >> >>
> > >> >> Hao,
> > >> >>
> > >> >> Could you help do the evaluation on this RFC?
> > >> >
> > >> > Sure, I will take a look on this.
> > >> >
> > >>
> > >> Any feedback?
> > >>
> > >
> > > Hi Ard,
> > >
> > > Sorry for the delayed response.
> > >
> > > I am still collecting feedbacks internally to see if there are
> > > additional hook points needed or other features/services that can be
> > > added to the SD/MMC override protocol.
> > >
> > > I think it would be better for this protocol to be general when it
> > > is introduced, which might avoid changing the protocol frequently later.
> > >
> > > What is your thought on this?
> >
> > Thank you for bringing this up internally. I agree that we should
> > carefully consider potential use cases now and not later.
> 
> Hi Ard,
> 
> Could you help to share an code example of the consumer of this protocol for
> reference?
> 
> Also, we think that it might be helpful to pass the pointer of the
> EFI_SD_MMC_PASS_THRU_PROTOCOL to the
> SD_MMC_OVERRIDE_INVOKE_HOOK service as an additional input parameter:
> 
> typedef
> EFI_STATUS
> (EFIAPI * SD_MMC_OVERRIDE_INVOKE_HOOK) (
>   IN      EFI_HANDLE                       ControllerHandle,
>   IN      UINT8                            Slot,
>   IN      SD_MMC_OVERRIDE_HOOK             HookType,
>   IN      EFI_SD_MMC_PASS_THRU_PROTOCOL    PassThru
>   );
> 
> The implementation of the service can decide whether to use the PassThru
> protocol.
> 
> If more hook points will be later added to the SDHCI override protocol, they
> may use the EFI_SD_MMC_PASS_THRU_PROTOCOL to send additional
> commands to the host controller during initialization.
> 
> Best Regards,
> Hao Wu
> 
> >
> > Thanks,
> > Ard.

Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers

[Ard Biesheuvel]

On 30 November 2017 at 02:16, Wu, Hao A <hao.a.wu@intel.com> wrote:
>> -----Original Message-----
>> From: Zeng, Star
>> Sent: Thursday, November 30, 2017 10:15 AM
>> To: Wu, Hao A; Ard Biesheuvel
>> Cc: edk2-devel@lists.01.org; leif.lindholm@linaro.org; Kinney, Michael D; Gao,
>> Liming; Tian, Feng; Dong, Eric; Zeng, Star
>> Subject: RE: [RFC PATCH 0/2] quirks handling for SDHCI controllers
>>
>> Hao,
>>
>>   IN      EFI_SD_MMC_PASS_THRU_PROTOCOL    *PassThru
>>
>> Right?
>
> Yes. Sorry for the typo.
>
> Best Regards,
> Hao Wu
>
>>
>> Thanks,
>> Star

Hello Hao, Star,

Please check the link for an example producer of the SD/MMC override protocol

https://lists.01.org/pipermail/edk2-devel/2017-November/017672.html

Thanks,
Ard.

>> -----Original Message-----
>> From: Wu, Hao A
>> Sent: Thursday, November 30, 2017 10:11 AM
>> To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Cc: Zeng, Star <star.zeng@intel.com>; edk2-devel@lists.01.org;
>> leif.lindholm@linaro.org; Kinney, Michael D <michael.d.kinney@intel.com>;
>> Gao, Liming <liming.gao@intel.com>; Tian, Feng <feng.tian@intel.com>; Dong,
>> Eric <eric.dong@intel.com>
>> Subject: RE: [RFC PATCH 0/2] quirks handling for SDHCI controllers
>>
>> > -----Original Message-----
>> > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
>> > Sent: Thursday, November 23, 2017 8:57 PM
>> > To: Wu, Hao A
>> > Cc: Zeng, Star; edk2-devel@lists.01.org; leif.lindholm@linaro.org;
>> > Kinney, Michael D; Gao, Liming; Tian, Feng; Dong, Eric
>> > Subject: Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers
>> >
>> > On 23 November 2017 at 12:55, Wu, Hao A <hao.a.wu@intel.com> wrote:
>> > >> -----Original Message-----
>> > >> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
>> > >> Sent: Thursday, November 23, 2017 6:11 PM
>> > >> To: Wu, Hao A
>> > >> Cc: Zeng, Star; edk2-devel@lists.01.org; leif.lindholm@linaro.org;
>> > >> Kinney, Michael D; Gao, Liming; Tian, Feng; Dong, Eric
>> > >> Subject: Re: [RFC PATCH 0/2] quirks handling for SDHCI controllers
>> > >>
>> > >> On 13 November 2017 at 03:37, Wu, Hao A <hao.a.wu@intel.com> wrote:
>> > >> >> -----Original Message-----
>> > >> >> From: Zeng, Star
>> > >> >> Sent: Monday, November 13, 2017 11:32 AM
>> > >> >> To: Wu, Hao A; Ard Biesheuvel; edk2-devel@lists.01.org;
>> > >> >> leif.lindholm@linaro.org; Kinney, Michael D
>> > >> >> Cc: Gao, Liming; Tian, Feng; Dong, Eric; Zeng, Star
>> > >> >> Subject: RE: [RFC PATCH 0/2] quirks handling for SDHCI
>> > >> >> controllers
>> > >> >>
>> > >> >> Hao,
>> > >> >>
>> > >> >> Could you help do the evaluation on this RFC?
>> > >> >
>> > >> > Sure, I will take a look on this.
>> > >> >
>> > >>
>> > >> Any feedback?
>> > >>
>> > >
>> > > Hi Ard,
>> > >
>> > > Sorry for the delayed response.
>> > >
>> > > I am still collecting feedbacks internally to see if there are
>> > > additional hook points needed or other features/services that can be
>> > > added to the SD/MMC override protocol.
>> > >
>> > > I think it would be better for this protocol to be general when it
>> > > is introduced, which might avoid changing the protocol frequently later.
>> > >
>> > > What is your thought on this?
>> >
>> > Thank you for bringing this up internally. I agree that we should
>> > carefully consider potential use cases now and not later.
>>
>> Hi Ard,
>>
>> Could you help to share an code example of the consumer of this protocol for
>> reference?
>>
>> Also, we think that it might be helpful to pass the pointer of the
>> EFI_SD_MMC_PASS_THRU_PROTOCOL to the
>> SD_MMC_OVERRIDE_INVOKE_HOOK service as an additional input parameter:
>>
>> typedef
>> EFI_STATUS
>> (EFIAPI * SD_MMC_OVERRIDE_INVOKE_HOOK) (
>>   IN      EFI_HANDLE                       ControllerHandle,
>>   IN      UINT8                            Slot,
>>   IN      SD_MMC_OVERRIDE_HOOK             HookType,
>>   IN      EFI_SD_MMC_PASS_THRU_PROTOCOL    PassThru
>>   );
>>
>> The implementation of the service can decide whether to use the PassThru
>> protocol.
>>
>> If more hook points will be later added to the SDHCI override protocol, they
>> may use the EFI_SD_MMC_PASS_THRU_PROTOCOL to send additional
>> commands to the host controller during initialization.
>>
>> Best Regards,
>> Hao Wu
>>
>> >
>> > Thanks,
>> > Ard.