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. Bean
