| Message ID | 20171214185550.15779-1-bjorn@mork.no |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
| Series | [net-next] qmi_wwan: set FLAG_SEND_ZLP to avoid network initiated disconnect | expand |
On Thu, Dec 14, 2017 at 07:55:50PM +0100, Bjørn Mork wrote: > It has been reported that the dummy byte we add to avoid > ZLPs can be forwarded by the modem to the PGW/GGSN, and that > some operators will drop the connection if this happens. > > In theory, QMI devices are based on CDC ECM and should as such > both support ZLPs and silently ignore the dummy byte. The latter > assumption failed. Let's test out the first. > > Signed-off-by: Bjørn Mork <bjorn@mork.no> > --- > I am a bit worried about the effect of this change on all the > devices I can't test myself. But trying it is the only way we > can ever find out.... flag zlp is tested with pids: 9034,9048,904c,9075, 908E,9079, 908A,909F and 90A4. In general, qualcomm usb firmware can handle zlps.
Vamsi Samavedam <vskrishn@codeaurora.org> writes: > On Thu, Dec 14, 2017 at 07:55:50PM +0100, Bjørn Mork wrote: >> It has been reported that the dummy byte we add to avoid >> ZLPs can be forwarded by the modem to the PGW/GGSN, and that >> some operators will drop the connection if this happens. >> >> In theory, QMI devices are based on CDC ECM and should as such >> both support ZLPs and silently ignore the dummy byte. The latter >> assumption failed. Let's test out the first. >> >> Signed-off-by: Bjørn Mork <bjorn@mork.no> >> --- >> I am a bit worried about the effect of this change on all the >> devices I can't test myself. But trying it is the only way we >> can ever find out.... > > flag zlp is tested with pids: 9034,9048,904c,9075, 908E,9079, > 908A,909F and 90A4. In general, qualcomm usb firmware can > handle zlps. Thanks. That's very good to know. Bjørn
From: Bjørn Mork <bjorn@mork.no> Date: Thu, 14 Dec 2017 19:55:50 +0100 > It has been reported that the dummy byte we add to avoid > ZLPs can be forwarded by the modem to the PGW/GGSN, and that > some operators will drop the connection if this happens. > > In theory, QMI devices are based on CDC ECM and should as such > both support ZLPs and silently ignore the dummy byte. The latter > assumption failed. Let's test out the first. > > Signed-off-by: Bjørn Mork <bjorn@mork.no> > --- > I am a bit worried about the effect of this change on all the > devices I can't test myself. But trying it is the only way we > can ever find out.... :-) Applied to net-next, thanks.
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c index 304ec6555cd8..1ed00519f29e 100644 --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -826,7 +826,7 @@ static int qmi_wwan_resume(struct usb_interface *intf) static const struct driver_info qmi_wwan_info = { .description = "WWAN/QMI device", - .flags = FLAG_WWAN, + .flags = FLAG_WWAN | FLAG_SEND_ZLP, .bind = qmi_wwan_bind, .unbind = qmi_wwan_unbind, .manage_power = qmi_wwan_manage_power, @@ -835,7 +835,7 @@ static const struct driver_info qmi_wwan_info = { static const struct driver_info qmi_wwan_info_quirk_dtr = { .description = "WWAN/QMI device", - .flags = FLAG_WWAN, + .flags = FLAG_WWAN | FLAG_SEND_ZLP, .bind = qmi_wwan_bind, .unbind = qmi_wwan_unbind, .manage_power = qmi_wwan_manage_power,
It has been reported that the dummy byte we add to avoid ZLPs can be forwarded by the modem to the PGW/GGSN, and that some operators will drop the connection if this happens. In theory, QMI devices are based on CDC ECM and should as such both support ZLPs and silently ignore the dummy byte. The latter assumption failed. Let's test out the first. Signed-off-by: Bjørn Mork <bjorn@mork.no> --- I am a bit worried about the effect of this change on all the devices I can't test myself. But trying it is the only way we can ever find out.... drivers/net/usb/qmi_wwan.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)