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 | [email protected]
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
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 | [email protected]
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
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 | [email protected]
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
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 | [email protected]
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
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 | [email protected]
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 | [email protected]
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 | [email protected]
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 <[email protected]>
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 | [email protected]
On Sat, Apr 4, 2009 at 17:27, Matthew Garrett <[email protected]> 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
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 | [email protected]
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 | [email protected]
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 | [email protected]
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