linux-kernel - Re: [RFC] mmc: core: transplant ti,wl1251 quirks from to be retired omap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 27 Oct 2021 19:00:42 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     Jerome Pouiller <Jerome.Pouiller@...abs.com>,
        Avri Altman <avri.altman@....com>,
        Shawn Lin <shawn.lin@...k-chips.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bean Huo <beanhuo@...ron.com>, linux-mmc@...r.kernel.org,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>, kernel@...a-handheld.com,
        Tony Lindgren <tony@...mide.com>,
        Linux-OMAP <linux-omap@...r.kernel.org>
Subject: Re: [RFC] mmc: core: transplant ti,wl1251 quirks from to be retired
 omap_hsmmc

Hi Ulf,

> Am 26.10.2021 um 20:08 schrieb H. Nikolaus Schaller <hns@...delico.com>:
> 
> Hi Uf,
>> 
>> As a matter of fact, the similar problem that you are looking to
>> address (applying card quirks based on DT compatibility strings), is
>> partly being taken care of in another series [1], being discussed
>> right now. I think the solution for the ti,wl1251 should be based upon
>> that too. Please have a look and see if you can play with that!?
> 
> That is interesting.
> Yes, maybe it can be the basis. At least for finding the chip and driver.

I have done a first experiment.

It seems as if the series [1] does the opposite of what we need... It just
skips entries in struct mmc_fixup if the DT does *not* match.

This new match is not even tried in the wl1251 case since card->cis.vendor
and card->cis.device are not properly initialized when mmc_fixup_device() is called.
(in the upstream code the init_card function sets these and also sets MMC_QUIRK_NONSTD_SDIO
to early abort before sdio_read_cccr, sdio_read_common_cis, and mmc_fixup_device).

What I don't get from the code is how cis.vendor or cis.device can be
initialized from device tree for a specific device. As far as I see it can
only be checked for and some quirks can be set from a table if vendor and
device read from the CIS registers do match. 

Instead, we want to match DT and define some values for an otherwise unknown
device (i.e. we can't match by vendor or other methods) to help to initialize
the interface. So in mmc_fixup_device it is too late and we need something
running earlier, based purely on device tree information...

BR and thanks,
Nikolaus

> [1]
> [RFC PATCH 0/2] mmc: allow to rely on the DT to apply quirks
> https://lore.kernel.org/lkml/20211014143031.1313783-1-Jerome.Pouiller@silabs.com/