[...] >> > Those platforms could still update their DT files and add "broken-cd", >> > since that would be the proper description of the HW. Once that's done, >> > it would enable you to remove the SDHCI_QUIRK_BROKEN_CARD_DETECTION as >> > default, right? >> > >> Yes, and if remove SDHCI_QUIRK_BROKEN_CARD_DETECTION as default, 'borken-cd' would be needed to be added for most platforms using esdhc. > > I was OK with changing the device tree if it just meant that things that > previously didn't work now work. I'm not OK with requiring the device > trees to change in order for things that already work to stay working. I get your point, but.. considering maintaince from mmc code point of view, I don't like the suggested approach in $subject patch. As this patch anyway requires updating DTBs, I would like to know the involved platforms and at what level of deployment the DTBs are in. In principle what I am asking is, how hard is it to update the DTBs? BTW, is it only sdhci-of-esdhc.c we are discussing here? > > In general it is not reasonable to expect device trees to enumerate > hardware bugs since the bugs (or the need to work aronud them) are often > discovered after the device tree has been created. > > Yangbo, when I asked why you couldn't use SVR you said that it was a > common SDHC file. But, the file that sets > SDHCI_QUIRK_BROKEN_CARD_DETECTION in the first place is sdhci-of-esdhc.c > which is Freescale-specific. Why not just test SVR in there to > determine whether the quirk should be set? > > -Scott > > Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
