From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.43; helo=mga05.intel.com; envelope-from=ruiyu.ni@intel.com; receiver=edk2-devel@lists.01.org Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id BD69B2035626A for ; Tue, 5 Dec 2017 02:30:25 -0800 (PST) Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2017 02:34:56 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,363,1508828400"; d="scan'208";a="246472" Received: from ray-dev.ccr.corp.intel.com (HELO [10.239.9.14]) ([10.239.9.14]) by fmsmga008.fm.intel.com with ESMTP; 05 Dec 2017 02:34:55 -0800 To: Ard Biesheuvel , Hao A Cc: "edk2-devel@lists.01.org" , Leif Lindholm , "Tian, Feng" , "Zeng, Star" References: <20171130101132.18317-1-ard.biesheuvel@linaro.org> <20171130101132.18317-2-ard.biesheuvel@linaro.org> From: "Ni, Ruiyu" Message-ID: <5697a7e7-4994-1528-0c98-ad03efafb7e0@Intel.com> Date: Tue, 5 Dec 2017 18:34:54 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Subject: Re: [PATCH v2 1/2] MdeModulePkg: introduce SD/MMC override protocol X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 10:30:26 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 12/5/2017 6:24 PM, Ard Biesheuvel wrote: > On 5 December 2017 at 10:12, Ni, Ruiyu wrote: >> Some comments re the detailed interfaces embedded in below. >> >> On 11/30/2017 6:11 PM, Ard Biesheuvel wrote: >>> >>> 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 >>> --- >>> MdeModulePkg/Include/Protocol/SdMmcOverride.h | 103 ++++++++++++++++++++ >>> MdeModulePkg/MdeModulePkg.dec | 3 + >>> 2 files changed, 106 insertions(+) >>> >>> diff --git a/MdeModulePkg/Include/Protocol/SdMmcOverride.h >>> b/MdeModulePkg/Include/Protocol/SdMmcOverride.h >>> new file mode 100644 >>> index 000000000000..5a5c393896f4 >>> --- /dev/null >>> +++ b/MdeModulePkg/Include/Protocol/SdMmcOverride.h >>> @@ -0,0 +1,103 @@ >>> +/** @file >>> + Protocol to describe overrides required to support non-standard SDHCI >>> + implementations >>> ... >>> + IN EFI_SD_MMC_PASS_THRU_PROTOCOL *PassThru, >>> + IN EFI_HANDLE ControllerHandle, >>> + IN UINT8 Slot, >>> + IN OUT UINT64 *SdMmcHcSlotCapability >>> + ); >> >> >> Is this API too specific? >> Besides SlotCapability, is there any other attributes that may need >> override as well? >> > > The capability structure is the root data structure that describes the > SD/MMC host controller. Which other data structures did you have in > mind? > I do not know either. Hao, any comments? -- Thanks, Ray