On Mon, 2017-09-25 at 11:33 +0800, Shawn Lin wrote: > >> I'm just curious about if these ATP cards could work for ACMD23? > >> > >> Could you kindly try this patch? > >> > >> |https://patchwork.kernel.org/patch/9887651/ > > > > By looking at your patch I can see that bool variable 'need_acmd23' is > > only set when card does not support CMD23. But here this card (falsely) > > claims to support CMD23, which is the whole point of the NO_CMD23 quirk. > > > > So testing your patch would not make any difference, because its > > yup, sorry fot that. I mean you could hack it a little to mask > CMD23 support and let ACMD23 take effect, and see how it would > go? forcing ACMD23 instead of CMD23 works fine: dd if=/dev/urandom of=/mnt/test bs=1M count=100 conv=fsync 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 9.9496 s, 10.5 MB/s It's as fast as using my NO_CMD23 quirk. > >>>> /* > >>>> + * Some SD cards lockup while using CMD23 multiblock transfers. > >>>> + */ > >>>> + MMC_FIXUP("AF SD", CID_MANFID_ATP, CID_OEMID_ANY, add_quirk_sd, > >>>> + MMC_QUIRK_BLK_NO_CMD23), > >>> > >>> Is really all ATP cards having this problem? Perhaps we should > >>> consider making this a bit more fine grained? > >>> > >>> On the other hand, this may be the safest way to do it... > > > > I also thought about this and set CID_OEMID_ANY because I wanted to be > > on the safe side. Maybe ATP can comment on this (in CC)? Thanks -- Christoph -- 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
