Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Subject: Re: [RFC] mmc: core: transplant ti,wl1251 quirks from to be retired
 omap_hsmmc
From:   "H. Nikolaus Schaller" <hns@goldelico.com>
In-Reply-To: <4153E8E6-2D39-4AEA-9CC6-411D4FF8CE67@goldelico.com>
Date:   Mon, 1 Nov 2021 10:12:52 +0100
Cc:     Avri Altman <avri.altman@wdc.com>,
        Shawn Lin <shawn.lin@rock-chips.com>,
        Linus Walleij <linus.walleij@linaro.org>,
        Bean Huo <beanhuo@micron.com>, linux-mmc@vger.kernel.org,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Discussions about the Letux Kernel 
        <letux-kernel@openphoenux.org>, kernel@pyra-handheld.com,
        Tony Lindgren <tony@atomide.com>,
        Linux-OMAP <linux-omap@vger.kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3C22E794-1839-4B53-AC5C-B34DD2C6E2E6@goldelico.com>
References: <8ecc5c79c1dd0627d570ede31e18c860786cacca.1633519499.git.hns@goldelico.com>
 <2013308.OSlt1BDEiP@pc-42>
 <1EF25CD6-7801-4C15-AB4C-5F499948A653@goldelico.com>
 <34072875.m9Xp8G9xV5@pc-42>
 <4153E8E6-2D39-4AEA-9CC6-411D4FF8CE67@goldelico.com>
To:     =?utf-8?B?SsOpcsO0bWUgUG91aWxsZXI=?= <jerome.pouiller@silabs.com>,
        Ulf Hansson <ulf.hansson@linaro.org>
Precedence: bulk

Hi Jerome and Ulf,

> Am 28.10.2021 um 12:07 schrieb H. Nikolaus Schaller =
<hns@goldelico.com>:
>=20
>=20
>=20
>> Am 28.10.2021 um 11:55 schrieb J=C3=A9r=C3=B4me Pouiller =
<jerome.pouiller@silabs.com>:
>>=20
>> On Thursday 28 October 2021 11:40:59 CEST H. Nikolaus Schaller wrote:
>>>> Am 28.10.2021 um 10:59 schrieb J=C3=A9r=C3=B4me Pouiller =
<jerome.pouiller@silabs.com>:
>>>> On Thursday 28 October 2021 09:08:50 CEST H. Nikolaus Schaller =
wrote:
>>>>=20
>>>>>> Let me have a closer look - and for sure, I am willing to help if =
needed.
>>>>=20
>>>> I confirm it does not have the expected behavior. =
!mmc_fixup_of_compatible_match()
>>>> should be mmc_fixup_of_compatible_match(), sorry.

I did take a deeper look and contrary to my first analyses your original =
patches
are correct. I did not completely understand how it was intended to be =
used
and how to match the compatible entry.

>>>=20
>>> Ok, I see.
>>>=20
>>> 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?
>>=20
>> yes, I didn't provide it with my RFC.=20

Now I was able to make a version that works on the OpenPandora.

It does not yet use a macro to define the mmc_fixup table, but that can =
be
easily changed.

>=20
> I see.
>=20
> Starts to look like a good plan and we just have to execute it.
>=20
> Please notify if you have a new version to work with (it isn't urgent =
since the
> transplantation is only needed if omap_hsmmc is retired which depends =
on merge
> of the new driver).

I'll send an RFCv2 for the ti,wl1251 quirks now.

Best regards and thanks,
Nikolaus