This reverts commit d8f00cd6.

Tony writes:

This upstream commit is causing an oops:
d8f00cd6 ("usb: hub: do not clear BOS field during reset device")

This patch has already been included in several -stable kernels.  Here
are the affected kernels:
4.5.0-rc4 (current git)
4.4.2
4.3.6 (currently in review)
4.1.18
3.18.27
3.14.61

How to reproduce the problem:
Boot kernel with slub debugging enabled (otherwise memory corruption
will cause random oopses later instead of immediately)
Plug in USB 3.0 disk to xhci USB 3.0 port
dd if=/dev/sdc of=/dev/null bs=65536
(where /dev/sdc is the USB 3.0 disk)
Unplug USB cable while dd is still going
Oops is immediate:
Reported-by: NTony Battersby <tonyb@cybernetics.com>
Cc: Du, Changbin <changbin.du@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In function usb_reset_and_verify_device, the old BOS descriptor may
still be used before allocating a new one. (usb_unlocked_disable_lpm
function uses it under the situation that it fails to disable lpm.)
So we cannot set the udev->bos to NULL before that, just keep what it
was. It will be overwrite when allocating a new one.

Crash log:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000010
IP: [<ffffffff8171f98d>] usb_enable_link_state+0x2d/0x2f0
Call Trace:
[<ffffffff8171ed5b>] ? usb_set_lpm_timeout+0x12b/0x140
[<ffffffff8171fcd1>] usb_enable_lpm+0x81/0xa0
[<ffffffff8171fdd8>] usb_disable_lpm+0xa8/0xc0
[<ffffffff8171fe1c>] usb_unlocked_disable_lpm+0x2c/0x50
[<ffffffff81723933>] usb_reset_and_verify_device+0xc3/0x710
[<ffffffff8172c4ed>] ? usb_sg_wait+0x13d/0x190
[<ffffffff81724743>] usb_reset_device+0x133/0x280
[<ffffffff8179ccd1>] usb_stor_port_reset+0x61/0x70
[<ffffffff8179cd68>] usb_stor_invoke_transport+0x88/0x520
Signed-off-by: NDu, Changbin <changbin.du@intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 8520f380 ("USB: change hub initialization sleeps to
delayed_work") changed the hub_activate() routine to make part of it
run in a workqueue.  However, the commit failed to take a reference to
the usb_hub structure or to lock the hub interface while doing so.  As
a result, if a hub is plugged in and quickly unplugged before the work
routine can run, the routine will try to access memory that has been
deallocated.  Or, if the hub is unplugged while the routine is
running, the memory may be deallocated while it is in active use.

This patch fixes the problem by taking a reference to the usb_hub at
the start of hub_activate() and releasing it at the end (when the work
is finished), and by locking the hub interface while the work routine
is running.  It also adds a check at the start of the routine to see
if the hub has already been disconnected, in which nothing should be
done.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NAlexandru Cornea <alexandru.cornea@intel.com>
Tested-by: NAlexandru Cornea <alexandru.cornea@intel.com>
Fixes: 8520f380 ("USB: change hub initialization sleeps to delayed_work")
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some USB device / host controller combinations seem to have problems
with Link Power Management.  For example, Steinar found that his xHCI
controller wouldn't handle bandwidth calculations correctly for two
video cards simultaneously when LPM was enabled, even though the bus
had plenty of bandwidth available.

This patch introduces a new quirk flag for devices that should remain
disabled for LPM, and creates quirk entries for Steinar's devices.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NSteinar H. Gunderson <sgunderson@bigfoot.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently usb_port_resume waits for up to 2 seconds for CONNECT
status for SS devices only. This change will do the same thing for
non-SS devices even though the reason is a little different. This
will fix an issue where VBUS is turned off during system wide
"suspend to ram" and some 2.0 devices take greater than the current
max of 100ms to show connected after VBUS is enabled. This is most
commonly seen on hard drive based devices and USB3.0 devices plugged
into a 2.0 only port.
Signed-off-by: NAl Cooper <alcooperx@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

USB3 LPM is default on in Linux kernel if both xHCI host controller
and the USB devices declare to be LPM-capable. Unfortunately, some
devices are known to work well with LPM disabled, but to be broken
if LPM is enabled, although it declares the LPM capability.  Users
won't be able to use this kind of devices, until someone puts them
in the kernel blacklist and gets the kernel upgraded.

This patch adds a sysfs node to permit or forbit USB3 LPM U1 or U2
entry for a port. The settings apply to both before and after device
enumeration. Supported values are "0" - neither u1 nor u2 permitted,
"u1" - only u1 is permitted, "u2" - only u2 is permitted, "u1_u2" -
both u1 and u2 are permitted. With this interface, users can use an
LPM-unfriendly USB device on a released Linux kernel.
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: NZhuang Jin Can <jin.can.zhuang@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 655fe4ef ("usbcore: add sysfs support to xHCI usb3
hardware LPM") introduced usb3_hardware_lpm sysfs node. This
doesn't show the correct status of USB3 U1 and U2 LPM status.

This patch fixes this by replacing usb3_hardware_lpm with two
nodes, usb3_hardware_lpm_u1 (for U1) and usb3_hardware_lpm_u2
(for U2), and recording the U1/U2 LPM status in right places.

This patch should be back-ported to kernels as old as 4.3,
that contains Commit 655fe4ef ("usbcore: add sysfs support
to xHCI usb3 hardware LPM").

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

When a USB 3.0 mass storage device is disconnected in transporting
state, storage device driver may handle it as a transport error and
reset the device by invoking usb_reset_and_verify_device()
and following could happen:

in usb_reset_and_verify_device():
   udev->bos = NULL;

For U1/U2 enabled devices, driver will disable LPM, and in some
conditions:
   from usb_unlocked_disable_lpm()
    --> usb_disable_lpm()
    --> usb_enable_lpm()
        udev->bos->ss_cap->bU1devExitLat;

And it causes 'NULL pointer' and 'kernel panic':

[  157.976257] Unable to handle kernel NULL pointer dereference
at virtual address 00000010
...
[  158.026400] PC is at usb_enable_link_state+0x34/0x2e0
[  158.031442] LR is at usb_enable_lpm+0x98/0xac
...
[  158.137368] [<ffffffc0006a1cac>] usb_enable_link_state+0x34/0x2e0
[  158.143451] [<ffffffc0006a1fec>] usb_enable_lpm+0x94/0xac
[  158.148840] [<ffffffc0006a20e8>] usb_disable_lpm+0xa8/0xb4
...
[  158.214954] Kernel panic - not syncing: Fatal exception

This commit moves 'udev->bos = NULL' behind usb_unlocked_disable_lpm()
to prevent from NULL pointer access.

Issue can be reproduced by following setup:
1) A SS pen drive behind a SS hub connected to the host.
2) Transporting data between the pen drive and the host.
3) Abruptly disconnect hub and pen drive from host.
4) With a chance it crashes.
Signed-off-by: NHans Yang <hansy@nvidia.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since a_alt_hnp_support is obsolete in OTG 2.0, HNP capable host should
send this set feature request only if the otg device is connecting to a
non-HNP port and it's compliant with OTG 1.x revision. This is done by
checking its otg descriptor length, OTG 2.0 uses usb_otg20_descriptor
which has different length than OTG 1.x using usb_otg_descriptor.
Signed-off-by: NLi Jun <jun.li@freescale.com>
Acked-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix two occurrences of the Sparse warning:

warning: symbol XXX shadows an earlier one
Signed-off-by: NKris Borer <kborer@gmail.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Removed some checkpatch.pl warnings saying there was an unwanted space
between function names and their arguments.
Signed-off-by: NChase Metzger <chasemetzger15@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Removed some checkpatch.pl warnings saying there was an unwanted space between
function names and their arguments.
Signed-off-by: NChase Metzger <chasemetzger15@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix one occurrence of the checkpatch.pl error:

ERROR: do not use assignment in if condition

The semantic patch that makes this change is:

// <smpl>
@@
identifier i;
expression E, E2, E3;
statement S1, S2;
binary operator b;
@@

+ i = E;
  if (
- (i = E)
+ i
  b
  ... && E2 && E3 ) S1 else S2
// </smpl>
Signed-off-by: NKris Borer <kborer@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Removed some checkpatch.pl warnings saying there was an unwanted space between
function names and their arguments.
Signed-off-by: NChase Metzger <chasemetzger15@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add a sysfs node to make it easier to verify if LPM is supported and being
enabled for USB 3.0 devices.
Signed-off-by: NKevin Strasser <kevin.strasser@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 25cd2882 ("usb/xhci: Change how we indicate a host supports
Link PM.") removed the code to set lpm_capable for USB 3.0 super-speed
root hub. The intention of that change was to avoid touching usb core
internal field, a.k.a. lpm_capable, and let usb core to set it by
checking U1 and U2 exit latency values in the descriptor.

Usb core checks and sets lpm_capable in hub_port_init(). Unfortunately,
root hub is a special usb device as it has no parent. Hub_port_init()
will never be called for a root hub device. That means lpm_capable will
by no means be set for the root hub. As the result, lpm isn't functional
at all in Linux kernel.

This patch add the code to check and set lpm_capable when registering a
root hub device. It could be back-ported to kernels as old as v3.15,
that contains the Commit 25cd2882 ("usb/xhci: Change how we indicate
a host supports Link PM.").

Cc: stable@vger.kernel.org # 3.15
Reported-by: NKevin Strasser <kevin.strasser@linux.intel.com>
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset.

Dissolve the function hub_port_finish_reset() completely and divide the
actions to be taken into those which need to be done after each reset
attempt and those which need to be done after the full procedure is
complete, and place them in the appropriate places in hub_port_reset().
Also, remove an unneeded forward declaration of hub_port_reset().

Verbose Problem Description:

USB 3.0 devices may be "lost for good" during a hub port reset.
This makes Linux unable to boot from USB 3.0 devices in certain
constellations of host controllers and devices, because the USB device is
lost during initialization, preventing the rootfs from being mounted.

The underlying problem is that in the affected constellations, during the
processing inside hub_port_reset(), the hub link state goes from 0 to
SS.inactive after the initial reset, and back to 0 again only after the
following "warm" reset.

However, hub_port_finish_reset() is called after each reset attempt and
sets the state the connected USB device based on the "preliminary" status
of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when
the following warm reset is complete and hub_port_finish_reset() is
called again, its call to set the device to USB_STATE_DEFAULT is blocked
by usb_set_device_state() which does not allow taking USB devices out of
USB_STATE_NOTATTACHED state.

Thanks to Alan Stern for guiding me to the proper solution and how to
submit it.

Link: http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27Signed-off-by: NRobert Schlabbach <robert_s@gmx.net>
Cc: stable <stable@vger.kernel.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We should not be doing assignments within an if () block
so fix up the code to not do this.

change was created using Coccinelle.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
CC: Dan Williams <dan.j.williams@intel.com>
CC: Petr Mladek <pmladek@suse.cz>
CC: Peter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NFelipe Balbi <balbi@ti.com>

USB 2.01+ full-speed devices can have extended descriptor as well
and can support LPM.
Signed-off-by: NRupesh Tatiya <rtatiya@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The Microsoft document "Using ACPI to Configure USB Ports on a Computer"
makes it clear that the removable flag will be cleared on ports that are
marked as unused by the firmware. Handle this case to match.
Signed-off-by: NMatthew Garrett <mjg59@coreos.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Windows appears to pay more attention to the ACPI values than any hub
configuration, so prefer the firmware's opinion on whether a port is
fixed or removable before falling back to the hub values.
Signed-off-by: NMatthew Garrett <mjg59@coreos.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make sure we're using the new macro, so our
resume signaling will always pass certification.

Cc: <stable@vger.kernel.org> # v3.10+
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In commit ceb6c9c8 ("USB / PM: Drop CONFIG_PM_RUNTIME from the
USB core"), all occurrences of CONFIG_PM_RUNTIME in the USB core
code were replaced by CONFIG_PM. This created the following structure
of #ifdef blocks in drivers/usb/core/hub.c:

 [...]
 #ifdef CONFIG_PM
 #ifdef CONFIG_PM
 /* always on / undead */
 #else
 /* dead */
 #endif
 [...]

This patch removes unnecessary inner "#ifdef CONFIG_PM" as well as
the corresponding dead #else block. This inconsistency was found using
the undertaker-checkpatch tool.
Signed-off-by: NAndreas Ruprecht <rupran@einserver.de>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The EHCI controller on the RK3288 SoC is violating basic parts of the
USB spec and thereby unable to properly resume a suspended port. It does
not start SOF generation within 3ms of finishing resume signaling, so
the attached device will drop of the bus again. This is a particular
problem with runtime PM, where accessing the device will trigger a
resume that immediately makes it unavailable (and reenumerate with a new
handle).

Thankfully, the persist feature is generally able to work around stuff
like that. Unfortunately, it doesn't quite work in this particular case
because the controller will turn off the CurrentConnectStatus bit for an
instant while the device is reconnecting, which causes the kernel to
conclude that it permanently disappeared. This patch adds a tiny retry
mechanism to the core port resume code which will catch this case and
shouldn't have any notable impact on other controllers.
Signed-off-by: NJulius Werner <jwerner@chromium.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This revert a82b76f7.

The commit causes an extra reset in remote wakeup as described in:
http://www.spinics.net/lists/linux-usb/msg119080.htmlSigned-off-by: NZhuang Jin Can <jin.can.zhuang@intel.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently if port power is turned off by user on hub port
using USBDEVFS then port power is turned back ON
by hub driver.
This commit modifies hub reset logic in hub_port_connect() to prevent
hub driver from turning back the port power ON if port is not owned
by kernel.
Signed-off-by: NDeepak Das <deepakdas.linux@gmail.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The USB stack provides a mechanism for drivers to request an
asynchronous device reset (usb_queue_reset_device()).  The mechanism
uses a work item (reset_ws) embedded in the usb_interface structure
used by the driver, and the reset is carried out by a work queue
routine.

The asynchronous reset can race with driver unbinding.  When this
happens, we try to cancel the queued reset before unbinding the
driver, on the theory that the driver won't care about any resets once
it is unbound.

However, thanks to the fact that lockdep now tracks work queue
accesses, this can provoke a lockdep warning in situations where the
device reset causes another interface's driver to be unbound; see

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

for an example.  The reason is that the work routine for reset_ws in
one interface calls cancel_queued_work() for the reset_ws in another
interface.  Lockdep thinks this might lead to a work routine trying to
cancel itself.  The simplest solution is not to cancel queued resets
when unbinding drivers.

This means we now need to acquire a reference to the usb_interface
when queuing a reset_ws work item and to drop the reference when the
work routine finishes.  We also need to make sure that the
usb_interface structure doesn't outlive its parent usb_device; this
means acquiring and dropping a reference when the interface is created
and destroyed.

In addition, cancelling a queued reset can fail (if the device is in
the middle of an earlier reset), and this can cause usb_reset_device()
to try to rebind an interface that has been deallocated (see
http://marc.info/?l=linux-usb&m=142175717016628&w=2 for details).
Acquiring the extra references prevents this failure.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NRussell King - ARM Linux <linux@arm.linux.org.uk>
Reported-by: NOlivier Sobrie <olivier@sobrie.be>
Tested-by: NOlivier Sobrie <olivier@sobrie.be>
Cc: stable <stable@vger.kernel.org> # 3.19
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

After commit b2b49ccb (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so quite a few
depend on CONFIG_PM (or even dropped in some cases).

Replace CONFIG_PM_RUNTIME with CONFIG_PM in the USB core code
and documentation.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It is safe to call notify disconnect when the usb core
thinks the device is disconnected.

This commit also fixes one bug found at below situation:
we have not enabled usb wakeup, we do system suspend when
there is an usb device at the port, after suspend, we plug out
the usb device, then plug in device again. At that time,
the nofity disconnect was not called at current code, as
the controller doesn't know the usb device was disconnected
during the suspend, but USB core knows the port has changed
during that periods.

So to fix this problem, and let the usb core call notify disconnect.

Cc: 3.17+ <stable@vger.kernel.org>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since we notify disconnecting based on the usb device is existed
(port_dev->child, the child device at roothub is not NULL), we
need to notify connect after device has been registered.

This fixes a bug that do fast plug in/out test, and the notify_disconnect
is not called due to roothub child is NULL and the enumeration has failed.

Cc: v3.17+ <stable@vger.kernel.org>
Signed-off-by: NTony Zheng <Tony.Zheng@freescale.com>
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

the integer variable 'feature' was not being used anywhere in the function.
so it is safe to remove the variable.
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch modifies the usb_authorize_device() function such as that it does
not reload the device descriptor for wired devices. The reasons for this
are as follows:

* Some devices dislike the master requesting the descriptor from them twice,
  failing on the usb_get_device_descriptor() call with -ETIMEOUT. Observed this
  on my Pretec 16GB flash drive (4146:ba65).

* Malicious device could send two different descriptors - one before
  authorization, used by userspace to determine whether to authorize it and
  second to be actually used by the kernel when determining which drivers to
  bind.
Signed-off-by: NJosef Gajdusek <atx@atx.name>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The USB PHY member of the HCD structure is renamed to 'usb_phy' and
modifications are done in all drivers accessing it.
This is in preparation to adding the generic PHY support.
Signed-off-by: NAntoine Tenart <antoine.tenart@free-electrons.com>
[Sergei: added missing 'drivers/usb/misc/lvstest.c' file, resolved rejects,
updated changelog.]
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The current code only returns -ENOTSUPP for OTG host, but in fact,
embedded host also needs to returns -ENOTSUPP if the peripheral
is not at TPL.
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It seems that only choose_devnum() was not ready to process more hub
events at the same time.

All should be fine if we take bus->usb_address0_mutex there. It will
make sure that more devnums will not be chosen for the given bus and
the related devices at the same time.
Signed-off-by: NPetr Mladek <pmladek@suse.cz>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

USB hub has started to use a workqueue instead of kthread. Let's update
the documentation and comments here and there.

This patch mostly just replaces "khubd" with "hub_wq". There are only few
exceptions where the whole sentence was updated. These more complicated
changes can be found in the following files:

	   Documentation/usb/hotplug.txt
	   drivers/net/usb/usbnet.c
	   drivers/usb/core/hcd.c
	   drivers/usb/host/ohci-hcd.c
	   drivers/usb/host/xhci.c
Signed-off-by: NPetr Mladek <pmladek@suse.cz>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

USB hub started to use a workqueue instead of kthread. Let's make it clear from
the function names.
Signed-off-by: NPetr Mladek <pmladek@suse.cz>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There is no need to have separate kthread for handling USB hub events.
It is more elegant to use the workqueue framework.

The workqueue is allocated as freezable because the original thread was
freezable as well.

Also it is allocated as ordered because the code is not ready for parallel
processing of hub events, see choose_devnum().

struct usb_hub is passed via the work item. Therefore we do not need
hub_event_list.

Also hub_thread() is not longer needed. It would call only hub_event().
The rest of the code did manipulate the kthread and it is handled by the
workqueue framework now.

kick_khubd is renamed to kick_hub_wq() to make the function clear. And the
protection against races is done another way, see below.

hub_event_lock has been removed. It cannot longer be used to protect struct
usb_hub between hub_event() and hub_disconnect(). Instead we need to get
hub->kref already in kick_hub_wq().

The lock is not really needed for the other scenarios as well. queue_work()
returns whether it succeeded. We could revert the needed operations
accordingly. This is enough to avoid duplicity and inconsistencies.

Yes, the removed lock causes that there is not longer such a strong
synchronization between scheduling the work and manipulating
hub->disconnected.

But kick_hub_wq() must never be called together with hub_disconnect()
otherwise even the original code would have failed. Any callers are
responsible for this.

Therefore the only problem is that hub_disconnect() could be called in parallel
with hub_event(). But this was possible even in the past. struct usb_hub is
still guarded by hub->kref and released in hub_events() when needed.

Note that the source file is still full of the obsolete "khubd" strings.
Let's remove them in a follow up patch. This patch already is complex enough.

Thanks a lot Alan Stern <stern@rowland.harvard.edu> for code review, many useful
tips and guidance. Also thanks to Tejun Heo <tj@kernel.org> for hints how to
allocate the workqueue.
Signed-off-by: NPetr Mladek <pmladek@suse.cz>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We would like to convert khubd kthread to a workqueue. As a result hub_events()
will handle only one event per call.

In fact, we could do this already now because there is another cycle in
hub_thread(). It calls hub_events() until hub_event_list is empty.

This patch renames the function to hub_event(), removes the while cycle, and
renames the goto targets from loop* to out*.

When touching the code, it fixes also formatting of dev_err() and dev_dbg()
calls to make checkpatch.pl happy :-)
Signed-off-by: NPetr Mladek <pmladek@suse.cz>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This is just a small optimization of the fix from the commit c605f3cd
("usb: hub: take hub->hdev reference when processing from eventlist).

We do not need to take the reference for each event. Instead we could get it
when struct usb_hub is allocated and put it when it is released. By other words,
we could handle it the same way as the reference for hub->intfdev.

The motivation is that it will make the life easier when switching from khubd
kthread to a workqueue.
Suggested-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NPetr Mladek <pmladek@suse.cz>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>