On Mon, 2016-07-04 at 19:01 +0200, Bjørn Mork wrote:
> The proposed driver solution is a hack, allowing us to resyncronize
> without resetting the firmware. We have no reliable way to reset the
> firmware and doing so will have large side effects anyway. The hack
> allows us to continue, with a possibly lost message or two as the only
> consequences. We don't have to break any existing session etc.
OK, then I propose it is time to bring out the sledge hammer.
How about changing usb_cdc_wdm_register() to include a flag
about the necessity to drain the buffers?
> But it turns out that it is a real problem for the very same MBIM
> firmwares which caused us to need the hack in the first place: They
> stall when you try to read and there is no data. Which means that a
> lost race can end up with an EPIPE being returned to _read(), where it
> is translated and returned to userspace.
This sucks and it tells me even more that CDC MBIM should tell us when
to apply this work around at startup.
> This is a mess. I fully agree that it looks like this either should go
> into both open() and resume(), or none. The real answer is 'none'.
>
> But we need the hack for the yucky MBIM firmwares. Putting it in open()
> is defining open() as a syncronization point for something which should
> not need syncronization in a perfect world. I can expand the comment
> there a bit to make this clear. Making resume() a syncronization point
> as well is only making things worse.
I'd say add a flag, let CDC MBIM set it unconditionally (we can switch
to a black list if we absolutely need to) and include a big, fat
commentary. There is no good solution for this problem.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
