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:   Tue, 26 Oct 2021 19:12:52 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     "H. Nikolaus Schaller" <hns@...delico.com>,
        Jerome Pouiller <Jerome.Pouiller@...abs.com>
Cc:     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@...r.kernel.org, letux-kernel@...nphoenux.org,
        kernel@...a-handheld.com
Subject: Re: [RFC] mmc: core: transplant ti,wl1251 quirks from to be retired omap_hsmmc

+ Jerome

On Wed, 6 Oct 2021 at 13:25, H. Nikolaus Schaller <hns@...delico.com> wrote:
>
> The TiWi 5 WiFi module needs special setup of the sdio
> interface before it can be probed.
>
> So far, this is done in omap_hsmmc_init_card() in omap_hsmmc.c
> which makes it useable only if connected to omap devices
> which use the omap_hsmmc. The OpenPandora is the most promient
> example.
>
> There are plans to switch to a newer sdhci-omap driver and
> retire omap_hsmmc. Hence this quirk must be reworked or moved
> somewhere else. Ideally to some location that is not dependent
> on the specific SoC mmc host driver.
>
> Analysis has shown that omap_hsmmc_init_card() is called
> through the host->ops->init_card hook which itself
> is called in three generic locations:
>
> mmc_init_card()
> mmc_sd_init_card()
> mmc_sdio_init_card()
>
> All these functions share a call to mmc_select_card() shortly
> after running the init hook and therefore I assume that
> a good place transplanting the special wl1251 handling is
> mmc_select_card() - unless we want to copy and maintain the
> code to three different places.
>
> After this quirk has been moved there, we can remove
> omap_hsmmc_init_card() in omap_hsmmc.c in a separate patch.
> Indeed the plan is to remove omap_hsmmc.c completely.
>
> A future development path to generalize could be to make
> the code not depend on compatible = "ti,wl1251" but check
> for optional device tree properties (non-std-sdio, bus width,
> vendor, device, blksize, max_dtr, ocr) which can be defined
> for any child device of the mmd/sd port needing such special
> setup.

I wouldn't go that path, simply because it may look like we encourage
vendors to deviate from the SDIO spec. :-)

At least for now, matching on the compatible string and applying card
quirks makes perfect sense to me.

>
> Related-to: commit f6498b922e57 ("mmc: host: omap_hsmmc: add code for special init of wl1251 to get rid of pandora_wl1251_init_card")
> Related-to: commit 2398c41d6432 ("omap: pdata-quirks: remove openpandora quirks for mmc3 and wl1251")
> Related-to: commit f9d50fef4b64 ("ARM: OMAP2+: omap3-pandora: add wifi support")
> Tested-by: H. Nikolaus Schaller <hns@...delico.com> # on OpenPandora
> Signed-off-by: H. Nikolaus Schaller <hns@...delico.com>

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!?

Kind regards
Uffe

[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/

> ---
>  drivers/mmc/core/mmc_ops.c | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)
>
> diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
> index 0c54858e89c0..6f9b96be9fe6 100644
> --- a/drivers/mmc/core/mmc_ops.c
> +++ b/drivers/mmc/core/mmc_ops.c
> @@ -7,6 +7,7 @@
>
>  #include <linux/slab.h>
>  #include <linux/export.h>
> +#include <linux/of.h>
>  #include <linux/types.h>
>  #include <linux/scatterlist.h>
>
> @@ -107,6 +108,35 @@ static int _mmc_select_card(struct mmc_host *host, struct mmc_card *card)
>
>  int mmc_select_card(struct mmc_card *card)
>  {
> +       if (card->type == MMC_TYPE_SDIO || card->type == MMC_TYPE_SD_COMBO) {
> +               struct device_node *np = card->host->parent->of_node;
> +
> +               /*
> +                * REVISIT: should be made more general
> +                * e.g. by expanding the DT bindings of child nodes to
> +                * optionally provide this information:
> +                * Documentation/devicetree/bindings/mmc/mmc-card.txt
> +                */
> +
> +               np = of_get_compatible_child(np, "ti,wl1251");
> +               if (np) {
> +                       /*
> +                        * We have TI wl1251 attached to this mmc. Pass this
> +                        * information to the SDIO core because it can't be
> +                        * probed by normal methods.
> +                        */
> +
> +                       dev_info(card->host->parent, "found wl1251\n");
> +                       card->quirks |= MMC_QUIRK_NONSTD_SDIO;
> +                       card->cccr.wide_bus = 1;
> +                       card->cis.vendor = 0x104c;
> +                       card->cis.device = 0x9066;
> +                       card->cis.blksize = 512;
> +                       card->cis.max_dtr = 24000000;
> +                       card->ocr = 0x80;
> +                       of_node_put(np);
> +               }
> +       }
>
>         return _mmc_select_card(card->host, card);
>  }
> --
> 2.33.0
>

Powered by blists - more mailing lists