[PATCH] CDC_NCM adding support IFF_NOARP for infineon modem platform

Infineon(now Intel) HSPA Modem platform NCM cannot support ARP. so I introduce a flag CDC_NCM_DRIVER_DATA_NOARP which is defined in driver_info:data. so later on, if more such buggy devices are found, they could use same flag to handle. 

Signed-off-by: Wei Shuai <redacted>
---
 drivers/net/usb/cdc_ncm.c |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 71b6e92..6093e07 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c

@@ -55,6 +55,9 @@
 
 #define	DRIVER_VERSION				"14-Mar-2012"
 
+/* Flags for driver_info::data */
+#define CDC_NCM_DRIVER_DATA_NOARP  1
+
 static void cdc_ncm_txpath_bh(unsigned long param);
 static void cdc_ncm_tx_timeout_start(struct cdc_ncm_ctx *ctx);
 static enum hrtimer_restart cdc_ncm_tx_timer_cb(struct hrtimer *hr_timer);

@@ -573,6 +576,10 @@ static int cdc_ncm_bind(struct usbnet *dev, struct usb_interface *intf)
 		return -ENODEV;
 #endif
 
+	if (dev->driver_info->data & CDC_NCM_DRIVER_DATA_NOARP) {
+		/* some buggy device cannot do ARP*/
+		dev->net->flags |= IFF_NOARP;
+	}
 	/* NCM data altsetting is always 1 */
 	ret = cdc_ncm_bind_common(dev, intf, 1);
 

@@ -1155,6 +1162,21 @@ static const struct driver_info wwan_info = {
 	.tx_fixup = cdc_ncm_tx_fixup,
 };
 
+/* Same as wwan_info, but with IFF_NOARP  */
+static const struct driver_info wwan_noarp_info = {
+	.description = "Mobile Broadband Network Device (NO ARP)",
+	.flags = FLAG_POINTTOPOINT | FLAG_NO_SETINT | FLAG_MULTI_PACKET
+			| FLAG_WWAN,
+	.data = CDC_NCM_DRIVER_DATA_NOARP,
+	.bind = cdc_ncm_bind,
+	.unbind = cdc_ncm_unbind,
+	.check_connect = cdc_ncm_check_connect,
+	.manage_power = usbnet_manage_power,
+	.status = cdc_ncm_status,
+	.rx_fixup = cdc_ncm_rx_fixup,
+	.tx_fixup = cdc_ncm_tx_fixup,
+};
+
 static const struct usb_device_id cdc_devs[] = {
 	/* Ericsson MBM devices like F5521gw */
 	{ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO

@@ -1194,6 +1216,13 @@ static const struct usb_device_id cdc_devs[] = {
 	  .driver_info = (unsigned long)&wwan_info,
 	},
 
+	/* Infineon(now Intel) HSPA Modem platform */
+	{ USB_DEVICE_AND_INTERFACE_INFO(0x1519, 0x0443,
+		USB_CLASS_COMM,
+		USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
+	  .driver_info = (unsigned long)&wwan_noarp_info,
+	},
+
 	/* Generic CDC-NCM devices */
 	{ USB_INTERFACE_INFO(USB_CLASS_COMM,
 		USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),

-- 
1.7.6.5

From: Wei Shuai <redacted>
Date: Sat, 12 Jan 2013 19:34:39 +0800

Infineon(now Intel) HSPA Modem platform NCM cannot support ARP. so I
introduce a flag CDC_NCM_DRIVER_DATA_NOARP which is defined in
driver_info:data. so later on, if more such buggy devices are found,
they could use same flag to handle.

Is it no able to do ARP or, the more likely case, does broadcast
not work at all?

If it's the latter, IFF_NOARP is just making over the real problem.

I'm not applying this, no hardware device should set IFF_NOARP.
You probably really want IFF_POINTOPOINT or similar.

On Sat, 2013-01-12 at 15:35 -0800, David Miller wrote:

From: Wei Shuai <redacted>
Date: Sat, 12 Jan 2013 19:34:39 +0800

quoted

Infineon(now Intel) HSPA Modem platform NCM cannot support ARP. so I
introduce a flag CDC_NCM_DRIVER_DATA_NOARP which is defined in
driver_info:data. so later on, if more such buggy devices are found,
they could use same flag to handle.

Is it no able to do ARP or, the more likely case, does broadcast
not work at all?

If it's the latter, IFF_NOARP is just making over the real problem.

I'm not applying this, no hardware device should set IFF_NOARP.
You probably really want IFF_POINTOPOINT or similar.

IFF_NOARP is already done for other WWAN devices (sierra_net, hso,
cdc-ether, cdc-phonet, lg-vl600, etc) so there is some precedent.  Some
drivers (phonet, hso) set *both* POINTTOPOINT and NOARP.  Is that
redundant, and should all WWAN drivers be moved to only POINTTOPOINT?

(aside: usbnet has FLAG_POINTTOPOINT, but that's nothing to do with
IFF_POINTTOPOINT, it only controls whether the interface is named usbX
or ethX.  Confusing.)

Dan

From: Dan Williams <redacted>
Date: Mon, 14 Jan 2013 11:19:13 -0600

On Sat, 2013-01-12 at 15:35 -0800, David Miller wrote:

quoted

From: Wei Shuai <redacted>
Date: Sat, 12 Jan 2013 19:34:39 +0800

quoted

Infineon(now Intel) HSPA Modem platform NCM cannot support ARP. so I
introduce a flag CDC_NCM_DRIVER_DATA_NOARP which is defined in
driver_info:data. so later on, if more such buggy devices are found,
they could use same flag to handle.

Is it no able to do ARP or, the more likely case, does broadcast
not work at all?

If it's the latter, IFF_NOARP is just making over the real problem.

I'm not applying this, no hardware device should set IFF_NOARP.
You probably really want IFF_POINTOPOINT or similar.

IFF_NOARP is already done for other WWAN devices (sierra_net, hso,
cdc-ether, cdc-phonet, lg-vl600, etc) so there is some precedent.  Some
drivers (phonet, hso) set *both* POINTTOPOINT and NOARP.  Is that
redundant, and should all WWAN drivers be moved to only POINTTOPOINT?

(aside: usbnet has FLAG_POINTTOPOINT, but that's nothing to do with
IFF_POINTTOPOINT, it only controls whether the interface is named usbX
or ethX.  Confusing.)

I can't answer any of your questions unless you tell me what the
real limitation of these devices is.

For the second time, is the problem that these devices cannot
support broadcast packets properly?

David Miller wrote:

quoted

should all WWAN drivers be moved to only POINTTOPOINT?

I can't answer any of your questions unless you tell me what the
real limitation of these devices is.

It's rather about the network than any given devices, right?


//Peter

David Miller [off-list ref] writes:

From: Dan Williams <redacted>

quoted

IFF_NOARP is already done for other WWAN devices (sierra_net, hso,
cdc-ether, cdc-phonet, lg-vl600, etc) so there is some precedent.  Some
drivers (phonet, hso) set *both* POINTTOPOINT and NOARP.  Is that
redundant, and should all WWAN drivers be moved to only POINTTOPOINT?

(aside: usbnet has FLAG_POINTTOPOINT, but that's nothing to do with
IFF_POINTTOPOINT, it only controls whether the interface is named usbX
or ethX.  Confusing.)

I can't answer any of your questions unless you tell me what the
real limitation of these devices is.

For the second time, is the problem that these devices cannot
support broadcast packets properly?

The main problem is that these devices don't support ethernet.  They
support IP (v4 and _maybe_ v6) with an ethernet header.  Many of them
will do ARP (and IPv6 ND) as well to complete the picture, but some of
them don't and that's what these drivers try to deal with.

Note that most of the devices will run a DHCP server, so there is some
sort of IP broadcast support.  Whether that qualifies as proper ethernet
broadcast support is another question...

These devices are attempting to bridge an IP-only point-to-point
interface and an ethernet over USB interface, with the intention to make
the point-to-point interface look like ethernet to applications and
users. This is of course always going to be imperfect.  But I believe
that we should aim to help the firmware achive this goal when writing
drivers instead of working against it.  Setting IFF_NOARP and not
IFF_POINTTOPOINT is one way to do that.



Bjørn

yes. usbnet has FLAG_POINTTOPOINT, but that's nothing to do with
IFF_POINTTOPOINT. At least we should do something to handle
relationship of these flags rather than only have different names.
or new flag FLAG_NOARP could be introduced to corresponding to IFF_NOARP.

2013/1/15 Dan Williams [off-list ref]:

On Sat, 2013-01-12 at 15:35 -0800, David Miller wrote:

quoted

From: Wei Shuai <redacted>
Date: Sat, 12 Jan 2013 19:34:39 +0800

quoted

Infineon(now Intel) HSPA Modem platform NCM cannot support ARP. so I
introduce a flag CDC_NCM_DRIVER_DATA_NOARP which is defined in
driver_info:data. so later on, if more such buggy devices are found,
they could use same flag to handle.

Is it no able to do ARP or, the more likely case, does broadcast
not work at all?

If it's the latter, IFF_NOARP is just making over the real problem.

I'm not applying this, no hardware device should set IFF_NOARP.
You probably really want IFF_POINTOPOINT or similar.

IFF_NOARP is already done for other WWAN devices (sierra_net, hso,
cdc-ether, cdc-phonet, lg-vl600, etc) so there is some precedent.  Some
drivers (phonet, hso) set *both* POINTTOPOINT and NOARP.  Is that
redundant, and should all WWAN drivers be moved to only POINTTOPOINT?

(aside: usbnet has FLAG_POINTTOPOINT, but that's nothing to do with
IFF_POINTTOPOINT, it only controls whether the interface is named usbX
or ethX.  Confusing.)

Dan