On Mon, Dec 21, 2015 at 11:39:56AM +0000, Russell King - ARM Linux wrote: > - Fixing the SDHCI timeout calculation code to correctly round timeouts > up rather than down, and correctly calculate the time (in microseconds) > for a certain number of card clocks.
What I didn't point out, but should have, is the obvious issue. Given that the overall effect of the currently broken code is that the calculated timeout microsecond value is smaller than it should be, and in the case of a card which specifies a number of clock cycles, it will be _substantially_ smaller than it should be, I think that _all_ users of SDHCI_QUIRK_BROKEN_TIMEOUT_VAL are suspect mis-diagnosis of this driver bug. Once this series goes in, I'm intending to completely rip out the SDHCI_QUIRK_BROKEN_TIMEOUT_VAL quirk, so diagnosis of any problems can restart from a correct timeout calculation, and we will see how many SDHCI implementations _actually_ have an issue. If anyone knows for certain that the timeout hardware is broken, then they need to reply to this point. Otherwise, it would be useful if people could try removing this quirk with these fixes in place, and submit patches removing it from the drivers which are fixed by this change. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
