>> If not I would at least add the !mmc_is_host_spi condition for calling mmc_blk_status_error to make it a bit more clear that this function does do what is intended for SPI cards. > >I am not sure what you mean. Isn't it OK to check CMD13 response for SPI? You can do that for sure, but e.g. without some knowledge about what state you're in it doesn't tell you a lot. If you get all zeroes after a write e.g., you cannot always tell if the SPI card is holding the line LOW because of busy[*], or you actually got an SPI R2 with no error bits set. (The CMD12 = ILLEGAL assert would fix it, but now all cards behave this way and the spec doesn't mandate it.) It cannot really be dealt with in a nice manner. Furthermore cards are, according to spec, free to treat cmd13 as ILLEGAL during data state. If so, that's nice for us, we get a 0x4 back and know we have to fix state, some cards also accept CMD13 (no error bits set), perfectly legal, but we don't know if we should fix state or not. (Furthermore, how to fix state is then dependent on the issued (e.g. timedout command) *The SD SPI spec e.g. says in 7.2.8 that a CMD13 must ALWAYS be responded to, but that is clearly not the intention of the spec, a card always listening for CMD13 in RCV state simply doesn't make sense. Hyperstone GmbH | Reichenaustr. 39a | 78467 Konstanz Managing Director: Dr. Jan Peter Berns. Commercial register of local courts: Freiburg HRB381782
