On 11 December 2017 at 23:12, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 5 December 2017 at 18:01, Ard Biesheuvel <ard.biesheu...@linaro.org> 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 applying >> SDHCI quirks. >> >> 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 64 bits >> in size) >> > > Comments anyone?
Please ignore - I thought I had sent out my v4 already, but apparently not. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
