USB fixes for 2.6.10-rc3
PATCH 1/1 USB fixes for 2.6.10-rc3
Hi,
Here are some USB fixes for 2.6.10-rc3. There is also a PCI build time fix, and a Documentation grammer fix in here too. Some of the patches are big, as they involve deleting a unworking driver and replacing it with a working version.
Please pull from:
bk://kernel.bkbits.net/gregkh/linux/usb-2.6
Patches will be posted to linux-usb-devel as a follow-up thread for those who want to see them.
thanks,
greg k-h
drivers/usb/host/hc_simple.c | 1039 ---------------------- drivers/usb/host/hc_simple.h | 231 ---- drivers/usb/host/hc_sl811.c | 1357 ----------------------------- drivers/usb/host/hc_sl811.h | 385 -------- drivers/usb/host/hc_sl811_rh.c | 583 ------------ arch/i386/kernel/quirks.c | 3 arch/x86_64/Kconfig | 1 drivers/usb/core/inode.c | 3 drivers/usb/host/Kconfig | 16 drivers/usb/host/Makefile | 3 drivers/usb/host/ehci-hub.c | 2 drivers/usb/host/ehci-q.c | 133 +- drivers/usb/host/ehci-sched.c | 5 drivers/usb/host/hc_crisv10.c | 2 drivers/usb/host/ohci-hub.c | 18 drivers/usb/host/sl811-hcd.c | 1909 ++++++++++++++++++++++++++++++++++++++++- drivers/usb/host/sl811.h | 270 +++++ drivers/usb/host/uhci-debug.c | 11 drivers/usb/host/uhci-hub.c | 10 include/linux/usb_sl811.h | 26 20 files changed, 2320 insertions(+), 3687 deletions(-)
-----
Adrian Bunk:
o USB uhci-debug.c: remove an unused function (fwd)
Alan Stern:
o USB UHCI: minor bugfix for port resume
David Brownell:
o USB: sl811-hcd driver, replaces hc_sl811
o USB: OHCI "resume"/smp fix
o USB: EHCI qh update race fix
Greg Kroah-Hartman:
o USB: fix another sparse warning in the USB core
o USB: fix obvious build error in hc_chrisv10.c driver
o USB: removed unused hc_sl811 driver from the tree
o USB: fix sparse warning in ehci-hcd driver
o USB: fix sparse warnings in sl811-hcd driver
Nishanth Aravamudan:
o USB: add wake-up for waitqueues in usbfs_remove_file() to fix bug 387
Randy Dunlap:
o PCI/x86-64: build with PCI=n
Quoted 3 lines · Greg KH
Greg Kroah-Hartman:
o USB: fix another sparse warning in the USB core
This one looks incorrect.
The code doesn't _fix_ any warnings. It just shuts them up, without fixing anything at all.
The fact is "le16_to_cpu()" should act on a le16 value, and sparse _should_ complain if you pass it the wrong value and ask sparse to check with -Wbitwise.
But instead of fixing "config->wTotalLength" to be of type "le16", which would _fix_ the problem, you shut up the valid warning.
If you don't want to see those warnings, don't use -Wbitwise. But don't just shut them up.
Linus
Quoted 11 lines · Linus Torvalds
Quoted 3 lines · Greg KH
Greg Kroah-Hartman:
o USB: fix another sparse warning in the USB coreThis one looks incorrect.
The code doesn't _fix_ any warnings. It just shuts them up, without fixing anything at all.
No, the "fun" problem with this specific field (the wTotalLength one) is that we initially read them in from the hardware (which for USB is in le order) and then, in a later function, convert all of the le fields to native cpu order so that all device drivers don't have to worry about which fields in the usb structures are in which order.
I tried a while ago to create 2 different versions of the structures, one in the "on the wire" format, and the other after we had converted them to native format, but it just got too messy for no real good reason. I then just put the proper __force markings in the needed places within the USB core. Here's just a place where I had missed it before for some reason.
Yeah, it's not the cleanest, and yes, it is just shutting the warning up, but that's ok in this case. I guess I could look into doing the "two different structures" type thing again, if people don't like things like this in different places.
thanks,
greg k-h
Quoted 6 lines · Greg KH
No, the "fun" problem with this specific field (the wTotalLength one) is that we initially read them in from the hardware (which for USB is in le order) and then, in a later function, convert all of the le fields to native cpu order so that all device drivers don't have to worry about which fields in the usb structures are in which order.
Aargh.
Quoted 4 lines
Yeah, it's not the cleanest, and yes, it is just shutting the warning up, but that's ok in this case. I guess I could look into doing the "two different structures" type thing again, if people don't like things like this in different places.
On the other hand, maybe you could just leave it in "hardware byte order".
That's something that sparse really can help with - it should pinpoint exactly everybody who uses it, and give a reasonable error for them, so that everybody can agree on the byte-order.
Oh, well..
Linus
Quoted 5 lines · Greg KH
Yeah, it's not the cleanest, and yes, it is just shutting the warning up, but that's ok in this case. I guess I could look into doing the "two different structures" type thing again, if people don't like things like this in different places.
Or maybe just cache a pre-swapped value in the wrapper structure (usb_host_config)? You don't need to create a third structure ... and it'd be nice to have simple rule that the raw descriptors are always in wire order.
- Dave
Quoted 7 lines · Linus Torvalds
Quoted 4 lines · Greg KH
Yeah, it's not the cleanest, and yes, it is just shutting the warning up, but that's ok in this case. I guess I could look into doing the "two different structures" type thing again, if people don't like things like this in different places.
On the other hand, maybe you could just leave it in "hardware byte order".
True. Nothing like changing the byte order of structure fields to really drive the "out-of-tree" driver writers crazy. I like it :)
Quoted 3 lines
That's something that sparse really can help with - it should pinpoint exactly everybody who uses it, and give a reasonable error for them, so that everybody can agree on the byte-order.
Hm, I'll look into doing that after 2.6.10, as it does make more sense in the long run.
thanks,
greg k-h
Quoted 3 lines
Hm, I'll look into doing that after 2.6.10, as it does make more sense in the long run.
I agree. I remember playing with a USB driver in linux a while ago and spending some time trying to figure out what was going on with byte order :) I'd rather keep the raw HW (that is: well defined) byte order in those fields, and let sparse catch drivers who don't properly convert before use.
Ben.
Hi,everyone! I want to add usb support as a module to my kernel 2.6.8,how can I buider and install a single module?I don't want't to rebuilder the whole kernel.thanks!