Re: [RFC] mmc: core: transplant ti,wl1251 quirks from to be retired omap_hsmmc

[H. Nikolaus Schaller]

> Am 28.10.2021 um 11:40 schrieb H. Nikolaus Schaller <hns@xxxxxxxxxxxxx>:
> 
> Hi Jérôme,
> 
>> Am 28.10.2021 um 10:59 schrieb Jérôme Pouiller <jerome.pouiller@xxxxxxxxxx>:
>> 
>> Hi Nikolaus,
>> 
>> On Thursday 28 October 2021 09:08:50 CEST H. Nikolaus Schaller wrote:
>> 
>>>> Let me have a closer look - and for sure, I am willing to help if needed.
>> 
>> I confirm it does not have the expected behavior. !mmc_fixup_of_compatible_match()
>> should be mmc_fixup_of_compatible_match(), sorry.
> 
> Ok, I see.
> 
> One more question: how can I specify "ti,wl1251" in some struct mmc_fixup table?
> Does it need another macro like MMC_FIXUP() or SDIO_FIXUP() to set the .name
> field?
> 
>>> 
>>> Combining your suggestions we could do roughly:
>>> 
>>> in mmc_sdio_init_card():
>>> 
>>>       if (host->ops->init_card)
>>>               host->ops->init_card(host, card);
>>>       else
>>>               mmc_fixup_device(host, sdio_prepare_fixups_methods);
>> 
>> I think I mostly agree, but why you don't call mmc_fixup_device() if
>> init_card is defined? (BTW, mmc_fixup_device() takes a card as
>> first parameter)
> 
> Because I want to get rid of init_card. It is host specific and not client
> specific.

Ah, on a second though we can do that independently. Either there is
some init_card - or something in the fixup tables. Why not both...
So the else clause is not needed.

And you are right, the first parameter should be card`.

> 
>> 
>> 
>>> Next we need a location for the sdio_prepare_fixups_methods table and functions.
>>> 
>>> For "ti,wl1251" we would then provide the entry in the table and a function doing
>>> the setup. But where should these be defined? Likely not in a header file like
>>> quirks.h? But there is no quirks.c.
>> 
>> I think you can place your function in drivers/mmc/core/card.h. There are
>> already add_quirk(), add_limit_rate_quirk(), add_quirk_mmc(), etc...
> 
> Ok. Would be some add_wl1251_quirk() then.
> 
> BR and thanks,
> Nikolaus
>