The system suspend flow as following:
1, Freeze all user processes and kenrel threads.

2, Try to suspend all devices.

2.1, If pci device is in RPM suspended state, then pci driver will try
to resume it to RPM active state in the prepare stage.

2.2, xhci_resume function calls usb_hcd_resume_root_hub to queue two
workqueue items to resume usb2&usb3 roothub devices.

2.3, Call suspend callbacks of devices.

2.3.1, All suspend callbacks of all hcd's children, including
roothub devices are called.

2.3.2, Finally, hcd_pci_suspend callback is called.

Due to workqueue threads were already frozen in step 1, the workqueue
items can't be scheduled, and the roothub devices can't be resumed in
this flow. The HCD_FLAG_WAKEUP_PENDING flag which is set in
usb_hcd_resume_root_hub won't be cleared. Finally,
hcd_pci_suspend will return -EBUSY, and system suspend fails.

The reason why this issue doesn't show up very often is due to that
choose_wakeup will be called in step 2.3.1. In step 2.3.1, if
udev->do_remote_wakeup is not equal to device_may_wakeup(&udev->dev), then
udev will resume to RPM active for changing the wakeup settings. This
has been a lucky hit which hides this issue.

For some special xHCI controllers which have no USB2 port, then roothub
will not match hub driver due to probe failed. Then its
do_remote_wakeup will be set to zero, and we won't be as lucky.

xhci driver doesn't need to resume roothub devices everytime like in
the above case. It's only needed when there are pending event TRBs.

This patch should be back-ported to kernels as old as 3.2, that
contains the commit f69e3120
"USB: XHCI: resume root hubs when the controller resumes"

Cc: stable@vger.kernel.org # 3.2
Signed-off-by: NWang, Yu <yu.y.wang@intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
[use readl() instead of removed xhci_readl(), reword commit message -Mathias]
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When xHCI PCI host is suspended, if do_wakeup is false in xhci_pci_suspend,
xhci_bus_suspend needs to clear all root port wake on bits. Otherwise some Intel
platforms may get a spurious wakeup, even if PCI PME# is disabled.

This patch should be back-ported to kernels as old as 2.6.37, that
contains the commit 9777e3ce
"USB: xHCI: bus power management implementation".

Cc: stable@vger.kernel.org # 2.6.37
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The transfer burst count (TBC) field in xhci 1.0 hosts should be set
to the number of bursts needed to transfer all packets in a isoc TD.
Supported values are 0-2 (1 to 3 bursts per service interval).

Formula for TBC calculation is given in xhci spec section 4.11.2.3:
TBC = roundup( Transfer Descriptor Packet Count / Max Burst Size +1 ) - 1

This patch should be applied to stable kernels since 3.0 that contain
the commit 5cd43e33
"xhci 1.0: Set transfer burst count field."

Cc: stable@vger.kernel.org # 3.0
Suggested-by: NShiChun Ma <masc2008@qq.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Command completion events normally include command completion status,
SLOT_ID, and a pointer to the original command. Reset device command
completion SLOT_ID may be zero according to xhci specs 4.6.11.

VIA controllers set the SLOT_ID to zero, triggering a WARN_ON in the
command completion handler.

Use the SLOT ID found from the original command instead.

This patch should be applied to stable kernels since 3.13 that contain
the commit 20e7acb1
"xhci: use completion event's slot id rather than dig it out of command"

Cc: stable@vger.kernel.org # 3.13
Reported-by: NSaran Neti <sarannmr@gmail.com>
Tested-by: NSaran Neti <sarannmr@gmail.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

BABBLE and RESET share the same interrupt. The interrupt
is considered to be RESET if MUSB is in peripheral mode and
as a BABBLE if MUSB is in HOST mode.

Handle babble condition iff MUSB is in HOST mode.

Fixes: ca88fc2e (usb: musb: add a work_struct to recover from babble errors)
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NGeorge Cherian <george.cherian@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This reverts commit 1826e9b1 (usb: gadget: gadgetfs: use
after free in dev_release()) and places the call to
put_dev() after setting the state.

If this is not the final call to dev_release() and the
state is not reset to STATE_DEV_DISABLED and hence all
further open() calls to the gadgetfs ep0 device will
fail with EBUSY.
Signed-off-by: NMarcus Nutzinger <marcus.nutzinger@theobroma-systems.com>
Reviewed-by: NChristoph Muellner <christoph.muellner@theobroma-systems.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Function's interface directories need to be created when the function
directory is created, but interface numbers are not known until
the gadget is ready and bound to udc, so we cannot use numbers
as part of interface directory names.
Let the client decide what names to use.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

A number of variables serve a generic purpose of handling
"compatible id" and "subcompatible id", but the names suggest they
are for rndis only. Rename to reflect variables' purpose.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

If the descriptors do not need any strings and user space sends empty
set of strings, the ffs->stringtabs field remains NULL.  Thus
*ffs->stringtabs in functionfs_bind leads to a NULL pointer
dereferenece.

The bug was introduced by commit [fd7c9a00: “use usb_string_ids_n()”].

While at it, remove double initialisation of lang local variable in
that function.

ffs->strings_count does not need to be checked in any way since in
the above scenario it will remain zero and usb_string_ids_n() is
a no-operation when colled with 0 argument.

Cc: <stable@vger.kernel.org>  # v2.6.36+
Signed-off-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

There is a regression in the upcoming v3.16-rc1, that is caused
by a problem that has been around for a while but now finally
hangs the system. The bootcrawl looks like this:

pinctrl-nomadik soc:pinctrl: pin GPIO256_AF28 already
requested by a03e0000.usb_per5; cannot claim for musb-hdrc.0.auto
pinctrl-nomadik soc:pinctrl: pin-256 (musb-hdrc.0.auto) status -22
pinctrl-nomadik soc:pinctrl: could not request pin 256
(GPIO256_AF28) from group usb_a_1  on device pinctrl-nomadik
musb-hdrc musb-hdrc.0.auto: Error applying setting, reverse
things back
HS USB OTG: no transceiver configured
musb-hdrc musb-hdrc.0.auto: musb_init_controller failed
with status -517
platform musb-hdrc.0.auto: Driver musb-hdrc requests
probe deferral
(...)

The ux500 MUSB driver propagates the OF node to the dynamically
created musb-hdrc device, which is incorrect as it makes the OF
core believe there are two devices spun from the very same
DT node, which confuses other parts of the device core, notably
the pin control subsystem, which will try to apply all the pin
control settings also to the HDRC device as it gets
instantiated. (The OMAP2430 for example, does not set the
of_node member.)

Cc: <stable@vger.kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Current usbhs gadget driver didn't complete STATUS stage after receiving.
It wasn't problem for us before, because some USB class doesn't use
DATA OUT stage in control transfer.
But, it is required on some device.
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

When disconnecting, it's possible that another thread has already made it
into eth_start_xmit before we call netif_stop_queue. This can lead to a
crash as eth_start_xmit tries to use resources that gether_disconnect is
freeing. Use netif_tx_lock/unlock around netif_stop_queue to ensure no
threads are executing during the remainder of gether_disconnect.
Signed-off-by: NJeff Westfahl <jeff.westfahl@ni.com>
Tested-by: NJaeden Amero <jaeden.amero@ni.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The dwc3 wrapper driver should not be fiddling with the core interrupts.
Disabling the core interrupts in prepare stops xhci from proper operation.
So remove disable/enable of core interrupts from prepare/complete.
Signed-off-by: NGeorge Cherian <george.cherian@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Following crash is seen on dwc3_omap removal
Unable to handle kernel NULL pointer dereference at virtual address 00000018
pgd = ec098000
[00000018] *pgd=ad1f9831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] SMP ARM
Modules linked in: usb_f_ss_lb g_zero usb_f_acm u_serial usb_f_ecm u_ether libcomposite configfs snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_hwdep snd_soc_omap snd_pcm_dmaengine snd_soc_core snd_compress snd_pcm snd_tim]
CPU: 0 PID: 1296 Comm: rmmod Tainted: G        W     3.15.0-rc4-02716-g95c4e18-dirty #10
task: ed05a080 ti: ec368000 task.ti: ec368000
PC is at release_resource+0x14/0x7c
LR is at release_resource+0x10/0x7c
pc : [<c0044724>]    lr : [<c0044720>]    psr: 60000013
sp : ec369ec0  ip : 60000013  fp : 00021008
r10: 00000000  r9 : ec368000  r8 : c000e7a4
r7 : 00000081  r6 : bf0062c0  r5 : ed7cd000  r4 : ed7d85c0
r3 : 00000000  r2 : 00000000  r1 : 00000011  r0 : c086d08c
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: ac098059  DAC: 00000015
Process rmmod (pid: 1296, stack limit = 0xec368248)
Stack: (0xec369ec0 to 0xec36a000)
9ec0: 00000000 00000001 ed7cd000 c034de94 ed7cd010 ed7cd000 00000000 c034e194
9ee0: 00000000 bf0062cc ed7cd010 c03490b0 ed154cc0 ed4c2570 ed2b8410 ed156810
ed156810 bf006d24 c034db9c c034db84 c034c518
9f20: bf006d24 ed156810 bf006d24 c034cd2c bf006d24 bf006d68 00000800 c034c340
9f40: 00000000 c00a9e5c 00000020 00000000 bf006d68 00000800 ec369f4c 33637764
9f60: 616d6f5f 00000070 00000001 ec368000 ed05a080 c000e670 00000001 c0084010
9f80: 00021088 00000800 00021088 00000081 80000010 0000e6f4 00021088 00000800
9fa0: 00021088 c000e5e0 00021088 00000800 000210b8 00000800 e04f6d00 e04f6d00
9fc0: 00021088 00000800 00021088 00000081 00000001 00000000 be91de08 00021008
9fe0: 4d768880 be91dbb4 b6fc5984 4d76888c 80000010 000210b8 00000000 00000000
[<c0044724>] (release_resource) from [<c034de94>] (platform_device_del+0x6c/0x9c)
[<c034de94>] (platform_device_del) from [<c034e194>] (platform_device_unregister+0xc/0x18)
[<c034e194>] (platform_device_unregister) from [<bf0062cc>] (dwc3_omap_remove_core+0xc/0x14 [dwc3_omap])
[<bf0062cc>] (dwc3_omap_remove_core [dwc3_omap]) from [<c03490b0>] (device_for_each_child+0x34/0x74)
[<c03490b0>] (device_for_each_child) from [<bf0062b4>] (dwc3_omap_remove+0x6c/0x78 [dwc3_omap])
[<bf0062b4>] (dwc3_omap_remove [dwc3_omap]) from [<c034db9c>] (platform_drv_remove+0x18/0x1c)
[<c034db9c>] (platform_drv_remove) from [<c034c518>] (__device_release_driver+0x70/0xc8)
[<c034c518>] (__device_release_driver) from [<c034cd2c>] (driver_detach+0xb4/0xb8)
[<c034cd2c>] (driver_detach) from [<c034c340>] (bus_remove_driver+0x4c/0x90)
[<c034c340>] (bus_remove_driver) from [<c00a9e5c>] (SyS_delete_module+0x10c/0x198)
[<c00a9e5c>] (SyS_delete_module) from [<c000e5e0>] (ret_fast_syscall+0x0/0x48)
Code: e1a04000 e59f0068 eb14505e e5943010 (e5932018)
---[ end trace 7e2a8746ff4fc811 ]---
Segmentation fault

[ balbi@ti.com : add CONFIG_OF dependency ]
Signed-off-by: NGeorge Cherian <george.cherian@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This should be return -ENOMEM.  The current code returns successs.

Fixes: de7a8d2d ('usb: gadget: f_rndis: OS descriptors support')
Acked-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In ISOC transfers, when free_slot points to the last TRB (i.e. Link
TRB), and all queued requests meet Missed Interval Isoc error, busy_slot
points to trb0.
	busy_slot->trb0
		   trb1
		   ...
	free_slot->trb31(Link TRB)

After end transfer and receiving the XferNotReady event, trb_left is
caculated as 1 which is wrong, and no TRB will be primed to the
endpoint.

The root cause is free_slot is not increased the same way as busy_slot.
When busy_slot is increased by one, it checks if points to a link TRB
after increasement, but free_slot checks it before increasement.
free_slot should behave the same as busy_slot to make the trb_left
caculation correct.
Reviewed-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NZhuang Jin Can <jin.can.zhuang@intel.com>
Signed-off-by: NJiebing Li <jiebing.li@intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In usbtest, tests 5 - 8 use the scatter-gather library in usbcore
without any sort of timeout.  If there's a problem in the gadget or
host controller being tested, the test can hang.

This patch adds a 10-second timeout to the tests, so that they will
fail gracefully with an ETIMEDOUT error instead of hanging.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NHuang Rui <ray.huang@amd.com>
Tested-by: NHuang Rui <ray.huang@amd.com>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Leandro Liptak reports that his HASEE E200 computer hangs when we ask
the BIOS to hand over control of the EHCI host controller.  This
definitely sounds like a bug in the BIOS, but at the moment there is
no way to fix it.

This patch works around the problem by avoiding the handoff whenever
the motherboard and BIOS version match those of Leandro's computer.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NLeandro Liptak <leandroliptak@gmail.com>
Tested-by: NLeandro Liptak <leandroliptak@gmail.com>
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 9262c19d "usb: disable port power control if not supported in
wHubCharacteristics" gated enabling runtime pm for usb_port devices on
whether the parent hub supports power control, which causes a
regression.  The port must still be allowed to carry out runtime pm
callbacks and receive a -EAGAIN or -EBUSY result.  Otherwise the
usb_port device will transition to the pm error state and trigger the
same for the child usb_device.

Prior to the offending commit usb_hub_create_port_device() arranged for
runtime pm to be disabled is dev_pm_qos_expose_flags() failed.  Instead,
force the default state of PM_QOS_FLAG_NO_POWER_OFF flag to be set prior
to enabling runtime pm.  If that policy can not be set then fail
registration.

Report: http://marc.info/?l=linux-usb&m=140290586301336&w=2
Fixes: 9262c19d ("usb: disable port power control if not supported in wHubCharacteristics")
Reported-by: NBjørn Mork <bjorn@mork.no>
Reported-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In the case where platform firmware has specified conflicting values for
port locations it is confusing and otherwise not helpful to throw a
backtrace.  Instead, include enough information to determine that
firmware has done something wrong and globally disable port poweroff.
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Reading through a recent bug report [1], Alan notes:

  "Dan, the warning message in hub_suspend() should mention that the
   child device isn't suspended yet."

...update the warning from:

  "usb usb3-port4: not suspended yet"

...to:

   "usb usb3-port4: device 3-4: not suspended yet"

[1]: http://marc.info/?l=linux-usb&m=140290586301336&w=2Reported-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci_stop_device() allocates and issues stop commands for each active endpoint.
This is done with spinlock held and interrupt disabled so we can't sleep during
memory allocation. Use GFP_NOWAIT instead

Regression from commit ddba5cd0
"xhci: Use command structures when queuing commands on the command ring"
for 3.16-rc1

Fixes: ddba5cd0 ("xhci: Use command structures when queuing commands")
Reported-by: NDan Williams <dan.j.williams@intel.com>
Reported-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit d8521afe "usb: assign default peer ports for root hubs"
delayed marking a hub valid (set hdev->maxchild) until it had been fully
configured and to enable the publishing of valid hubs to be serialized
by usb_port_peer_mutex.

However, xhci_update_hub_device() in some cases depends on
hdev->maxchild already being set.  Do the minimal fix and move it after
the setting of hdev->maxchild.

Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
Reported-by: NValdis Kletnieks <Valdis.Kletnieks@vt.edu>
Tested-by: NValdis Kletnieks <Valdis.Kletnieks@vt.edu>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Acked-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A set of new VID/PIDs retrieved from the out-of-tree GobiNet/GobiSerial
Sierra Wireless drivers.
Signed-off-by: NAleksander Morgado <aleksander@aleksander.es>
Link: http://marc.info/?l=linux-usb&m=140136310027293&w=2
Cc: <stable@vger.kernel.org>	# backport in link above
Signed-off-by: NJohan Hovold <jhovold@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

module_spi_driver simplifies the code by eliminating
boilerplate code.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Acked-by: NDavid Mosberger <davidm@egauge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NDavidm Mosberger <davidm@egauge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

kmalloc the SPI rx and tx data buffers.  This appears to be the only
portable way to guarantee that the buffers are DMA-safe (e.g., in
separate DMA cache-lines).  This patch makes the spi_rdX()/spi_wrX()
non-reentrant, but that's OK because calls to them are guaranteed to
be serialized by the per-HCD SPI-thread.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NDavid Mosberger <davidm@egauge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDavid Mosberger <davidm@egauge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NAleksander Morgado <aleksander@aleksander.es>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Lists of endpoints are stored for bandwidth calculation for roothub ports.
Make sure we remove all endpoints from the list before the whole device,
containing its endpoints list_head stuctures, is freed.

This used to be done in the wrong order in xhci_mem_cleanup(),
and triggered an oops in resume from S4 (hibernate).

Cc: stable <stable@vger.kernel.org>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some platforms (such as the Renesas R-Car) need to initialize some specific
registers after xhci driver calls usb_add_hcd() and before the driver calls
xhci_run(). So, this patch adds the xhci_plat_start() function.
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NDavid Mosberger <davidm@egauge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Sony VAIO t-series machines are not capable of switching usb2 ports over
from Intel EHCI to xHCI controller. If tried the USB2 port will be left
unconnected and unusable.

This patch should be backported to stable kernels as old as 3.12,
that contain the commit 26b76798
"Intel xhci: refactor EHCI/xHCI port switching"

Cc: stable <stable@vger.kernel.org> # 3.12
Reported-by: NJorge <xxopxe@gmail.com>
Tested-by: NJorge <xxopxe@gmail.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit c4128cac.

This should come through Felipe's tree first, and there was a bunch of
other patches that are needed after this one as well that I didn't have.

Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Unconditionally wake up the child device when the power session is
recovered.

This addresses the following scenarios:

1/ The device may need a reset on power-session loss, without this
   change port power-on recovery exposes khubd to scenarios that
   usb_port_resume() is set to handle.  Prior to port power control the
   only time a power session would be lost is during dpm_suspend of the
   hub.  In that scenario usb_port_resume() is guaranteed to be called
   prior to khubd running for that port.  With this change we wakeup the
   child device as soon as possible (prior to khubd running again for this
   port).

   Although khubd has facilities to wake a child device it will only do
   so if the portstatus / portchange indicates a suspend state.  In the
   case of port power control we are not coming from a hub-port-suspend
   state.  This implementation simply uses pm_request_resume() to wake the
   device and relies on the port_dev->status_lock to prevent any collisions
   between khubd and usb_port_resume().

2/ This mechanism rate limits port power toggling.  The minimum port
   power on/off period is now gated by the child device suspend/resume
   latency.  Empirically this mitigates devices downgrading their connection
   on perceived instability of the host connection.  This ratelimiting is
   really only relevant to port power control testing, but it is a nice
   side effect of closing the above race.  Namely, the race of khubd for
   the given port running while a usb_port_resume() event is pending.

3/ Going forward we are finding that power-session recovery requires
   warm-resets (http://marc.info/?t=138659232900003&r=1&w=2).  This
   mechanism allows for warm-resets to be requested at the same point in
   the resume path for hub dpm_suspend power session losses, or port
   rpm_suspend power session losses.

4/ If the device *was* disconnected the only time we'll know for sure is
   after a failed resume, so it's necessary for usb_port_runtime_resume()
   to expedite a usb_port_resume() to clean up the removed device.  The
   reasoning for this is "least surprise" for the user. Turning on a port
   means that hotplug detection is again enabled for the port, it is
   surprising that devices that were removed while the port was off are not
   disconnected until they are attempted to be used.  As a user "why would
   I try to use a device I removed from the system?"

1, 2, and 4 are not a problem in the system dpm_resume() case because,
although the power-session is lost, khubd is frozen until after device
resume.  For the rpm_resume() case pm_request_resume() is used to
request re-validation of the device, and if it happens to collide with a
khubd run we rely on the port_dev->status_lock to synchronize those
operations.

Besides testing, the primary scenario where this mechanism is expected
to be triggered is when the user changes the port power policy
(control/pm_qos_no_poweroff, or power/control).   Each time power is
enabled want to revalidate the child device, where the revalidation is
handled by usb_port_resume().

Given that this arranges for port_dev->child to be de-referenced in
usb_port_runtime_resume() we need to make sure not to collide with
usb_disconnect() that frees the usb_device.  To this end we hold the
port active with the "child_usage" reference across the disconnect
event.  Subsequently, the need to access hub->child_usage_bits lead to
the creation of hub_disconnect_children() to remove any ambiguity of
which "hub" is being acted on in usb_disconnect() (prompted-by sharp
eyes from Alan).

Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Per Alan:
"You mean from within hub_handle_remote_wakeup()?  That routine will
never get called if CONFIG_PM_RUNTIME isn't enabled, because khubd
never sees wakeup requests if they arise during system suspend.

In fact, that routine ought to go inside the "#ifdef CONFIG_PM_RUNTIME"
portion of hub.c, along with the other suspend/resume code."
Suggested-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In general we do not want khubd to act on port status changes that are
the result of in progress resets or USB runtime PM operations.
Specifically port power control testing has been able to trigger an
unintended disconnect in hub_port_connect_change(), paraphrasing:

	if ((portstatus & USB_PORT_STAT_CONNECTION) && udev &&
	    udev->state != USB_STATE_NOTATTACHED) {
		if (portstatus & USB_PORT_STAT_ENABLE) {
			/* Nothing to do */
		} else if (udev->state == USB_STATE_SUSPENDED &&
				udev->persist_enabled) {
			...
		} else {
			/* Don't resuscitate */;
		}
	}

...by falling to the "Don't resuscitate" path or missing
USB_PORT_STAT_CONNECTION because usb_port_resume() was in the middle of
modifying the port status.

So, we want a new lock to hold off khubd for a given port while the
child device is being suspended, resumed, or reset.  The lock ordering
rules are now usb_lock_device() => usb_lock_port().  This is mandated by
the device core which may hold the device_lock on the usb_device before
invoking usb_port_{suspend|resume} which in turn take the status_lock on
the usb_port.  We attempt to hold the status_lock for the duration of a
port_event() run, and drop/re-acquire it when needing to take the
device_lock.  The lock is also dropped/re-acquired during
hub_port_reconnect().

This patch also deletes hub->busy_bits as all use cases are now covered
by port PM runtime synchronization or the port->status_lock and it
pushes down usb_device_lock() into usb_remote_wakeup().
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If a port is powered-off, or in the process of being powered-off, prevent
khubd from operating on it.  Otherwise, the following sequence of events
leading to an unintended disconnect may occur:

Events:
(0) <set pm_qos_no_poweroff to '0' for port1>
(1) hub 2-2:1.0: hub_resume
(2) hub 2-2:1.0: port 1: status 0301 change 0000
(3) hub 2-2:1.0: state 7 ports 4 chg 0002 evt 0000
(4) hub 2-2:1.0: port 1, power off status 0000, change 0000, 12 Mb/s
(5) usb 2-2.1: USB disconnect, device number 5

Description:
(1) hub is resumed before sending a ClearPortFeature request
(2) hub_activate() notices the port is connected and sets
    hub->change_bits for the port
(3) hub_events() starts, but at the same time the port suspends
(4) hub_connect_change() sees the disabled port and triggers disconnect
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In preparation for synchronizing port handling with pm_runtime
transitions refactor port handling into its own subroutine.

We expect that clearing some status flags will be required regardless of
the port state, so handle those first and group all non-trivial actions
at the bottom of the routine.

This also splits off the bottom half of hub_port_connect_change() into
hub_port_reconnect() in prepartion for introducing a port->status_lock.
hub_port_reconnect() will expect the port lock to not be held while
hub_port_connect_change() expects to enter with it held.

Other cleanups include:
1/ reflowing to 80 columns
2/ replacing redundant usages of 'hub->hdev' with 'hdev'
3/ consolidate clearing of ->change_bits() in hub_port_connect_change
4/ consolidate calls to usb_reset_device
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>