Fixed typos in comments of various drivers/usb files
Signed-off-by: NMickael Maison <mickael.maison@gmail.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Update configuration for USB_OTG_WHITELIST, any targeted hosts
(non PC-hosts) can have TPL (Targered Peripheral List).
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

According to On-The-Go and Embedded Host Supplement to the USB Revision
2.0 Specification, the targeted hosts (non-PC hosts) include both
embedded hosts and otg, and each targeted host product defines the
set of supported peripherals on a TPL (Targeted Peripheral List). So,
TPL should apply for both OTG and embedded host, and the otg support is
not a must for embedded host.

The TPL support feature will only be effect when CONFIG_USB_OTG_WHITELIST
has been chosen and hcd->tpl_support flag is set, it can avoid the enumeration
fails problem for the user who chooses CONFIG_USB_OTG_WHITELIST wrongly.
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Enable device-qualifier quirk for Elan Touchscreen, which often fails to
handle requests for the device_descriptor.

Note that the device sometimes do respond properly with a Request Error
(three times as USB core retries), but usually fails to respond at all.
When this happens any further descriptor requests also fails, for
example:

[ 1528.688934] usb 2-7: new full-speed USB device number 4 using xhci_hcd
[ 1530.945588] usb 2-7: unable to read config index 0 descriptor/start: -71
[ 1530.945592] usb 2-7: can't read configurations, error -71

This has been observed repeating for over a minute before eventual
successful enumeration.
Reported-by: NDrew Von Spreecken <drewvs@gmail.com>
Reported-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add new quirk for devices that cannot handle requests for the
device_qualifier descriptor.

A USB-2.0 compliant device must respond to requests for the
device_qualifier descriptor (even if it's with a request error), but at
least one device is known to misbehave after such a request.
Suggested-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

During surprise device hotplug removal tests, it was observed that
hub_events may try to call usb_lock_device on a device that has already
been freed. Protect the usb_device by taking out a reference (under the
hub_event_lock) when hub_events pulls it off the list, returning the
reference after hub_events is finished using it.
Signed-off-by: NJoe Lawrence <joe.lawrence@stratus.com>
Suggested-by: David Bulkow <david.bulkow@stratus.com> for using kref
Suggested-by: Alan Stern <stern@rowland.harvard.edu> for placement
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bdd405d2 ("usb: hub: Prevent hub autosuspend if
usbcore.autosuspend is -1") causes a build error if CONFIG_PM_RUNTIME is
disabled.  Fix that by doing a simple #ifdef guard around it.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Cc: Roger Quadros <rogerq@ti.com>
Cc: Michael Welling <mwelling@emacinc.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If user specifies that USB autosuspend must be disabled by module
parameter "usbcore.autosuspend=-1" then we must prevent
autosuspend of USB hub devices as well.

commit 596d789a introduced in v3.8 changed the original behaivour
and stopped respecting the usbcore.autosuspend parameter for hubs.

Fixes: 596d789a "USB: set hub's default autosuspend delay as 0"

Cc: [3.8+] <stable@vger.kernel.org>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Tested-by: NMichael Welling <mwelling@emacinc.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

linux-2.6/drivers/usb/core/hub.c: In function 'usb_disconnect':
linux-2.6/drivers/usb/core/hub.c:2110: warning: 'hub' may be used uninitialized in this function
linux-2.6/drivers/usb/core/hub.c:2111: warning: 'port1' may be used uninitialized in this function
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit [5ee0f803: usbcore: don't log on consecutive debounce
failures of the same port] added the check of the reliable port, but
it also replaced the device argument to dev_err() wrongly, which leads
to a NULL dereference.

This patch restores the right device, port_dev->dev.  Also, since
dev_err() itself shows the port number, reduce the port number shown
in the error message, essentially reverting to the state before the
commit 5ee0f803.

[The fix suggested by Hannes, and the error message cleanup suggested
 by Alan Stern]

Fixes: 5ee0f803 ('usbcore: don't log on consecutive debounce failures of the same port')
Reported-by: NHannes Reinecke <hare@suse.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

usbfs allows user space to pass down an URB which sets URB_SHORT_NOT_OK
for output URBs. That causes usbcore to log messages without limit
for a nonsensical disallowed combination. The fix is to silently drop
the attribute in usbfs.
The problem is reported to exist since 3.14
https://www.virtualbox.org/ticket/13085Signed-off-by: NOliver Neukum <oneukum@suse.de>
CC: stable@vger.kernel.org
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch adds a usb quirk to support devices with interupt endpoints
and bInterval values expressed as microframes. The quirk causes the
parse endpoint function to modify the reported bInterval to a standards
conforming value.

There is currently code in the endpoint parser that checks for
bIntervals that are outside of the valid range (1-16 for USB 2+ high
speed and super speed interupt endpoints). In this case, the code assumes
the bInterval is being reported in 1ms frames. As well, the correction
is only applied if the original bInterval value is out of the 1-16 range.

With this quirk applied to the device, the bInterval will be
accurately adjusted from microframes to an exponent.
Signed-off-by: NJames P Michels III <james.p.michels@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Section 4.4.7.2 "Interrupt Transfer Bandwidth Requirements" of the USB3.0 spec
says:
	A zero-length data payload is a valid transfer and may be useful for
	some implementations.

So, extend the logic of allowing URB_ZERO_PACKET to interrupt urbs too.
Otherwise, the kernel throws warning of BOGUS transfer flags.
Signed-off-by: NAmit Virdi <amit.virdi@st.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The assigned IRQ should be freed before calling pci_disable_device()
when shutting down system, otherwise it will cause following warning.
[  568.879482] ------------[ cut here ]------------
[  568.884236] WARNING: CPU: 1 PID: 3300 at /home/konrad/ssd/konrad/xtt-i386/bootstrap/linux-usb/fs/proc/generic.c:521 remove_proc_entry+0x165/0x170()
[  568.897846] remove_proc_entry: removing non-empty directory 'irq/16', leaking at least 'ohci_hcd:usb4'
[  568.907430] Modules linked in: dm_multipath dm_mod iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c_generic sg sd_mod crct10dif_generic crc_t10dif crct10dif_common radeon fbcon tileblit ttm font bitblit softcursor ata_generic ahci libahci drm_kms_helper skge r8169 libata mii scsi_mod wmi acpi_cpufreq
[  568.938539] CPU: 1 PID: 3300 Comm: init Tainted: G        W     3.16.0-rc5upstream-01651-g03b9189 #1
[  568.947946] Hardware name: ECS A780GM-A Ultra/A780GM-A Ultra, BIOS 080015  04/01/2010
[  568.956008]  00000209 ed0f1cd0 c1617946 c175403c ed0f1d00 c1090c3f c1754084 ed0f1d2c
[  568.964068]  00000ce4 c175403c 00000209 c11f22a5 c11f22a5 f755e8c0 ed0f1d78 f755e90d
[  568.972128]  ed0f1d18 c1090cde 00000009 ed0f1d10 c1754084 ed0f1d2c ed0f1d60 c11f22a5
[  568.980194] Call Trace:
[  568.982715]  [<c1617946>] dump_stack+0x48/0x60
[  568.987294]  [<c1090c3f>] warn_slowpath_common+0x7f/0xa0
[  569.003887]  [<c1090cde>] warn_slowpath_fmt+0x2e/0x30
[  569.009092]  [<c11f22a5>] remove_proc_entry+0x165/0x170
[  569.014476]  [<c10da6ca>] unregister_irq_proc+0xaa/0xc0
[  569.019858]  [<c10d582f>] free_desc+0x1f/0x60
[  569.024346]  [<c10d58aa>] irq_free_descs+0x3a/0x80
[  569.029283]  [<c10d9e9d>] irq_dispose_mapping+0x2d/0x50
[  569.034666]  [<c1078fd3>] mp_unmap_irq+0x73/0xa0
[  569.039423]  [<c107196b>] acpi_unregister_gsi_ioapic+0x2b/0x40
[  569.045431]  [<c107180f>] acpi_unregister_gsi+0xf/0x20
[  569.050725]  [<c1339cad>] acpi_pci_irq_disable+0x4b/0x50
[  569.056196]  [<c14daa38>] pcibios_disable_device+0x18/0x20
[  569.061848]  [<c130123d>] do_pci_disable_device+0x4d/0x60
[  569.067410]  [<c13012b7>] pci_disable_device+0x47/0xb0
[  569.077814]  [<c14800b1>] usb_hcd_pci_shutdown+0x31/0x40
[  569.083285]  [<c1304b19>] pci_device_shutdown+0x19/0x50
[  569.088667]  [<c13fda64>] device_shutdown+0x14/0x120
[  569.093777]  [<c10ac29d>] kernel_restart_prepare+0x2d/0x30
[  569.099429]  [<c10ac41e>] kernel_restart+0xe/0x60
[  569.109028]  [<c10ac611>] SYSC_reboot+0x191/0x220
[  569.159269]  [<c10ac6ba>] SyS_reboot+0x1a/0x20
[  569.163843]  [<c161c718>] sysenter_do_call+0x12/0x16
[  569.168951] ---[ end trace ccc1ec4471c289c9 ]---
Tested-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Problem Summary: Problem has been observed generally with PM states
where VBUS goes off during suspend. There are some SS USB devices which
take longer time for link training compared to many others.  Such
devices fail to reconnect with same old address which was associated
with it before suspend.

When system resumes, at some point of time (dpm_run_callback->
usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device->
usb_port_resume) SW reads hub status. If device is present,
then it finishes port resume and re-enumerates device with same
address. If device is not present then, SW thinks that device was
removed during suspend and therefore does logical disconnection
and removes all the resource allocated for this device.

Now, if I put sufficient delay just before root hub status read in
usb_resume_device then, SW sees always that device is present. In normal
course(without any delay) SW sees that no device is present and then SW
removes all resource associated with the device at this port.  In the
latter case, after sometime, device says that hey I am here, now host
enumerates it, but with new address.

Problem had been reproduced when I connect verbatim USB3.0 hard disc
with my STiH407 XHCI host running with 3.10 kernel.

I see that similar problem has been reported here.
https://bugzilla.kernel.org/show_bug.cgi?id=53211
Reading above it seems that bug was not in 3.6.6 and was present in 3.8
and again it was not present for some in 3.12.6, while it was present
for few others. I tested with 3.13-FC19 running at i686 desktop, problem
was still there. However, I was failed to reproduce it with 3.16-RC4
running at same i686 machine. I would say it is just a random
observation. Problem for few devices is always there, as I am unable to
find a proper fix for the issue.

So, now question is what should be the amount of delay so that host is
always able to recognize suspended device after resume.

XHCI specs 4.19.4 says that when Link training is successful, port sets
CSC bit to 1. So if SW reads port status before successful link
training, then it will not find device to be present.  USB Analyzer log
with such buggy devices show that in some cases device switch on the
RX termination after long delay of host enabling the VBUS. In few other
cases it has been seen that device fails to negotiate link training in
first attempt. It has been reported till now that few devices take as
long as 2000 ms to train the link after host enabling its VBUS and
RX termination. This patch implements a 2000 ms timeout for CSC bit to set
ie for link training. If in a case link trains before timeout, loop will
exit earlier.

This patch implements above delay, but only for SS device and when
persist is enabled.

So, for the good device overhead is almost none. While for the bad
devices penalty could be the time which it take for link training.
But, If a device was connected before suspend, and was removed
while system was asleep, then the penalty would be the timeout ie
2000 ms.

Results:

Verbatim USB SS hard disk connected with STiH407 USB host running 3.10
Kernel resumes in 461 msecs without this patch, but hard disk is
assigned a new device address. Same system resumes in 790 msecs with
this patch, but with old device address.

Cc: <stable@vger.kernel.org>
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

I am removing two fix mes in this file as after dicussing then it  seems
there is no reason to check against Null for usb_device as it can never
be NULL and this is check is therefore not needed.
Signed-off-by: NNicholas Krause <xerofoify@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some laptops have an internal port for a BT device which picks
up noise when the kill switch is used, but not enough to trigger
printk_rlimit(). So we shouldn't log consecutive faults of this kind.
Signed-off-by: NOliver Neukum <oneukum@suse.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When using USB 3.0 pen drive with the [AMD] FCH USB XHCI Controller
[1022:7814], the second hotplugging will experience the USB 3.0 pen
drive is recognized as high-speed device. After bisecting the kernel,
I found the commit number 41e7e056
(USB: Allow USB 3.0 ports to be disabled.) causes the bug. After doing
some experiments, the bug can be fixed by avoiding executing the function
hub_usb3_port_disable(). Because the port status with [AMD] FCH USB
XHCI Controlleris [1022:7814] is already in RxDetect
(I tried printing out the port status before setting to Disabled state),
it's reasonable to check the port status before really executing
hub_usb3_port_disable().

Fixes: 41e7e056 (USB: Allow USB 3.0 ports to be disabled.)
Signed-off-by: NGavin Guo <gavin.guo@canonical.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

usb_alloc_dev is used by lvstest driver now which can be built as
module. Therefore export usb_alloc_dev symbol.
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When a host controller dies, we don't need to wait for a driver to
time out.  We can shut down its URBs immediately.  Without this
change, we can end up waiting 30 seconds for a mass-storage transfer
to time out.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The usb device will autoresume from choose_wakeup() if it is
autosuspended with the wrong wakeup setting, but below errors occur
because usb3503 misc driver will switch to standby mode when suspended.

As add USB_QUIRK_RESET_RESUME, it can stop setting wrong wakeup from
autosuspend_check().

[    7.734717] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
[    7.854658] usb 1-3: device descriptor read/64, error -71
[    8.079657] usb 1-3: device descriptor read/64, error -71
[    8.294664] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
[    8.414658] usb 1-3: device descriptor read/64, error -71
[    8.639657] usb 1-3: device descriptor read/64, error -71
[    8.854667] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
[    9.264598] usb 1-3: device not accepting address 3, error -71
[    9.374655] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
[    9.784601] usb 1-3: device not accepting address 3, error -71
[    9.784838] usb usb1-port3: device 1-3 not suspended yet
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Resuming a powered down port sometimes results in the port state being
stuck in the training sequence.

 hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0
 port1: can't get reconnection after setting port  power on, status -110
 hub 3-0:1.0: port 1 status 0000.02e0 after resume, -19
 usb 3-1: can't resume, status -19
 hub 3-0:1.0: logical disconnect on port 1

In the case above we wait for the port re-connect timeout of 2 seconds
and observe that the port status is USB_SS_PORT_LS_POLLING (although it
is likely toggling between this state and USB_SS_PORT_LS_RX_DETECT).
This is indicative of a case where the device is failing to progress the
link training state machine.

It is resolved by issuing a warm reset to get the hub and device link
state machines back in sync.

 hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0
 usb usb3: port1 usb_port_runtime_resume requires warm reset
 hub 3-0:1.0: port 1 not warm reset yet, waiting 50ms
 usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd

After a reconnect timeout when we expect the device to be present, force
a warm reset of the device.  Note that we can not simply look at the
link status to determine if a warm reset is required as any of the
training states USB_SS_PORT_LS_POLLING, USB_SS_PORT_LS_RX_DETECT, or
USB_SS_PORT_LS_COMP_MOD are valid states that do not indicate the need
for warm reset by themselves.

Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Vincent Palatin <vpalatin@chromium.org>
Cc: Lan Tianyu <tianyu.lan@intel.com>
Cc: Ksenia Ragiadakou <burzalodowa@gmail.com>
Cc: Vivek Gautam <gautam.vivek@samsung.com>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Sunil Joshi <joshi@samsung.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Acked-by: NJulius Werner <jwerner@chromium.org>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When a USB device is disconnected, usb_unbind_interface is called, which
tries to enable and disable LPM. usb_enable_lpm also try to send a
control command SET SEL to the device.
Since device is already disconnected, therefore it does not make sense
to execute usb_(en/dis)able_lpm.
This patch returns from usb_(en/dis)able_lpm, if device was not in
default state atleast.
Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
Tested-by: NAymen Bouattay <aymen.bouattay@st.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
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>

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>

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>

The port pm_runtime implementation unconditionally clears FEAT_C_ENABLE
after clearing PORT_POWER, but the bit is reserved on usb3 hub ports.
We expect khubd to be prevented from running because the port state is
not RPM_ACTIVE, so we need to clear any errors for usb2 ports.
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>

Three reasons:
1/ It's an invalid operation on usb3 ports
2/ There's no guarantee of when / if a usb2 port has entered an error
   state relative to PORT_POWER request
3/ The port is active / powered at this point, so khubd will clear it as
   a matter of course
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>

ClearPortFeature(PORT_POWER) on a usb3 port places the port in either a
DSPORT.Powered-off-detect / DSPORT.Powered-off-reset loop, or the
DSPORT.Powered-off state.  There is no way to ensure that RX
terminations will persist in this state, so it is possible a device will
degrade to its usb2 connection.  Prevent this by blocking power-off of a
usb3 port while its usb2 peer is active, and powering on a usb3 port
before its usb2 peer.

By default the latency between peer power-on events is 0.  In order for
the device to not see usb2 active while usb3 is still powering up inject
the hub recommended power_on_good delay.  In support of satisfying the
power_on_good delay outside of hub_power_on() refactor the places where
the delay is consumed to call a new hub_power_on_good_delay() helper.

Finally, because this introduces several new checks for whether a port
is_superspeed, cache that disctinction at port creation so that we don't
need to keep looking up the parent hub device.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
[alan]: add a 'superspeed' flag to the port
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We want to manipulate ->did_runtime_put in usb_port_runtime_resume(),
but we don't want that to collide with other updates.  Move usb_port
flags to new port-bitmap fields in usb_hub. "did_runtime_put" is renamed
"child_usage_bits" to reflect that it is strictly standing in for the
fact that usb_devices are not the device_model children of their parent
port.
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The usb topology after this change will have symlinks between usb3 ports
and their usb2 peers, for example:

usb2/2-1/2-1:1.0/2-1-port1/peer => ../../../../usb3/3-1/3-1:1.0/3-1-port1
usb2/2-1/2-1:1.0/2-1-port2/peer => ../../../../usb3/3-1/3-1:1.0/3-1-port2
usb2/2-1/2-1:1.0/2-1-port3/peer => ../../../../usb3/3-1/3-1:1.0/3-1-port3
usb2/2-1/2-1:1.0/2-1-port4/peer => ../../../../usb3/3-1/3-1:1.0/3-1-port4
usb2/2-0:1.0/usb2-port1/peer    => ../../../usb3/3-0:1.0/usb3-port1
usb2/2-0:1.0/usb2-port2/peer    => ../../../usb3/3-0:1.0/usb3-port2
usb2/2-0:1.0/usb2-port3/peer    => ../../../usb3/3-0:1.0/usb3-port3
usb2/2-0:1.0/usb2-port4/peer    => ../../../usb3/3-0:1.0/usb3-port4

usb3/3-1/3-1:1.0/usb3-1-port1/peer => ../../../../usb2/2-1/2-1:1.0/2-1-port1
usb3/3-1/3-1:1.0/usb3-1-port2/peer => ../../../../usb2/2-1/2-1:1.0/2-1-port2
usb3/3-1/3-1:1.0/usb3-1-port3/peer => ../../../../usb2/2-1/2-1:1.0/2-1-port3
usb3/3-1/3-1:1.0/usb3-1-port4/peer => ../../../../usb2/2-1/2-1:1.0/2-1-port4
usb3/3-0:1.0/usb3-port1/peer       => ../../../usb2/2-0:1.0/usb2-port1
usb3/3-0:1.0/usb3-port2/peer       => ../../../usb2/2-0:1.0/usb2-port2
usb3/3-0:1.0/usb3-port3/peer       => ../../../usb2/2-0:1.0/usb2-port3
usb3/3-0:1.0/usb3-port4/peer       => ../../../usb2/2-0:1.0/usb2-port4

Introduce link_peers_report() to notify on all link_peers() failure
cases.
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>

ACPI identifies peer ports by setting their 'group_token' and
'group_position' _PLD data to the same value.  If a platform has tier
mismatch [1] , ACPI can override the default (USB3 defined) peer port
association for internal hubs.  External hubs follow the default peer
association scheme.

Location data is cached as an opaque cookie in usb_port_location data.

Note that we only consider the group_token and group_position attributes
from the _PLD data as ACPI specifies that group_token is a unique
identifier.

When we find port location data for a port then we assume that the
firmware will also describe its peer port.  This allows the
implementation to only ever set the peer once.  This leads to a question
about what happens when a pm runtime event occurs while the peer
associations are still resolving.  Since we only ever set the peer
information once, a USB3 port needs to be prevented from suspending
while its ->peer pointer is NULL (implemented in a subsequent patch).

There is always the possibility that firmware mis-identifies the ports,
but there is not much the kernel can do in that case.

[1]: xhci 1.1 appendix D figure 131
[2]: acpi 5 section 6.1.8

[alan]: don't do default peering when acpi data present
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>

Given that root hub port peers are already established, external hub peer
ports can be determined by traversing the device topology:

1/ ascend to the parent hub and find the upstream port_dev

2/ walk ->peer to find the peer port

3/ descend to the peer hub via ->child

4/ find the port with the matching port id

Note that this assumes the port labeling scheme required by the
specification [1].

[1]: usb3 3.1 section 10.3.3
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>