All of lore.kernel.org
 help / color / mirror / Atom feed
From: Enrico Mioso <mrkiko.rs@gmail.com>
To: Dan Williams <dcbw@redhat.com>
Cc: "Bjørn Mork" <bjorn@mork.no>,
	netdev@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH net,stable] net: huawei_cdc_ncm: increase command buffer size
Date: Wed, 18 Jun 2014 18:32:58 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LNX.2.03.1406181831060.596@gmail.com> (raw)
In-Reply-To: <1403100197.2266.14.camel@dcbw.local>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3580 bytes --]

I am sorry - I am not in good conditions to perform the testing. But - I think 
it sould be fine anyway.
Sorry Bjorn. I might be able to do it in the weekend if you would like.
Enrico


On Wed, 18 Jun 2014, Dan Williams wrote:

==Date: Wed, 18 Jun 2014 16:03:17
==From: Dan Williams <dcbw@redhat.com>
==To: Bjørn Mork <bjorn@mork.no>
==Cc: netdev@vger.kernel.org, linux-usb@vger.kernel.org,
==    Enrico Mioso <mrkiko.rs@gmail.com>
==Subject: Re: [PATCH net,
==    stable] net: huawei_cdc_ncm: increase command buffer size
==
==On Wed, 2014-06-18 at 14:21 +0200, Bjørn Mork wrote:
==> 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@gmail.com>
==> Reported-by: Dan Williams <dcbw@redhat.com>
==> Signed-off-by: Bjørn Mork <bjorn@mork.no>
==
==Tested-by: Dan Williams <dcbw@redhat.com>
==
=='<CR><LF>^SYSCFGEX:
==("00","01","02","03","99"),((400380,"GSM900/GSM1800/WCDMA2100"),(6a80000,"GSM850/GSM1900/WCDMA850/AWS/WCDMA1900"),(3fffffff,"All bands")),(0-2),(0-4),((1081b,"LTE_B1/LTE_B2/LTE_B4/LTE_B5/LTE_B12/LTE_B17"),(7fffffffffffffff,"All bands"))<CR><LF><CR><LF>OK<CR><LF>'
==
==I get the last "<LF>" now :)
==
==> ---
==> 
==> The problem is a showstopper for anyone hitting it, so I believe this
==> fix should go into all maintained stable kernels with this driver.
==> That is anything based on v3.13 or newer.
==> 
==> Thanks,
==> Bjørn
==> 
==> 
==>  drivers/net/usb/huawei_cdc_ncm.c | 7 ++++---
==>  1 file changed, 4 insertions(+), 3 deletions(-)
==> 
==> diff --git a/drivers/net/usb/huawei_cdc_ncm.c b/drivers/net/usb/huawei_cdc_ncm.c
==> index f9822bc75425..5d95a13dbe2a 100644
==> --- 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 usbnet *usbnet_dev,
==>  	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);
==
==
==

  reply	other threads:[~2014-06-18 16:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-18 12:21 [PATCH net,stable] net: huawei_cdc_ncm: increase command buffer size Bjørn Mork
     [not found] ` <1403094084-13588-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
2014-06-18 13:41   ` Enrico Mioso
2014-06-18 13:45   ` Enrico Mioso
2014-06-18 14:03 ` Dan Williams
2014-06-18 16:32   ` Enrico Mioso [this message]
2014-06-18 17:55     ` Bjørn Mork
     [not found]   ` <1403100197.2266.14.camel-ZWpNTBV2bRGs1BDpvl8NfQ@public.gmane.org>
2014-06-19  7:48     ` Enrico Mioso
2014-06-22  2:34 ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LNX.2.03.1406181831060.596@gmail.com \
    --to=mrkiko.rs@gmail.com \
    --cc=bjorn@mork.no \
    --cc=dcbw@redhat.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.