On 24/09/21 4:08 pm, Bean Huo wrote: > On Fri, 2021-09-24 at 15:17 +0300, Adrian Hunter wrote: >>>>> sdhci_writeb(host, count, SDHCI_TIMEOUT_CONTROL); >>>>> } >>>>> The driver has detected that the hardware timer cannot meet the >>>>> timeout >>>>> requirements of the device, but we still use the hardware >>>>> timer, >>>>> which will >>>>> allow potential timeout issuea . Rather than allowing a >>>>> potential >>>>> problem to exist, why can’t software timing be used to avoid >>>>> this >>>>> problem? >>>> Timeouts aren't that accurate. The maximum is assumed still to >>>> work. >>>> mmc->max_busy_timeout is used to tell the core what the maximum >>>> is. >>> mmc->max_busy_timeout is still a representation of Host HW timer >>> maximum timeout count, isn't it? >> >> >> Not necessarily. For SDHCI_QUIRK2_DISABLE_HW_TIMEOUT it would be >> >> set to zero to indicate no maximum. > > yes, this is the purpose of the patch, for the host controller without > quirk SDHCI_QUIRK2_DISABLE_HW_TIMEOUT, if the timeout count required by > device is beyond the HW timer max count, we choose SW timer to avoid the HW timer timeout IRQ. > > I don't know if I get it correctly. Why can't drivers that want the behaviour just set the quirk? Drivers that do not work with the quirk, do not have to set it.
