This been sitting in my queue for ages now ... it just
clarifies three points about unlink semantics.  Basically,

  - You can only unlink once per submission.

  - For synchronous unlink: urb completes, then unlink returns.

  - For async unlink: the order is unspecified; although usually
    the completion happens after unlink returns.

This is the third part of what used to be as66c.  The patch makes several
changes in the routines that handle unbinding and selecting altsettings
and configurations.

	Upon unbinding a driver, don't nuke all the URBs for the device
	-- only kill the ones on the driver's interface.  Afterwards,
	reinitialize the interface by selecting altsetting 0 (the
	default).

	When changing an altsetting, if the interface has only one
	altsetting it is allowed to STALL the request.  Attempt to carry
	out the equivalent initialization by clearing the HALT feature
	on each of the interface's endpoints.

	When changing configurations, mark each interface as being in
	altsetting 0.

	In general, use the new disable/enable routines instead of doing
	everything by hand.

This is the second part of what used to be as66c.  It fixes the
initialization of the debugging macros in core/message.c and adds routines
to enable/disable endpoints, interfaces, and entire devices.  The code
that _uses_ these routines will come in the next patch.

 # Initialize the debugging macros properly in message.c.
 #
 # Add usb_disable_endpoint(), usb_disable_interface(), usb_disable_device(),
 # usb_enable_endpoint(), and usb_enable_interface().

The is the first part of what used to be as66c.  It simply renames
usb_device_probe() and usb_device_remove() to usb_probe_interface() and
usb_unbind_interface().  And since they're not needed outside of usbcore,
it stops exporting them.

Here are updates to unusual_devs.h sent in by users.  They apply to both
2.4.22 and 2.6.0.

It fixes a few minor problems in the usbtest driver:

	Unlinks are done in the expected order, preventing some
	inappropriate error messages.

	The driver would wait for an URB to complete, even if the URB
	got an error on submission.

	There was a surprising memory leak: the driver didn't kfree()
	its private data structure.

The "automagic control completion" has been gone for some
time now, except for the documentation fixed in this patch.
It mentions the "deferred response" mode that's used when
some context (like a gadgetfs thread) other than the IRQ
handler is responding to control requests.

Wayne Wylupski sent some more PIDs (in a patch, but I've modified
it) for the ftdi_sio driver to the ftdi-usb-sio-devel list.  These
PIDs were for additional CrystalFontz LCD displays.

An earlier patch from David Glance for the DSS-20 SyncStation was
applied to the 2.6 tree.  This did not have a changelog entry in
the file header comment of ftdi_sio.c, so I have retroactively
added one in the attached patch.

Thanks to Paulo Marques <pmarques@grupopie.com> for finding this.

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.