Protocol stall should not be fatal while reading port or hub status as it is
transient state.  Currently hub EP0 STALL during port status read results in
failed device enumeration.  This has been observed with ST-Ericsson (formerly
Philips) USB 2.0 Hub (04cc:1521) after connecting keyboard.
Signed-off-by: NLibor Pechacek <lpechacek@suse.cz>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Some USB3.0 devices go to SS.Inactive state when hot plug to USB3 ports.
Warm reset the port to transition it to U0 state.

This patch fixes the issue that Kingston USB3.0 flash drive can not be
recognized when hot plug to USB3 port.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

In the past, we use USB2.0 request to suspend and resume a USB3.0 device.
Actually, USB3.0 hub does not support Set/Clear PORT_SUSPEND request,
instead, it uses Set PORT_LINK_STATE request. This patch makes USB3.0 device
suspend/resume comply with USB3.0 specification.

This patch fixes the issue that USB3.0 device can not be suspended when
connected to a USB3.0 external hub.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

USB3.0 specification has different wPortStatus and wPortChange definitions
from USB2.0 specification. Since USB3 root hub and USB2 root hub are split
now and USB3 hub only has USB3 protocol ports, we should modify the
portstatus and portchange report of USB3 ports to comply with USB3.0
specification.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

This patch clear PORT_POWER when suspend a USB3.0 device behind a USB3.0
external hub, so the system can suspend and resume.

Note USB3.0 device may not work after system resume and this is a temporary
workaround. The correct fix will be in future patches.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>

A subsequent patch will modify device_set_wakeup_capable() in such
a way that it will call functions which may sleep and therefore it
shouldn't be called under spinlocks.  In preparation to that, modify
usb_set_device_state() to avoid calling device_set_wakeup_capable()
under device_state_lock.
Tested-by: NMinchan Kim <minchan.kim@gmail.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>

USB 3.0 devices have a slightly different suspend sequence than USB
2.0/1.1 devices.  There isn't support for USB 3.0 device suspend yet, so
make khubd leave autosuspend disabled for USB 3.0 hubs.  Make sure that
USB 3.0 roothubs still have autosuspend enabled, since that path in the
xHCI driver works fine.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

USB_PORT_STAT_SUPER_SPEED is a made up symbol that the USB core used to
track whether USB ports had a SuperSpeed device attached.  This is a
linux-internal symbol that was used when SuperSpeed and non-SuperSpeed
devices would show up under the same xHCI roothub.  This particular
port status is never returned by external USB 3.0 hubs.  (Instead they
have a USB_PORT_STAT_SPEED_5GBPS that uses a completely different speed
mask.)

Now that the xHCI driver registers two roothubs, USB 3.0 devices will only
show up under USB 3.0 hubs.  Rip out USB_PORT_STAT_SUPER_SPEED and replace
it with calls to hub_is_superspeed().
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Change the bandwith_mutex in struct usb_hcd to a pointer.  This will allow
the pointer to be shared across usb_hcds for the upcoming work to split
the xHCI driver roothub into a USB 2.0/1.1 and a USB 3.0 bus.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

In USB 3.0, there are two types of resets: a "hot" port reset and a "warm"
port reset.  The hot port reset is always tried first, and involves
sending the reset signaling for a shorter amount of time.  But sometimes
devices don't respond to the hot reset, and a "Bigger Hammer" is needed.

External hubs and roothubs will automatically try a warm reset when the
hot reset fails, and they will set a status change bit to indicate when
there is a "BH reset" change.  Make sure the USB core clears that port
status change bit, or we'll get lots of status change notifications on the
interrupt endpoint of the USB 3.0 hub.

(Side note: you may be confused why the USB 3.0 spec calls the same type
of reset "warm reset" in some places and "BH reset" in other places.  "BH"
reset is supposed to stand for "Big Hammer" reset, but it also stands for
"Brad Hosler".  Brad died shortly after the USB 3.0 bus specification was
started, and they decided to name the reset after him.  The suggestion was
made shortly before the spec was finalized, so the wording is a bit
inconsistent.)
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Update the USB core to deal with USB 3.0 hubs.  These hubs have a slightly
different hub descriptor than USB 2.0 hubs, with a fixed (rather than
variable length) size.  Change the USB core's hub descriptor to have a
union for the last fields that differ.  Change the host controller drivers
that access those last fields (DeviceRemovable and PortPowerCtrlMask) to
use the union.

Translate the new version of the hub port status field into the old
version that khubd understands.  (Note: we need to fix it to translate the
roothub's port status once we stop converting it to USB 2.0 hub status
internally.)

Add new code to handle link state change status.  Send out new control
messages that are needed for USB 3.0 hubs, like Set Hub Depth.

This patch is a modified version of the original patch submitted by John
Youn.  It's updated to reflect the removal of the "bitmap" #define, and
change the hub descriptor accesses of a couple new host controller
drivers.
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
Cc: Tony Olech <tony.olech@elandigitalsystems.com>
Cc: "Robert P. J. Day" <rpjday@crashcourse.ca>
Cc: Max Vozeler <mvz@vozeler.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Rodolfo Giometti <giometti@linux.it>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Anton Vorontsov <avorontsov@mvista.com>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Cc: Lothar Wassmann <LW@KARO-electronics.de>
Cc: Olav Kongas <ok@artecdesign.ee>
Cc: Martin Fuzzey <mfuzzey@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <dbrownell@users.sourceforge.net>

On a laptop I see these errors on (most) resumes:
    hub 3-0:1.0: over-current change on port 1
    hub 3-0:1.0: over-current change on port 2

Since over-current conditions can disappear quite quickly it's better to
downgrade that message to debug level, recheck for an over-current
condition a little later and only print and over-current condition error
if that condition (still) exists when it's rechecked.

Add similar logic to hub over-current changes. (That code is untested,
as those changes do not occur on this laptop.)
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The Patch below removes one to many "n's" in a word..
Signed-off-by: NJustin P. Mattock <justinmattock@gmail.com>
CC: Alan Stern <stern@rowland.harvard.edu>
CC: linux-usb@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The USB stack historically has conflated device numbers (i.e., the
value of udev->devnum) with device addresses.  This is understandable,
because until recently the two values were always the same.

But with USB-3.0 they aren't the same, so we should start calling
these things by their correct names.  This patch (as1449b) changes many
of the references to "address" in the hub driver to "device number"
or "devnum".

The patch also removes some unnecessary or misleading comments.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NLuben Tuikov <ltuikov@yahoo.com>
Reviewed-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

If the device isn't reset, the XHCI HCD sends
SET ADDRESS to address 0 while the device is
already in Addressed state, and the request is
dropped on the floor as it is addressed to the
default address. This sequence of events, which this
patch fixes looks like this:

usb_reset_and_verify_device()
	hub_port_init()
		hub_set_address()
			SET_ADDRESS to 0 with 1
		usb_get_device_descriptor(udev, 8)
		usb_get_device_descriptor(udev, 18)
	descriptors_changed() --> goto re_enumerate:
		hub_port_logical_disconnect()
			kick_khubd()

And then:

hub_events()
	hub_port_connect_change()
		usb_disconnect()
			usb_disable_device()
		new device struct
		sets device state to Powered
		choose_address()
		hub_port_init() <-- no reset, but SET ADDRESS to 0 with 1, timeout!

The solution is to always reset the device in
hub_port_init() to put it in a known state.

Note from Sarah Sharp:

This patch should be queued for stable trees all the way back to 2.6.34,
since that was the first kernel that supported configured device reset.
The code this patch touches has been there since 2.6.32, but the bug
would never be hit before 2.6.34 because the xHCI driver would
completely reject an attempt to reset a configured device under xHCI.
Signed-off-by: NLuben Tuikov <ltuikov@yahoo.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

This reverts commit 637d11bf.  Sarah
wants to tweak it some more before it's applied to the tree.

Cc: Luben Tuikov <ltuikov@yahoo.com>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

If the device isn't reset, the XHCI HCD sends
SET ADDRESS to address 0 while the device is
already in Addressed state, and the request is
dropped on the floor as it is addressed to the
default address. This sequence of events, which this
patch fixes looks like this:

usb_reset_and_verify_device()
	hub_port_init()
		hub_set_address()
			SET_ADDRESS to 0 with 1
		usb_get_device_descriptor(udev, 8)
		usb_get_device_descriptor(udev, 18)
	descriptors_changed() --> goto re_enumerate:
		hub_port_logical_disconnect()
			kick_khubd()

And then:

hub_events()
	hub_port_connect_change()
		usb_disconnect()
			usb_disable_device()
		new device struct
		sets device state to Powered
		choose_address()
		hub_port_init() <-- no reset, but SET ADDRESS to 0 with 1, timeout!

The solution is to always reset the device in
hub_port_init() to put it in a known state.
Signed-off-by: NLuben Tuikov <ltuikov@yahoo.com>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

If anyone comes across a high-speed hub that (by mistake or by design)
claims to have no Transaction Translators, plugging a full- or
low-speed device into it will cause the USB stack to crash.  This
patch (as1446) prevents the problem by ignoring such devices, since
the kernel has no way to communicate with them.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NPerry Neben <neben@vmware.com>
CC: <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When there's an xHCI host power loss after a suspend from memory, the USB
core attempts to reset and verify the USB devices that are attached to the
system.  The xHCI driver has to reallocate those devices, since the
hardware lost all knowledge of them during the power loss.

When a hub is plugged in, and the host loses power, the xHCI hardware
structures are not updated to say the device is a hub.  This is usually
done in hub_configure() when the USB hub is detected.  That function is
skipped during a reset and verify by the USB core, since the core restores
the old configuration and alternate settings, and the hub driver has no
idea this happened.  This bug makes the xHCI host controller reject the
enumeration of low speed devices under the resumed hub.

Therefore, make the USB core re-setup the internal xHCI hub device
information by calling update_hub_device() when hub_activate() is called
for a hub reset resume.  After a host power loss, all devices under the
roothub get a reset-resume or a disconnect.

This patch should be queued for the 2.6.37 stable tree.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org

This patch (as1434) cleans up the uses of usb_mark_last_busy() in
usbcore.  The function will be called when a device is resumed and
whenever a usage count is decremented.  A call that was missing from
the hub driver is added: A hub is used whenever one of its ports gets
suspended (this prevents hubs from suspending immediately after their
last child).

In addition, the call to disable autosuspend support for new devices
by default is moved from usb_detect_quirks() (where it doesn't really
belong) into usb_new_device() along with all the other runtime-PM
initializations.  Finally, an extra pm_runtime_get_noresume() is added
to prevent new devices from autosuspending while they are being
registered.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1428) converts USB over to the new runtime-PM core
autosuspend framework.  One slightly awkward aspect of the conversion
is that USB devices will now have two suspend-delay attributes: the
old power/autosuspend file and the new power/autosuspend_delay_ms
file.  One expresses the delay time in seconds and the other in
milliseconds, but otherwise they do the same thing.  The old attribute
can be deprecated and then removed eventually.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Since the runtime-PM core already defines a .last_busy field in
device.power, this patch uses it to replace the .last_busy field
defined in usb_device and uses pm_runtime_mark_last_busy to implement
usb_mark_last_busy.
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Reviewed-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

A few devices (such as the RCA VR5220 voice recorder) are so
non-compliant with the USB spec that they have invalid maxpacket sizes
for endpoint 0.  Nevertheless, as long as we can safely use them, we
may as well do so.

This patch (as1432) softens our acceptance criterion by allowing
high-speed devices to have ep0-maxpacket sizes other than 64.  A
warning is printed in the system log when this happens, and the
existing error message is clarified.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NJames <bjlockie@lockie.ca>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When the system suspends and a host controller's power is lost, the USB
core attempts to revive any USB devices that had the persist_enabled flag
set.  For non-SuperSpeed devices, it will disable the port, and then set
the udev->reset_resume flag.  This will cause the USB core to reset the
device, verify the device descriptors to make sure it's the same device,
and re-install any non-default configurations or alternate interface
settings.

However, we can't disable SuperSpeed root hub ports because that turns off
SuperSpeed terminations, which will inhibit any devices connecting at USB
3.0 speeds.  (Plus external hubs don't allow SuperSpeed ports to be
disabled.)

Because of this logic in hub_activate():
                /* We can forget about a "removed" device when there's a
                 * physical disconnect or the connect status changes.
                 */
                if (!(portstatus & USB_PORT_STAT_CONNECTION) ||
                                (portchange & USB_PORT_STAT_C_CONNECTION))
                        clear_bit(port1, hub->removed_bits);

                if (!udev || udev->state == USB_STATE_NOTATTACHED) {
                        /* Tell khubd to disconnect the device or
                         * check for a new connection
                         */
                        if (udev || (portstatus & USB_PORT_STAT_CONNECTION))
                                set_bit(port1, hub->change_bits);

                } else if (portstatus & USB_PORT_STAT_ENABLE) {
                        /* The power session apparently survived the resume.
                         * If there was an overcurrent or suspend change
                         * (i.e., remote wakeup request), have khubd
                         * take care of it.
                         */
                        if (portchange)
                                set_bit(port1, hub->change_bits);

                } else if (udev->persist_enabled) {
                        udev->reset_resume = 1;
                        set_bit(port1, hub->change_bits);

                } else {
                        /* The power session is gone; tell khubd */
                        usb_set_device_state(udev, USB_STATE_NOTATTACHED);
                        set_bit(port1, hub->change_bits);
                }

a SuperSpeed device after a resume with a loss of power will never get the
reset_resume flag set.  Instead the core will assume the power session
survived and that the device still has the same address, configuration,
and alternate interface settings.  The xHCI host controller will have no
knowledge of the device (since all xhci_virt_devices were destroyed when
power loss was discovered, and xhci_discover_or_reset_device() has not
been called), and all URBs to the device will fail.

If the device driver responds by resetting the device, everything will
continue smoothly.  However, if lsusb is used before the device driver
resets the device (or there is no driver), then all lsusb descriptor
fetches will fail.

The quick fix is to pretend the port is disabled in hub_activate(), by
clearing the local variable.  But I'm not sure what other parts of the hub
driver need to be changed because they have assumptions about when ports
will be disabled.
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

xHCI driver uses hardware assigned device address. This may cause device
address conflict in certain cases.

Use kernel assigned address for devices under xHCI. Store the xHC assigned
address locally in xHCI driver.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>

Found while debugging a USB problem and trying to find the mentioned function.
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The Logitech Harmony 700 series needs an extra delay during
initialization.  This patch adds a USB quirk which enables such a delay
and adds the device to the quirks list.
Signed-off-by: NPhil Dibowitz <phil@ipom.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

And audit all the users. None needed the BKL.  That was easy
because there was only very few around.

Tested with allmodconfig build on x86-64
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
From: Andi Kleen <ak@linux.intel.com>

With this patch, the LPM capable EHCI host controller can put device
into L1 sleep state which is a mode that can enter/exit quickly, and
reduce power consumption.
Signed-off-by: NJacob Pan <jacob.jun.pan@intel.com>
Signed-off-by: NAlek Du <alek.du@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Without this fix, a USB 3.0 port is downgraded to full speed after a port
reset of a configured device.  The USB 3.0 terminations will be disabled
permanently, and USB 3.0 devices will always enumerate as full speed
devices, until the host controller is unplugged (if it is an ExpressCard)
or the computer is rebooted.

Fajun Chen traced this traced the speed downgrade issue to the port reset
and the interpretation of port status in USB hub driver code.  The hub
code was not testing for the port being a SuperSpeed port, and it fell
through to the else case of Full Speed.

The following patch adds SuperSpeed mapping from the port status, and
fixes the speed downgrade issue.
Reported-by: NFajun Chen <fajun.chen@seagate.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When USB3 protocol port detects an USB3.0 device attach, the port will
automatically transition to the Enabled state upon the completion
of successful link training.

Do not disable USB3 protocol ports in hub_activate(), or USB3.0 device
will fail to be recognized if xHCI bus power management is implemented.
Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1364) avoids enabling remote wakeup by default on all
non-root-hub USB devices.  Individual drivers or userspace will have
to enable it wherever it is needed, such as for keyboards or network
interfaces.  Note: This affects only system sleep, not autosuspend.

External hubs will continue to relay wakeup requests received from
downstream through their upstream port, even when remote wakeup is not
enabled for the hub itself.  Disabling remote wakeup on a hub merely
prevents it from generating wakeup requests in response to connect,
disconnect, and overcurrent events.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1349b) clears up the confusion in many USB host
controller drivers between port features and port statuses.  In mosty
cases it's true that the status bit is in the position given by the
corresponding feature value, but that's not always true and it's not
guaranteed in the USB spec.

There's no functional change, just replacing expressions of the form
(1 << USB_PORT_FEAT_x) with USB_PORT_STAT_x, which has the same value.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1348) removes the bogus
USB_PORT_FEAT_{HIGHSPEED,SUPERSPEED} symbols from ch11.h.  No such
features are defined by the USB spec.  (There is a PORT_LOWSPEED
feature, but the spec doesn't mention it except to say that host
software should never use it.)  The speed indicators are port
statuses, not port features.

As a temporary workaround for the xhci-hcd driver, a fictional
USB_PORT_STAT_SUPER_SPEED symbol is added.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The usbcore headers: hcd.h and hub.h are shared between usbcore,
HCDs and a couple of other drivers (e.g. USBIP modules).
So, it makes sense to move them into a more public location and
to cleanup dependency of those modules on kernel internal headers.
This patch moves hcd.h from drivers/usb/core into include/linux/usb/
Signed-of-by: NEric Lescouet <eric@lescouet.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The id_table field of the struct usb_device_id is constant in <linux/usb.h>
so it is worth to make the initialization data also constant.

The semantic match that finds this kind of pattern is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r@
disable decl_init,const_decl_init;
identifier I1, I2, x;
@@
	struct I1 {
	  ...
	  const struct I2 *x;
	  ...
	};
@s@
identifier r.I1, y;
identifier r.x, E;
@@
	struct I1 y = {
	  .x = E,
	};
@c@
identifier r.I2;
identifier s.E;
@@
	const struct I2 E[] = ... ;
@depends on !c@
identifier r.I2;
identifier s.E;
@@
+	const
	struct I2 E[] = ...;
// </smpl>
Signed-off-by: NNémeth Márton <nm127@freemail.hu>
Cc: Julia Lawall <julia@diku.dk>
Cc: cocci@diku.dk
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

USB: Move hcd free_dev call into usb_disconnect

I found a way to oops the kernel:

1. Open a USB device through devio.
2. Remove the hcd module in the host kernel.
3. Close the devio file descriptor.

The problem is that closing the file descriptor does usb_release_dev
as it is the last reference.  usb_release_dev then tries to invoke
the hcd free_dev function (or rather dereferencing the hcd driver
struct).  This causes an oops as the hcd driver has already been
unloaded so the struct is gone.

This patch tries to fix this by bringing the free_dev call earlier
and into usb_disconnect.  I have verified that repeating the
above steps no longer crashes with this patch applied.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch (as1329) converts the USB stack over to the PM core's
runtime PM framework.  This involves numerous changes throughout
usbcore, especially to hub.c and driver.c.  Perhaps the most notable
change is that CONFIG_USB_SUSPEND now depends on CONFIG_PM_RUNTIME
instead of CONFIG_PM.

Several fields in the usb_device and usb_interface structures are no
longer needed.  Some code which used to depend on CONFIG_USB_PM now
depends on CONFIG_USB_SUSPEND (requiring some rearrangement of header
files).

The only visible change in behavior should be that following a system
sleep (resume from RAM or resume from hibernation), autosuspended USB
devices will be resumed just like everything else.  They won't remain
suspended.  But if they aren't in use then they will naturally
autosuspend again in a few seconds.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>