From: Enrico Mioso <mrkiko.rs@gmail.com>
To: "Bjørn Mork" <bjorn@mork.no>
Cc: netdev@vger.kernel.org
Subject: [PATCH] usbnet: cdc_ncm: remove huawei devices handled by cdc_ncm_huawei.c
Date: Wed, 3 Jul 2013 15:13:34 +0200 (CEST) [thread overview]
Message-ID: <alpine.LNX.2.02.1307031511140.25159@eeeadesso> (raw)
In-Reply-To: <871u7gvz2z.fsf@nemi.mork.no>
Some huawei devices implements an NCM-like protocol, but require applications
to manage the link in a different mamner.
So another driver is needed to handle them.
Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 62686be..31f43f7 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1236,17 +1236,6 @@ static const struct usb_device_id cdc_devs[] = {
.driver_info = (unsigned long)&wwan_info,
},
- /* Huawei NCM devices disguised as vendor specific */
- { USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x16),
- .driver_info = (unsigned long)&wwan_info,
- },
- { USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x46),
- .driver_info = (unsigned long)&wwan_info,
- },
- { USB_VENDOR_AND_INTERFACE_INFO(0x12d1, 0xff, 0x02, 0x76),
- .driver_info = (unsigned long)&wwan_info,
- },
-
/* Infineon(now Intel) HSPA Modem platform */
{ USB_DEVICE_AND_INTERFACE_INFO(0x1519, 0x0443,
USB_CLASS_COMM,
On Wed, 3 Jul 2013, Bj?rn Mork wrote:
==Date: Wed, 03 Jul 2013 10:15:32 +0200
==From: Bj?rn Mork <bjorn@mork.no>
==To: Enrico Mioso <mrkiko.rs@gmail.com>
==Cc: netdev@vger.kernel.org
==Subject: Re: Huaei E3131 - status
==
==Enrico Mioso <mrkiko.rs@gmail.com> writes:
==
==> Ok ... As Bjorn stated, cdc-wdm is handling the notifications now - or, better:
==> is not handling them, as it is not made to do these things! The connection
==> stays up and the character device seems to work properly. Obviously cdc-wdm
==> notices me about one single unknown notifications.
==> We're ignoring all the notifications from the NCM erspective, but all works
==> because the device probably doesn't rely on them so much.
==> Aniway - now I'm conscious about why it works. Now it's time to improve the
==> situation of the driver, and might be the api. Waiting for suggestions and
==> injuries! :)
==
==The only notification actually used for anything by cdc_ncm is
==USB_CDC_NOTIFY_NETWORK_CONNECTION, which it uses to set the link up or
==down. That functionality is disabled in your driver, leaving the link
==always up.
==
==This is of course not entirely correct if we apply a strict NCM
==specification to this driver. But it does no harm either. You have
==added support for the embedded management channel, which must be used to
==configure and connect the device. Connection status will also be
==reported here, and the managing userspace application (for example
==ModemManager) will use this to pick up the actual network connection
==state. So the link state reported by NCM is redundant for these
==devices.
==
==The issue is that the few simple notifications standardized in CDC NCM
==are sufficient for management of ethernet connections, but not for
==3G/LTE connections. That's why you need access to the additional vendor
==specific management channel in the first place. And when you have that
==channel, then the additional NCM notifications are redundant at best.
==Or confusing at worst.
==
==The second notification implemented by cdc_ncm is
==USB_CDC_NOTIFY_SPEED_CHANGE, which is shown in your logs. But there is
==nothing cdc_ncm can do with this, so it will just log it. That's mostly
==useless, both for wired and wireless devices. 3G/LTE management
==applications will pick up the same information via the appropriate
==management channel instead.
==
==So the main reason why you should implement support for these
==notifications eventually is not so much to handle them, but to silence
==cdc-wdm. It will otherwise complain, which will confuse some users. But
==this is a really minor issue, and I see no reason why it should hold
==back this driver. It is perfectly usable as it is, and all necessary
==features are implemented.
==
==
==Bj?rn
==
next prev parent reply other threads:[~2013-07-03 13:13 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-02 10:43 [PATCH RFC] cdc_ncm.c: make rx and tx functions exportable Enrico Mioso
2013-07-02 12:01 ` Bjørn Mork
2013-07-02 12:05 ` Enrico Mioso
2013-07-02 17:04 ` [RFC] huawei_cdc_ncm driver - status Enrico Mioso
2013-07-02 19:06 ` Enrico Mioso
2013-07-02 20:06 ` [PATCH 0/3] make cdc_ncm_tx_fixup and cdc_ncm_rx_fixup non-static functions Enrico Mioso
2013-07-02 20:10 ` [PATCH 1/3] Export cdc_ncm_{tx,rx}_fixup functions Enrico Mioso
2013-07-02 20:13 ` [PATCH RFC 2/3] Introduce huawei_cdc_ncm driver Enrico Mioso
2013-07-02 20:15 ` [PATCH RFC 3/3] huawei_cdc_ncm base skeleton Enrico Mioso
2013-07-03 6:40 ` Huaei E3131 - connected! Enrico Mioso
2013-07-03 7:11 ` Huaei E3131 - status Enrico Mioso
2013-07-03 8:15 ` Bjørn Mork
2013-07-03 12:55 ` [PATCH V2 1/3] usbnet: cdc_ncm: let cdc_ncm_tx_fixup and cdc_ncm_rx_fixup be non-static Enrico Mioso
2013-07-03 13:00 ` [PATCH V2 2/3] usbnet: cdc_ncm: export cdc_ncm_tx_fixup and cdc_ncm_rx_fixup Enrico Mioso
2013-07-03 13:19 ` Sergei Shtylyov
2013-07-03 13:22 ` Enrico Mioso
2013-07-03 13:33 ` [PATCH V3 1/2] Export cdc_ncm_{tx,rx]_fixup functions Enrico Mioso
2013-07-03 13:38 ` [PATCH V3 2/2] Introduce huawei_cdc_ncm driver Enrico Mioso
2013-07-03 16:18 ` Ben Hutchings
2013-07-03 18:11 ` [PATCH V3 2/2 RESEND] " Enrico Mioso
2013-07-04 13:19 ` Bjørn Mork
2013-07-04 17:03 ` Enrico Mioso
2013-07-03 18:11 ` [PATCH V3 2/2] " Enrico Mioso
2013-07-03 13:05 ` [PATCH V2 3/3] usbnet: introduce " Enrico Mioso
2013-07-03 13:13 ` Enrico Mioso [this message]
2013-07-03 7:13 ` Huaei E3131 - connected! Bjørn Mork
2013-07-03 7:38 ` [PATCH RFC 3/3] huawei_cdc_ncm base skeleton Bjørn Mork
2013-07-03 10:16 ` Enrico Mioso
2013-07-03 7:40 ` [PATCH RFC 2/3] Introduce huawei_cdc_ncm driver Bjørn Mork
2013-07-03 7:43 ` [PATCH 1/3] Export cdc_ncm_{tx,rx}_fixup functions Bjørn Mork
2013-07-03 10:19 ` Enrico Mioso
2013-07-03 7:45 ` [PATCH 0/3] make cdc_ncm_tx_fixup and cdc_ncm_rx_fixup non-static functions Bjørn Mork
2013-07-10 12:27 ` [PATCH 1/3] net: cdc_ncm: Export cdc_ncm_{tx,rx}_fixup functions for re-use Enrico Mioso
[not found] ` <0cbf7c81-182e-493c-9c28-5b78160a08f1@email.android.com>
[not found] ` <alpine.LNX.2.02.1307170457450.1161@eeeadesso>
[not found] ` <87bo4xx3ef.fsf@nemi.mork.no>
[not found] ` <87bo4xx3ef.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
2013-08-16 13:39 ` [PATCH] " Enrico Mioso
2013-08-16 13:49 ` Greg Kroah-Hartman
2013-08-16 13:51 ` Enrico Mioso
2013-08-16 13:52 ` Greg Kroah-Hartman
2013-08-16 13:44 ` [PATCH] net: huawei_cdc_ncm: Introduce new huawei_cdc_ncm driver Enrico Mioso
2013-07-10 12:28 ` [PATCH 2/3] net: huawei_cdc_ncm: Introduce the " Enrico Mioso
2013-07-10 12:30 ` [PATCH 3/3] net: cdc_ncm: remove Huawei non-standard NCM device IDs Enrico Mioso
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.02.1307031511140.25159@eeeadesso \
--to=mrkiko.rs@gmail.com \
--cc=bjorn@mork.no \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).