From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Permerror (SPF Permanent Error: More than 10 MX records returned) identity=mailfrom; client-ip=134.134.136.31; helo=mga06.intel.com; envelope-from=hao.a.wu@intel.com; receiver=edk2-devel@lists.01.org Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) (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 714E721A1099A for ; Tue, 12 Dec 2017 02:52:03 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2017 02:56:42 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,394,1508828400"; d="scan'208";a="183508384" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga005.jf.intel.com with ESMTP; 12 Dec 2017 02:56:41 -0800 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 12 Dec 2017 02:56:41 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.152]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.213]) with mapi id 14.03.0319.002; Tue, 12 Dec 2017 18:56:39 +0800 From: "Wu, Hao A" To: Ard Biesheuvel , "edk2-devel@lists.01.org" CC: "Ni, Ruiyu" , "Tian, Feng" , Leif Lindholm , "Kinney, Michael D" , "Zeng, Star" Thread-Topic: [edk2] [PATCH v4 0/2] quirks handling for SDHCI controllers Thread-Index: AQHTb6zR+ZfQeHvS/0KOLUwPEOcfSaM+yDmAgADA6zA= Date: Tue, 12 Dec 2017 10:56:39 +0000 Message-ID: References: <20171207224322.20362-1-ard.biesheuvel@linaro.org> In-Reply-To: Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [PATCH v4 0/2] quirks handling for SDHCI controllers 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, 12 Dec 2017 10:52:04 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ard, > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ar= d > Biesheuvel > Sent: Tuesday, December 12, 2017 3:00 PM > To: edk2-devel@lists.01.org > Cc: Ni, Ruiyu; Tian, Feng; Ard Biesheuvel; Wu, Hao A; Leif Lindholm; Kinn= ey, > Michael D; Zeng, Star > Subject: Re: [edk2] [PATCH v4 0/2] quirks handling for SDHCI controllers >=20 > On 7 December 2017 at 22:43, Ard Biesheuvel > wrote: > > Many SDHCI implementations exist that are almost spec complicant, and > > could be driven 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 applyin= g > > SDHCI quirks. > > > > Changes since v3: > > - remove PassThru argument from protocol members: it is unclear whether= the > > protocol is available when the override protocol is invoked, and my > > example use case does not need it > > - replace incorrect HandleProtocol with LocateProtocol, given that the > override > > protocol is now a singleton instance > > - merge notifier calls into SdMmcHcReset() and SdMmcHcInitHost (), this > > required changing the prototype to take a SD_MMC_HC_PRIVATE_DATA* > argument > > and so the prototypes no longer belong in SdMmcPciHci.h and have been > moved > > to SdMmcPciHcDxe.h > > - use VOID* type for capability not UINT64* since we don't know its > alignment > > > > Changes since v2: > > - use a singleton instance of the SD/MMC protocol rather than one per > > controller; this is needed to support 'reconnect -r', as pointed out > > by Ray > > - use EDKII prefixes for all types defined by the protocol > > - replace 'hook' with 'notify', and tweak some other identifiers > > - add missing function comment headers for factored out functions > > > > Changes since RFC/v1: > > - add EFI_SD_MMC_PASS_THRU_PROTOCOL* member to override methods > > - use UINT64* not VOID* to pass capability structure (which is always 6= 4 bits > > in size) > > > > Ard Biesheuvel (2): > > MdeModulePkg: introduce SD/MMC override protocol > > MdeModulePkg/SdMmcPciHcDxe: allow HC capabilities to be overridden > > >=20 > OK, so I did send my v4 but I couldn't find it in my mail folders :-) >=20 > Comments anyone? I still need some time to evaluate whether the current proposed override protocol can be utilized in our using scenario. Will let you know the feedbacks as soon as I finish the evaluation. Really sorry for the delay. Best Regards, Hao Wu > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel