Hi Subhash, > >> sdhci_add_host() reads host controller's capabilities and initialize host->caps of function > >> mmc_host_uhs(). So mmc_host_uhs() only return this cached values. > > So, it does represent host controller's capabilities, not the capabilities of the card. > > What happens if I have a UHS capable controller and a 2.0 card? > > The S18R bit will be set in this case, which might cause problem for the card? > Hi Bing, > > Why do you see an issue with setting S18R bit when sending CMD5 to > SDIO2.0 compliant card? > If SDIO2.0 card don't support it, return OCR won't have the S18A bit set. Some times ago I ever encountered a problem with CMD52 when I played with an SDIO driver and accidentally set one of the reserved bits to 1. The issue was resolved immediately after I realized it and cleared that bit to 0. This experience makes me thinking that CMD5 S18R might confuse some 2.0 cards, because bit24 is also a reserved bit in 2.0 spec. > We are already doing same thing for SD cards as well (check > mmc_sd_get_cid function). There also even if we set the S18R bit which > sending OCR to non-SD3.0 cards, they respond back with S18A bit cleared. Then it's fair enough to handle SDIO the same way. Thanks for the elaboration. > > If non-SDIO3.0 card misbehaves after receiving the OCR with S18R bit set > then it means card is not compliant to specification properly and in > that case those cards can be handled with QUIRKs. But there is no need > to add any QUIRKs as of now. That sounds reasonable. The quirk for non-compliant cards can be done later when they come up. Regards, Bing > > I hope this make sense. > > Regards, > Subhash > -- 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
