qcserial comes up in unhelpful custom mode?

qcserial comes up in unhelpful custom mode?

[Matthew Garrett]

The qcserial driver appears to bind with the device providing a "QDL" 
interface, whatever that is. The internet suggests that the device needs 
firmware loading before it'll do anything useful. Is there any code out 
there to do this on Linux, or is the driver currently fairly useless?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: qcserial comes up in unhelpful custom mode?

[Greg KH]

On Wed, Apr 01, 2009 at 09:37:26PM +0100, Matthew Garrett wrote:
> The qcserial driver appears to bind with the device providing a "QDL" 
> interface, whatever that is. The internet suggests that the device needs 
> firmware loading before it'll do anything useful. Is there any code out 
> there to do this on Linux, or is the driver currently fairly useless?

I have a package from Qualcom, that dumps the firmware down into the
device.  It includes a udev rule and firmware images to get the modem
working.

Unfortunatly, the license on the code seems to be restricting its
redistribution at the moment, although I have been told this will change
in the future when some machines ship with Linux installed on them with
this hardware included.

But, I have heard reports of people dual-booting with other operating
systems and then successfully using the device under Linux with the
qcserial driver, so that is one solution for some users.

Sorry I don't have better news,

greg k-h

Re: qcserial comes up in unhelpful custom mode?

[Matthew Garrett]

On Thu, Apr 02, 2009 at 07:56:54PM -0700, Greg KH wrote:

> But, I have heard reports of people dual-booting with other operating
> systems and then successfully using the device under Linux with the
> qcserial driver, so that is one solution for some users.

So it's a driver that's useless without a closed source firmware loader, 
either in the form of a Linux userspace application that can't be 
distributed or in the form of Windows? I thought we'd decided that 
drivers weren't going to be merged in that case (poulsbow, the original 
3945 driver)

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: qcserial comes up in unhelpful custom mode?

[Greg KH]

On Fri, Apr 03, 2009 at 02:57:19PM +0100, Matthew Garrett wrote:
> On Thu, Apr 02, 2009 at 07:56:54PM -0700, Greg KH wrote:
> 
> > But, I have heard reports of people dual-booting with other operating
> > systems and then successfully using the device under Linux with the
> > qcserial driver, so that is one solution for some users.
> 
> So it's a driver that's useless without a closed source firmware loader, 
> either in the form of a Linux userspace application that can't be 
> distributed or in the form of Windows?

Hm, I originally thought that as well, but I have a laptop here that
doesn't seem to need the firmware code at all (I deleted it and rebooted
from poweroff and everything worked fine.)

So it seems it depends on the hardware platform.

> I thought we'd decided that drivers weren't going to be merged in that
> case (poulsbow, the original 3945 driver)

We have lots of drivers that rely on firmware that is not in the kernel
to work properly, I see this as just the same thing.

And again, I have been assured that the code is going to be distributed
soon, and that others are already using the driver successfully.

I understand your frustration, sorry.

greg k-h

Re: qcserial comes up in unhelpful custom mode?

[Matthew Garrett]

On Fri, Apr 03, 2009 at 08:03:01AM -0700, Greg KH wrote:
> On Fri, Apr 03, 2009 at 02:57:19PM +0100, Matthew Garrett wrote:
> > So it's a driver that's useless without a closed source firmware loader, 
> > either in the form of a Linux userspace application that can't be 
> > distributed or in the form of Windows?
> 
> Hm, I originally thought that as well, but I have a laptop here that
> doesn't seem to need the firmware code at all (I deleted it and rebooted
> from poweroff and everything worked fine.)
> 
> So it seems it depends on the hardware platform.

Hmm. What's the USB ID of that one?

> > I thought we'd decided that drivers weren't going to be merged in that
> > case (poulsbow, the original 3945 driver)
> 
> We have lots of drivers that rely on firmware that is not in the kernel
> to work properly, I see this as just the same thing.

It's not that it relies on firmware - I can get my hands on the firmware 
easily enough. The issue is that I have no way of loading it without 
using non-free code, which I think puts it in the same category as 
Poulsbo and ipw3945 rather than, say, b43.

> And again, I have been assured that the code is going to be distributed
> soon, and that others are already using the driver successfully.

Everything I've been able to find suggests that the only people using it 
are booting Windows first, so your one seems to be the oddity. On the 
other hand, I'm kind of surprised that we're merging drivers on the 
promise that code to use them will be available "soon". It seems to end 
up giving the vendor credit that they don't deserve as yet.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: qcserial comes up in unhelpful custom mode?

[Greg KH]

On Fri, Apr 03, 2009 at 04:12:32PM +0100, Matthew Garrett wrote:
> On Fri, Apr 03, 2009 at 08:03:01AM -0700, Greg KH wrote:
> > On Fri, Apr 03, 2009 at 02:57:19PM +0100, Matthew Garrett wrote:
> > > So it's a driver that's useless without a closed source firmware loader, 
> > > either in the form of a Linux userspace application that can't be 
> > > distributed or in the form of Windows?
> > 
> > Hm, I originally thought that as well, but I have a laptop here that
> > doesn't seem to need the firmware code at all (I deleted it and rebooted
> > from poweroff and everything worked fine.)
> > 
> > So it seems it depends on the hardware platform.
> 
> Hmm. What's the USB ID of that one?

USB_DEVICE(0x05c6, 0x9211);

> > > I thought we'd decided that drivers weren't going to be merged in that
> > > case (poulsbow, the original 3945 driver)
> > 
> > We have lots of drivers that rely on firmware that is not in the kernel
> > to work properly, I see this as just the same thing.
> 
> It's not that it relies on firmware - I can get my hands on the firmware 
> easily enough. The issue is that I have no way of loading it without 
> using non-free code, which I think puts it in the same category as 
> Poulsbo and ipw3945 rather than, say, b43.

No, both of those are quite different, they interact with the closed
source bits directly from the kernel, which isn't allowed.  This just
needs the firmware loaded into the device to work at all, much like an
"empty" b43 device would be.

> > And again, I have been assured that the code is going to be distributed
> > soon, and that others are already using the driver successfully.
> 
> Everything I've been able to find suggests that the only people using it 
> are booting Windows first, so your one seems to be the oddity. On the 
> other hand, I'm kind of surprised that we're merging drivers on the 
> promise that code to use them will be available "soon". It seems to end 
> up giving the vendor credit that they don't deserve as yet.

As I did not realize the hardware was shipping yet (my machine is a
pre-production unit), I thought the firmware issue would be resolved by
the time shipments happened.

We want manufacturers to ship early and often, this was just doing that.

Oh, and it was not giving the vendor any credit at all, their original
driver was one of the worse things I had seen in a long time (200 or so
lines, over 300 checkpatch errors, a new record.)  I rewrote it from
scratch because of the mess involved.

thanks,

greg k-h

Re: qcserial comes up in unhelpful custom mode?

[Matthew Garrett]

On Fri, Apr 03, 2009 at 08:57:04AM -0700, Greg KH wrote:
> On Fri, Apr 03, 2009 at 04:12:32PM +0100, Matthew Garrett wrote:
> > Hmm. What's the USB ID of that one?
> 
> USB_DEVICE(0x05c6, 0x9211);

The driver seems to flag that as the QDL device rather than the modem. 
Are you sure it's working?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: qcserial comes up in unhelpful custom mode?

[Greg KH]

On Fri, Apr 03, 2009 at 05:06:39PM +0100, Matthew Garrett wrote:
> On Fri, Apr 03, 2009 at 08:57:04AM -0700, Greg KH wrote:
> > On Fri, Apr 03, 2009 at 04:12:32PM +0100, Matthew Garrett wrote:
> > > Hmm. What's the USB ID of that one?
> > 
> > USB_DEVICE(0x05c6, 0x9211);
> 
> The driver seems to flag that as the QDL device rather than the modem. 
> Are you sure it's working?

No I'm not as the whole laptop seems to be dead now, so I can't verify
it :(

stupid pre-production hardware...

sorry,

greg k-h

Re: qcserial comes up in unhelpful custom mode?

[Greg KH]

On Fri, Apr 03, 2009 at 08:03:01AM -0700, Greg KH wrote:
> > I thought we'd decided that drivers weren't going to be merged in that
> > case (poulsbow, the original 3945 driver)
> 
> We have lots of drivers that rely on firmware that is not in the kernel
> to work properly, I see this as just the same thing.
> 
> And again, I have been assured that the code is going to be distributed
> soon, and that others are already using the driver successfully.

Hm, look at the linux-usb list, someone has posted a shell script that
gets the hardware to work properly already.

So you should be good to go now.

thanks,

greg k-h

Re: qcserial comes up in unhelpful custom mode?

[Matthew Garrett]

On Fri, Apr 03, 2009 at 08:12:37AM -0700, Greg KH wrote:
> On Fri, Apr 03, 2009 at 08:03:01AM -0700, Greg KH wrote:
> > > I thought we'd decided that drivers weren't going to be merged in that
> > > case (poulsbow, the original 3945 driver)
> > 
> > We have lots of drivers that rely on firmware that is not in the kernel
> > to work properly, I see this as just the same thing.
> > 
> > And again, I have been assured that the code is going to be distributed
> > soon, and that others are already using the driver successfully.
> 
> Hm, look at the linux-usb list, someone has posted a shell script that
> gets the hardware to work properly already.

Ah, now that is progress. Thanks!
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: qcserial comes up in unhelpful custom mode?

[Matthew Garrett]

On Fri, Apr 03, 2009 at 08:12:37AM -0700, Greg KH wrote:

> Hm, look at the linux-usb list, someone has posted a shell script that
> gets the hardware to work properly already.

I've reimplemented this as C code with udev hooks. I'll post it once 
I've checked Alexander is fine with the licensing.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

qcserial/gobi firmware loader

[Matthew Garrett]

I've reimplemented Alexander's shell scripts for firmware loading in C 
and added a udev rule to automatically trigger the loading[1]. Thanks to 
Sergey's hint I've added checksumming support so it should work on other 
firmwares as well. The firmware needs to be obtained somehow and then 
put in /lib/firmware/gobi, but should then automatically load when the 
device is ready.

You can download this at http://www.codon.org.uk/~mjg59/gobi_loader/

[1] The firmware to be loaded depends on the user's network, so I can't 
think of an especially clean way of doing this in kernel.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

[PATCH] qcserial: Add extra device IDs

[Matthew Garrett]

Add a set of device IDs from the Windows drivers. These aren't complete 
(there's a couple of cases where a QDL device is identified without the 
associated modem being identified), but it's better than the current 
situation.

Signed-off-by: Matthew Garrett <mjg@redhat.com>

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index e6d6b0c..7528b8d 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -26,6 +26,27 @@ static struct usb_device_id id_table[] = {
 	{USB_DEVICE(0x05c6, 0x9212)},	/* Acer Gobi Modem Device */
 	{USB_DEVICE(0x03f0, 0x1f1d)},	/* HP un2400 Gobi Modem Device */
 	{USB_DEVICE(0x03f0, 0x201d)},	/* HP un2400 Gobi QDL Device */
+	{USB_DEVICE(0x04da, 0x250d)},	/* Panasonic Gobi Modem device */
+	{USB_DEVICE(0x04da, 0x250c)},	/* Panasonic Gobi QDL device */
+	{USB_DEVICE(0x413c, 0x8172)},	/* Dell Gobi Modem device */
+	{USB_DEVICE(0x413c, 0x8171)},	/* Dell Gobi QDL device */
+	{USB_DEVICE(0x1410, 0xa001)},	/* Novatel Gobi Modem device */
+	{USB_DEVICE(0x1410, 0xa008)},	/* Novatel Gobi QDL device */
+	{USB_DEVICE(0x0b05, 0x1776)},	/* Asus Gobi Modem device */
+	{USB_DEVICE(0x0b05, 0x1774)},	/* Asus Gobi QDL device */
+	{USB_DEVICE(0x19d2, 0xfff3)},	/* ONDA Gobi Modem device */
+	{USB_DEVICE(0x19d2, 0xfff2)},	/* ONDA Gobi QDL device */
+	{USB_DEVICE(0x1557, 0x0a80)},	/* OQO Gobi QDL device */
+	{USB_DEVICE(0x05c6, 0x9001)},   /* Generic Gobi Modem device */
+	{USB_DEVICE(0x05c6, 0x9002)},	/* Generic Gobi Modem device */
+	{USB_DEVICE(0x05c6, 0x9202)},	/* Generic Gobi Modem device */
+	{USB_DEVICE(0x05c6, 0x9203)},	/* Generic Gobi Modem device */
+	{USB_DEVICE(0x05c6, 0x9222)},	/* Generic Gobi Modem device */
+	{USB_DEVICE(0x05c6, 0x9008)},	/* Generic Gobi QDL device */
+	{USB_DEVICE(0x05c6, 0x9201)},	/* Generic Gobi QDL device */
+	{USB_DEVICE(0x05c6, 0x9221)},	/* Generic Gobi QDL device */
+	{USB_DEVICE(0x05c6, 0x9231)},	/* Generic Gobi QDL device */
+	{USB_DEVICE(0x1f45, 0x0001)},	/* Unknown Gobi QDL device */
 	{ }				/* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, id_table);

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: qcserial/gobi firmware loader

[Kay Sievers]

On Sat, Apr 4, 2009 at 17:27, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> I've reimplemented Alexander's shell scripts for firmware loading in C
> and added a udev rule to automatically trigger the loading[1].

This misses a '=':
  GOTO "gobi_rules_end"

This:
  /dev/%k
should be:
  $env{DEVNAME}

Thanks,
Kay

Re: qcserial/gobi firmware loader

[Matthew Garrett]

On Sat, Apr 04, 2009 at 07:51:06PM +0200, Kay Sievers wrote:
> This misses a '=':
>   GOTO "gobi_rules_end"
> 
> This:
>   /dev/%k
> should be:
>   $env{DEVNAME}

Thanks, fixed those.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: qcserial/gobi firmware loader

[Alexander Shumakovitch]

Hi,

Messages magic4 magic5 contain the length of the second firmware file that has
to be implanted using the same procedure as in magic2 and magic3 (without
subtracting 8). The CRC checksum has to be updated afterwards.

Thanks,

   --- Alex.

On Sat, Apr 04, 2009 at 04:27:31PM +0100, Matthew Garrett wrote:
> I've reimplemented Alexander's shell scripts for firmware loading in C 
> and added a udev rule to automatically trigger the loading[1]. Thanks to 
> Sergey's hint I've added checksumming support so it should work on other 
> firmwares as well. The firmware needs to be obtained somehow and then 
> put in /lib/firmware/gobi, but should then automatically load when the 
> device is ready.
> 
> You can download this at http://www.codon.org.uk/~mjg59/gobi_loader/
> 
> [1] The firmware to be loaded depends on the user's network, so I can't 
> think of an especially clean way of doing this in kernel.
> -- 
> Matthew Garrett | mjg59@srcf.ucam.org

Re: qcserial/gobi firmware loader

[Matthew Garrett]

On Sat, Apr 04, 2009 at 02:14:22PM -0400, Alexander Shumakovitch wrote:
> Hi,
> 
> Messages magic4 magic5 contain the length of the second firmware file that has
> to be implanted using the same procedure as in magic2 and magic3 (without
> subtracting 8). The CRC checksum has to be updated afterwards.

Good catch. I've uploaded a fixed version.

-- 
Matthew Garrett | mjg59@srcf.ucam.org