Re: [PATCH v3 0/2] quirks handling for SDHCI controllers

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 11 December 2017 at 23:12, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 5 December 2017 at 18:01, Ard Biesheuvel <ard.biesheuvel@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.