Hi Ulf, > Am 26.10.2021 um 20:08 schrieb H. Nikolaus Schaller <hns@xxxxxxxxxxxxx>: > > 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@xxxxxxxxxx/
