On 4 October 2018 at 18:08, Clément Péron <peron.clem@xxxxxxxxx> wrote: > On Thu, 4 Oct 2018 at 18:05, Clément Péron <peron.clem@xxxxxxxxx> wrote: >> >> From: Chris Boot <bootc@xxxxxxxxx> >> >> I was trying to get a Micro-SD card working over SPI today when I ran >> into an issue which made the card unusable. The card was probed >> correctly, and the msdos partition table was read, but then some command >> was sent that made the card go into a bad state and stay that way. Only >> a re-probe would get the card unstuck and only until just after the >> partition tables were read. >> >> After some digging I ran into a post [1] on the spi-devel-general mailing >> list where someone had exactly the same issue as me, but back in 2007. >> There was a patch attached which, after some cleanup, fixes the issue >> completely for me. >> >> I have tried this with 3 different Micro-SD cards, all of which suffered >> from the problem before the patch and none of which fail after the >> patch. >> >> The error shows up as lots of: >> mmcblk0: error -38 sending status comand, retrying >> mmcblk0: error -38 sending status comand, retrying >> mmcblk0: error -38 sending status comand, aborting >> >> 1 : http://permalink.gmane.org/gmane.linux.kernel.spi.devel/516 >> >> Signed-off-by: Chris Boot <bootc@xxxxxxxxx> >> Signed-off-by: Clément Péron <peron.clem@xxxxxxxxx> > > Hi, > > I got issue with some SD Cards over SPI. > After some debugging I understand that there is an issue with reading > latest sector in multiblock mode. > Googling and found this patch from 2007 > https://lore.kernel.org/patchwork/patch/305060/ > I test it on my Kernel 4.9 and was fixing my issue ! > > If someone could have a look at it, We are lacking a driver maintainer for "drivers/mmc/host/mmc_spi.c" and unfortunate me personally, also has limited knowledge around the SPI case. However, from the problem description and by looking at the mmc spi driver code (which certainly would need a little love), I get the feeling that this isn't really a card specific problem. The point is, instead of adding a hack in the mmc core, for something that probably should be fixed in the host driver, doesn't really make sense in the long run. Of course I might be wrong, but in such case we should use a so called mmc/sd card quirk instead. Another option to workaround the problem, is to implement the ->multi_io_quirk host ops for mmc_spi. In that way you can for multi block reads, return 1 as the required block size - thus telling the mmc core to use single block read instead. Of course that would then effect all multi block reads for mmc spi, then likely degrade performance/throughput. What do you think? [...] Kind regards Uffe
