On 2 May 2018 at 15:16, Michał Pecio <michal.pecio@xxxxxxxxx> wrote: >> 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. That should be okay. > > 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? The mmc core may decide to erase/discard a different numbers of bytes/sectors depending on what the card supports and whether the host have a "max_busy_timeout" set. Moreover, as for the rtsx case, max_busy_timeout isn't set, thus the core always tries with R1B responses, which leads to the rtsx driver uses a fixed 3s timeout for the erase/discard requests. Then, depending on the number of bytes/sectors to be erased, 3s may not be sufficient. > >> 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. That's okay, we should notice quite quickly if it breaks. Moreover, similar tests have been already for the patches to rtsx_pci. > > 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. Right. Thanks for your feedback! Kind regards Uffe -- 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
