From mboxrd@z Thu Jan 1 00:00:00 1970 From: Enrico Mioso Subject: Re: Is this 32-bit NCM? Date: Tue, 2 Dec 2014 12:39:38 +0100 (CET) Message-ID: References: <87ppc957h1.fsf@nemi.mork.no> <874mtl55ar.fsf@nemi.mork.no> <87ppc71xne.fsf@nemi.mork.no> <547D37CA.7050506@audiocodes.com> <547D5F84.6020608@audiocodes.com> <547D6D7B.5090704@audiocodes.com> <547D7243.80508@audiocodes.com> <87fvcyqoup.fsf@nemi.mork.no> Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-1669091443-1417520380=:29454" Cc: Kevin Zhu , Eli Britstein , Alex Strizhevsky , Midge Shaojun Tan , "youtux@gmail.com" , "linux-usb@vger.kernel.org" , "netdev@vger.kernel.org" To: =?ISO-8859-15?Q?Bj=F8rn_Mork?= Return-path: Received: from mail-wg0-f42.google.com ([74.125.82.42]:55287 "EHLO mail-wg0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932760AbaLBLjI (ORCPT ); Tue, 2 Dec 2014 06:39:08 -0500 In-Reply-To: <87fvcyqoup.fsf@nemi.mork.no> Sender: netdev-owner@vger.kernel.org List-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1669091443-1417520380=:29454 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: 8BIT To be clear - I also rebooted the remote system to power cycle the modem, wanting to avoid at^reset But this modification of the driver unfortunately seems to lead to no changes. Thank you so much Bjorn. Interetingly - a misbehaviour of the firmware was observed - I wasn't able to at^ndisdup=1,0 ... the firmware seemed to ignore it. But this might not be related to the patch. Thank you again. Enrico On Tue, 2 Dec 2014, Bjørn Mork wrote: ==Date: Tue, 2 Dec 2014 12:21:18 ==From: Bjørn Mork ==To: Enrico Mioso ==Cc: Kevin Zhu , == Eli Britstein , == Alex Strizhevsky , == Midge Shaojun Tan , == "youtux@gmail.com" , == "linux-usb@vger.kernel.org" , == "netdev@vger.kernel.org" ==Subject: Re: Is this 32-bit NCM? == ==Enrico Mioso writes: == ==> Kevin - it works! the key seems to be in the tx_fixup function; there is a ==> special handling for frames effectively. ==> Please ... help me backport those changes to the standard Linux driver - it ==> will be a gain for us all, and in general you'll have a more probable ==> maintenance than you would with the driver from huawei. == ==Very interesting. The NCM code in the huawei driver has a different ==origin, so it is quite different and not too easy to merge into the ==existing Linux cdc_ncm driver. == ==But this does pinpoint differences we should explore. One is the ==placement of the NDP: The Huawei driver puts it at the end. Another, ==which is much easier to test out quickly, is the sequence numbering: The ==Huawei driver doesn't use it. == ==So I wonder if this makes any difference: == ==diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c ==index 80a844e0ae03..37f11770acb6 100644 ==--- a/drivers/net/usb/cdc_ncm.c ==+++ b/drivers/net/usb/cdc_ncm.c ==@@ -1049,7 +1049,7 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign) == nth16 = (struct usb_cdc_ncm_nth16 *)memset(skb_put(skb_out, sizeof(struct usb_cdc_ncm_nth16)), 0, sizeof(struct usb_cdc_ncm_nth16)); == nth16->dwSignature = cpu_to_le32(USB_CDC_NCM_NTH16_SIGN); == nth16->wHeaderLength = cpu_to_le16(sizeof(struct usb_cdc_ncm_nth16)); ==- nth16->wSequence = cpu_to_le16(ctx->tx_seq++); ==+// nth16->wSequence = cpu_to_le16(ctx->tx_seq++); == == /* count total number of frames in this NTB */ == ctx->tx_curr_frame_num = 0; == == == ==Bjørn == --8323328-1669091443-1417520380=:29454--