This patch changes the return codes used by hub_port_wait_reset(),
hub_port_reset(), and hub_port_debounce() in hub.c.  I couldn't stand the
{-1=error, 0=okay, 1=disconnect} scheme; the meanings seemed arbitrary and
I constantly forgot which number stood for what status.  The revised code
uses normal negative error codes, including -ENOTCONN to indicate device
disconnected, or 0 for success.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

As part of the cleanup effort, I wanted to name all the variables in hub.c
uniformly.  Currently there are different names for the same thing in
different routines, and the same names are used for different things --
it's impossible to keep things straight.  I also wanted to step away from
the deplorable practice of naming everything "dev".  It is not an
exaggeration that up until relatively recently one of the drivers (not the
hub driver, fortunately!) contained a line which looked basically like
this:

	dev->dev.dev = &intf->dev;

If you can make sense out of that, you're a better code reader than I am!

Ranting aside, this patch institutes the following name scheme for local
variables in hub.c:

	hub:		struct usb_hub
	hdev:		hub's corresponding struct usb_device
	hub_dev:	hub interface's embedded struct device
	udev:		general struct usb_device

There are a couple of genuine code changes hidden in there too.  Just
trivial things, like creating a local hub_dev variable for use in place of
&hub->intf->dev.

This patch creates a separate subroutine to encapsulate the work required
in choosing an initial configuration for a device.  In my opinion that
reflects a policy decision that should be kept apart from all the other
work involved in creating a new device structure.  The existing code in
usb_new_device() is simply moved into usb_choose_configuration().

This patch adds usb_release_address() as a complement to
usb_choose_address(), to centralize the work required when freeing an
allocated device address.  It also moves the usb_set_address() routine
from usb.c to hub.c -- which is the only place it is ever used -- and
renames it to hub_set_address().

Before fixing up the device locking and device reset code, I want to do
some cleanups of the hub driver and related areas.  This is the first of a
series of patches for that purpose.

This patch changes all the occurrences of "driverfs" in usbcore to "sysfs"
-- I just couldn't stand seeing the out-of-date name any more (and I kept
confusing it with usbfs, don't know why).

Although I did a "bk mv driverfs.c sysfs.c" when creating the patch, the
exported patch file itself doesn't reflect that very well.  It looks like
driverfs.c was deleted and sysfs.c created from scratch.  If you prefer, I
can resubmit this in a slightly different form, with the file name
unchanged so that you can issue the "bk mv" command in your repository
after applying the patch.

A lot of people with USB controllers made by VIA have been suffering from
the fact that these controllers stop working when they receive a babble
packet.  In particular, they stop generating interrupt requests.  Since
the UHCI driver relies on IRQs from the controller for proper timing and
interlocking of unlink requests, this means that those broken controllers
will hang the UHCI driver and drivers for any device connected through it.

This patch, written by Herbert Xu, gives the UCHI driver the ability to
manage the unlink procedure using timer interrupts as well as controller
interrupts.  (It also fixes a race in the UHCI irq handler.)  Although it
won't prevent the VIA controllers from flaking out when they encounter
babble, at least now users will be able to rmmod the uhci-hcd driver and
then reload it, restoring their systems back to normal operation (until
the next babble!).

P.S.: Herbert, there's one loose end I still want to tie up.  When the
controller isn't running (i.e., is suspended) the frame number won't
change, but unlinks still need to work.  It's a small point, not too
likely to come up in normal usage.  I'll fix it later on when I update the
state-changing part of the driver.

This patch reads the full 9 bytes of a configuration descriptor during
enumeration rather than just the first 8 bytes.  That's how Windows does
it, and today I ran across a device that doesn't work properly when asked
to send only 8 bytes worth.  I doubt very much this will cause any
problems with currently-working devices; since the descriptor itself is 9
bytes long and since the devices are most likely to expect a 9-byte
request, anything that can handle an 8-byte request should have no
difficulty.  (Also, some debugging messages have been slightly improved.)

Incidentally, USB traces taken from Windows 2000 and Windows XP show that
when those operating systems retrieve a string descriptor during
enumeration, they do so by requesting a 255-byte transfer.  They do not
first ask just for the initial 2 bytes (which contain the actual length)
and then ask for the actual length, which is what we do.  Interestingly,
back in 2.4 we _did_ do things the same as Windows.

This fixes http://bugme.osdl.org/show_bug.cgi?id=2289

This patch has been tweaked by greg@kroah.com

hiddev_table[] is an array of pointers.  the minor number is used as an
offset.  hiddev minors start either with zero, or with 96.  If they start
with 96, the offset must be reduced by HIDDEV_MINOR_BASE because only 16
minors are available.  unplugging a hiddevice will zero data outside the
hiddev_table array.

this was spotted by Takashi Iwai.

Fixes this warning:

May 18 06:56:01 Knoppix kernel: Debug: sleeping function called from
invalid context at include/asm/semaphore.h:119
May 18 06:56:01 Knoppix kernel: in_atomic():1, irqs_disabled():0
May 18 06:56:01 Knoppix kernel: Call Trace:
May 18 06:56:01 Knoppix kernel:  [<c0117083>] __might_sleep+0xb2/0xd3
May 18 06:56:01 Knoppix kernel:  [<f88b92f4>] powermate_config_complete+0x33/0x77 [powermate]
May 18 06:56:01 Knoppix kernel:  [<c02c6760>] usb_hcd_giveback_urb+0x25/0x39
May 18 06:56:01 Knoppix kernel:  [<c02d7194>] uhci_finish_urb+0x54/0xa1
May 18 06:56:01 Knoppix kernel:  [<c02d7224>] uhci_finish_completion+0x43/0x55
May 18 06:56:01 Knoppix kernel:  [<c02d737d>] uhci_irq+0xf8/0x179
May 18 06:56:01 Knoppix kernel:  [<c02c67aa>] usb_hcd_irq+0x36/0x67
May 18 06:56:01 Knoppix kernel:  [<c01060c6>] handle_IRQ_event+0x3a/0x64
May 18 06:56:01 Knoppix kernel:  [<c0106479>] do_IRQ+0xb8/0x192
May 18 06:56:01 Knoppix kernel:  [<c0104850>] common_interrupt+0x18/0x20

Attached patch uses spinlocks instead of a semaphore so that we can't sleep
when in_atomic().

the kobil_sct didn't work with uhci hcds.
It used usb_fill_bulk_urb instead of usb_fill_int_urb.
The attached patch fixes this.

It starts reading in open now - this gives apps (CT-API) the chance to
detect the p'n'p string correctly.

I took the relevant parts from the patch (not some PHY stuff that was
irrelevant).  Attached is the patch against stock 2.6.6.

I noticed some problems with the PXA 2xx UDC and the
RNDIS version of the ethernet-over-usb link:

  - Static linking needs more than just two endpoints now

  - The endpoint autoconfig misbehaves (sounds like what
    Stefan reported a couple weeks ago)

This patch fixes those two problems, though there are
a couple others lurking too.

 that code is generating the fallowing warning:

drivers/usb/gadget/serial.c:162: warning: `debug' defined but not used

 When G_SERIAL_DEBUG is not defined, `debug' is not used, because
the gs_debug() function is compiled only when G_SERIAL_DEBUG is
defined.

 Thus, a solution is to define `debug' only when G_SERIAL_DEBUG
is defined. That includes the use of `debug' as a module parameter
(this last part I'm not sure).

 The patch bellow does that (compiles ok, not tested because I don't
have that hardware):

the previous patch was buggy. The state must be set _before_ the
condition is checked, or there's a window missing a wakeup.
This incremental change set fixes that.

  - fix race condition with current->state

this was buggy for the same reason that the old msleep was buggy.

  - safe waiting in case we are left on other wait queues

this is in kobil_sct.
It uses msleep() and replaces needless GFP_ATOMICs with GFP_NOIO
as this function can sleep.

  - no need for GFP_ATOMIC
  - use msleep()

Here's one you overlooked.

  - safe sleep helper

There is a problem in the usblp GET_DEVICE_ID ioctl() implementation. The patch
below (against 2.6 current) fixes the code to be according to the official usb
printer spec.

Most printers are not affected by this fix, as they use interface 0 and
alternate 0. For those, nothing changes. But my printer/scanner uses interface
1 for the printer.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

Any architecture (like pa-risc) that makes use of the helper function
flush_dcache_mmap_lock() won't compile with the new rmap due to use of
the wrong "mapping". 

Trivial fix.

into ppc970.osdl.org:/home/torvalds/v2.6/linux

into ppc970.osdl.org:/home/torvalds/v2.6/linux

PCM Midlevel,ALSA Core
Added SNDRV_PCM_SYNC_PTR_APPL and SNDRV_PCM_SYNC_PTR_AVAIL_MIN extensions
to SYNC_PTR ioctl for PCM API.

VIA82xx driver
- added the DXS entry for ECS K7VTA3 v8.0
- fixed the DXS entry for ASUS A7V8X to NO_VRA.

ALSA Core
added reverse selections of components to CONFIG_SND_BIT32_EMUL.

PCI drivers,ICE1712 driver,ICE1724 driver
- improved the description of ice1724 driver on Kconfig.
- better support of VT1720 with snd-ice1724 driver.
- check PCI subsystem IDs when no EEPROM is available (ice1724 only)
- change the driver name string if given in the board list.
- merged prodigy 7.1 support into aureon.c.  they are almost identical.
- allow to use PDMA4 and RMDA1 for non-SPDIF purpose if specified (ice1724 only).

into nuts.davemloft.net:/disk1/BK/net-2.6

The PCMCIA devices are not devices for the kernel and the bt3c_cs
driver uses a fake device for calling request_firmware(). The fake
device initialization must also set .kobj.k_name to prevent an oops
until PCMCIA devices are fully integrated into the driver model.

It is not possible to use __module_get() when adding a new RFCOMM
session, because there is a case where no reference count is hold.
This happens when the module is not in use right now and an incoming
connection occurs.

Bump driver version

This patch removes all usage of anonymous unions from the ipr
driver since gcc 2.95 does not support anonymous unions.

This patch fixes an oops discovered in test which can occur
on bad hardware if the ipr adapter times out coming operational. 

This patch adds additional error logging to abort, device reset,
and bus reset paths to help in diagnosing scsi problems on ipr.

This patch fixes an issue where ipr was including a kernel
data structure, list_head, in a packed structure, which causes
compile issues on some architectures, and is just a bad thing to do.

From: 	Alan Cox <alan@redhat.com>

Pretty minimal. queue_command is now called locked, this requires propogating
some small locking changes for send_s870

This takes ncpfs ioctl handling into fs/compat_ioctl.c, removing it from
ppc64 and sparc64 code.

Code sanitized, switched to compat_alloc_user_space(), bunch of
{k,v}malloc() killed.

There is a longstanding bug in the rt_sigreturn system call.
This exists in both 2.4 and 2.6, and for almost every platform.

I am referring to this code in sys_rt_sigreturn (arch/i386/kernel/signal.c):

	if (__copy_from_user(&st, &frame->uc.uc_stack, sizeof(st)))
		goto badframe;
	/* It is more difficult to avoid calling this function than to
	   call it and ignore errors.  */
	/*
	 * THIS CANNOT WORK! "&st" is a kernel address, and "do_sigaltstack()"
	 * takes a user address (and verifies that it is a user address). End
	 * result: it does exactly _nothing_.
	 */
	do_sigaltstack(&st, NULL, regs->esp);

As the comment says, this is bogus.  On vanilla i386 kernels, this is just
harmlessly stupid--do_sigaltstack always does nothing and returns -EFAULT.

However this code actually bites users on kernels using Ingo Molnar's 4G/4G
address space layout changes.  There some kernel stack address might very
well be a lovely and readable user address as well.  When that happens, we
make a sigaltstack call with some random buffer, and then the fun begins.

To my knowledge, this has produced trouble in the real world only for 4G
i386 kernels (RHEL and Fedora "hugemem" kernels) on machines that actually
have several GB of physical memory (and in programs that are actually using
sigaltstack and handling a lot of signals).  However, the same clearly
broken code has been blindly copied to most other architecture ports, and
off hand I don't know the address space details of any other well enough to
know if real kernel stack addresses and real user addresses are in fact
disjoint as they are on i386 when not using the nonstandard 4GB address
space layout.

The obvious intent of the call being there in the first place is to permit
a signal handler to diddle its ucontext_t.uc_stack before returning, and
have this effect a sigaltstack call on the signal handler return.  This is
not only an optimization vs doing the extra system call, but makes it
possible to make a sigaltstack change when that handler itself was running
on the signal stack.  AFAICT this has never actually worked before, so
certainly noone depends on it.  But the code certainly suggests that
someone intended at one time for that to be the behavior.  Thus I am
inclined to fix it so it works in that way, though it has not done so before.
It would also be reasonable enough to simply rip out the bogus call and not
have this functionality.

From the current state of code in both 2.4 and 2.6, there is no fathoming
how this broken code came about.  It's actually much simpler to just make
it work!  I can only presume that at some point in the past the sigaltstack
implementation functions were different such that this made sense.  Of the
few ports I've looked at briefly, only the ppc/pc64 porters (go paulus!)
actually tried to understand what the i386 code was doing and implemented
it correctly rather than just carefully transliterating the bug.

The patch below fixes only the i386 and x86_64 versions.  The x86_64
patches I have not actually tested.  I think each and every arch (except
ppc and ppc64) need to make the corresponding fixes as well.  Note that
there is a function to fix for each native arch, and then one for each
emulation flavor.  The details differ minutely for getting the calls right
in each emulation flavor, but I think that most or all of the arch's with
biarch/emulation support have similar enough code that each emulation
flavor's fix will look very much like the arch/x86_64/ia32/ia32_signal.c
patch here.