linux-kernel - Re: qcserial comes up in unhelpful custom mode?

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 3 Apr 2009 08:57:04 -0700
From:	Greg KH <gregkh@...e.de>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: qcserial comes up in unhelpful custom mode?

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
--
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/