Skip to contentSkip to conversation

USB fixes for 2.6.10-rc3

PATCH In review Greg KH 5 participants 8 messages Dec 9, 2004 – Dec 10, 2004

lore
Share & tools
lore

Greg KH

author
#0 lore raw

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

#1 lore raw
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

author
#2 lore raw
Quoted 11 lines · Linus Torvalds
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.

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

#3 lore raw
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

author
#4 lore raw
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

#5 lore raw
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.

#6 lore raw

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!

#7 lore raw
In reply to Greg KH
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