This revised patch includes the change that David Brownell asked for.  It
renames usb_connect() to usb_choose_address(), no longer exports the
function, and adds equivalent functionality to usb_register_root_hub().
It also removes the unnecessary (and incorrect) assignment to
bMaxPacketSize0.

Attached are two patches, one for 2.4.21 and 2.5.75 for the PWC driver. I
assume the 2.5.75 patch will go into 2.6.0-test* without problems (I hope
this driver can make it into the kernel before the 'real' 2.6.0).

 From the ChangeLog:

* 20 dev_hints (per request)
* Hot unplugging should be better, no more dangling pointers or memory leaks
* Added reserved Logitech webcam IDs
* Device now remembers size & fps between close()/open()
* Removed palette stuff altogether

I have two open issues, though: Oliver Neukem pointed out that I should
resubmit URBs in the 2.5. kernel even in case of USB errors, which I did.
However, I never got a patch so I'm not 100% if this is the solution that
he had in mind.

Second... I've been thinking long and hard about the problem of properly
deregistering the video device when the cam gets unplugged while it is in
use. Various schemes failed; immediately deregistering while in the
disconnect routine causes crashes because the videodev layer sets some
pointer to null but still uses it later. A deregister in close() causes
hangs because of locked mutexes...

My current implemententation is to set an errorflag in the disconnect
routine, then wait there (using schedule()) until close() is being called
(I assume the application will immediately close the device when it gets a
serious error). So far it doesn't crash :-)

The attached patch fixes the flags used on the receive URBs and greatly
increases throughput (especially on EHCI).  On EHCI before the patch,
receives came in around 460KB/s and after I am in the 10-11MB/s range
which is about the same speed I am able to achieve using my Intel nics.
Now transmit is actually the bottleneck on EHCI (only getting around 6MB/s).

This patch:
Adds the Intellinet device IDs
Adds msg_level support (to be utilized in the future)
Fixes ethtool/mii support so link checking actually works
Changed timeout on usb_fill_int_urb to support High Speed (mru@users.sf.net)
Added devdbg/err/info defines borrowed from usbnet
Changed strlcpy to strncpy

Key issue not currently resolved (as brought up by mru@users.sf.net) is
that the receive performance is terrible on OHCI.  I ran a set of tests
with ttcp and transmit performance achieved 6146.16 KB/sec  but receive
only yielded 466.26 KB/sec which really sucks (sorry for the technical
jargon).  In porting the driver to 2.5 I had to pull the transmit
queueing that Tivo had originally used for the driver to even function.
My initial attempts at pulling the receive queueing met with many
Ooopses thus I backed off.  Looks like I will need to dig in again on
that one.

I noticed that some cases where USB produced lots of TT messages
were clearly wrong, since the transactions completed cleanly
(with a stall) and the TT buffer cleanup is only supposed to
be needed when a CSPLIT transaction fails (for control or bulk).

This patch makes the TT buffer cleanup happen only in the rarer
cases where there was an error that might really need it.

  - fix timeout handling

this cleans up locking and freeing in usblp_release and
poll.

Thanks to Joilnen Leite <knl_joi@yahoo.com.br> for pointing this out.

This patch:

   - Makes the cdc code handle a Motorola cable modem that stores
     CDC descriptors in the wrong place.  The workaround might be
     helpful for other hardware too.  (This was a 2.4 regression.)

   - Recognizes another Zaurus (PXA 255 based clamshell, not yet
     sold by Sharp in the US).

   - Cleaned the Zaurus stuff up a bit.  Rather than expecting
     a new driver_info struct (or re-using the right one) for
     each new pxa based product, they all use the same one.  So
     patches for new products only need new usb_device_id entries.
     (Also notes the issue that every Zaurus model will need to be
     blacklisted for CDC if the Z code isn't enabled.)

From pavel@ucw.cz

This adds support for another handheld from sharp to 2.6.0-test1

an unknown ioctl shall return ENOTTY, not EINVAL.

Now we just throw urbs at the device as fast as we can.

This is a one-line "obviously correct" patch that Lutz reports
is needed on one ARM platform.

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

From mru@users.sourceforge.net

My Netgear FA120 USB2 ethernet adaptor isn't working properly with
Linux 2.6.0-test1.  First off, I had to modify it slightly (patch
below) to make it work at all with USB2.  Now I can send data at the
full expected speed (~11 MB/s).

From mru@users.sourceforge.net

This trivial Makefile patch causes the AX8817x driver to actually be
built.

The recent change made to the irq handling in hcd_endpoint_disable()
caused a problem.  The statement

	local_irq_save (flags);

needs to be outside the rescan loop.  Otherwise, on loop iterations after
the first, flags is always set to indicate that interrupts are disabled.

In fact, since the routine ends with might_sleep() anyway, I don't see any
reason to save the interrupt state at all.  My patch just disables
interrupts at the start and enables them at the end.  I'm not sure that's
how you intended it to work, so you may want to change it a little.

There are two places where the audio driver checks for
endpoint-less interfaces, but the second one doesn't
filter out a garbage warning (without this patch).

Likely it'd be better to remove these warnings from
the driver, and maybe just place them in usbcore if
they'd ever be useful.  But this at least gets rid
of one class of "is this device broken" questions.

This patch makes the shuttle_usbat subdriver use proper DMA I/O buffering.
Although I try to be careful with these changes, I can't test them.  So I
urge you to read through it carefully to verify that nothing seems to be
wrong.

Also set usb_device.dev.release right after initialization to catch any
early devices being destroyed.  I still think there's a few error paths
to correct, but this catches a lot of previous errors.

Added a release callback, as is required, otherwise we can easily oops
if a user grabs a sysfs file and the device is removed from the system.

also detach the threads.

Otherwise we'll leave them around as zombies, waiting for them
to be picked up by their parent. Which might be the execve()
thread itself, causing a deadlock.

Noted by Sean Estabrooks:

There is a bug in "ll_rw_blk.c" handling partial bvec submissions.
For whatever reason the floppy driver was triggering it more than
other users (most likely because most other devices tend to be able
to always complete a full request in one go).

Fixed by updating the proper bio vector index entry.

Add kconfig options to allow excluding either or both the I/O
schedulers.  This can be useful for embedded systems (saves about ~13KB).

All schedulers are enabled by default for non-embedded.

This updates the valkyriefb driver to the new API.

From Paul Mackerras <paulus@samba.org>:

 "It compiles OK, but I haven't been able to test it.  I have simplified
  the driver quite a bit using the knowledge that there can only ever be
  one valkyrie graphics adaptor in a system - it is the built-in
  graphics adaptor on various ancient mac and powermac machines, and we
  access it at a hard-coded address, so we can only handle one."