Patch "net: huawei_cdc_ncm: increase command buffer size" has been added to the 3.14-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    net: huawei_cdc_ncm: increase command buffer size

to the 3.14-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     net-huawei_cdc_ncm-increase-command-buffer-size.patch
and it can be found in the queue-3.14 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.


>From foo@baz Sat Jul 26 10:08:04 PDT 2014
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= <bjorn@xxxxxxx>
Date: Wed, 18 Jun 2014 14:21:24 +0200
Subject: net: huawei_cdc_ncm: increase command buffer size
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= <bjorn@xxxxxxx>

[ Upstream commit 3acc74619b0175b7a154cf8dc54813f6faf97aa9 ]

Messages from the modem exceeding 256 bytes cause communication
failure.

The WDM protocol is strictly "read on demand", meaning that we only
poll for unread data after receiving a notification from the modem.
Since we have no way to know how much data the modem has to send,
we must make sure that the buffer we provide is "big enough".
Message truncation does not work. Truncated messages are left unread
until the modem has another message to send.  Which often won't
happen until the userspace application has given up waiting for the
final part of the last message, and therefore sends another command.

With a proper CDC WDM function there is a descriptor telling us
which buffer size the modem uses. But with this vendor specific
implementation there is no known way to calculate the exact "big
enough" number.  It is an unknown property of the modem firmware.
Experience has shown that 256 is too small.  The discussion of
this failure ended up concluding that 512 might be too small as
well. So 1024 seems like a reasonable value for now.

Fixes: 41c47d8cfd68 ("net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver")
Cc: Enrico Mioso <mrkiko.rs@xxxxxxxxx>
Reported-by: Dan Williams <dcbw@xxxxxxxxxx>
Signed-off-by: Bjørn Mork <bjorn@xxxxxxx>
Acked-By: Enrico Mioso <mrkiko.rs@xxxxxxxxx>
Tested-by: Dan Williams <dcbw@xxxxxxxxxx>
Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
 drivers/net/usb/huawei_cdc_ncm.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- a/drivers/net/usb/huawei_cdc_ncm.c
+++ b/drivers/net/usb/huawei_cdc_ncm.c
@@ -84,12 +84,13 @@ static int huawei_cdc_ncm_bind(struct us
 	ctx = drvstate->ctx;
 
 	if (usbnet_dev->status)
-		/* CDC-WMC r1.1 requires wMaxCommand to be "at least 256
-		 * decimal (0x100)"
+		/* The wMaxCommand buffer must be big enough to hold
+		 * any message from the modem. Experience has shown
+		 * that some replies are more than 256 bytes long
 		 */
 		subdriver = usb_cdc_wdm_register(ctx->control,
 						 &usbnet_dev->status->desc,
-						 256, /* wMaxCommand */
+						 1024, /* wMaxCommand */
 						 huawei_cdc_ncm_wdm_manage_power);
 	if (IS_ERR(subdriver)) {
 		ret = PTR_ERR(subdriver);


Patches currently in stable-queue which might be from bjorn@xxxxxxx are

queue-3.14/net-qmi_wwan-add-two-sierra-wireless-netgear-devices.patch
queue-3.14/net-huawei_cdc_ncm-add-subclass-3-devices.patch
queue-3.14/net-qmi_wwan-add-id-for-telewell-tw-lte-4g-v2.patch
queue-3.14/net-huawei_cdc_ncm-increase-command-buffer-size.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]