On Thu, Dec 17, 2015 at 01:22:29PM +0100, David Jander wrote: > Ok, this sounds like a good way to go. Unfortunately it also sounds like a > major endeavor, for which good knowledge of the SDHCI standard is necessary. That's not entirely true. Anyone who is really good at programming can fix this: it's a matter of making changes via a series of code transformations which allow you to reach a goal. As far as I can see, there's two solutions to SDHCI: 1. We chuck the existing crappy driver away and start over. 2. We change the existing driver to improve it, which requires the transformation approach. When I say "transformation", it's about making just one change at a time, such as creating a new function which contains shared code, and then arranging for it to be called. The series I did (starting at da91a8f9c0f5) is most likely done via this method - when modifying a complex driver, I think it's the only way to make changes safely. The approach has many advantages, the most important is that the changes should look obvious and trivial, even though the sum of the changes may be complex. -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
