On 15.04.24 08:47, Bjørn Mork wrote:
I'm not sure I understand what problem that patch is supposed to fix. Which means that everything I write could be completely wrong...
wdm_in_callback() can schedule service_outs_intr(), which can call service_outstanding_interrupt(), which sets WDM_RESPONDING and submits desc->response. That is not problematic in itself, but wdm_read() also calls service_outstanding_interrupt(), which can lead to teh same URB being submitted twice (which caused me to write the patch) or, apparently, in this case, it leads to discarding a buffer by resubmitting and completing an URB.
But to me it looks like the described issue is exactly what you should expect if that change ever triggers. I believe we must resubmit the
Yes, it does.
urb from service_outstanding_interrupt(). That's why it was added. See the explanation Robert wrote when introducing it: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/class/cdc-wdm.c?id=c1da59dad0ebd3f9bd238f3fff82b1f7ffda7829
Well, the explanation is correct in that we must read data available. However, if the RESPONDING flag is set and the URB submitted, we are already doing so.
As for the XMM behaviour: it's been a long time since I tried any of those, but AFAIR one the major differences compared to Qualcomm was the strict queue handling in the firmware. This caused a number of problems where the cdc-wdm driver wanted to skip a message for some reason. So I'm not surprised that a bug like this is triggered by one of those modems. That's probably the only thing they are good for :-)
I am not sure where exactly the issue lies here. Suggestions for debugging? Regards Oliver
