Hi Uf, + Tony, linux-omap list > Am 26.10.2021 um 19:12 schrieb Ulf Hansson <ulf.hansson@xxxxxxxxxx>: > > + Jerome > > On Wed, 6 Oct 2021 at 13:25, H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> 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. :-) Well, that ti,wl1251 chip is so old [1] that probably the SDIO spec did deviate from what the vendor thought it will look like :) [1] https://www.ti.com/lit/ml/swmt009a/swmt009a.pdf > At least for now, matching on the compatible string and applying card > quirks makes perfect sense to me. Yes, that is how it already was in the omal_hsmmc driver quirks. > >> >> 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@xxxxxxxxxxxxx> # on OpenPandora >> Signed-off-by: H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> > > 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. BR and thanks, Nikolaus > > 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@xxxxxxxxxx/
