Add a hook for updating xHCI internal structures after khubd fetches the
hub descriptor and sets up the hub's TT information.  The xHCI driver must
update the internal structures before devices under the hub can be
enumerated.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1268) changes the way usbcore handles child devices that
undergo a disconnection and reconnection while the parent hub is
suspended.  Currently, if the child isn't enabled for remote wakeup we
leave it alone, figuring that it will go through a reset-resume when
somebody tries to use it.

However this isn't a good approach if the reason for the disconnection
is that the child decided to switch modes or in some other way alter
its descriptors.  In that case we want to re-enumerate it as soon as
possible, not wait until somebody forces a reset-resume.

To resolve the issue, this patch treats reconnected suspended child
devices as though they had requested a remote wakeup, even if they
weren't enabled for it.  The mode switch or descriptor change will be
detected during the reset part of the reset-resume, and the device
will be re-enumerated immediately.

The disadvantage of this change is that it will cause autosuspended
devices to be resumed when the computer wakes up from a system sleep
during which the root hub was reset or lost power.  This shouldn't
matter much; some people would even argue that autosuspended devices
should _always_ be resumed when the system wakes up!
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: N"Yang Fei-AFY095" <fei.yang@motorola.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1267) changes usb_kick_khubd() and hdev_to_hub() to make
them more resilient against situations where a hub device isn't bound
to the hub driver.  The code assumes that if a root hub was
successfully registered then it must be bound to the hub driver.

But this assumption can fail if the user manually unbinds the hub
driver, or more importantly, if the host controller dies causing
usb_set_configuration to fail.

To protect against these possibilities, make hdev_to_hub() check that
the hub device is configured before dereferencing the active
configuration, and make usb_kick_khubd() check that the pointer to the
hub's private data structure isn't NULL.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1260) changes the pm_usage_cnt field in struct
usb_interface from an int to an atomic_t.  This is so that drivers can
invoke the usb_autopm_get_interface_async() and
usb_autopm_put_interface_async() routines without locking and without
fear of corrupting the pm_usage_cnt value.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1258) implements a feature that users have been asking
for: It gives programs the ability to "claim" a port on a hub, via a
new usbfs ioctl.  A device plugged into a "claimed" port will not be
touched by the kernel beyond the immediate necessities of
initialization and enumeration.

In particular, when a device is plugged into a "claimed" port, the
kernel will not select and install a configuration.  And when a config
is installed by usbfs or sysfs, the kernel will not probe any drivers
for any of the interfaces.  (However the kernel will fetch various
string descriptors during enumeration.  One could argue that this
isn't really necessary, but the strings are exported in sysfs.)

The patch does not guarantee exclusive access to these devices; it is
still possible for more than one program to open the device file
concurrently.  Programs are responsible for coordinating access among
themselves.

A demonstration program showing how to use the new interface can be 
found in an attachment to

	http://marc.info/?l=linux-usb&m=124345857431452&w=2

The patch also makes a small simplification to the hub driver,
replacing a bunch of more-or-less useless variants of "out of memory"
with a single message.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1255) updates the interface for calling
usb_hub_clear_tt_buffer().  Even the name of the function is changed!

When an async URB (i.e., Control or Bulk) going through a high-speed
hub to a non-high-speed device is cancelled or fails, the hub's
Transaction Translator buffer may be left busy still trying to
complete the transaction.  The buffer has to be cleared; that's what
usb_hub_clear_tt_buffer() does.

It isn't safe to send any more URBs to the same endpoint until the TT
buffer is fully clear.  Therefore the HCD needs to be told when the
Clear-TT-Buffer request has finished.  This patch adds a callback
method to struct hc_driver for that purpose, and makes the hub driver
invoke the callback at the proper time.

The patch also changes a couple of names; "hub_tt_kevent" and
"tt.kevent" now look rather antiquated.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add host controller driver API and a slot_id variable to struct
usb_device.  This allows the xHCI host controller driver to ask the
hardware to allocate a slot for the device when a struct usb_device is
allocated.  The slot needs to be allocated at that point because the
hardware can run out of internal resources, and we want to know that very
early in the device connection process.  Don't call this new API for root
hubs, since they aren't real devices.

Add HCD API to let the host controller choose the device address.  This is
especially important for xHCI hardware running in a virtualized
environment.  The guests running under the VM don't need to know which
addresses on the bus are taken, because the hardware picks the address for
them.  Announce SuperSpeed USB devices after the address has been assigned
by the hardware.

Don't use the new get descriptor/set address scheme with xHCI.  Unless
special handling is done in the host controller driver, the xHC can't
issue control transfers before you set the device address.  Support for
the older addressing scheme will be added when the xHCI driver supports
the Block Set Address Request (BSR) flag in the Address Device command.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The USB 3.0 bus specification defines a new connection sequence for USB 3.0
hubs and roothubs.  USB 3.0 devices are reset and link trained by the hub
before the port status change notification is sent to the host OS.  This means
that an entire tree of devices can be trained in parallel on power up, and the
OS no longer needs to reset USB 3.0 devices.  Change the USB core's hub port
init sequence so that it does not reset USB 3.0 devices.

The port status change from the roothub and from the USB 3.0 hub will report
the SuperSpeed connect correctly.  This patch currently only handles the
roothub case.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add USB 3.0 root hub descriptors.  This is a kludge because I reused the old
USB 2.0 descriptors, instead of using the new USB 3.0 hub descriptors with
endpoint companion descriptors and other descriptors.  I did this because I
wasn't ready to add USB 3.0 hub changes to khubd.  For now, a USB 3.0 roothub
looks like a USB 2.0 roothub, with a higher speed.

USB 3.0 hubs have no transaction translator (TT).

Make USB core debugging handle super speed ports.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Modify the USB core to handle the new USB 3.0 speed, "SuperSpeed".  This
is 5.0 Gbps (wire speed).  There are probably more places that check for
speed that I've missed.

SuperSpeed devices have a 512 byte endpoint 0 max packet size.  This shows
up as a bMaxPacketSize0 set to 0x09 (see table 9-8 of the USB 3.0 bus
spec).

xHCI spec says that the xHC can handle intervals up to 2^15 microframes.  That
might change when real silicon becomes available.

Add FIXME note for SuperSpeed isochronous endpoints.  They can transmit up
to 16 packets in one "burst" before they wait for an acknowledgment of the
packets.  They can do up to 3 bursts per microframe (determined by the
mult value in the endpoint companion descriptor).  The xHCI driver doesn't
have support for isoc yet, so fix this later.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix sparse warning in drivers/usb/core/hub.c.

The following sparse warning is seen when building on ARM due
do the macro raw_local_irq_save():

	warning: symbol 'temp' shadows an earlier one
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

transfer_buffer_length and actual_length have become unsigned, therefore some
additional conversion of local variables, function arguments and print
specifications is desired.

A test for a negative urb->transfer_buffer_length became obsolete; instead
we ensure that it does not exceed INT_MAX. Also, urb->actual_length is always
less than urb->transfer_buffer_length.

rh_string() does no longer return -EPIPE in the case of an unsupported ID.
Instead its only caller, rh_call_control() does the check.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1221) changes the way usbcore reinitializes a device
following a reset or a reset-resume.  Currently we call
usb_set_interface() for every interface in the active configuration;
this is to put the interface into the same altsetting as before the
reset and to make sure that the host's endpoint state matches the
device's endpoint state.

However, sending a Set-Interface request is a waste of time if an
interface was already in altsetting 0 before the reset, since it is
certainly in altsetting 0 afterward.  In addition, many devices can't
handle Set-Interface requests -- they crash when they receive them.

So instead, the patch adds code to check each interface.  If the
interface wasn't in altsetting 0 before the reset, we go head with the
Set-Interface request as before.  But if it was then we skip sending
the Set-Interface request, and we clear out the host-side endpoint
state by calling usb_disable_interface() followed by
usb_enable_interface().

The patch also adds a couple of new comments to explain what's going
on.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

To permit a userspace application to associate with WUSB devices
using numeric association, control transfers to unauthenticated WUSB
devices must be allowed.

This requires that wusbcore correctly sets the device state to
UNAUTHENTICATED, DEFAULT and ADDRESS and that control transfers can be
performed to UNAUTHENTICATED devices.
Signed-off-by: NDavid Vrabel <david.vrabel@csr.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The base versions handle constant folding now.
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1200) finishes some fixes that were left incomplete by
an earlier patch.

Although nobody has addressed this issue in the past, it turns out
that we need to distinguish between two different modes of disabling
and enabling endpoints.  In one mode only the data structures in
usbcore are affected, and in the other mode the host controller and
device hardware states are affected as well.

The earlier patch added an extra argument to the routines in the
enable_endpoint pathways to reflect this difference.  This patch adds
corresponding arguments to the disable_endpoint pathways.  Without
this change, the endpoint toggle state can get out of sync between
the host and the device.  The exact mechanism depends on the details
of the host controller (whether or not it stores its own copy of the
toggle values).
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NDan Streetman <ddstreet@ieee.org>
Tested-by: NDan Streetman <ddstreet@ieee.org>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Carry out the PM-routine interface change in the USB OTG pathway.  This
was omitted from the earlier interface-change patch by mistake.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: Greg KH <greg@kroah.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Felipe Balbi <felipe.balbi@nokia.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch (as1197) fixes an error introduced recently.  Since a
significant number of devices can't handle Set-Interface requests, we
no longer call usb_set_interface() when a driver unbinds from an
interface, provided the interface is already in altsetting 0.  However
the interface still does get disabled, and the call to
usb_set_interface() was the only thing re-enabling it.  Since the
interface doesn't get re-enabled, further attempts to use it fail.

So the patch adds a call to usb_enable_interface() when a driver
unbinds and the interface is in altsetting 0.  For this to work
right, the interface's endpoints have to be re-enabled but their
toggles have to be left alone.  Therefore an additional argument is
added to usb_enable_endpoint() and usb_enable_interface(), a flag
indicating whether or not the endpoint toggles should be reset.

This is a forward-ported version of a patch which fixes Bugzilla
#12301.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NDavid Roka <roka@dawid.hu>
Reported-by: NErik Ekman <erik@kryo.se>
Tested-by: NErik Ekman <erik@kryo.se>
Tested-by: NAlon Bar-Lev <alon.barlev@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1185) makes usbcore take advantage of the bus
notifications sent out by the driver core.  Now we can create all our
device and interface attribute files before the device or interface
uevent is broadcast.

A side effect is that we no longer create the endpoint "pseudo"
devices at the same time as a device or interface is registered -- it
seems like a bad idea to try registering an endpoint before the
registration of its parent is complete.  So the routines for creating
and removing endpoint devices have been split out and renamed, and
they are called explicitly when needed.  A new bitflag is used for
keeping track of whether or not the interface's endpoint devices have
been created, since (just as with the interface attributes) they vary
with the altsetting and hence can be changed at random times.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

USB: make printk messages more searchable

Make USB printk messages long and straightforward.  One of these
decorated USB error messages cost me non-trivial efforts to locate.
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1177) modifies the USB core suspend and resume
routines.  The resume functions now will take a pm_message_t argument,
so they will know what sort of resume is occurring.  The new argument
is also passed to the port suspend/resume and bus suspend/resume
routines (although they don't use it for anything but debugging).

In addition, special pm_message_t values are used for user-initiated,
device-initiated (i.e., remote wakeup), and automatic suspend/resume.
By testing these values, drivers can tell whether or not a particular
suspend was an autosuspend.  Unfortunately, they can't do the same for
resumes -- not until the pm_message_t argument is also passed to the
drivers' resume methods.  That will require a bigger change.

IMO, the whole Power Management framework should have been set up this
way in the first place.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1166) changes usb_new_device().  Now new devices will be
announced in the log _prior_ to being registered; this way the "new
device" lines will appear before all the output from driver probing,
which seems much more logical.

Also, the patch adds a call to usb_stop_pm() to the failure pathway,
so that the parent's count of unsuspended children will remain correct
if registration fails.  In order for this to work properly, the code
to increment that count has to be moved forward, before the first
point where a failure can occur.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch introduces a new call to be able to do a USB reset from an
atomic contect. This is quite helpful in USB callbacks to handle
errors (when the only thing that can be done is to do a device
reset).

It is done queuing a work struct that will do the actual reset. The
struct is "attached" to an interface so pending requests from an
interface are removed when said interface is unbound from the driver.

The call flow then becomes:

usb_queue_reset_device()
  __usb_queue_reset_device() [workqueue]
    usb_reset_device()

usb_probe_interface()
  usb_cancel_queue_reset()      [error path]

usb_unbind_interface()
  usb_cancel_queue_reset()

usb_driver_release_interface()
  usb_cancel_queue_reset()

Note usb_cancel_queue_reset() needs smarts to try not to unqueue when
it is actually being executed. This happens when we run the reset from
the workqueue: usb_reset_device() is called and on interface unbind
time, usb_cancel_queue_reset() would be called. That would deadlock on
cancel_work_sync(). To avoid that, we set (before running
usb_reset_device()) usb_intf->reset_running and clear it inmediately
after returning.

Patch is against 2.6.28-rc2 and depends on
http://marc.info/?l=linux-usb&m=122581634925308&w=2 (as submitted by
Alan Stern).
Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1160b) adds support routines for asynchronous autosuspend
and autoresume, with accompanying documentation updates.  There
already are several potential users of this interface, and others are
likely to arise as autosuspend support becomes more widespread.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1153) fixes a potential problem in hub initialization.
Starting in 2.6.28, initialization was split into several tasks to
help speed up booting.  This opens the possibility that the hub may be
autosuspended before all the initialization tasks can complete.

Normally that wouldn't matter, but with incomplete initialization
there is a risk that the hub would never autoresume -- especially if
devices were plugged into the hub beforehand.  The solution is a
simple one-line change to suppress autosuspend until the
initialization is finished.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1151) protects usbcore against drivers that try to
unlink an URB after the URB's device or bus have been removed.  The
core does not currently check for this, and certain drivers can cause
a crash if they are running while an HCD is unloaded.

Certainly it would be best to fix the guilty drivers.  But a little
defensive programming doesn't hurt, especially since it appears that
quite a few drivers need to be fixed.

The patch prevents the problem by grabbing a reference to the device
while an unlink is in progress and using a new spinlock to synchronize
unlinks with device removal.  (There's no need to acquire a reference
to the bus as well, since the device structure itself keeps a
reference to the bus.)  In addition, the kerneldoc is updated to
indicate that URBs should not be unlinked after the disconnect method
returns.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1152) may help prevent some problems associated with the
new policy of unbinding drivers that don't support suspend/resume or
pre_reset/post_reset.  If for any reason the resume or reset fails, and
the device is logically disconnected, there's no point in trying to
rebind the driver.  So the patch checks for success before carrying
out the unbind/rebind.

There was a report from one user that this fixed a problem he was
experiencing, but the details never became fully clear.  In any case,
adding these tests can't hurt.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch adds initial_descriptor_timeout module parameter for usbcore.ko
to allow modify initial 64-byte USB_REQ_GET_DESCRIPTOR timeout for
non-standard devices.

For example, the SATA8000 device from DATAST0R Technology Corp
requires about 10 seconds to send reply (probably it waits until
inserted disk is ready for operation).

Also, this patch adds missing usbcore parameters to
Documentation/kernel-parameters.txt.
Signed-off-by: NJaroslav Kysela <perex@perex.cz>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1137) changes the hub_activate() routine, replacing the
power-power-up and debounce delays with delayed_work calls.  The idea
is that on systems where the USB stack is compiled into the kernel
rather than built as modules, these delays will no longer block the
boot thread.  At least 100 ms is saved for each root hub, which can
add up to a significant savings in total boot time.

Arjan van de Ven was very pleased to see that this shaved 700 ms off
his computer's boot time.  Since his total boot time is on the order
of two seconds, the improvement is considerable.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NArjan van de Ven <arjan@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1135) essentially reverts the major parts of two earlier
patches to usbcore, because they ended up causing a regression.

Trying to recover from transient communication errors can lead to
other problems, because operations that failed during the error period
are not always retried.  The simplest example is the initial
Set-Config request sent after device enumeration; if it gets lost then
it will not be retried and the device will remain unconfigured.

This patch restores the old behavior in which any port disconnect or
port disable causes the entire device structure to be removed, fixing a
reported regression.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NFrans Pop <elendil@planet.nl>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1069c) changes the way OHCI root-hub status-change
interrupts are enabled.  Currently a special HCD method,
hub_irq_enable(), is called when the hub driver is finished using a
root hub.  This approach turns out to be subject to races, resulting
in unnecessary polling.

The patch does away with the method entirely.  Instead, the driver
automatically enables the RHSC interrupt when no more status changes
are present.  This scheme is safe with controllers using
level-triggered semantics for their interrupt flags.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1109b) makes USB-Persist more resilient to errors.  With
the current code, if a normal resume fails, it's an unrecoverable
error.  With the patch, if a normal resume fails (and if the device is
enabled for USB-Persist) then a reset-resume is tried.

This fixes the problem reported in Bugzilla #10977.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1024) takes care of a FIXME issue: Drivers that don't
have the necessary suspend, resume, reset_resume, pre_reset, or
post_reset methods will be unbound and their interface reprobed when
one of the unsupported events occurs.

This is made slightly more difficult by the fact that bind operations
won't work during a system sleep transition.  So instead the code has
to defer the operation until the transition ends.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch renames the existing usb_reset_device in hub.c to
usb_reset_and_verify_device and renames the existing
usb_reset_composite_device to usb_reset_device. Also the new
usb_reset_and_verify_device does't need to be EXPORTED .

The idea of the patch is that external interface driver
should warn the other interfaces' driver of the same
device before and after reseting the usb device. One interface
driver shoud call _old_ usb_reset_composite_device instead of
_old_ usb_reset_device since it can't assume the device contains
only one interface. The _old_ usb_reset_composite_device
is safe for single interface device also. we rename the two
functions to make the change easily.

This patch is under guideline from Alan Stern.
Signed-off-by: NMing Lei <tom.leiming@gmail.com>

From the current implementation of usb_reset_composite_device
function, the iface parameter is no longer useful. This function
doesn't do something special for the iface usb_interface,compared
with other interfaces in the usb_device. So remove the parameter
and fix the related caller.
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We can't allow hubs on the 7th tier as they would allow
devices on the 8th tier.
Signed-off-by: NFelipe Balbi <felipe.balbi@nokia.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1083) combines hub_quiesce() and hub_stop() into a
single routine.  There's no point keeping them separate since they are
usually called together.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1071) combines hub_activate() and hub_restart() into a
single routine.  There's no point keeping them separate, since they
are always called together.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1082) makes a small optimization to the way the hub
driver carries out port debouncing immediately after a hub is
activated (i.e., initialized, reset, or resumed).  If any port-change
statuses are observed, the code will delay for a minimal debounce
period -- thereby making a good start at debouncing all the ports at
once.

If this wasn't sufficient then khubd will debounce any port that still
requires attention.  But in most cases it should suffice; it's rare
for a device to need more than a minimal debounce delay.  (In the
cases of hub initialization or reset even that is most likely not
needed, since any devices plugged in at such times have probably been
attached for a while.)
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1073) adds to khubd a way to recover from power-session
interruption caused by transient connect-change or enable-change
events.  After the debouncing period, khubd attempts to do a
USB-Persist-style reset or reset-resume.  If it works, the connection
will remain unscathed.

The upshot is that we will be more immune to noise caused by EMI.  The
grace period is on the order of 100 ms, so this won't permit recovery
from the "accidentally knocked the USB cable out of its socket" type
of event, but it's a start.

As an added bonus, if a device was suspended when the system goes to
sleep then we no longer need to check for power-session interruptions
when the system wakes up.  Khubd will naturally see the status change
while processing the device's parent hub and will do the right thing.

The remote_wakeup() routine is changed; now it expects the caller to
acquire the device lock rather than acquiring the lock itself.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>