[PATCH net-next 2/2] caif_usb: Make the driver name check more efficient

[PATCH net-next 2/2] caif_usb: Make the driver name check more efficient

[Ben Hutchings]

Use the device model to get just the name, rather than using the
ethtool API to get all driver information.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
Compile-tested only.  I'm assuming that the strncmp() is not really
necessary, but perhaps there is some OOT variant of cdc_ncm that is also
supposed to be supported?

Ben.

 net/caif/caif_usb.c |   13 +++----------
 1 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/net/caif/caif_usb.c b/net/caif/caif_usb.c
index 582f80c..3ebc8cb 100644
--- a/net/caif/caif_usb.c
+++ b/net/caif/caif_usb.c
@@ -128,17 +128,10 @@ static int cfusbl_device_notify(struct notifier_block *me, unsigned long what,
 	struct cflayer *layer, *link_support;
 	struct usbnet *usbnet;
 	struct usb_device *usbdev;
-	struct ethtool_drvinfo drvinfo;
 
-	/*
-	 * Quirks: High-jack ethtool to find if we have a NCM device,
-	 * and find it's VID/PID.
-	 */
-	if (dev->ethtool_ops == NULL || dev->ethtool_ops->get_drvinfo == NULL)
-		return 0;
-
-	dev->ethtool_ops->get_drvinfo(dev, &drvinfo);
-	if (strncmp(drvinfo.driver, "cdc_ncm", 7) != 0)
+	/* Check whether we have a NCM device, and find its VID/PID. */
+	if (!(dev->dev.parent && dev->dev.parent->driver &&
+	      strcmp(dev->dev.parent->driver->name, "cdc_ncm") == 0))
 		return 0;
 
 	usbnet = netdev_priv(dev);
-- 
1.7.7.6


-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Experimental network protocol produces "dropping frag"

[Templin, Fred L]

Hello,

Under the 3.2.17 kernel, I am working with an experimental
tunneling protocol. I am using ip-proto-253 for the experiment,
and have coded the tunnel code in as a module under net/ipv4
by cloning net/ipv4/ip_gre.c. I have been testing the module
by using modprobe to reload the module without rebooting the
machines.

I was successfully able to send and receive packets via the
tunnel and verified that both directions were working using
tcpdump and wireshark which showed ip-proto-253 packets going
in both directions. Since then, however, I recompiled and
reinistalled the entire kernel and rebooted the machines.

Now, I can still send my ip-proto-253 packets, but on the
receiving side I see dmesg output that says:

  "dropping frag"

for every packet received. The input packets appear to be
accounted for when I type "ifconfig eth0" (i.e., the input
packet count is incrementing) but printk's from my tunnel
driver code are not showing up when I type dmesg and
"ifconfig tun0" on the tunnel interface does not show any
input packets. It is as if the receiver has "forgotten"
how to deal with ip-proto-253.

Any ideas on how I may have shot myself in the foot, and
ways to recover?

Thanks - Fred
fred.l.templin@boeing.com

Re: [PATCH net-next 2/2] caif_usb: Make the driver name check more efficient

[David Miller]

From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 7 Dec 2012 16:20:27 +0000

> Use the device model to get just the name, rather than using the
> ethtool API to get all driver information.
> 
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
> Compile-tested only.  I'm assuming that the strncmp() is not really
> necessary, but perhaps there is some OOT variant of cdc_ncm that is also
> supposed to be supported?

Applied, I guess you found this while looking around for tests
of ethtool_ops being NULL?

Re: [PATCH net-next 2/2] caif_usb: Make the driver name check more efficient

[Ben Hutchings]

On Sun, 2012-12-09 at 00:34 -0500, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Fri, 7 Dec 2012 16:20:27 +0000
> 
> > Use the device model to get just the name, rather than using the
> > ethtool API to get all driver information.
> > 
> > Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> > ---
> > Compile-tested only.  I'm assuming that the strncmp() is not really
> > necessary, but perhaps there is some OOT variant of cdc_ncm that is also
> > supposed to be supported?
> 
> Applied, I guess you found this while looking around for tests
> of ethtool_ops being NULL?

Yes.  These (bonding and caif_usb) weren't the only ones, though.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.