Andreas Böhler <[email protected]> writes:
> On 19/09/17 14:25, Bjørn Mork wrote:
>> Bjørn Mork <[email protected]> writes:
>>
>> What happens if you kill the mbim-proxy process? Are you then able to
>> use the modem again without resetting it?
>
> I was unable to test that: It can only be killed using SIGKILL, any new
> mbim-proxy processes are then unable to open the device.
>
>>
>> Maybe we should simply ignore stalls completely? They should not happen
>> with any real WDM device anyway.
>>
>> What happens if you e.g. change the if-test here:
>>
>> /*
>> * only set a new error if there is no previous error.
>> * Errors are only cleared during read/open
>> */
>> if (desc->rerr == 0)
>> desc->rerr = status;
>>
>>
>> to
>>
>> if (desc->rerr == 0 && status != -EPIPE)
>
> Well, this looks very promising: Although the error messages persist
> every now and then, the device now works!
>
> I'll make the new module the default and I'll test it more thouroughly
> during the next few days.
>
> Are you planning on adding a more "proper" fix, i.e. without ignoring
> the error? Or is this something that should be "fixed" in libmbim?
If I only knew what the proper fix was... Ignoring the "error" as such
should not be a big problem. It's really just a signal from the
firmware that there is no data available to read. There are many
similar examples in the Linux USB code. For example from the core code
in drivers/usb/core/message.c:
static int usb_get_string(struct usb_device *dev, unsigned short langid,
unsigned char index, void *buf, int size)
{
int i;
int result;
for (i = 0; i < 3; ++i) {
/* retry on length 0 or stall; some devices are flakey */
result = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
(USB_DT_STRING << 8) + index, langid, buf, size,
USB_CTRL_GET_TIMEOUT);
if (result == 0 || result == -EPIPE)
continue;
if (result > 1 && ((u8 *) buf)[1] != USB_DT_STRING) {
result = -ENODATA;
continue;
}
break;
}
return result;
}
We cannot do the same looping since we are using async requests of
course. We could add a counter to catch repeated errors, but I feel that
is overkill. Ignoring will do.
Bjørn
--
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
