On Sat, 4 Aug 2007 10:32:09 -0700
David Brownell <[EMAIL PROTECTED]> wrote:
>
> 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.
>
I've thought about it, and the interesting cases are difficult to
achieve with a standard card. If you have some ideas, I'd love to hear
them.
Also, a common problem is drivers that break layering. So my number one
wanted test is to issue a command opcode that doesn't match what the
spec says in terms of response and semantics.
> 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.
>
Now if only there was time. :)
> >
> > 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.
>
Well, the sdio code so far hasn't paid any attention to sdio. Perhaps
it's best to just avoid that detection on a spi host for now.
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
