There's an unnecessary pci-ism in usbcore -- just an oversight
in some API conversion, and harmless on most systems.  This'll
be a good thing to remove for non-PCI HCD support though.

> Data point:  "visor.c" always passes GFP_ATOMIC there.

Here's a patch that makes cdc-acm use GFP_ATOMIC too,
and report consequent allocation failures.  Compiles
but otherwise untested.

I have a patch for a typo in the 2.6.0 kernel, drivers/usb/core/hub.c,

in hub_clear_tt_buffer, the value USB_DIR_IN | USB_RECIP_OTHER is used
for bmRequestType, when section 11.24.2 of the spec says it should
really be USB_RT_PORT, or 00100011b.

After limited testing, this change exhibited better recovery from TT
errors, here's the patch :

It replaces a call to device_unregister_wait() in the File-backed
Storage Gadget.

(moving the one used function into the usb.c file.)

drivers/usb/storage/usb.c: In function `usb_stor_release_resources':
drivers/usb/storage/usb.c:837: error: invalid lvalue in assignment

drivers/usb/misc/uss720.c: In function `parport_uss720_epp_read_data':
drivers/usb/misc/uss720.c:336: error: invalid lvalue in increment
drivers/usb/misc/uss720.c: In function `parport_uss720_epp_read_addr':
drivers/usb/misc/uss720.c:395: error: invalid lvalue in increment
drivers/usb/misc/uss720.c: In function `parport_uss720_epp_write_addr':
drivers/usb/misc/uss720.c:415: error: invalid lvalue in increment
drivers/usb/misc/uss720.c: In function `parport_uss720_ecp_write_addr':
drivers/usb/misc/uss720.c:472: error: invalid lvalue in increment

drivers/usb/input/hid-core.c: In function `fetch_item':
drivers/usb/input/hid-core.c:605: error: invalid lvalue in increment
drivers/usb/input/hid-core.c:612: error: invalid lvalue in increment

drivers/usb/gadget/net2280.c: In function `write_fifo':
drivers/usb/gadget/net2280.c:527: error: `typeof' applied to a bit-field
drivers/usb/gadget/net2280.c: In function `handle_ep_small':
drivers/usb/gadget/net2280.c:2042: error: `typeof' applied to a bit-field

into cheetah.(none):/home/davem/src/BK/sparc-2.6

into home.osdl.org:/home/torvalds/v2.5/linux

From: Dominik Brodowski <linux@dominikbrodowski.de>

This brown paper bag patch is needed to assure cpufreq_update_policy works
correctly.

Please apply, else the next ACPI patch will cause trouble with thermal
management [it needs cpufreq_update_policy to work properly].

Fix a horribly wrong memcpy instruction in cpufreq_update_policy which
caused it to oops.

From: Torsten Duwe <duwe@suse.de>

pmdisk.c uses struct new_utsname, so give it the header.

From: Christoph Hellwig <hch@lst.de>

Put kernel_flag back to where it used to be, near its comment and its
EXPORT_SYMBOL.

From: Andi Kleen <ak@muc.de>

Just fix two warnings on x86-64 that were recently introduced (one by me
and the other by the sort extable changes)

  Add comment for HdrS ver 0x201

into hopper.(none):/usr/src/kernel/sparc-2.6

into home.osdl.org:/home/torvalds/v2.5/linux

  - Fix kconfig botch (bk automerge can be rather flakey)
  - The gadgetfs patches going with the kconfig cleanups

into home.osdl.org:/home/torvalds/v2.5/linux

into kroah.com:/home/greg/linux/BK/i2c-2.6

into kroah.com:/home/greg/linux/BK/usb-2.6

Here is a patch that brings the lm75 and lm78 drivers in compliance with
sysfs naming conventions. The drivers as found in existing 2.6 kernels
do not have a digit appended to the temperature-related files names as
the sysfs naming conversion recommends (obviously because they each have
a single temperature channel). As a result, libsensors won't find the
files.

It was discussed on the list wether a '1' should be appended in this
case, and our conclusion was that it would be better to do so because it
helps automatic processing of the sysfs exported files. Please apply if
you agree with this.

On Tue, 27 Jan 2004, Greg KH wrote:

> Hm, can you send me a patch to fix up snd_usb_extigy_boot_quirk() in
> sound/usb/usbaudio.c now that this patch broke that code?  :)

Here it is.  The problem with changing things in the core is always that
you may miss some of the repercussions.  In this case the patch will
restore the code's original functionality.

However the whole thing looks a bit creaky to me.  Changing device
descriptors and who knows what else without informing usbcore isn't a good
idea.  What this code _really_ appears to need is some form of
usb_device_reenumerate().  Such a function would fit very nicely into the
framework I've worked out for the revised usb_device_reset(); maybe I'll
add it in there.  It would do essentially the same thing as device_reset
except for skipping the actual port reset.

I accidentally left a debug printk in the sn2 timer_interrupt().

into home.osdl.org:/home/torvalds/v2.5/linux

into intel.com:/home/lenb/src/linux-acpi-test-2.6.2

into intel.com:/home/lenb/src/linux-acpi-test-2.6.1

        from ia64 via Alex Williamson

	from Jes Sorensen

	from Jes Sorensen

into home.osdl.org:/home/torvalds/v2.5/linux