On 06/11/15 15:55, Scott Branden wrote:
> Hi Ulf,
> 
> On 15-11-06 12:14 AM, Ulf Hansson wrote:
>> On 5 November 2015 at 23:39, Al Cooper <[email protected]> wrote:
>>> Add quirk to disable SDR50 mode for controllers/boards that have
>>> problems with this mode.
>>
>> No thanks! No more quirks please!
>>
> 
> I'm fine with not having this quirk added (I don't need this one but use
> multiple of the other quirks in the driver)  But, what if I also needed
> it in my driver?  When do we determine when a quirk should be added to
> sdhci.c or not.  What about existing quirks - should the current ones be
> moved to multiple existing drivers?
>> Kind regards
>> Uffe
>>
>>>
>>> Signed-off-by: Al Cooper <[email protected]>
>>> ---
>>>   drivers/mmc/host/sdhci.c | 3 +++
>>>   drivers/mmc/host/sdhci.h | 2 ++
>>>   2 files changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>> index b48565e..71067c7 100644
>>> --- a/drivers/mmc/host/sdhci.c
>>> +++ b/drivers/mmc/host/sdhci.c
>>> @@ -3176,6 +3176,9 @@ int sdhci_add_host(struct sdhci_host *host)
>>>          } else if (caps[1] & SDHCI_SUPPORT_SDR50)
>>>                  mmc->caps |= MMC_CAP_UHS_SDR50;
>>>
>>> +       if (host->quirks2 & SDHCI_QUIRK2_BROKEN_SDR50)
>>> +               mmc->caps &= ~MMC_CAP_UHS_SDR50;
>>> +
> Perhaps a lot of these quirks can be solved by having a generic
> mechanism to override any of the values in the caps registers rather
> than adding all these quirks?

Are the capabilities register override specific to the Arasan controller
or is there a generic and well define SDIO configuration register for
these registers? The register information I am looking at seems to
suggest this is part of how you glue your SDIO controller to your SoC.

The entire purpose of Al's changes were precisely so we do not have to
fiddle with these capabilities register like we are currently doing in
some versions of our downstream kernel.
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to