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.93; helo=mga11.intel.com; envelope-from=star.zeng@intel.com; receiver=edk2-devel@lists.01.org Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (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 6CE0D20356240 for ; Mon, 4 Dec 2017 18:04:52 -0800 (PST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Dec 2017 18:09:21 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,362,1508828400"; d="scan'208";a="9588113" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga003.jf.intel.com with ESMTP; 04 Dec 2017 18:09:19 -0800 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 4 Dec 2017 18:08:16 -0800 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by fmsmsx110.amr.corp.intel.com (10.18.116.10) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 4 Dec 2017 18:08:16 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.175]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.152]) with mapi id 14.03.0319.002; Tue, 5 Dec 2017 10:08:14 +0800 From: "Zeng, Star" To: Ard Biesheuvel , "edk2-devel@lists.01.org" CC: "Wu, Hao A" , "Tian, Feng" , Leif Lindholm , "Ni, Ruiyu" , "Kinney, Michael D" , "Zeng, Star" Thread-Topic: [edk2] [PATCH v2 0/2] quirks handling for SDHCI controllers Thread-Index: AQHTacOp4EvSmp6AjkCcbXlkao1X26MyxZIAgAFCkuA= Date: Tue, 5 Dec 2017 02:08:13 +0000 Message-ID: <0C09AFA07DD0434D9E2A0C6AEB0483103B9BF703@shsmsx102.ccr.corp.intel.com> References: <20171130101132.18317-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 v2 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, 05 Dec 2017 02:04:52 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Include Ruiyu and Mike. Thanks, Star -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ard = Biesheuvel Sent: Monday, December 4, 2017 10:53 PM To: edk2-devel@lists.01.org Cc: Wu, Hao A ; Tian, Feng ; Zeng,= Star ; Leif Lindholm ; Ard = Biesheuvel Subject: Re: [edk2] [PATCH v2 0/2] quirks handling for SDHCI controllers On 30 November 2017 at 10:11, Ard Biesheuvel wr= ote: > Many SDHCI implementations exist that are almost spec complicant, and=20 > could be driven by the generic SD/MMC host controller driver except=20 > for some minimal necessary init time tweaks. > > Adding such tweaks to the generic driver is undesirable. On the other=20 > hand, forking the driver for every platform that has such a SDHCI=20 > controller is problematic when it comes to upstreaming and ongoing=20 > maintenance (which is arguably the point of upstreaming in the first=20 > place). > > So these patches propose a workaround that is minimally invasive on=20 > the > EDK2 side, but gives platforms a lot of leeway when it comes to=20 > applying SDHCI quirks. > > 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 alwys 64 b= its > in size) > > Ard Biesheuvel (2): > MdeModulePkg: introduce SD/MMC override protocol > MdeModulePkg/SdMmcPciHcDxe: allow HC capabilities to be overridden > Hao, Star, Any comments? Thanks, Ard. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel