On Saturday 04 August 2007, Pierre Ossman wrote: > On Thu, 2 Aug 2007 13:34:49 -0700 > David Brownell <[EMAIL PROTECTED]> wrote: > > > The intended design of an MMC/SD host driver has never > > been all that clear. It's becoming more clear with your > > recent work ... but it's not there yet, and there aren't > > even test scripts or suites for de-facto requirements > > (and to facilitate regression testing). > > I agree. There are still a bunch of corner cases that are fuzzy at > best. Unfortunately, all difficult cases usually involve error > conditions. So I haven't been able to come up with a way to test things > without having a custom card that can fail requests in different exotic > ways.
There's always writing negative tests ... i.e. issue requests that will fail, and make sure they fail "correctly". One of those might be an alternative to the current block driver. One expects that code developed outside any test framework will have fair coverage for success paths (e.g. whatever is needed to make MMC and SD memory cards work), and the most common fault paths (e.g. what's triggered during enumeration). But beyond that ... passing illegal params, reading past end of card, "unusual" write sizes, and other things are unlikely to behave consistently between drivers. > > Patches #1 and #2 were easy fixes; about 2/3 of #3 is rejected, > > and I've not yet looked at the details ... that's all the core > > changes, which haven't previously cared about much more than > > success-or-fault. #4 should be easy to cope with. > > It should just be a matter of replacing MMC_ERR_ codes with -Esomething. Or MMC_ERR_NONE with zero. Almost ... thing is, the new SDIO stuff seems to bork things in some cases, more with SD cards than MMC. - Dave ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
