System-wide PM resume now happily deadlocks if one of the
resuming devices tries to remove devices which vanished
during the suspend(*).  IMO that's unreasonable both
because devices can/do vanish, and because 2.4 didn't
deadlock in those cases; but no patch to fix that has been
merged.  The result is that ever since merging the "new" PM
code, some OHCI-based systems deadlock on resume.

So this patch handles the "lost power during resume" case
differently:  it doesn't disconnect the root hub (or its
children) directly.  Instead, it does part of that work
immediately, and defers the rest to khubd:

  - add a "pending" list for live urbs, and use it after reset
    to abort pending URBs (and reclaim "live" EDs/TDs)
  - immediately mark all devices NOTATTACHED, so any operations
    on the devices before khubd handles the disconnects, including
    resume() callbacks, will fail
  - kick root hub so it can do the cleanup

It also handles "fminterval" init/reinit a bit better, mostly
to work better in some remote wakeup scenarios addressed in
later patches:

   - save any initial value the boot firmware provided
   - use it during initialization (and eventually, remote wakeup)

Other changes:

  - use better jiffies calculation for scheduled delays
  - the allocator does more of the one-time initialization
  - initialize hcd.can_wakeup according to boot firmware
  - move some inlines to the header
  - minor cleanups


(*) http://marc.theaimsgroup.com/?l=linux-kernel&m=106606272103414&w=2
     reported against 2.6.0-test7.

quoting Linus:

--
> so there is no need to recheck the bit in do/while loop, because
> there is no false wakeups now.

You should never assume this. You should assume that there are _always_
false wakeups.

Why? Because Linux has always allowed people to leave wait-queues active,
without being "atomic". For example, the tty read/write layer used to
(still does?)  add itself on the wait-queue _once_, and then leave itself
on the wait-queue while in a loop it does copies from/to user space.
--

Unfortunately, this means us. Here's the first fix. Comments?

  - make sure timeouts are observed even if somebody left us on a queue

This patch makes the usbcore PCI suspend/resume logic behave
much better.  In particular:

  - Even HCs without PCI PM support will normally be able
    to support global suspend, saving power ... and will
    need to resume later.  Let them try to suspend; lots
    of not-that-old USB controllers don't have PM caps.

  - Saner order for the boilerplate PCI stuff.  It also
    explicitly disables the IRQ and DMA, which aren't
    available in D1/D2/D3 states anyway.

  - Uses pci_enable_wake() when the root hub supports
    remote wakeup.  Didn't fully work in one test setup;
    that controller's PME# was evidently ignored.  (Not
    enabled unless CONFIG_USB_SUSPEND.)

It worked for me with brief tests with the current 2.6.6-rc
uhci-hcd with one old UHCI; more extensive ones with various
OHCIs (using patches which I'll post soonish); and not at all
with EHCI (where PM hasn't ever worked).

Those of you who've been having PM problems might find
this helpful as-is, though I think that unless you're
using UHCI you'll also need an HCD patch.

- Dave

Now that all the USB drivers have been audited, we can safely accept
devices that have noncompliant numbering for their interfaces or
altsettings.  This patch skips bad or duplicate descriptors, allows gaps
in the numbering, accepts more or fewer interfaces than bNumInterfaces,
and logs warnings describing all these things.  Also, the debugging log
messages have been improved by David Brownell.

This should please a sizeable group of users.

This patch updates EHCI suspend/resume so that its essential
components work on a few different implementations:

   - make root hub suspend/resume work
   - make remote wakeup work (given CONFIG_USB_SUSPEND patch)
   - separate root hub suspend/resume from PCI suspend/resume
   - say if controller supports remote wakeup (on this system)
   - sysfs register dump unavailable if controller is suspended

Plus a handful of minor cleanups.  Please merge, along with the
"hcd-0506.patch" I sent last week.

Tested by modifying sysfs power/state files, since ACPI doesn't
work on this system (so I can't test system suspend/resume):

  - For root hub(*) ... suspend/resume works, also remote wakeup
  - PCI controller ... suspend/resume works, remote wakeup
    signals PME# (according to "lspci -vv"), but that's ignored
    on my test sytem

Regardless of whether USB was active, "echo 1 > /proc/acpi/sleep"
produced a system that wouldn't resume, and the same result
came from "echo standby > /sys/power/state".  So that's about
as far as I can take this testing for now.

- Dave

(*) Doing this relies on the CONFIG_USB_SUSPEND patch.  Otherwise
     no USB devices respond to sysfs power/state updates.  The
     PCI suspend/resume is a superset of this.

On Fri, 7 May 2004, kernel@metro.cx wrote:
> Hi All,
>
> I don't know where else to report this, but I found a very very very
> minor bug in the usb gadgets drivers, specifically the file_storage.c
> mass storage driver.
>
> In the function do_request_sense(..) it says:
>
> buf[7] = 18 - 7;                        // Additional sense length
>
> Whereas (according to page 38 of the USB mass storage class, UFI command spec,
> http://www.usb.org/developers/devclass_docs#approved) this clearly neads
> to be equal to 10, not 11.
>
> I checked with the 2.6.5 source, it is still there. Hope someone will find this usefull, although most USB hosts seem to ignore length bits alltogether anyway....
>
> Koen Martens

You are quite right; thank you for pointing this out.  Greg, please apply
the patch below.

drivers/usb/media/dsbr100.c: In function `usb_dsbr100_probe':
drivers/usb/media/dsbr100.c:239: warning: unused variable `videodev'

Thanks to Tridge's findstatic.pl script for helping find these.

I've received the following report which indicates that the Sony Clie needs
the US_FL_FIX_INQUIRY flag set.

http://bugs.debian.org/243650

This patch imports the changes that David Brownell has made to the
device-reset functions in his gadget-2.6 tree.  Once these ongoing
troubling questions about locking are settled, I'll add support for the
"descriptors changed" case.

Only one aspect of it is notable: The CPiA USB
driver calls usb_driver_release_interface() during its disconnect()
routine.  That doesn't appear to be necessary, since it didn't call
usb_driver_claim_interface() beforehand and since the interface will be
released automatically when disconnect() returns.

On 4 May 2004, Rajesh Kumble Nayak wrote:

> The Above patch work fine for Sony Hc-85
> I shall post the dmesg entry soon.
>
> With many thanks
> Rajesh

Greg and Pete, here's the patch.  It's possible that this entry could be
combined with the previous one, but until we know definitely they should
be kept separate.

This patch allocates a temporary array from the heap instead of from the
kernel's stack in usb_set_configuration().  It also updates a few
comments.  Please apply.

this is the second version of the patch to add support for eGalax Touchkit USB
touchscreen. changes since last patch:
- fixed the bug in open, found by oliver neukum
- renamed driver from touchkit.c to touchkitusb.c (since the thing also exists
  as RS232, PS/2 and I2C)
- some minor coding style updates

This adds another ax8817x device to "usbnet".

g_serial.ko can't be load as module because "debug" is only
defined if G_SERIAL_DEBUG is defined, but "debug" is referenced
in MODULE_PARM().

below is a trivial patch which fixes the PXA gadget define
in drivers/linux/usb/gadget/gadget_chips.h

Everywhere CONFIG_USB_GADGET_PXA2XX is used, except in that file, which
bites obviously ...


Fix define for PXA UDC.

Info was from Adriaan de Groot <adridg@cs.kun.nl>

The attached patch for the 3M Touch Systems Capacitive controller. (again)

Quick list of changes:

   * decrease mtouch->open counter in the event of a urb submission
     failure

The changes are due to comments Oliver Neukum's comments on the
touchkit.c driver.  Good catch!  Sorry I missed it.

http://marc.theaimsgroup.com/?l=linux-usb-devel&m=108343028201159&w=2

This patch updates the USB IrDA driver to take into account that the
kernel may no longer store altsetting entries in numerical order.
The driver only needed one change; this was a simple matter of using the
entry corresponding to the altsetting that was just installed.

On Fri, Feb 06, 2004 at 10:17:32AM -0800, Greg KH wrote:
> On Fri, Feb 06, 2004 at 05:06:01PM +0100, Markus Demleitner wrote:
> > Since I finally switched over to 2.6 I noticed that my dsbr100 driver
> > produces a warning to the effect that I should provide a release
> > callback.  After a quick google on the issue I came to the conclusion
>
> No, you will have to fix up your driver to work properly, sorry.  It's
> due to the changes to the v4l layer to handle removable devices much
> better (and to tie it into the driver model.)

I didn't get around to doing real work on this until now, but finally
in the attachment there's my stab at bringing dsbr100 up to kernel 2.6.
I'm not really comfortable with the release callback issues (I've yet
to find some HOWTO-like documentation on this...) on the v4l side,
so I'd be grateful if you could have a look at it.  I've basically
tried to copy what stv680 does, which may or may not have been a
good idea (in particular see the comment above the disconnect
function).

I've used the opportunity for some code beautyfing, which of course
makes the patch a bit of a mess.  I hope you won't mind too much
-- as you can see, it would have been pretty messy anyway.

Here's what's in my tree to make dummy_hcd do suspend and
wakeup correctly ... that is, making its emulated root hub
and gadget work more like real ones.

It's easier to do this for fake hardware than the real stuff.
But real drivers tend to need very similar changes ... :)

- Dave

p.s. This does not depend on the suspend/resume patch.
      And it doesn't do "global" suspend (of root hub).

On Tuesday 27 April 2004 10:58, Oliver Neukum wrote:
> Am Dienstag, 27. April 2004 00:14 schrieb Greg KH:
> > On Mon, Apr 26, 2004 at 04:05:17PM +0200, Duncan Sands wrote:
> > > diff -Nru a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
> > > --- a/drivers/usb/core/devio.c	Mon Apr 26 13:48:28 2004
> > > +++ b/drivers/usb/core/devio.c	Mon Apr 26 13:48:28 2004
> > > @@ -350,8 +350,8 @@
> > >  	 * all pending I/O requests; 2.6 does that.
> > >  	 */
> > >
> > > -	if (ifnum < 8*sizeof(ps->ifclaimed))
> > > -		clear_bit(ifnum, &ps->ifclaimed);
> > > +	BUG_ON(ifnum >= 8*sizeof(ps->ifclaimed));
> >
> > I've changed that to a WARN_ON().  Yeah, writing over memory is bad, but
> > oopsing is worse.  Let's be a bit nicer than that.
>
> You aren't nice that way. An oops has localised consequences. Scribbling
> over memory can cause anything.

Hi Greg, if won't accept a BUG_ON, how about the following?

And change __inline__ to inline and get rid of an unused function
while at it.

here is the latest version 0.95 of the LEGO USB Tower driver against 2.6.6-rc3
which corrects a lot of problems in the version currently in the kernel,
most notably sleeping in interrupt context and improper locking.
Please apply.

It has been thoroughly tested with UHCI, OHCI and EHCI host controllers
using Lejos and NQC.  Firmware and program download, and with proper
modifications all communication protocols supported by Lejos work,
as well as firmware and program download and datalog upload in NQC.

Notes to application maintainers/protocol designers:

- Small modifications are needed in communication protocols because
  the tower tends to discard the first byte of transmissions.
  So for example LNP needs to send an extra byte like 0xff before
  the packet, and F7 handlers needs to cope with a lost 0x55.

- I suggest /dev/usb/legousbtower0 etc. as the standard device names.
  This puts it in the same place as the other USB devices and makes
  clear which driver is responsible for these devices.

This patch rejects URB submissions to suspended devices, so
that they don't get hardware-specific fault reports.  Instead,
they get the same code (-EHOSTUNREACH) for all HCDs.

It also fixes a minor problem with colliding declarations of
the symbol USB_STATE_SUSPENDED.

This patch lets gadget zero be more useful in testing usb suspend
and resume.  It prints messages on suspend() and resume(), and
supports an "autoresume=N" mode to wake the host after N seconds.

The Alcatel TD10 USB to Serial converter cable (for use with a Alcatel
OT 535 or 735(i) mobile phone) seems to be a repackaged Alcatel
version of the Prolific 2303 adapter.

And as such, simply adding its product/vendor id (0x11f7/0x02df) to
drivers/usb/serial/pl2303.c seems to be enough to make it work.

The USB core is changing the way interfaces and altsettings are stored.
They are no longer required to be in numerical order, and as a result,
simply indexing the interface and altsetting arrays won't work as
expected.

This patch for the st5481 takes these changes into account.  A simpler
approach would be to store a pointer to the struct usb_host_interface
rather than look it up repeatedly, but I'm not very familiar with this
driver and didn't want to attempt such an alteration.

This really needs to get fixed the proper way, by making the urb allocation
dynamic in the driver, instead of the hack it is currently doing...

Somehow I managed to send the wrong version. Here is a patch which fixes
that. (Remove a dev_info() which wasn't supposed to be there, and make sure
that everything is still consistent in the unlikely event that kmalloc()
fails). Just minor cleanups.

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

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

a ppc64 tree.

> 2) An undefined 'hubstatus' variable in drivers/usb/core/hub.c:
>
>       CC      drivers/usb/core/hub.o
>     drivers/usb/core/hub.c: In function `hub_port_connect_change':
>     drivers/usb/core/hub.c:1343: error: `hubstatus' undeclared (first use in this function)
>     drivers/usb/core/hub.c:1343: error: (Each undeclared identifier is reported only once
>     drivers/usb/core/hub.c:1343: error: for each function it appears in.)
>     make[3]: *** [drivers/usb/core/hub.o] Error 1
>
>   As a total shot in the dark, the following fixes the build (I've no clue
>   if it is the right fix):

Yes, it's the right fix.  Greg, please merge the attached patch,
which will be needed on any big-endian system.