From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) 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 3D3212035D315 for ; Sun, 28 Jan 2018 21:08:05 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jan 2018 21:13:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,429,1511856000"; d="scan'208";a="26214241" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga001.fm.intel.com with ESMTP; 28 Jan 2018 21:13:38 -0800 Received: from fmsmsx114.amr.corp.intel.com (10.18.116.8) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 28 Jan 2018 21:13:38 -0800 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by FMSMSX114.amr.corp.intel.com (10.18.116.8) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 28 Jan 2018 21:13:38 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.127]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.192]) with mapi id 14.03.0319.002; Mon, 29 Jan 2018 13:13:28 +0800 From: "Wu, Hao A" To: Ard Biesheuvel , "edk2-devel@lists.01.org" CC: "leif.lindholm@linaro.org" , "Kinney, Michael D" , "Zeng, Star" , "Tian, Feng" , "Ni, Ruiyu" Thread-Topic: [PATCH v4 0/2] quirks handling for SDHCI controllers Thread-Index: AQHTb6zR+ZfQeHvS/0KOLUwPEOcfSaOKZN5w Date: Mon, 29 Jan 2018 05:13:27 +0000 Message-ID: References: <20171207224322.20362-1-ard.biesheuvel@linaro.org> In-Reply-To: <20171207224322.20362-1-ard.biesheuvel@linaro.org> 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.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 05:08:06 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One minor comment, please help to remove the line (around line 1067): @param[in] Capability The capability of the slot. within function description comment for SdMmcHcInitHost() in file: MdeModulePkg\Bus\Pci\SdMmcPciHcDxe\SdMmcPciHci.c Other than that, the series is good to me: Reviewed-by: Hao Wu Really sorry for the delay. Best Regards, Hao Wu > -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > Sent: Friday, December 08, 2017 6:43 AM > To: edk2-devel@lists.01.org > Cc: leif.lindholm@linaro.org; Kinney, Michael D; Zeng, Star; Tian, Feng; = Ni, > Ruiyu; Wu, Hao A; Ard Biesheuvel > Subject: [PATCH v4 0/2] quirks handling for SDHCI controllers >=20 > 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. >=20 > 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). >=20 > 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. >=20 > Changes since v3: > - remove PassThru argument from protocol members: it is unclear whether t= he > 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 ov= erride > 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 align= ment >=20 > 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 >=20 > 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 64 = bits > in size) >=20 > Ard Biesheuvel (2): > MdeModulePkg: introduce SD/MMC override protocol > MdeModulePkg/SdMmcPciHcDxe: allow HC capabilities to be overridden >=20 > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 35 ++++++- > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 36 ++++++++ > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf | 2 + > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 95 > +++++++++++++++++-- > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 35 ------- > MdeModulePkg/Include/Protocol/SdMmcOverride.h | 97 > ++++++++++++++++++++ > MdeModulePkg/MdeModulePkg.dec | 3 + > 7 files changed, 257 insertions(+), 46 deletions(-) > create mode 100644 MdeModulePkg/Include/Protocol/SdMmcOverride.h >=20 > -- > 2.11.0