> Yes, we do need a little more than MMC_CAP_ERASE. I have had patches > for this in my pipe for a while, but never got to the point of posting > them as I needed someone to test them on HW. So the three commits that you posted ought to be enough to get it working and that's what you'd like me to try? I can test them, I guess. Preferebly on 4.9 or 4.14 as I have machines running these kernels right now. I'm still puzzled by the timeouts, though. If the chip responds to USB queries within 25ms and is polled repeteadly until completion, what's the point of having multi-second timeouts for each query? > If you could run a round of tests and preferably add you tested by > tag, that would be great so I can queue them up. OK, so what exactly would constitute a satisfactory "round of tests"? Frankly, I just wanted to wipe a single card in a single USB reader and that's all I tried so far. I could perhaps find some second card for testing and maybe check partial discards or '-o discard' if you think it would be useful, though I'm not sure it would. > I guess you even want them for stable? Your call. I personally have no need for that. I suppose it may also enable '-o discard' on some systems which are currently running without that, hard to guess whether it's desired by their owners. -- 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
