linux-kernel - Add the infamous Huawei E220 to option.c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20071128161305.b01167b3.zaitcev@redhat.com>
Date:	Wed, 28 Nov 2007 16:13:05 -0800
From:	Pete Zaitcev <zaitcev@...hat.com>
To:	linux-usb@...r.kernel.org
Cc:	zaitcev@...hat.com, <preining@...ic.at>,
	<kristoffer.ericson@...il.com>, <drussell@...hat.com>,
	<johann.wilhelm@...dent.tugraz.at>, linux-kernel@...r.kernel.org
Subject: Add the infamous Huawei E220 to option.c

Hi, All:

It looks like the Huawei E220 saga is not over yet. A collegue of mine,
David Russll, reported that the modem does not work reliably on Fedora 8,
which does have the initializer in usb-storage.

The problem stems from the fact that both option and usb-storage can bind
to the modem when in storage mode: the former binds because of the storage
class, the latter binds because of VID/PID match. The modprobe loads both,
it's random which wins. If usb-storage wins, everything is fine. If option
wins, it binds to modem still in storage mode and does not work.

I propose we add the same initializer that usb-storage has to the option.
This way no matter which driver wins the modem gets initialized. The
patch is tested on David's modem, but I would like someone give it more
testing.

I dunno, do we want some kind of code sharing between storage and option?
They both could use the normal usb_control_msg, I think.

Also, from archives it looks like Johann may need PID 0x1004 added.

Since we're on topic, David's modem has exactly same IDs as Norbert's,
but works fine with the length of 1. Although it's possible that the
firmware is different without different firmware reported in USB desc-
riptors. Does anyone know a magic AT command? ATI or something?
Norbert, please try my patch, maybe it'll work this time.

And finally, pleas stop using that script from the polish website and
above all quit using the generic serial subdriver. The option must
work now with the patch. Please let me know if it fails.

Thanks in advance,
-- Pete

diff -urp -X dontdiff linux-2.6.23.1-42.fc8/drivers/usb/serial/option.c linux-2.6.23.1-42.fc8.e220.1/drivers/usb/serial/option.c
--- linux-2.6.23.1-42.fc8/drivers/usb/serial/option.c	2007-10-09 13:31:38.000000000 -0700
+++ linux-2.6.23.1-42.fc8.e220.1/drivers/usb/serial/option.c	2007-11-27 21:36:11.000000000 -0800
@@ -448,7 +448,7 @@ static void option_indat_callback(struct
 			err = usb_submit_urb(urb, GFP_ATOMIC);
 			if (err)
 				printk(KERN_ERR "%s: resubmit read urb failed. "
-					"(%d)", __FUNCTION__, err);
+					"(%d)\n", __FUNCTION__, err);
 		}
 	}
 	return;
@@ -728,6 +728,35 @@ static int option_send_setup(struct usb_
 	return 0;
 }

+static void option_start_huawei(struct usb_serial *serial)
+{
+	struct usb_device *dev = serial->dev;
+	char *buf;
+	int rc;
+
+	if (!(le16_to_cpu(dev->descriptor.idVendor) == HUAWEI_VENDOR_ID &&
+	    le16_to_cpu(dev->descriptor.idProduct) == HUAWEI_PRODUCT_E220))
+		return;
+
+	if ((buf = kmalloc(1, GFP_KERNEL)) == 0)
+		goto err_buf;
+
+	buf[0] = 0x1;
+	rc = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
+		USB_REQ_SET_FEATURE, USB_TYPE_STANDARD | USB_RECIP_DEVICE,
+		0x01, 0x0, buf, 1, 1000);
+	if (rc) {
+		printk(KERN_ERR "%s: HUAWEI E220 setup failed (%d)\n",
+		    __FUNCTION__, rc);
+	}
+
+	kfree(buf);
+	return;
+
+err_buf:
+	;
+}
+
 static int option_startup(struct usb_serial *serial)
 {
 	int i, err;
@@ -736,6 +765,8 @@ static int option_startup(struct usb_ser

 	dbg("%s", __FUNCTION__);

+	option_start_huawei(serial);
+
 	/* Now setup per port private data */
 	for (i = 0; i < serial->num_ports; i++) {
 		port = serial->port[i];
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/