drivers/usb/gadget/epautoconf.c: In function `ep_matches':
drivers/usb/gadget/epautoconf.c:175: error: `typeof' applied to a bit-field

I've posted all these before, the only notable change is
treating that one gphoto2 case as warn-and-continue rather
than return-with-failure.


usb_set_configuration() cleanup

 * Remove it from the USB kernel driver API.  No drivers need it now,
   and the sysadmin can change bConfigurationValue using sysfs (say,
   when hotplugging an otherwise problematic device).

 * Simpler/cleaner locking:  caller must own dev->serialize.

 * Access from usbfs now uses usb_reset_configuration() sometimes,
   preventing sysfs thrash, and warns about some dangerous usage
   (which gphoto2 and other programs may be relying on).  (This is
   from Alan Stern, but I morphed an error return into a warning.)

 * Prevent a couple potential "no configuration" oopses. (Alan's?)

 * Remove one broken call from usbcore,  in the "device morphed" path
   of usb_reset_device().  This should be more polite now, hanging
   that one device rather than khubd.

This updates the existing Ethernet gadget driver to
support an additional RNDIS configuration on all
current USB controllers that can support one.

It also includes a bit more work to address the complex
autoconfiguration of this driver.  Needs testing on PXA.

Patch (mostly) contributed by Robert Schwebel, and developed
with support from Auerswald GmbH.

This patch adds the RNDIS message engine and kbuild/kconfig
support for it.  This is currently labeled EXPERIMENTAL.

Patch contributed by Robert Schwebel, and developed with
support from Auerswald GmbH.

Minor unlink tweaks, including a case where SMP could oops
if it were abused, as if from 'usbtest' or 'stir4200'.

Prevents an oops with some other patchsets.


Clear some pointers after the memory is kfreed, to avoid
making some other patch combinations oops.

These are "obvious" locking fixes:  using the right lock
to protect interface claim/release (should be the driver
model bus lock, not BKL).

This patch continues the update process for the cur_altsetting change.
The drivers in usb/input were all in good shape and needed only minimal
changes.

Mostly from Benjamin Herrenschmidt:

  - prevent usbcore from asking the HCD root hub code
    to read registers on one more suspend path (some
    hardware gets upset in those cases);

  - try handling a "device died" cleanup case better

  - add some wmb() calls in spots that could matter
    on some hardware

The 2.6 code for Intel's IXP4xx NPU line has been updated to
remove all references to IXP42x or IXP425 and replace it
with IXP4XX, including config options and file names. This
patch updates the USB-gadget pxa-udc driver with these changes.

This is a resubmission of as225, together with appropriate changes for the
g_serial driver.  David Brownell's latest g_ether update makes it
unnecessary to change that file or gadget_chips.h.



dummy_hcd is simultaneously a host controller driver and a device
controller driver.  It creates a simulated HC together with a simulated
UDC plugged into it.  Gadget drivers can run under the simulated UDC and
will appear as regular USB devices on the simulated HC.  The simulation is
reasonably (although not totally) realistic.

It's a wonderful tool for testing and developing gadget drivers without
the need for lots of additional hardware: Both the host driver and the
gadget driver can run on the same computer.  It's been available for quite
some time in David's gadget-2.6 tree and it works well.  I couldn't have
gotten the file-storage gadget running in any reasonable length of time
without it.

And the maintainer doesn't seem to want to fix it :(

> Bah, looks like PPC doesn't ever define CMSPAR :(
>
> How about adding something like:
> 	#ifndef CMSPAR
> 	#define CMSPAR 0
> 	#endif
> To the beginning of the driver like the cdc-acm.c driver does?  If that
> works, care to send me a patch?

Yes, it compiles.

Here's an update for the Ethernet gadget that corresponds
to the earlier one for Gadget Zero ... it gets rid of almost
all the remaining controller-specific #ifdefs in this driver.
(And also lets the driver initialize using "dummy_hcd".)

This is a significant step towards doing hardware-specific
configuration at run time (or at least init-time) rather
than compile time, but other patches will be needed to take
it the rest of the way there.   (Especially considering the
RNDIS support...)  The runtime footprint of the driver shrank
a bit, mostly because things moved into the init section.

Some hardware had the poor taste to misbehave during probe(),
which turned up a minor bug.  This fixes it:  don't try to
free a network device that hasn't been registerd.

This patch provides standard symbols for the various USB
device and endpoint feature bits, so that drivers can
use symbolic names for them.  It also changes the code
relating to endpoint halts so it uses those symbols.

Patch below fixes an obvious race in the whiteheat usb serial driver...

This allows the pegasus driver to actually be seen as a config option.
Apparently it's not that popular, though I have confirmed that it still
works on at least the netgear fv101.

you are using GFP_KERNEL in irq and __devinit with hotpluggable code.

      - use proper GFP flags
      - kill __devinit

I screwed up. This corrects it.

you are using __devinit which must not be used with USB drivers,
in addition you are using some false GFP values and fail to check
some error codes.

  - check for unlink due to removal of controller
  - correct GFP values
  - no __devinit in USB

this driver is doing DMA to the stack. Here's the obvious fix.

Patch below fixes some obscenely high stack uage;
struct hiddev_usage_ref_multi is well over 4Kb in size so really doesn't
belong on the stack.

some error codes are incorrect and there's an URB leak in an error path.

This patch introduces a major simplification into the UHCI driver by
replacing its multiple spinlocks with a single one.  The protected area of
code is slightly larger and there's more possibilities for contention on
an SMP system, but I think that shouldn't be a problem.  Stephen Hemminger
has been kind enough to test this on his SMP computer and he hasn't
encountered any difficulties.

This patch simplies the way the UHCI driver handles short control
transfers.  When a transfer is short the HC will stop handling that
endpoint, and it's necessary to get it going again so that the status
stage of the control transfer can take place.  Currently the driver does
this by allocating a new QH for the transfer and setting its element
pointer to point at the final status TD.  The old QH is recycled.  But
it's not necessary to go to all that trouble; the element pointer in the
original QH can be updated directly.

Normally the element pointer is supposed to be owned by the HC, and it's
not safe to just change its value since the HC may overwrite it at any
time.  But when a transfer is stopped because of a short packet, the
current TD is marked inactive and the HC will not update the element
pointer.  To write an unchanged pointer value back to memory would be a
waste of PCI bus cycles.  Now the UHCI spec doesn't say explicitly that an
HC _can't_ do this, but I've tested both Intel and VIA hardware and
neither of them does.

As a side effect of this change, some of the code for removing QHs can be
eliminated.

This patch makes some simple changes to the way the UHCI driver does short
packet detection.  The current implementation is incorrect in several
ways:

	The Short-Packet-Detect flag is set for OUT transfers, which
	yields undefined behavior according to the UHCI spec.

	It's not set for URBs with URB_SHORT_NOT_OK, which is just the
	opposite of what we want!  Those are the ones where short packets
	do matter.

	It is set for the last packet in a transfer, which causes an
	unnecessary pause in the data flow (except of course that the
	pause _is_ necessary when URB_SHORT_NOT_OK is set).

The patch also implements the URB_NO_INTERRUPT flag for bulk transfers,
which can help improve system performance by reducing interrupt overhead.

This is a very minor point, unlikely ever to come up.  But just in case...

It's conceivable that a device might transmit different values for a
configuration descriptor's wTotalLength the first time we ask for it (in
order to get the length) and the second time (to get the entire
descriptor).  Should that improbable event occur, the rawdescriptor buffer
could be allocated using a size that's smaller than the length recorded in
the rawdescriptor itself.  This patch protects devio.c against such a
problem.

If you feel this sequence of events is too unlikely to worry about, then
don't bother to apply the patch.

there's a race in how open handles multiple openers.
You implement exclusive opening and wait for close
in case of further openers. However if there are more than one
waiter, only one of them must be allowed to proceed.

On Thu, 18 Mar 2004, Urban Borstnik wrote:

> The 2.6.4 and 2.6.3 (and possibly some earlier) kernels log the
> following message when I plug in a Lexar CompactFlash Reader:
>
> usb-storage: This device (05dc,b002,0113 S 06 P 50) has unneeded
> SubClass and Protocol entries in unusual_devs.h
>    Please send a copy of this message to <linux-usb-devel@lists.sourceforge.net>
>
> Otherwise it has been working very well with the devepment kernels on at
> least 4 machines ever since a trivial fix was introduced for this device
> to unusual_devs.c over a year ago.
>
> Best regards,
> Urban.

Thank you for sending this in.  An update will appear soon.

On Thu, 2004-03-18 at 07:44, Oliver Neukum wrote:
> Hi,
>
> you must use set_current_state() only after usb_submit_urb() with GFP_KERNEL
> as second argument, because it may sleep to allocate memory and is woken up
> resetting the state to TASK_RUNNING. In that case you had a busy polling loop.
> Furthermore, always use wake_up unconditionally. It checkes anyway.

Thanks for reviewing this code, I'm new to Linux driver development and
more eyes on my work is a good thing.   I've actually been working on
some more cleanups to the driver to fix the race between open and
disconnect, and was just about to send it in...

So, the attached patch against 2.6.5-rc1-mm1 includes a mutex to lock
the open/disconnect paths, modelled after the usb-skeleton driver. It
includes Oliver Neukum's fixes and other cleanups as well.

Correct kernel-doc comment with incorrect parameters documented

I saw that you just added another unusual_devs.h entry submitted by
Henning Schild, for vendor ID 0x05e3.  It turns out this is our old friend
Genesys Logic.

A recent message from Brad Campbell included a Windows driver file by
Genesys, and it included these lines:

USB\VID_05E3&PID_0700.DeviceDesc="USB Card Reader"
USB\VID_05E3&PID_0701.DeviceDesc="USB Optical Device"
USB\VID_05E3&PID_0702.DeviceDesc="USB Mass Storage Device"

Based on this information, we can clean up the 0x05e3 entries in
unusual_devs.h.  This patch puts all three entries into a regularized
form.

On Tue, 16 Mar 2004, John Katzmaier wrote:

> Hi,
>
> Just wanted to let you know that when using my Panasonic PV-SD4090 digital
> camera with kernel 2.6.3, I found this entry in my logs:
>
> Mar 16 21:43:27 rocket kernel: usb-storage: Vendor: Panasonic
> Mar 16 21:43:27 rocket kernel: usb-storage: Product: LS-120 Camera
> Mar 16 21:43:27 rocket kernel: usb-storage: This device (04da,0901,0109 S 00 P
> 00) has an unneeded Protocol entry in unusual_devs.h
> Mar 16 21:43:27 rocket kernel:    Please send a copy of this message to
> <linux-usb-devel@lists.sourceforge.net>
>
> I thought it might be best to follow its instructions and so I did.
>
> Thanks.
>
> -John Katzmaier

Thank you for sending this in.  An update will appear in a forthcoming
kernel.

Greg, here's the patch.

Need to initialize timers a bit earlier to handle
certain initialization faults.


OSDL bug 2006

Need to initialize some timers a bit earlier to clean up safely
after very early init HCD failures.

Those early init faults were needlessly mysterious since they
didn't emit diagnostics except at HCD discretion.