usb: usb_autopm_get_interface use modern helper

PM core now gives us a primitive that does not touch
the counter in an error case. Use it.

Signed-off-by: Oliver Neukum <oneukum@suse.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20240118202300.1616-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: core: Use device_driver directly in struct usb_driver and usb_device_driver

There is usbdrv_wrap in struct usb_driver and usb_device_driver, it
contains device_driver and for_devices. for_devices is used to
distinguish between device drivers and interface drivers.

Like the is_usb_device(), it tests the type of the device. We can test
that if the probe of device_driver is equal to usb_probe_device in
is_usb_device_driver(), and then the struct usbdrv_wrap is no longer
needed.

Clean up struct usbdrv_wrap, use device_driver directly in struct
usb_driver and usb_device_driver. This makes the code cleaner.

Signed-off-by: Yajun Deng <yajun.deng@linux.dev>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20240104032822.1896596-1-yajun.deng@linux.dev
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: core: Don't force USB generic_subclass drivers to define probe()

There's no real reason that subclassed USB drivers _need_ to define
probe() since they might want to subclass for some other reason. Make
it optional to define probe() if we're a generic_subclass.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20231201102946.v2.1.I7ea0dd55ee2acdb48b0e6d28c1a704ab2c29206f@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: mark all struct bus_type as const

Now that the driver core can properly handle constant struct bus_type,
move all of the USB subsystem struct bus_type structures as const,
placing them into read-only memory which can not be modified at runtime.

Cc: Johan Hovold <johan@kernel.org>
Cc: Evan Green <evgreen@chromium.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb@vger.kernel.org
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20230313182918.1312597-36-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

driver core: make struct bus_type.uevent() take a const *

The uevent() callback in struct bus_type should not be modifying the
device that is passed into it, so mark it as a const * and propagate the
function signature changes out into all relevant subsystems that use
this callback.

Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20230111113018.459199-16-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb/core: fix repeated words in comments

Delete the redundant word 'the'.

Signed-off-by: Jilin Yuan <yuanjilin@cdjrlc.com>
Link: https://lore.kernel.org/r/20220716132403.35270-1-yuanjilin@cdjrlc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: core: Disable remote wakeup for freeze/quiesce

The PM_EVENT_FREEZE and PM_EVENT_QUIESCE messages should cause the
device to stop generating interrupts. USB core was previously allowing
devices that were already runtime suspended to keep remote wakeup
enabled if they had gone down that way. This violates the contract with
pm, and can potentially cause MSI interrupts to be lost.

Change that so that if a device is runtime suspended with remote wakeups
enabled, it will be resumed to ensure remote wakeup is always disabled
across a freeze.

Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Evan Green <evgreen@chromium.org>
Link: https://lore.kernel.org/r/20220421103751.v3.1.I2c636c4decc358f5e6c27b810748904cc69beada@changeid
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: core: Export usb_device_match_id

Export usb_device_match_id so that it can be used for easily matching an
usb_device with a table of IDs.

Signed-off-by: Razvan Heghedus <heghedus.razvan@gmail.com>
Link: https://lore.kernel.org/r/20211213183617.14156-1-heghedus.razvan@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: core: Fix file path that does not exist

Both driver.c and generic.c are not under drivers/usb/, should
be drivers/usb/core/ instead.

Signed-off-by: Wei Ming Chen <jj251510319013@gmail.com>
Link: https://lore.kernel.org/r/20211205023529.91165-1-jj251510319013@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: core: rename usb_driver_claim_interface() data parameter

It's been almost twenty years since the interface "private data" pointer
was removed in favour of using the driver-data pointer of struct device.

Let's rename the driver-data parameter of usb_driver_claim_interface()
so that it better reflects how it's used.

Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210318155406.22399-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: core: drop outdated interface-binding comment

It's been almost twenty years since USB drivers returned a data pointer
from their probe routines in order to bind to an interface.

Time to update the documentation for usb_driver_claim_interface().

Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20210318155406.22399-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usbcore: Check both id_table and match() when both available

From: Bastien Nocera <hadess@hadess.net>

When a USB device driver has both an id_table and a match() function, make
sure to check both to find a match, first matching the id_table, then
checking the match() function.

This makes it possible to have module autoloading done through the
id_table when devices are plugged in, before checking for further
device eligibility in the match() function.

Cc: <stable@vger.kernel.org> # 5.8
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Co-developed-by: M. Vefa Bicakci <m.v.b@runbox.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: M. Vefa Bicakci <m.v.b@runbox.com>
Tested-by: Pan (Pany) YUAN <pany@fedoraproject.org>
Link: https://lore.kernel.org/r/20201022135521.375211-2-m.v.b@runbox.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usbcore/driver: Accommodate usbip

Commit 88b7381a939d ("USB: Select better matching USB drivers when
available") inadvertently broke usbip functionality. The commit in
question allows USB device drivers to be explicitly matched with
USB devices via the use of driver-provided identifier tables and
match functions, which is useful for a specialised device driver
to be chosen for a device that can also be handled by another,
more generic, device driver.

Prior, the USB device section of usb_device_match() had an
unconditional "return 1" statement, which allowed user-space to bind
USB devices to the usbip_host device driver, if desired. However,
the aforementioned commit changed the default/fallback return
value to zero. This breaks device drivers such as usbip_host, so
this commit restores the legacy behaviour, but only if a device
driver does not have an id_table and a match() function.

In addition, if usb_device_match is called for a device driver
and device pair where the device does not match the id_table of the
device driver in question, then the device driver will be disqualified
for the device. This allows avoiding the default case of "return 1",
which prevents undesirable probe() calls to a driver even though
its id_table did not match the device.

Finally, this commit changes the specialised-driver-to-generic-driver
transition code so that when a device driver returns -ENODEV, a more
generic device driver is only considered if the current device driver
does not have an id_table and a match() function. This ensures that
"generic" drivers such as usbip_host will not be considered specialised
device drivers and will not cause the device to be locked in to the
generic device driver, when a more specialised device driver could be
tried.

All of these changes restore usbip functionality without regressions,
ensure that the specialised/generic device driver selection logic works
as expected with the usb and apple-mfi-fastcharge drivers, and do not
negatively affect the use of devices provided by dummy_hcd.

Fixes: 88b7381a939d ("USB: Select better matching USB drivers when available")
Cc: <stable@vger.kernel.org> # 5.8
Cc: Bastien Nocera <hadess@hadess.net>
Cc: Valentina Manea <valentina.manea.m@gmail.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: <syzkaller@googlegroups.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Acked-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: M. Vefa Bicakci <m.v.b@runbox.com>
Link: https://lore.kernel.org/r/20200922110703.720960-5-m.v.b@runbox.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usbcore/driver: Fix incorrect downcast

This commit resolves a minor bug in the selection/discovery of more
specific USB device drivers for devices that are currently bound to
generic USB device drivers.

The bug is related to the way a candidate USB device driver is
compared against the generic USB device driver. The code in
is_dev_usb_generic_driver() assumes that the device driver in question
is a USB device driver by calling to_usb_device_driver(dev->driver)
to downcast; however I have observed that this assumption is not always
true, through code instrumentation.

This commit avoids the incorrect downcast altogether by comparing
the USB device's driver (i.e., dev->driver) to the generic USB
device driver directly. This method was suggested by Alan Stern.

This bug was found while investigating Andrey Konovalov's report
indicating usbip device driver misbehaviour with the recently merged
generic USB device driver selection feature. The report is linked
below.

Fixes: d5643d2249b2 ("USB: Fix device driver race")
Cc: <stable@vger.kernel.org> # 5.8
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Bastien Nocera <hadess@hadess.net>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Valentina Manea <valentina.manea.m@gmail.com>
Cc: <syzkaller@googlegroups.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: M. Vefa Bicakci <m.v.b@runbox.com>
Link: https://lore.kernel.org/r/20200922110703.720960-4-m.v.b@runbox.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usbcore/driver: Fix specific driver selection

This commit resolves a bug in the selection/discovery of more
specific USB device drivers for devices that are currently bound to
generic USB device drivers.

The bug is in the logic that determines whether a device currently
bound to a generic USB device driver should be re-probed by a
more specific USB device driver or not. The code in
__usb_bus_reprobe_drivers() used to have the following lines:

if (usb_device_match_id(udev, new_udriver->id_table) == NULL &&
(!new_udriver->match || new_udriver->match(udev) != 0))
return 0;

ret = device_reprobe(dev);

As the reader will notice, the code checks whether the USB device in
consideration matches the identifier table (id_table) of a specific
USB device_driver (new_udriver), followed by a similar check, but this
time with the USB device driver's match function. However, the match
function's return value is not checked correctly. When match() returns
zero, it means that the specific USB device driver is *not* applicable
to the USB device in question, but the code then goes on to reprobe the
device with the new USB device driver under consideration. All this to
say, the logic is inverted.

This bug was found by code inspection and instrumentation while
investigating the root cause of the issue reported by Andrey Konovalov,
where usbip took over syzkaller's virtual USB devices in an undesired
manner. The report is linked below.

Fixes: d5643d2249b2 ("USB: Fix device driver race")
Cc: <stable@vger.kernel.org> # 5.8
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Bastien Nocera <hadess@hadess.net>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Valentina Manea <valentina.manea.m@gmail.com>
Cc: <syzkaller@googlegroups.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: M. Vefa Bicakci <m.v.b@runbox.com>
Link: https://lore.kernel.org/r/20200922110703.720960-3-m.v.b@runbox.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: core: driver: fix stray tabs in error messages

Commit 8bb54ab573ec ("usbcore: add usb_device_driver definition") added
the printk() calls with the error massages spoilt due to the stray tabs
in the middle. Remove these tabs and convert printk() calls to pr_err()
for consistency with the other code, while at it.

Fixes: 8bb54ab573ec ("usbcore: add usb_device_driver definition")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/4beb55c4-eb34-7744-155f-033b8f527e23@omprussia.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: Fix device driver race

When a new device with a specialised device driver is plugged in, the
new driver will be modprobe()'d but the driver core will attach the
"generic" driver to the device.

After that, nothing will trigger a reprobe when the modprobe()'d device
driver has finished initialising, as the device has the "generic"
driver attached to it.

Trigger a reprobe ourselves when new specialised drivers get registered.

Fixes: 88b7381a939d ("USB: Select better matching USB drivers when available")
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20200818110445.509668-3-hadess@hadess.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: Fallback to generic driver when specific driver fails

If ->probe fails for a device specific driver, ask the driver core to
reprobe us, after having flagged the device for the generic driver to be
forced.

Signed-off-by: Bastien Nocera <hadess@hadess.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20191016093933.693-6-hadess@hadess.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: Select better matching USB drivers when available

Now that USB device drivers can reuse code from the generic USB device
driver, we need to make sure that they get selected rather than the
generic driver. Add an id_table and match vfunc to the usb_device_driver
struct, which will get used to select a better matching driver at
->probe time.

This is a similar mechanism to that used in the HID drivers, with the
generic driver being selected unless there's a better matching one found
in the registered drivers (see hid_generic_match() in
drivers/hid/hid-generic.c).

Signed-off-by: Bastien Nocera <hadess@hadess.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20191016093933.693-5-hadess@hadess.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: Implement usb_device_match_id()

Match a usb_device with a table of IDs.

Signed-off-by: Bastien Nocera <hadess@hadess.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20191016093933.693-4-hadess@hadess.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: Make it possible to "subclass" usb_device_driver

The kernel currenly has only 2 usb_device_drivers, one generic one, one
that completely replaces the generic one to make USB devices usable over
a network.

Use the newly exported generic driver functions when a driver declares
to want them run, in addition to its own code. This makes it possible to
write drivers that extend the generic USB driver.

Note that this patch is not enough for another driver to automatically
get selected.

Signed-off-by: Bastien Nocera <hadess@hadess.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20191016093933.693-3-hadess@hadess.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: add support for dev_groups to struct usb_device_driver

Now that the driver core supports dev_groups for individual drivers,
expose that pointer to struct usb_device_driver to make it easier for USB
drivers to also use it.

Yes, users of usb_device_driver are much rare, but there are instances
already that use custom sysfs files, so adding this support will make
things easier for those drivers. usbip is one example, hubs might be
another one.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20190806144502.17792-3-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: add support for dev_groups to struct usb_driver

Now that the driver core supports dev_groups for individual drivers,
expose that pointer to struct usb_driver to make it easier for USB
drivers to also use it.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20190806144502.17792-2-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: core: Fix bug caused by duplicate interface PM usage counter

The syzkaller fuzzer reported a bug in the USB hub driver which turned
out to be caused by a negative runtime-PM usage counter. This allowed
a hub to be runtime suspended at a time when the driver did not expect
it. The symptom is a WARNING issued because the hub's status URB is
submitted while it is already active:

URB 0000000031fb463e submitted while active
WARNING: CPU: 0 PID: 2917 at drivers/usb/core/urb.c:363

The negative runtime-PM usage count was caused by an unfortunate
design decision made when runtime PM was first implemented for USB.
At that time, USB class drivers were allowed to unbind from their
interfaces without balancing the usage counter (i.e., leaving it with
a positive count). The core code would take care of setting the
counter back to 0 before allowing another driver to bind to the
interface.

Later on when runtime PM was implemented for the entire kernel, the
opposite decision was made: Drivers were required to balance their
runtime-PM get and put calls. In order to maintain backward
compatibility, however, the USB subsystem adapted to the new
implementation by keeping an independent usage counter for each
interface and using it to automatically adjust the normal usage
counter back to 0 whenever a driver was unbound.

This approach involves duplicating information, but what is worse, it
doesn't work properly in cases where a USB class driver delays
decrementing the usage counter until after the driver's disconnect()
routine has returned and the counter has been adjusted back to 0.
Doing so would cause the usage counter to become negative. There's
even a warning about this in the USB power management documentation!

As it happens, this is exactly what the hub driver does. The
kick_hub_wq() routine increments the runtime-PM usage counter, and the
corresponding decrement is carried out by hub_event() in the context
of the hub_wq work-queue thread. This work routine may sometimes run
after the driver has been unbound from its interface, and when it does
it causes the usage counter to go negative.

It is not possible for hub_disconnect() to wait for a pending
hub_event() call to finish, because hub_disconnect() is called with
the device lock held and hub_event() acquires that lock. The only
feasible fix is to reverse the original design decision: remove the
duplicate interface-specific usage counter and require USB drivers to
balance their runtime PM gets and puts. As far as I know, all
existing drivers currently do this.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: syzbot+7634edaea4d0b341c625@syzkaller.appspotmail.com
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: Consolidate LPM checks to avoid enabling LPM twice

USB Bluetooth controller QCA ROME (0cf3:e007) sometimes stops working
after S3:
[ 165.110742] Bluetooth: hci0: using NVM file: qca/nvm_usb_00000302.bin
[ 168.432065] Bluetooth: hci0: Failed to send body at 4 of 1953 (-110)

After some experiments, I found that disabling LPM can workaround the
issue.

On some platforms, the USB power is cut during S3, so the driver uses
reset-resume to resume the device. During port resume, LPM gets enabled
twice, by usb_reset_and_verify_device() and usb_port_resume().

Consolidate all checks into new LPM helpers to make sure LPM only gets
enabled once.

Fixes: de68bab4fa96 ("usb: Don't enable USB 2.0 Link PM by default.”)
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: stable <stable@vger.kernel.org> # after much soaking
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: Add new USB LPM helpers

Use new helpers to make LPM enabling/disabling more clear.

This is a preparation to subsequent patch.

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: stable <stable@vger.kernel.org> # after much soaking
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: core: remove set but not used variable 'udev'

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/usb/core/driver.c: In function 'usb_driver_claim_interface':
drivers/usb/core/driver.c:513:21: warning:
variable 'udev' set but not used [-Wunused-but-set-variable]

Since commit c183813fcee44a24 ("USB: remove LPM management from
usb_driver_claim_interface()"), 'udev' is not used.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: fix error handling in usb_driver_claim_interface()

The syzbot fuzzing project found a use-after-free bug in the USB
core. The bug was caused by usbfs not unbinding from an interface
when the USB device file was closed, which led another process to
attempt the unbind later on, after the private data structure had been
deallocated.

The reason usbfs did not unbind the interface at the appropriate time
was because it thought the interface had never been claimed in the
first place. This was caused by the fact that
usb_driver_claim_interface() does not clean up properly when
device_bind_driver() returns an error. Although the error code gets
passed back to the caller, the iface->dev.driver pointer remains set
and iface->condition remains equal to USB_INTERFACE_BOUND.

This patch adds proper error handling to usb_driver_claim_interface().

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: syzbot+f84aa7209ccec829536f@syzkaller.appspotmail.com
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: remove LPM management from usb_driver_claim_interface()

usb_driver_claim_interface() disables and re-enables Link Power
Management, but it shouldn't do either one, for the reasons listed
below. This patch removes the two LPM-related function calls from the
routine.

The reason for disabling LPM in the analogous function
usb_probe_interface() is so that drivers won't have to deal with
unwanted LPM transitions in their probe routine. But
usb_driver_claim_interface() doesn't call the driver's probe routine
(or any other callbacks), so that reason doesn't apply here.

Furthermore, no driver other than usbfs will ever call
usb_driver_claim_interface() unless it is already bound to another
interface in the same device, which means disabling LPM here would be
redundant. usbfs doesn't interact with LPM at all.

Lastly, the error return from usb_unlocked_disable_lpm() isn't handled
properly; the code doesn't clean up its earlier actions before
returning.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Fixes: 8306095fd2c1 ("USB: Disable USB 3.0 LPM in critical sections.")
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

driver core: hold dev's parent lock when needed

SoC have internal I/O buses that can't be proved for devices. The
devices on the buses can be accessed directly without additinal
configuration required. This type of bus is represented as
"simple-bus". In some platforms, we name "soc" with "simple-bus"
attribute and many devices are hooked under it described in DT
(device tree).

In commit bf74ad5bc417 ("Hold the device's parent's lock during
probe and remove") to solve USB subsystem lock sequence since
USB device's characteristic. Thus "soc" needs to be locked
whenever a device and driver's probing happen under "soc" bus.
During this period, an async driver tries to probe a device which
is under the "soc" bus would be blocked until previous driver
finish the probing and release "soc" lock. And the next probing
under the "soc" bus need to wait for async finish. Because of
that, driver's async probe for init time improvement will be
shadowed.

Since many devices don't have USB devices' characteristic, they
actually don't need parent's lock. Thus, we introduce a lock flag
in bus_type struct and driver core would lock the parent lock base
on the flag. For USB, we set this flag in usb_bus_type to keep
original lock behavior in driver core.

Async probe could have more benefit after this patch.

Signed-off-by: Martin Liu <liumartin@google.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: Don't print a warning if interface driver rebind is deferred at resume

Interface drivers like btusb that don't support reset-resume will be
rebound at resume if port was reset. Rebind is done during the pm_ops
.complete callback when probe returns EPROBE_DEFER as default.

Remove the "rebind failed: -517" message.
Device probe will eventually take place later.

[one-liner by Jerry Snitselaar posted in a mailing list question -Mathias]
Suggested-by: Jerry Snitselaar <jsnitsel@redhat.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: core: Fix logging messages with spurious periods after newlines

Using a period after a newline causes bad output.

Miscellanea:

o Coalesce formats too

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: core: introduce a new usb_get_std_status() helper

This new helper is a simple wrapper around usb_get_status(). This
patch is in preparation to adding support for fetching PTM_STATUS
types. No functional changes.

Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: core: move existing SPDX tags to top of the file

To match the rest of the kernel, the SPDX tags for the drivers/usb/core/
files are moved to the first line of the file. This makes it more
obvious the tag is present as well as making it match the other 12k
files in the tree with this location.

It also uses // to match the "expected style" as well.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: Force disconnect Huawei 4G modem during suspend

When going into S3 suspend, the Acer TravelMate P648-M and P648-G3
laptops immediately wake up 3-4 seconds later for no obvious reason.

Unbinding the integrated Huawei 4G LTE modem before suspend avoids
the issue, even though we are not using the modem at all (checked
from rescue.target/runlevel1). The problem also occurs when the option
and cdc-ether modem drivers aren't loaded; it reproduces just with the
base usb driver. Under Windows the system can suspend fine.

Seeking a better fix, we've tried a lot of things, including:
- Check that the device's power/wakeup is disabled
- Check that remote wakeup is off at the USB level
- All the quirks in drivers/usb/core/quirks.c e.g. USB_QUIRK_RESET_RESUME,
USB_QUIRK_RESET, USB_QUIRK_IGNORE_REMOTE_WAKEUP, USB_QUIRK_NO_LPM.

but none of that makes any difference.

There are no errors in the logs showing any suspend/resume-related issues.
When the system wakes up due to the modem, log-wise it appears to be a
normal resume.

Introduce a quirk to disable the port during suspend when the modem is
detected.

The modem from the P648-G3 model is:
T: Bus=01 Lev=01 Prnt=01 Port=08 Cnt=04 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=ff MxPS=64 #Cfgs= 3
P: Vendor=12d1 ProdID=15c3 Rev= 1.02
S: Manufacturer=Huawei Technologies Co., Ltd.
S: Product=HUAWEI Mobile
S: SerialNumber=0123456789ABCDEF
C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr= 2mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=10 Driver=
E: Ad=82(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=13 Driver=
E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=12 Driver=
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I: If#= 3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=06 Prot=16 Driver=
E: Ad=86(I) Atr=03(Int.) MxPS= 16 Ivl=2ms
I: If#= 3 Alt= 1 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=16 Driver=
E: Ad=86(I) Atr=03(Int.) MxPS= 16 Ivl=2ms
E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=1b Driver=
E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
C:* #Ifs= 6 Cfg#= 2 Atr=a0 MxPwr= 2mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether
E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=2ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=06 Prot=00 Driver=cdc_ether
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=10 Driver=option
E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=13 Driver=option
E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=12 Driver=option
E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=06 Prot=1b Driver=option
E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
C: #Ifs= 2 Cfg#= 3 Atr=a0 MxPwr= 2mA
A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=
E: Ad=82(I) Atr=03(Int.) MxPS= 16 Ivl=2ms
I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=
I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Based on an earlier patch by Chris Chiu.

Signed-off-by: Daniel Drake <drake@endlessm.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: hub: Do not attempt to autosuspend disconnected devices

While running a bind/unbind stress test with the dwc3 usb driver on rk3399,
the following crash was observed.

Unable to handle kernel NULL pointer dereference at virtual address 00000218
pgd = ffffffc00165f000
[00000218] *pgd=000000000174f003, *pud=000000000174f003,
*pmd=0000000001750003, *pte=00e8000001751713
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat rfcomm
xt_mark fuse bridge stp llc zram btusb btrtl btbcm btintel bluetooth
ip6table_filter mwifiex_pcie mwifiex cfg80211 cdc_ether usbnet r8152 mii joydev
snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device ppp_async
ppp_generic slhc tun
CPU: 1 PID: 29814 Comm: kworker/1:1 Not tainted 4.4.52 #507
Hardware name: Google Kevin (DT)
Workqueue: pm pm_runtime_work
task: ffffffc0ac540000 ti: ffffffc0af4d4000 task.ti: ffffffc0af4d4000
PC is at autosuspend_check+0x74/0x174
LR is at autosuspend_check+0x70/0x174
...
Call trace:
[<ffffffc00080dcc0>] autosuspend_check+0x74/0x174
[<ffffffc000810500>] usb_runtime_idle+0x20/0x40
[<ffffffc000785ae0>] __rpm_callback+0x48/0x7c
[<ffffffc000786af0>] rpm_idle+0x1e8/0x498
[<ffffffc000787cdc>] pm_runtime_work+0x88/0xcc
[<ffffffc000249bb8>] process_one_work+0x390/0x6b8
[<ffffffc00024abcc>] worker_thread+0x480/0x610
[<ffffffc000251a80>] kthread+0x164/0x178
[<ffffffc0002045d0>] ret_from_fork+0x10/0x40

Source:

(gdb) l *0xffffffc00080dcc0
0xffffffc00080dcc0 is in autosuspend_check
(drivers/usb/core/driver.c:1778).
1773 /* We don't need to check interfaces that are
1774 * disabled for runtime PM. Either they are unbound
1775 * or else their drivers don't support autosuspend
1776 * and so they are permanently active.
1777 */
1778 if (intf->dev.power.disable_depth)
1779 continue;
1780 if (atomic_read(&intf->dev.power.usage_count) > 0)
1781 return -EBUSY;
1782 w |= intf->needs_remote_wakeup;

Code analysis shows that intf is set to NULL in usb_disable_device() prior
to setting actconfig to NULL. At the same time, usb_runtime_idle() does not
lock the usb device, and neither does any of the functions in the
traceback. This means that there is no protection against a race condition
where usb_disable_device() is removing dev->actconfig->interface[] pointers
while those are being accessed from autosuspend_check().

To solve the problem, synchronize and validate device state between
autosuspend_check() and usb_disconnect().

Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: hub: Fix error loop seen after hub communication errors

While stress testing a usb controller using a bind/unbind looop, the
following error loop was observed.

usb 7-1.2: new low-speed USB device number 3 using xhci-hcd
usb 7-1.2: hub failed to enable device, error -108
usb 7-1-port2: cannot disable (err = -22)
usb 7-1-port2: couldn't allocate usb_device
usb 7-1-port2: cannot disable (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: activate --> -22
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
hub 7-1:1.0: hub_ext_port_status failed (err = -22)
** 57 printk messages dropped ** hub 7-1:1.0: activate --> -22
** 82 printk messages dropped ** hub 7-1:1.0: hub_ext_port_status failed (err = -22)

This continues forever. After adding tracebacks into the code,
the call sequence leading to this is found to be as follows.

[<ffffffc0007fc8e0>] hub_activate+0x368/0x7b8
[<ffffffc0007fceb4>] hub_resume+0x2c/0x3c
[<ffffffc00080b3b8>] usb_resume_interface.isra.6+0x128/0x158
[<ffffffc00080b5d0>] usb_suspend_both+0x1e8/0x288
[<ffffffc00080c9c4>] usb_runtime_suspend+0x3c/0x98
[<ffffffc0007820a0>] __rpm_callback+0x48/0x7c
[<ffffffc00078217c>] rpm_callback+0xa8/0xd4
[<ffffffc000786234>] rpm_suspend+0x84/0x758
[<ffffffc000786ca4>] rpm_idle+0x2c8/0x498
[<ffffffc000786ed4>] __pm_runtime_idle+0x60/0xac
[<ffffffc00080eba8>] usb_autopm_put_interface+0x6c/0x7c
[<ffffffc000803798>] hub_event+0x10ac/0x12ac
[<ffffffc000249bb8>] process_one_work+0x390/0x6b8
[<ffffffc00024abcc>] worker_thread+0x480/0x610
[<ffffffc000251a80>] kthread+0x164/0x178
[<ffffffc0002045d0>] ret_from_fork+0x10/0x40

kick_hub_wq() is called from hub_activate() even after failures to
communicate with the hub. This results in an endless sequence of
hub event -> hub activate -> wq trigger -> hub event -> ...

Provide two solutions for the problem.

- Only trigger the hub event queue if communication with the hub
is successful.
- After a suspend failure, only resume already suspended interfaces
if the communication with the device is still possible.

Each of the changes fixes the observed problem. Use both to improve
robustness.

Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: core: add missing license information to some files

Some of the USB core files were missing explicit license information.
As all files in the kernel tree are implicitly licensed under the
GPLv2-only, be explicit in case someone get confused looking at
individual files by using the SPDX nomenclature.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: leave LPM alone if possible when binding/unbinding interface drivers

When a USB driver is bound to an interface (either through probing or
by claiming it) or is unbound from an interface, the USB core always
disables Link Power Management during the transition and then
re-enables it afterward. The reason is because the driver might want
to prevent hub-initiated link power transitions, in which case the HCD
would have to recalculate the various LPM parameters. This
recalculation takes place when LPM is re-enabled and the new
parameters are sent to the device and its parent hub.

However, if the driver does not want to prevent hub-initiated link
power transitions then none of this work is necessary. The parameters
don't need to be recalculated, and LPM doesn't need to be disabled and
re-enabled.

It turns out that disabling and enabling LPM can be time-consuming,
enough so that it interferes with user programs that want to claim and
release interfaces rapidly via usbfs. Since the usbfs kernel driver
doesn't set the disable_hub_initiated_lpm flag, we can speed things up
and get the user programs to work by leaving LPM alone whenever the
flag isn't set.

And while we're improving the way disable_hub_initiated_lpm gets used,
let's also fix its kerneldoc.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Matthew Giassa <matthew@giassa.net>
CC: Mathias Nyman <mathias.nyman@intel.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: usb_driver_claim_interface: add sanity checking

Attacks that trick drivers into passing a NULL pointer
to usb_driver_claim_interface() using forged descriptors are
known. This thwarts them by sanity checking.

Signed-off-by: Oliver Neukum <ONeukum@suse.com>
CC: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: core: driver: Use kmalloc_array

Use kmalloc_array instead of kmalloc to allocate memory for an array.
Also, remove the dev_warn for a memory leak, making the if check more
sleek.

Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: interface authorization: Control interface probing and claiming

Driver probings and interface claims get rejected
if an interface is not authorized.

Signed-off-by: Stefan Koch <stefan.koch10@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert "usb: interface authorization: Control interface probing and claiming"

This reverts commit de7718bd9c4d3db96991a98c2a0cb38258a04e47 as the
signed-off-by address is invalid.

Cc: Stefan Koch <stefan.koch10@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: interface authorization: Control interface probing and claiming

Driver probings and interface claims get rejected
if an interface is not authorized.

Signed-off-by: Stefan Koch <skoch@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: fix coding style issue

Fixed coding style issue: newline after declaration

Signed-off-by: Kris Borer <kborer@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: add flag for HCDs that can't receive wakeup requests (isp1760-hcd)

Currently the USB stack assumes that all host controller drivers are
capable of receiving wakeup requests from downstream devices.
However, this isn't true for the isp1760-hcd driver, which means that
it isn't safe to do a runtime suspend of any device attached to a
root-hub port if the device requires wakeup.

This patch adds a "cant_recv_wakeups" flag to the usb_hcd structure
and sets the flag in isp1760-hcd. The core is modified to prevent a
direct child of the root hub from being put into runtime suspend with
wakeup enabled if the flag is set.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Nicolas Pitre <nico@linaro.org>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>

USB: don't cancel queued resets when unbinding drivers

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: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Russell King - ARM Linux <linux@arm.linux.org.uk>
Reported-by: Olivier Sobrie <olivier@sobrie.be>
Tested-by: Olivier Sobrie <olivier@sobrie.be>
Cc: stable <stable@vger.kernel.org> # 3.19
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB / PM: Drop CONFIG_PM_RUNTIME from the USB core

After commit b2b49ccbdd54 (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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: shutdown all URBs after controller death

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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: Avoid runtime suspend loops for HCDs that can't handle suspend/resume

Not all host controller drivers have bus-suspend and bus-resume
methods. When one doesn't, it will cause problems if runtime PM is
enabled in the kernel. The PM core will attempt to suspend the
controller's root hub, the suspend will fail because there is no
bus-suspend routine, and a -EBUSY error code will be returned to the
PM core. This will cause the suspend attempt to be repeated shortly
thereafter, in a never-ending loop.

Part of the problem is that the original error code -ENOENT gets
changed to -EBUSY in usb_runtime_suspend(), on the grounds that the PM
core will interpret -ENOENT as meaning that the root hub has gotten
into a runtime-PM error state. While this change is appropriate for
real USB devices, it's not such a good idea for a root hub. In fact,
considering the root hub to be in a runtime-PM error state would not
be far from the truth. Therefore this patch updates
usb_runtime_suspend() so that it adjusts error codes only for
non-root-hub devices.

Furthermore, the patch attempts to prevent the problem from occurring
in the first place by not enabling runtime PM by default for root hubs
whose host controller driver doesn't have bus_suspend and bus_resume
methods.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Will Deacon <will.deacon@arm.com>
Tested-by: Will Deacon <will.deacon@arm.com>
CC: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: unbind all interfaces before rebinding any

When a driver doesn't have pre_reset, post_reset, or reset_resume
methods, the USB core unbinds that driver when its device undergoes a
reset or a reset-resume, and then rebinds it afterward.

The existing straightforward implementation can lead to problems,
because each interface gets unbound and rebound before the next
interface is handled. If a driver claims additional interfaces, the
claim may fail because the old binding instance may still own the
additional interface when the new instance tries to claim it.

This patch fixes the problem by first unbinding all the interfaces
that are marked (i.e., their needs_binding flag is set) and then
rebinding all of them.

The patch also makes the helper functions in driver.c a little more
uniform and adjusts some out-of-date comments.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: "Poulain, Loic" <loic.poulain@intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb-core: Free bulk streams on interface release

Documentation/usb/bulk-streams.txt says:

All stream IDs will be deallocated when the driver releases the interface, to
ensure that drivers that don't support streams will be able to use the endpoint

This commit actually implements this.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

usb: core: let dynamic ids override static ids

This modifies the probing order so that any matching
dynamic entry always will be used, even if the driver
has a matching static entry.

It is sometimes useful to dynamically update existing
device entries. With the new ability to set the dynamic
entry driver_info field, this can be used to test new
additions to class driver exception lists or proposed
changes to existing static per-device driver_info
entries.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: core: Fix potential memory leak adding dyn USBdevice IDs

Fix a memory leak in the usb_store_new_id() error paths. When bailing out
due to sanity checks, the function left the already allocated usb_dynid
struct in place. This regression was introduced by the following commits:

c63fe8f6 (usb: core: add sanity checks when using bInterfaceClass with new_id)
1b9fb31f (usb: core: check for valid id_table when using the RefId feature)
52a6966c (usb: core: bail out if user gives an unknown RefId when using new_id)

Detected by Coverity: CID 1162604.

Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: core: check for valid id_table when using the RefId feature

When implementing the RefId feature, it was missed that id_tables can be
NULL under special circumstances. Bail out in that case.

Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: core: bail out if user gives an unknown RefId when using new_id

If users use the new RefId feature of new_id, give them an error message
if they provided an unknown reference. That helps detecting typos.

Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: core: allow a reference device for new_id

Often, usb drivers need some driver_info to get a device to work. To
have access to driver_info when using new_id, allow to pass a reference
vendor:product tuple from which new_id will inherit driver_info.

Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: core: add sanity checks when using bInterfaceClass with new_id

Check if that field is actually used and if so, bail out if it exeeds a
u8. Make it also future-proof by not requiring "exactly three"
parameters in new_id, but simply "more than two".

Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: core: Remove superfluous name casts

device_driver.name is "const char *"

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: change dev_warn about missing reset-resume to dev_dbg

This patch changes a dev_warn() call in usbcore to dev_dbg(). It's
not necessary to warn about drivers missing a reset-resume callback,
since the reset-resume method is optional.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: Don't enable USB 2.0 Link PM by default.

How it's supposed to work:
--------------------------

USB 2.0 Link PM is a lower power state that some newer USB 2.0 devices
support. USB 3.0 devices certified by the USB-IF are required to
support it if they are plugged into a USB 2.0 only port, or a USB 2.0
cable is used. USB 2.0 Link PM requires both a USB device and a host
controller that supports USB 2.0 hardware-enabled LPM.

USB 2.0 Link PM is designed to be enabled once by software, and the host
hardware handles transitions to the L1 state automatically. The premise
of USB 2.0 Link PM is to be able to put the device into a lower power
link state when the bus is idle or the device NAKs USB IN transfers for
a specified amount of time.

...but hardware is broken:
--------------------------

It turns out many USB 3.0 devices claim to support USB 2.0 Link PM (by
setting the LPM bit in their USB 2.0 BOS descriptor), but they don't
actually implement it correctly. This manifests as the USB device
refusing to respond to transfers when it is plugged into a USB 2.0 only
port under the Haswell-ULT/Lynx Point LP xHCI host.

These devices pass the xHCI driver's simple test to enable USB 2.0 Link
PM, wait for the port to enter L1, and then bring it back into L0. They
only start to break when L1 entry is interleaved with transfers.

Some devices then fail to respond to the next control transfer (usually
a Set Configuration). This results in devices never enumerating.

Other mass storage devices (such as a later model Western Digital My
Passport USB 3.0 hard drive) respond fine to going into L1 between
control transfers. They ACK the entry, come out of L1 when the host
needs to send a control transfer, and respond properly to those control
transfers. However, when the first READ10 SCSI command is sent, the
device NAKs the data phase while it's reading from the spinning disk.
Eventually, the host requests to put the link into L1, and the device
ACKs that request. Then it never responds to the data phase of the
READ10 command. This results in not being able to read from the drive.

Some mass storage devices (like the Corsair Survivor USB 3.0 flash
drive) are well behaved. They ACK the entry into L1 during control
transfers, and when SCSI commands start coming in, they NAK the requests
to go into L1, because they need to be at full power.

Not all USB 3.0 devices advertise USB 2.0 link PM support. My Point
Grey USB 3.0 webcam advertises itself as a USB 2.1 device, but doesn't
have a USB 2.0 BOS descriptor, so we don't enable USB 2.0 Link PM. I
suspect that means the device isn't certified.

What do we do about it?
-----------------------

There's really no good way for the kernel to test these devices.
Therefore, the kernel needs to disable USB 2.0 Link PM by default, and
distros will have to enable it by writing 1 to the sysfs file
/sys/bus/usb/devices/../power/usb2_hardware_lpm. Rip out the xHCI Link
PM test, since it's not sufficient to detect these buggy devices, and
don't automatically enable LPM after the device is addressed.

This patch should be backported to kernels as old as 3.11, that
contain the commit a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci:
add USB2 Link power management BESL support". Without this fix, some
USB 3.0 devices will not enumerate or work properly under USB 2.0 ports
on Haswell-ULT systems.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

USB: core: use DRIVER_ATTR_RW()

Use DRIVER_ATTR_RW() to make it easier to audit sysfs file permissions.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: fix some scripts/kernel-doc warnings

When building the htmldocs (in verbose mode), scripts/kernel-doc reports the
following type of warnings:

Warning(drivers/usb/core/usb.c:76): No description found for return value of
'usb_find_alt_setting'

Fix them by:
- adding some missing descriptions of return values
- using "Return" sections for those descriptions

Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PM / Runtime: Rework the "runtime idle" helper routine

The "runtime idle" helper routine, rpm_idle(), currently ignores
return values from .runtime_idle() callbacks executed by it.
However, it turns out that many subsystems use
pm_generic_runtime_idle() which checks the return value of the
driver's callback and executes pm_runtime_suspend() for the device
unless that value is not 0. If that logic is moved to rpm_idle()
instead, pm_generic_runtime_idle() can be dropped and its users
will not need any .runtime_idle() callbacks any more.

Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
ata_port_runtime_idle(), respectively, as well as a few drivers'
ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has
been returned by the .runtime_idle() callback executed by it.

To reduce overall code bloat, make the changes described above.

Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Kevin Hilman <khilman@linaro.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>

USB: driver.c: processing failure, maching resume condition with suspend condition

when suspend, it need check 'udev->actconfig'.
so when process failure, also need check it.

Signed-off-by: Chen Gang <gang.chen@asianux.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: remove CONFIG_USB_SUSPEND option

This patch (as1675) removes the CONFIG_USB_SUSPEND option, essentially
replacing it everywhere with CONFIG_PM_RUNTIME (except for one place
in hub.c, where it is replaced with CONFIG_PM because the code needs
to be used in both runtime and system PM). The net result is code
shrinkage and simplification.

There's very little point in keeping CONFIG_USB_SUSPEND because almost
everybody enables it. The few that don't will find that the usbcore
module has gotten somewhat bigger and they will have to take active
measures if they want to prevent hubs from being runtime suspended.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: adds comment on suspend callback

This patch adds comments on interface driver suspend callback
to emphasize that the failure return value is ignored by
USB core in system sleep context, so do not try to recover
device for this case and let resume/reset_resume callback
handle the suspend failure if needed.

Also kerneldoc for usb_suspend_both() is updated with the
fact.

Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb-core: remove CONFIG_HOTPLUG ifdefs

Remove conditional code based on CONFIG_HOTPLUG being false. It's
always on now in preparation of it going away as an option.

Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

treewide: fix typo of "suport" in various comments and Kconfig

Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>

USB: Enable LPM after a failed probe.

Before a driver is probed, we want to disable USB 3.0 Link Power
Management (LPM), in case the driver needs hub-initiated LPM disabled.
After the probe finishes, we want to attempt to re-enable LPM, order to
balance the LPM ref count.

When a probe fails (such as when libusual doesn't want to bind to a USB
3.0 mass storage device), make sure to balance the LPM ref counts by
re-enabling LPM.

This patch should be backported to kernels as old as 3.5, that contain
the commit 8306095fd2c1100e8244c09bf560f97aca5a311d "USB: Disable USB
3.0 LPM in critical sections."

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org

usb: remove junk from store_remove_id

retval is 0, and carefully assigned - and tested as non zero.

This is not useful. While we are at it remove some other bogus initialisation
in the function

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: Add quirk detection based on interface information

When a whole class of devices (possibly from a specific vendor, or
across multiple vendors) require a quirk, explictly listing all devices
in the class make the quirks table unnecessarily large. Fix this by
allowing matching devices based on interface information.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb-core: Set intfdata to NULL if a driver's probe method failed

Ensure that intfdata always is NULL if no driver is bound:
1) drvdata is for a driver to store a pointer to driver specific data
2) If no driver is bound, there is no driver specific data associated with
the device
3) Thus logically drvdata should be NULL if no driver is bound.

We already set intfdata to NULL when a driver is unbound, to ensure that
intfdata will be NULL even if the drivers disconnect method does not properly
clear it. This ensures that intfdata will also be NULL after a failed probe,
even if the driver's probe method left a (likely dangling) pointer in there.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: allow match on bInterfaceNumber

Some composite USB devices provide multiple interfaces
with different functions, all using "vendor-specific"
for class/subclass/protocol. Another OS use interface
numbers to match the driver and interface. It seems
these devices are designed with that in mind - using
static interface numbers for the different functions.

This adds support for matching against the
bInterfaceNumber, allowing such devices to be supported
without having to resort to testing against interface
number whitelists and/or blacklists in the probe.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: Disable USB 3.0 LPM in critical sections.

There are several places where the USB core needs to disable USB 3.0
Link PM:
- usb_bind_interface
- usb_unbind_interface
- usb_driver_claim_interface
- usb_port_suspend/usb_port_resume
- usb_reset_and_verify_device
- usb_set_interface
- usb_reset_configuration
- usb_set_configuration

Use the new LPM disable/enable functions to temporarily disable LPM
around these critical sections.

We need to protect the critical section around binding and unbinding USB
interface drivers. USB drivers may want to disable hub-initiated USB
3.0 LPM, which will change the value of the U1/U2 timeouts that the xHCI
driver will install. We need to disable LPM completely until the driver
is bound to the interface, and the driver has a chance to enable
whatever alternate interface setting it needs in its probe routine.
Then re-enable USB3 LPM, and recalculate the U1/U2 timeout values.

We also need to disable LPM in usb_driver_claim_interface,
because drivers like usbfs can bind to an interface through that
function. Note, there is no way currently for userspace drivers to
disable hub-initiated USB 3.0 LPM. Revisit this later.

When a driver is unbound, the U1/U2 timeouts may change because we are
unbinding the last driver that needed hub-initiated USB 3.0 LPM to be
disabled.

USB LPM must be disabled when a USB device is going to be suspended.
The USB 3.0 spec does not define a state transition from U1 or U2 into
U3, so we need to bring the device into U0 by disabling LPM before we
can place it into U3. Therefore, call usb_unlocked_disable_lpm() in
usb_port_suspend(), and call usb_unlocked_enable_lpm() in
usb_port_resume(). If the port suspend fails, make sure to re-enable
LPM by calling usb_unlocked_enable_lpm(), since usb_port_resume() will
not be called on a failed port suspend.

USB 3.0 devices lose their USB 3.0 LPM settings (including whether USB
device-initiated LPM is enabled) across device suspend. Therefore,
disable LPM before the device will be reset in
usb_reset_and_verify_device(), and re-enable LPM after the reset is
complete and the configuration/alt settings are re-installed.

The calculated U1/U2 timeout values are heavily dependent on what USB
device endpoints are currently enabled. When any of the enabled
endpoints on the device might change, due to a new configuration, or new
alternate interface setting, we need to first disable USB 3.0 LPM, add
or delete endpoints from the xHCI schedule, install the new interfaces
and alt settings, and then re-enable LPM. Do this in usb_set_interface,
usb_reset_configuration, and usb_set_configuration.

Basically, there is a call to disable and then enable LPM in all
functions that lock the bandwidth_mutex. One exception is
usb_disable_device, because the device is disconnecting or otherwise
going away, and we should not care about whether USB 3.0 LPM is enabled.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

USB: add read support to usb-serial/../new_id

Keep the usb-serial support for dynamic IDs in sync with the usb
support. This enables readout of dynamic device IDs for
usb-serial drivers. Common code is exported from the usb core
system and reused by the usb-serial bus driver.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: let both new_id and remove_id show dynamic id list

This enables the current list of dynamic IDs to be read out through
either new_id or remove_id.

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: remove CONFIG_USB_DEVICEFS

This option has been deprecated for many years now, and no userspace
tools use it anymore, so it should be safe to finally remove it.

Reported-by: Kay Sievers <kay@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: don't ignore suspend errors for root hubs

This patch (as1532) fixes a mistake in the USB suspend code. When the
system is going to sleep, we should ignore errors in powering down USB
devices, because they don't really matter. The devices will go to low
power anyway when the entire USB bus gets suspended (except for
SuperSpeed devices; maybe they will need special treatment later).

However we should not ignore errors in suspending root hubs,
especially if the error indicates that the suspend raced with a wakeup
request. Doing so might leave the bus powered on while the system was
supposed to be asleep, or it might cause the suspend of the root hub's
parent controller device to fail, or it might cause a wakeup request
to be ignored.

The patch fixes the problem by ignoring errors only when the device in
question is not a root hub.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Chen Peter <B29397@freescale.com>
CC: <stable@vger.kernel.org>
Tested-by: Chen Peter <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB/PCI/PCMCIA: Clean up new_id and remove_id sysfs attribute routines

This patch (as1514) cleans up some places where new_id and remove_id
sysfs attributes are created and deleted. Handling both attributes in
a single routine rather than a pair of routines makes the code
smaller. It also prevents certain kinds of errors, like one we
currently have in the USB subsystem: The removeid attribute is often
created even when newid isn't (because the driver's no_dynamid_id flag
is set).

In the case of the PCMCIA subsystem, the newid attribute is created
but never explicitly deleted. The patch adds a deletion routine.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Dynamic ID addition doesn't need get_driver()

As part of the removal of get_driver()/put_driver(), this patch
(as1511) changes all the places that add dynamic IDs for drivers.
Since these additions are done by writing to the drivers' sysfs
attribute files, and the attributes are removed when the drivers are
unregistered, there is no reason to take an extra reference to the
drivers.

The one exception is the pci-stub driver, which calls pci_add_dynid()
as part of its registration. But again, there's no reason to take an
extra reference here, because the driver can't be unloaded while it is
being registered.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Dmitry Torokhov <dmitry.torokhov@gmail.com>
CC: Jiri Kosina <jkosina@suse.cz>
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: cleanup the handling of the PM complete call

This eliminates the last instance of a function's behavior
controlled by a parameter as Linus hates such things.

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: code cleanup in suspend/resume path (3rd try)

Do the cleanup to avoid behaviorial parameters Linus
requested.

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: remove dead code from suspend/resume path

If a driver does not support the suspend/resume callbacks
it will be forcibly disconnected. There is no reason to check
for support of the callbacks after that.

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: Add optional match for interface class to dynamic ID facility

When adding the ID of a composite device dynamically to a driver, all
hitherto unbound interfaces are bound to this driver regardless of their
class, which may not be intended.
The patch adds the option to tell the targeted interface class to a driver
via the "new_id" attribute, in addition to the device ID.
Also, it appends the ABI documentation accordingly.

Example:
$ echo "1234 2a2a ff" >/sys/bus/usb-serial/drivers/option1/new_id
will bind only vendor-specific interfaces to the 3G driver.

Signed-off-by: Josua Dietze <digidietze@draisberghof.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: Update last_busy time after autosuspend fails

Originally, the runtime PM core would send an idle notification
whenever a suspend attempt failed. The idle callback routine could
then schedule a delayed suspend for some time later.

However this behavior was changed by commit
f71648d73c1650b8b4aceb3856bebbde6daa3b86 (PM / Runtime: Remove idle
notification after failing suspend). No notifications were sent, and
there was no clear mechanism to retry failed suspends.

This caused problems for the usbhid driver, because it fails
autosuspend attempts as long as a key is being held down. A companion
patch changes the PM core's behavior, but we also need to change the
USB core. In particular, this patch (as1493) updates the device's
last_busy time when an autosuspend fails, so that the PM core will
retry the autosuspend in the future when the delay time expires
again.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Henrik Rydberg <rydberg@euromail.se>
Cc: <stable@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

usb: Add export.h for EXPORT_SYMBOL/THIS_MODULE where needed

With module.h being implicitly everywhere via device.h, the absence
of explicitly including something for EXPORT_SYMBOL went unnoticed.
Since we are heading to fix things up and clean module.h from the
device.h file, we need to explicitly include these files now.

Use the lightweight version of the header that has just THIS_MODULE
and EXPORT_SYMBOL variants.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

xHCI: set USB2 hardware LPM

If the device pass the USB2 software LPM and the host supports hardware
LPM, enable hardware LPM for the device to let the host decide when to
put the link into lower power state.

If hardware LPM is enabled for a port and driver wants to put it into
suspend, it must first disable hardware LPM, resume the port into U0,
and then suspend the port.

Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: for usb_autopm_get_interface_async -EINPROGRESS is not an error

A return value of -EINPROGRESS from pm_runtime_get indicates that
the device is already resuming due to a previous call. Internally,
usb_autopm_get_interface_async doesn't treat this as an error and
increments the usage count, but passes the error status along
to the caller. The logical assumption of the caller is that
any negative return value reflects the device not resuming
and the pm_usage_cnt not being incremented. Since the usage count
is being incremented and the device is resuming, return success (0)
instead.

Signed-off-by: James Wylder <james.wylder@motorola.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

PM / Runtime: Add macro to test for runtime PM events

This patch (as1482) adds a macro for testing whether or not a
pm_message value represents an autosuspend or autoresume (i.e., a
runtime PM) event. Encapsulating this notion seems preferable to
open-coding the test all over the place.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

PM: Rename dev_pm_info.in_suspend to is_prepared

This patch (as1473) renames the "in_suspend" field in struct
dev_pm_info to "is_prepared", in preparation for an upcoming change.
The new name is more descriptive of what the field really means.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: stable@kernel.org

USB: don't let errors prevent system sleep

This patch (as1464) implements the recommended policy that most errors
during suspend or hibernation should not prevent the system from going
to sleep. In particular, failure to suspend a USB driver or a USB
device should not prevent the sleep from succeeding:

Failure to suspend a device won't matter, because the device will
automatically go into suspend mode when the USB bus stops carrying
packets. (This might be less true for USB-3.0 devices, but let's not
worry about them now.)

Failure of a driver to suspend might lead to trouble later on when the
system wakes up, but it isn't sufficient reason to prevent the system
from going to sleep.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: Move runtime PM callbacks to usb_device_pm_ops

USB defines usb_device_type pointing to usb_device_pm_ops that
provides system-wide PM callbacks only and usb_bus_type pointing to
usb_bus_pm_ops that provides runtime PM callbacks only. However,
the USB runtime PM callbacks may be defined in usb_device_pm_ops
which makes it possible to drop usb_bus_pm_ops and will allow us
to consolidate the handling of subsystems by the PM core code.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>

usb: Always return 0 or -EBUSY to the runtime PM core.

The PM core reacts badly when the return code from usb_runtime_suspend()
is not 0, -EAGAIN, or -EBUSY. The PM core regards this as a fatal error,
and refuses to run anymore PM helper functions. In particular,
usbfs_open() and other usbfs functions will fail because the PM core will
return an error code when usb_autoresume_device() is called. This causes
libusb and/or lsusb to either hang or segfault.

If a USB device cannot suspend for some reason (e.g. a hub doesn't report
it has remote wakeup capabilities), we still want lsusb and other
userspace programs to work. So return -EBUSY, which will fill people's
log files with failed tries, but will ensure userspace still works.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

PM: Replace the device power.status field with a bit field

The device power.status field is too complicated for its purpose
(storing the information about whether or not the device is in the
"active" state from the PM core's point of view), so replace it with
a bit field and modify all of its users accordingly.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

USB: improve uses of usb_mark_last_busy

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

In addition, the call to disable autosuspend support for new devices
by default is moved from usb_detect_quirks() (where it doesn't really
belong) into usb_new_device() along with all the other runtime-PM
initializations. Finally, an extra pm_runtime_get_noresume() is added
to prevent new devices from autosuspending while they are being
registered.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: use the runtime-PM autosuspend implementation

This patch (as1428) converts USB over to the new runtime-PM core
autosuspend framework. One slightly awkward aspect of the conversion
is that USB devices will now have two suspend-delay attributes: the
old power/autosuspend file and the new power/autosuspend_delay_ms
file. One expresses the delay time in seconds and the other in
milliseconds, but otherwise they do the same thing. The old attribute
can be deprecated and then removed eventually.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: make usb_mark_last_busy use pm_runtime_mark_last_busy

Since the runtime-PM core already defines a .last_busy field in
device.power, this patch uses it to replace the .last_busy field
defined in usb_device and uses pm_runtime_mark_last_busy to implement
usb_mark_last_busy.

Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: use the no_callbacks flag for interfaces

Call pm_runtime_no_callbacks to set no_callbacks flag for USB
interfaces. Since interfaces cannot be power-managed separately from
their parent devices, there's no reason for the runtime-PM core to
invoke any callbacks for them.

Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: do not print -ESHUTDOWN message if usb at otg device mode

At otg device mode, the otg host resume should do no-op during
system resume, otherwise, the otg device will be treated as a
host for enumeration.

So, the otg host driver returns -ESHUTDOWN if it detects the
current usb mode is device mode. The host driver has to return
-ESHUTDOWN, otherwise, the usb_hc_died will be called.

Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: remove fake "address-of" expressions

Fake "address-of" expressions that evaluate to NULL generally confuse
readers and can provoke compiler warnings. This patch (as1412)
removes three such fake expressions, using "#ifdef"s in their place.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: core driver: Fix Coding Styles

Fixed coding styles in the core usb driver.

Signed-off-by: Carlos Sánchez Acosta <csanchez@neurowork.net>
Signed-off-by: Alejandro Sánchez Acosta <asanchez@neurowork.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: obey the sysfs power/wakeup setting

This patch (as1403) is a partial reversion of an earlier change
(commit 5f677f1d45b2bf08085bbba7394392dfa586fa8e "USB: fix remote
wakeup settings during system sleep"). After hearing from a user, I
realized that remote wakeup should be enabled during system sleep
whenever userspace allows it, and not only if a driver requests it
too.

Indeed, there could be a device with no driver, that does nothing but
generate a wakeup request when the user presses a button. Such a
device should be allowed to do its job.

The problem fixed by the earlier patch -- device generating a wakeup
request for no reason, causing system suspend to abort -- was also
addressed by a later patch ("USB: don't enable remote wakeup by
default", accepted but not yet merged into mainline). The device
won't be able to generate the bogus wakeup requests because it will be
disabled for remote wakeup by default. Hence this reversion will not
re-introduce any old problems.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org> [.34]
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: unbind all interfaces before rebinding them

This patch (as1387) fixes a bug introduced during the changeover to
the runtime PM framework. When a driver doesn't support resume or
reset-resume, and consequently its interfaces need to be unbound and
rebound, we have to unbind all the interfaces before trying to rebind
any of them. Otherwise the driver's probe method for one interface
could try to claim a different interface and fail, because that other
interface hasn't been unbound yet.

This fixes Bugzilla #15788. The symptom is that some USB sound cards
don't work after hibernation.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: François Valenduc <francois.valenduc@tvcablenet.be>
Cc: stable <stable@kernel.org> [.34]
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: fix interface runtime-PM settings

This patch (as1379) reworks the logic for handling USB interface
runtime-PM settings -- hopefully it's right this time! The problem is
that when a driver is unbound or binding fails, runtime PM for the
interface always gets disabled. But pm_runtime_disable() nests, so it
shouldn't be called unless the interface was previously enabled for
runtime PM.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Rob Duncan <Robert.Duncan@exar.com>
Tested-by: Rob Duncan <Robert.Duncan@exar.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: use PM core routines to enable/disable autosuspend

This patch (as1366) replaces the private routines
usb_enable_autosuspend() and usb_disable_autosuspend() with calls to
the standard pm_runtime_allow() and pm_runtime_forbid() functions in
the runtime PM framework. They do the same thing.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: improve runtime remote wakeup settings

This patch (as1362) adjusts the way the USB autosuspend routines
handle remote-wakeup settings. They aren't supposed to use
device_may_wakeup(); that test is intended only for system sleep, not
runtime power management. Instead the code checks to see if any
interface drivers need remote wakeup; if they do then it is enabled,
provided the device is capable of it.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: make hcd.h public (drivers dependency)

The usbcore headers: hcd.h and hub.h are shared between usbcore,
HCDs and a couple of other drivers (e.g. USBIP modules).
So, it makes sense to move them into a more public location and
to cleanup dependency of those modules on kernel internal headers.
This patch moves hcd.h from drivers/usb/core into include/linux/usb/

Signed-of-by: Eric Lescouet <eric@lescouet.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: put claimed interfaces in the "suspended" state

This patch (as1370) fixes a bug in the USB runtime power management
code. When a driver claims an interface, it doesn't expect to need to
call usb_autopm_get_interface() or usb_autopm_put_interface() for
runtime PM to work. Runtime PM can be controlled by the driver's
primary interface; the additional interfaces it claims shouldn't
interfere. As things stand, the claimed interfaces will prevent the
device from autosuspending.

To fix this problem, the patch sets interfaces to the suspended state
when they are claimed.

Also, although in theory this shouldn't matter, the patch changes the
suspend code so that interfaces are suspended in reverse order from
detection and resuming. This is how the PM core works, and we ought
to use the same approach.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Debugged-and-tested-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: fix remote wakeup settings during system sleep

This patch (as1363) changes the way USB remote wakeup is handled
during system sleeps. It won't be enabled unless an interface driver
specifically needs it. Also, it won't be enabled during the FREEZE or
QUIESCE phases of hibernation, when the system doesn't respond to
wakeup events anyway. Finally, if the device is already
runtime-suspended with remote wakeup enabled, but wakeup is supposed
to be disabled for the system sleep, the device gets woken up so that
it can be suspended again with the proper wakeup setting.

This will fix problems people have reported with certain USB webcams
that generate wakeup requests when they shouldn't, and as a result
cause system suspends to fail. See

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/515109

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Erik Andrén <erik.andren@gmail.com>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.

2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).

* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

Driver core: create lock/unlock functions for struct device

In the future, we are going to be changing the lock type for struct
device (once we get the lockdep infrastructure properly worked out) To
make that changeover easier, and to possibly burry the lock in a
different part of struct device, let's create some functions to lock and
unlock a device so that no out-of-core code needs to be changed in the
future.

This patch creates the device_lock/unlock/trylock() functions, and
converts all in-tree users to them.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Dave Young <hidave.darkstar@gmail.com>
Cc: Ming Lei <tom.leiming@gmail.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Phil Carmody <ext-phil.2.carmody@nokia.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Len Brown <len.brown@intel.com>
Cc: Magnus Damm <damm@igel.co.jp>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Alex Chiang <achiang@hp.com>
Cc: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrew Patterson <andrew.patterson@hp.com>
Cc: Yu Zhao <yu.zhao@intel.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Wolfram Sang <w.sang@pengutronix.de>
Cc: CHENG Renquan <rqcheng@smu.edu.sg>
Cc: Oliver Neukum <oliver@neukum.org>
Cc: Frans Pop <elendil@planet.nl>
Cc: David Vrabel <david.vrabel@csr.com>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: remove debugging message for uevent constructions

This patch (as1332) removes an unneeded and annoying debugging message
announcing all USB uevent constructions.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: convert to the runtime PM framework

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

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

The only visible change in behavior should be that following a system
sleep (resume from RAM or resume from hibernation), autosuspended USB
devices will be resumed just like everything else. They won't remain
suspended. But if they aren't in use then they will naturally
autosuspend again in a few seconds.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: rearrange functions in driver.c

This patch (as1328) reorders the functions in drivers/usb/core/driver.c
so as to put all the routines dependent on CONFIG_PM in one place.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: implement usb_enable_autosuspend

This patch (as1326) adds usb_enable_autosuspend() and
usb_disable_autosuspend() routines for use by drivers. If a driver
knows that its device can handle suspends and resumes correctly, it
can enable autosuspend all by itself. This is equivalent to the user
writing "auto" to the device's power/level attribute.

The implementation differs slightly from what it used to be. Now
autosuspend is disabled simply by doing usb_autoresume_device() (to
increment the usage counter) and enabled by doing
usb_autosuspend_device() (to decrement the usage counter).

The set_level() attribute method is updated to use the new routines,
and the USB Power-Management documentation is updated.

The patch adds a usb_enable_autosuspend() call to the hub driver's
probe routine, allowing the special-case code for hubs in quirks.c to
be removed.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: change locking for device-level autosuspend

This patch (as1323) changes the locking requirements for
usb_autosuspend_device(), usb_autoresume_device(), and
usb_try_autosuspend_device(). This isn't a very important change;
mainly it's meant to make the locking more uniform.

The most tricky part of the patch involves changes to usbdev_open().
To avoid an ABBA locking problem, it was necessary to reduce the
region protected by usbfs_mutex. Since that mutex now protects only
against simultaneous open and remove, this posed no difficulty -- its
scope was larger than necessary.

And it turns out that usbfs_mutex is no longer needed in
usbdev_release() at all. The list of usbfs "ps" structures is now
protected by the device lock instead of by usbfs_mutex.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: rearrange code in usb_probe_interface

This patch (as1322) reverses the two outcomes of an "if" statement in
usb_probe_interface(), to avoid an unnecessary level of indentation.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: implement non-tree resume ordering constraints for PCI host controllers

This patch (as1331) adds non-tree ordering constraints needed for
proper resume of PCI USB host controllers from hibernation. The main
issue is that non-high-speed devices must not be resumed before the
high-speed root hub, because it is the ehci_bus_resume() routine which
takes care of handing the device connection over to the companion
controller. If the device resume is attempted before the handover
then the device won't be found and it will be treated as though it had
disconnected.

The patch adds a new field to the usb_bus structure; for each
full/low-speed bus this field will contain a pointer to the companion
high-speed bus (if one exists). It is used during normal device
resume; if the hs_companion pointer isn't NULL then we wait for the
root-hub device on the hs_companion bus.

A secondary issue is that an EHCI controlller shouldn't be resumed
before any of its companions. On some machines I have observed
handovers failing if the companion controller is reinitialized after
the handover. Thus, the EHCI resume routine must wait for the
companion controllers to be resumed.

The patch also fixes a small bug in usb_hcd_pci_probe(); an error path
jumps to the wrong label, causing a memory leak.

[rjw: Fixed compilation for CONFIG_PM_SLEEP unset.]

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

USB: add remove_id sysfs attr for usb drivers

Accroding commit 0994375e, which is adding remove_id sysfs attr
for pci drivers, for management tools dynamically bind/unbind
a pci/usb devices to a specified drivers; with this patch,
the management tools can be simplied.

And the original code didn't handle the failure of
usb_create_newid_file, fixed in this patch.

Signed-off-by: CHENG Renquan <rqcheng@smu.edu.sg>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: prepare for changover to Runtime PM framework

This patch (as1303) revises the USB Power Management infrastructure to
make it compatible with the new driver-model Runtime PM framework:

Drivers are no longer allowed to access intf->pm_usage_cnt
directly; the PM framework manages its own usage counters.

usb_autopm_set_interface() is eliminated, because it directly
sets intf->pm_usage_cnt.

usb_autopm_enable() and usb_autopm_disable() are eliminated,
because they call usb_autopm_set_interface().

usb_autopm_get_interface_no_resume() and
usb_autopm_put_interface_no_suspend() are added. They
correspond to pm_runtime_get_noresume() and
pm_runtime_put_noidle() in the PM framework.

The power/level attribute no longer accepts "suspend", only
"on" and "auto". The PM framework doesn't allow devices to be
forced into a suspended mode.

The hub driver contains the only code that violates the new
guidelines. It is updated to use the new interface routines instead.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: remove the auto_pm flag

This patch (as1302) removes the auto_pm flag from struct usb_device.
The flag's only purpose was to distinguish between autosuspends and
external suspends, but that information is now available in the
pm_message_t argument passed to suspend methods.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: fix missing error check in probing

usb: check for IO errors usb_set_interface can return

if they happen while unbinding a flag is set to retry upon probe
if they happen during probe they are handled as probe errors

Signed-off-by: Oliver Neukum <oliver@neukum.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: make intf.pm_usage an atomic_t

This patch (as1260) changes the pm_usage_cnt field in struct
usb_interface from an int to an atomic_t. This is so that drivers can
invoke the usb_autopm_get_interface_async() and
usb_autopm_put_interface_async() routines without locking and without
fear of corrupting the pm_usage_cnt value.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: add API for userspace drivers to "claim" ports

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

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

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

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

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

The patch also makes a small simplification to the hub driver,
replacing a bunch of more-or-less useless variants of "out of memory"
with a single message.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: Avoid PM error messages during resume if a device was disconnected

Currently if a laptop is suspended e.g. while docked and then resumed after
undocking it, the following errors get generated because the USB hub in the
docking station and the devices connected to it are no longer available:
pm_op(): usb_dev_resume+0x0/0x10 returns -19
PM: Device 1-2 failed to resume: error -19
pm_op(): usb_dev_resume+0x0/0x10 returns -19
PM: Device 1-2.2 failed to resume: error -19
pm_op(): usb_dev_resume+0x0/0x10 returns -19
PM: Device 1-2.3 failed to resume: error -19

As the removal of USB devices while a system is suspended is a relatively
common use case and in most cases not an error, just return success on
-ENODEV. The user gets informed anyway as the USB subsystem generates
regular disconnect messages for the devices shortly afterwards:
usb 1-2: USB disconnect, address 3
usb 1-2.2: USB disconnect, address 4
usblp0: removed
usb 1-2.3: USB disconnect, address 5

Signed-off-by: Frans Pop <elendil@planet.nl>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

usb: convert endpoint devices to bus-less childs of the usb interface

The endpoint devices look like simple attribute groups now, and no longer
like devices with a specific subsystem. They will also no longer emit uevents.

It also removes the device node requests for endpoint devices, which are not
implemented for now.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: consolidate usb_unbind_interface and usb_driver_release_interface

This patch (as1230) consolidates code in usb_unbind_interface() and
usb_driver_release_interface(). In fact, it makes release_interface
call unbind_interface, thereby removing the need for duplicated code.

It works like this: If the interface has already been registered with
the driver core when a driver releases it, then the usual driver-core
mechanism will call unbind_interface. If it hasn't been unregistered
then we will make the call ourselves.

As a nice bonus, drivers now don't have to worry about whether their
disconnect method will get called when they release an interface -- it
always will. Previously it would be called only if the interface was
registered.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: fix toggle mismatch in disable_endpoint paths

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

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

The earlier patch added an extra argument to the routines in the
enable_endpoint pathways to reflect this difference. This patch adds
corresponding arguments to the disable_endpoint pathways. Without
this change, the endpoint toggle state can get out of sync between
the host and the device. The exact mechanism depends on the details
of the host controller (whether or not it stores its own copy of the
toggle values).

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Dan Streetman <ddstreet@ieee.org>
Tested-by: Dan Streetman <ddstreet@ieee.org>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: re-enable interface after driver unbinds

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

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

This is a forward-ported version of a patch which fixes Bugzilla
#12301.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: David Roka <roka@dawid.hu>
Reported-by: Erik Ekman <erik@kryo.se>
Tested-by: Erik Ekman <erik@kryo.se>
Tested-by: Alon Bar-Lev <alon.barlev@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: Enhance usage of pm_message_t

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

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

IMO, the whole Power Management framework should have been set up this
way in the first place.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: utilize round_jiffies_up_relative()

This patch (as1178) uses the new round_jiffies_up_relative() routine
for setting the autosuspend delayed_work timer. It's appropriate
since we don't care too much about the exact length of the delay, but
we don't want it to be too short (rounded down).

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: Introduce usb_queue_reset() to do resets from atomic contexts

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

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

The call flow then becomes:

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

usb_probe_interface()
usb_cancel_queue_reset() [error path]

usb_unbind_interface()
usb_cancel_queue_reset()

usb_driver_release_interface()
usb_cancel_queue_reset()

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

Patch is against 2.6.28-rc2 and depends on
http://marc.info/?l=linux-usb&m=122581634925308&w=2 (as submitted by
Alan Stern).

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: add asynchronous autosuspend/autoresume support

This patch (as1160b) adds support routines for asynchronous autosuspend
and autoresume, with accompanying documentation updates. There
already are several potential users of this interface, and others are
likely to arise as autosuspend support becomes more widespread.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: skip Set-Interface(0) if already in altsetting 0

When a driver unbinds from an interface, usbcore always sends a
Set-Interface request to reinstall altsetting 0. Unforunately, quite
a few devices have buggy firmware that crashes when it receives this
request.

To avoid such problems, this patch (as1180) arranges to send the
Set-Interface request only when the interface is not already in
altsetting 0.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: don't rebind drivers after failed resume or reset

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

There was a report from one user that this fixed a problem he was
experiencing, but the details never became fully clear. In any case,
adding these tests can't hurt.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: RESET_RESUME needs to block autosuspend when remote wakeup is needed

Reset upon resumption will wipe the input buffer and is therefore
a reason to not suspend if remote wakeup is requested because
the driver needs that data.

Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: Don't rebind before "complete" callback

This patch (as1130) fixes an incompatibility between the new PM
infrastructure and USB power management. We are not allowed to call
drivers' probe routines during a system sleep transition between the
"prepare" and "complete" callbacks, but that's exactly what we do when
a driver doesn't have full suspend/resume support. Such drivers are
unbound during the "suspend" call and reprobed during the "resume" call.

The patch causes the reprobe step to be skipped if the "complete"
callback hasn't been issued yet, i.e., if the interface's
dev.power.status field is not equal to DPM_ON. Thus during the
"resume" callback nothing bad will happen, and during the final
"complete" callback the reprobing will occur as desired.

This fixes the problem reported in Bugzilla #11263.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: Add new PM callback methods for USB

This patch (as1129) adds support for the new PM callbacks to usbcore.
The new callbacks merely invoke the same old USB power management
routines as the old ones did.

A minor improvement is that the callbacks are present only in the
"USB-device" device_type structure, rather than in the bus_type
structure. This way they will be invoked only for USB devices, not
for USB interfaces. The core USB PM routines automatically handle
suspending and resuming interfaces along with their devices.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: Defer Set-Interface for suspended devices

This patch (as1128) fixes one of the problems related to the new PM
infrastructure. We are not allowed to register new child devices
during the middle of a system sleep transition, but unbinding a USB
driver causes the core to automatically install altsetting 0 and
thereby create new endpoint pseudo-devices.

The patch fixes this problem (and the related problem that installing
altsetting 0 will fail if the device is suspended) by deferring the
Set-Interface call until some later time when it is legal and can
succeed. Possible later times are: when a new driver is being probed
for the interface, and when the interface is being resumed.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: Add udev argument to interface suspend/resume functions

This patch (as1127) makes a minor change to the prototypes of the
usb_suspend_interface() and usb_resume_interface() routines. Now the
usb_device structure is passed as an argument, instead of being
computed on-the-fly from the usb_interface argument.

It makes the code look simpler, even if it really isn't much different
from before.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: fix compiler warning fix

This patch (as1123b) fixes a compiler warning: do_unbind_rebind() is
defined but not used if CONFIG_PM=n.

Problem originally found and initial patch submitted by Alexander
Beregalov <a.beregalov@gmail.com>.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

usb/core/driver: fix warning

usb/core/driver: fix warning:
drivers/usb/core/driver.c:834: warning: 'do_unbind_rebind' defined but not used

Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: Force unbinding of drivers lacking reset_resume or other methods

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

This is made slightly more difficult by the fact that bind operations
won't work during a system sleep transition. So instead the code has
to defer the operation until the transition ends.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: implement "soft" unbinding

This patch (as1091) changes the way usbcore handles interface
unbinding. If the interface's driver supports "soft" unbinding (a new
flag in the driver structure) then in-flight URBs are not cancelled
and endpoints are not disabled. Instead the driver is allowed to
continue communicating with the device (although of course it should
stop before its disconnect routine returns).

The purpose of this change is to allow drivers to do a clean shutdown
when they get unbound from a device that is still plugged in. Killing
all the URBs and disabling the endpoints before calling the driver's
disconnect method doesn't give the driver any control over what
happens, and it can leave devices in indeterminate states. For
example, when usb-storage unbinds it doesn't want to stop while in the
middle of transmitting a SCSI command.

The soft_unbind flag is added because in the past, a number of drivers
have experienced problems related to ongoing I/O after their disconnect
routine returned. Hence "soft" unbinding is made available only to
drivers that claim to support it.

The patch also replaces "interface_to_usbdev(intf)" with "udev" in a
couple of places, a minor simplification.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: try to salvage lost power sessions

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

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

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

The remote_wakeup() routine is changed; now it expects the caller to
acquire the device lock rather than acquiring the lock itself.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: simplify hub_restart() logic

This patch (as1081) straightens out the logic of the hub_restart()
routine. Each port of the hub is scanned and the driver makes sure
that ports which are supposed to be disabled really _are_ disabled.
Any ports with a significant change in status are flagged in
hub->change_bits, so that khubd can focus on them without the need to
scan all the ports a second time -- which means the hub->activating
flag is no longer needed.

Also, it is now recognized explicitly that the only reason for
resuming a port which was not suspended is to carry out a reset-resume
operation, which happens only in a non-CONFIG_USB_SUSPEND setting.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: usb dev_name() instead of dev->bus_id

The bus_id field is going away, use the dev_name() function instead.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: replace remaining __FUNCTION__ occurrences

__FUNCTION__ is gcc-specific, use __func__

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: HCDs use the do_remote_wakeup flag

When a USB device is suspended, whether or not it is enabled for
remote wakeup depends on the device_may_wakeup() setting. The setting
is then saved in the do_remote_wakeup flag.

Later on, however, the device_may_wakeup() value can change because of
user activity. So when testing whether a suspended device is or
should be enabled for remote wakeup, we should always test
do_remote_wakeup instead of device_may_wakeup(). This patch (as1076)
makes that change for root hubs in several places.

The patch also adjusts uhci-hcd so that when an autostopped controller
is suspended, the remote wakeup setting agrees with the value recorded
in the root hub's do_remote_wakeup flag.

And the patch adjusts ehci-hcd so that wakeup events on selectively
suspended ports (i.e., the bus itself isn't suspended) don't turn on
the PME# wakeup signal.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: remove dev->power.power_state

power.power_state is scheduled for removal. This patch (as1053)
removes all uses of that field from drivers/usb. Almost all of them
were write-only, the most significant exceptions being sl811-hcd.c and
u132-hcd.c.

Part of this patch was written by Pavel Machek.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <david-b@pacbell.net>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: EHCI: carry out port handover during each root-hub resume

This patch (as1044) causes EHCI port handover for non-high-speed
devices to occur during every root-hub resume, not just in cases where
the controller lost power or was reset. This is necessary because:

When some machines go into suspend, they remove power from
on-board USB devices while retaining suspend current for USB
controllers.

The user might well unplug a USB device while the system is
suspended and then plug it back in before resuming.

A corresponding change is made to the core resume routine; now
high-speed root hubs will always be resumed when the system wakes up,
even if they were suspended before the system went to sleep. If this
weren't done then EHCI port handover wouldn't work, since it is called
when the EHCI root hub is resumed.

Finally, a comment is added to the hub driver explaining the khubd has
to be freezable; if it weren't frozen then it could interfere with
port handover.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: fix codingstyle issues in drivers/usb/core/*.c

Fixes a number of coding style issues in the remaining .c files in
drivers/usb/core/

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: mark USB drivers as being GPL only

Over two years ago, the Linux USB developers stated that they believed
there was no way to create a USB kernel driver that was not under the
GPL. This patch moves the USB apis to enforce that decision.

There are no known closed source USB drivers in the wild, so this patch
should cause no problems.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: handle idVendor of 0x0000

Some crazy devices in the wild have a vendor id of 0x0000. If we try to
add a module alias with this id, we just can't do it due to a check in
the file2alias.c file. Change the test to verify that both the vendor
and product ids are 0x0000 to show a real "blank" module alias.

Note, the module-init-tools package also needs to be changed to properly
generate the depmod tables.

Cc: Janusz <janumix@poczta.fm>
Cc: stable <stable@kernel.org>
Cc: Jon Masters <jcm@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: use proper call to driver_create_file

Don't try to call the "raw" sysfs_create_file when we already have a
helper function to do this kind of work for us.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: uevent environment key fix

This patch (as1010) was written by both Kay Sievers and me. It solves
the problem of duplicated keys in USB uevent structures by refactoring
the uevent subroutines, taking advantage of the way the hotplug core
calls uevent handlers for the device's bus and for the device's type.
Keys needed for both USB-device and USB-interface events are added in
usb_uevent(), which is the bus handler. Keys appropriate only for
USB-device or USB-interface events are added in usb_dev_uevent() or
usb_if_uevent() respectively, the type handlers.

In addition, unnecessary tests for NULL pointers are removed as are
duplicated debugging log statements.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: fix race in autosuspend reschedule

This patch (as1002) fixes a small race which can occur when a driver
expects usbcore to reschedule an autosuspend request. If the request
arrives too late, it won't be rescheduled. The patch adds an extra
argument to autosuspend_check(), indicating that a reschedule is
needed no matter how much time has elapsed.

It also tries to avoid letting asynchronous changes to the value of
jiffies cause a delay to become negative, by caching a local copy of
the current time.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: skip autosuspended devices during system resume

System suspends and hibernation are supposed to be as transparent as
possible. By this reasoning, if a USB device is already autosuspended
before the system sleep begins then it should remain autosuspended
after the system wakes up.

This patch (as1001) adds a skip_sys_resume flag to the usb_device
structure and uses it to avoid waking up devices which were suspended
when a system sleep began.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: don't propagate FREEZE or PRETHAW suspends

This patch (as992) fixes a recently-added bug. During a FREEZE or
PRETHAW suspend notification, non-root devices don't actually get
suspended. So we shouldn't tell their parent hubs that they did.

(This code path used to be skipped over, until the FREEZE/PRETHAW test
got moved out of usb_suspend_both() into generic_suspend().)

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: flush outstanding URBs when suspending

This patch (as989) makes usbcore flush all outstanding URBs for each
device as the device is suspended. This will be true even when
CONFIG_USB_SUSPEND is not enabled.

In addition, an extra can_submit flag is added to the usb_device
structure. That flag will be turned off whenever a suspend request
has been received for the device, even if the device isn't actually
suspended because CONFIG_USB_SUSPEND isn't set.

It's no longer necessary to check for the device state being equal to
USB_STATE_SUSPENDED during URB submission; that check can be replaced
by a check of the can_submit flag. This also permits us to remove
some questionable references to the deprecated power.power_state field.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: move decision to ignore FREEZE events

This patch (as987) changes the way FREEZE and PRETHAW suspend events
are handled in usbcore. The decision about whether or not to ignore
them for non-root devices is pushed down into the USB-device driver,
instead of being made in the core code.

This is appropriate, since devices exported to a virtualized guest or
over a network may indeed need to handle these types of suspend, even
though normal devices don't.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

usb: usb_probe_interface() obeys authorization

If called and the device is not authorized to be used, it won't
configure the interface and print a message saying so.

Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Driver core: change add_uevent_var to use a struct

This changes the uevent buffer functions to use a struct instead of a
long list of parameters. It does no longer require the caller to do the
proper buffer termination and size accounting, which is currently wrong
in some places. It fixes a known bug where parts of the uevent
environment are overwritten because of wrong index calculations.

Many thanks to Mathieu Desnoyers for finding bugs and improving the
error handling.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: fix linked list insertion bugfix for usb core

This patch fixes the order of list_add_tail() arguments in
usb_store_new_id() so the list can have more than one single element.

Signed-off-by: Nathael Pajani <nathael.pajani@cpe.fr>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: update last_busy field correctly

This patch (as966) fixes a bug in the autosuspend code. The last_busy
field should be updated whenever any event occurs, not just events
that cause an autosuspend or an autoresume.

This partially fixes Bugzilla #8892.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

dev_vdbg(), available with -DVERBOSE_DEBUG

This defines a dev_vdbg() call, which is enabled with -DVERBOSE_DEBUG.
When enabled, dev_vdbg() acts just like dev_dbg(). When disabled, it is a
NOP ... just like dev_dbg() without -DDEBUG. The specific code was moved
out of a USB patch, but lots of drivers have similar support.

That is, code can now be written to use an additional level of debug
output, selected at compile time. Many driver authors have found this
idiom to be very useful. A typical usage model is for "normal" debug
messages to focus on fault paths and not be very "chatty", so that those
messages can be left on during normal operation without much of a
performance or syslog load. On the other hand "verbose" messages would be
noisy enough that they wouldn't normally be enabled; they might even affect
timings enough to change system or driver behavior.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: Make usb-autosuspend timer 1 sec jiffy aligned

Make usb autosuspend timers 1sec jiffy aligned.

This helps to reduce the frequency at which the CPU must be taken out of a
lower-power state.

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: Remove usages of dev->power.power_state

This patch (as922) removes all but one of the remaining vestiges of
dev->power.power_state from usbcore. The only usage left must remain
until the deprecated "power/state" sysfs attribute is gone.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: add reset_resume method

This patch (as918) introduces a new USB driver method: reset_resume.
It is called when a device needs to be reset as part of a resume
procedure (whether because of a device quirk or because of the
USB-Persist facility), thereby taking over a role formerly assigned to
the post_reset method. As a consequence, post_reset no longer needs
an argument indicating whether it is being called as part of a
reset-resume. This separation of functions makes the code clearer.

In addition, the pre_reset and post_reset method return types are
changed; they now must return an error code. The return value is
unused at present, but at some later time we may unbind drivers and
re-probe if they encounter an error during reset handling.

The existing pre_reset and post_reset methods in the usbhid,
usb-storage, and hub drivers are updated to match the new
requirements. For usbhid the post_reset routine is also used for
reset_resume (duplicate method pointers); for the other drivers a new
reset_resume routine is added. The change to hub.c looks bigger than
it really is, because mark_children_for_reset_resume() gets moved down
next to the new hub_reset_resume() routine.

A minor change to usb-storage makes the usb_stor_report_bus_reset()
routine acquire the host lock instead of requiring the caller to hold
it already.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: rework C++-style comments

This patch (as911) replaces some C++-style commented-out debugging
lines in driver.c with a new "verbose debugging" macro. It makes the
code look cleaner, and it's easier to turn the debugging on or off.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: add RESET_RESUME device quirk

This patch (as888) adds a new USB device quirk for devices which are
unable to resume correctly. By using the new code added for the
USB-persist facility, it is a simple matter to reset these devices
instead of resuming them. To get things kicked off, a quirk entry is
added for the Philips PSC805.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: add USB-Persist facility

This patch (as886) adds the controversial USB-persist facility,
allowing USB devices to persist across a power loss during system
suspend.

The facility is controlled by a new Kconfig option (with appropriate
warnings about the potential dangers); when the option is off the
behavior will remain the same as it is now. But when the option is
on, people will be able to use suspend-to-disk and keep their USB
filesystems intact -- something particularly valuable for small
machines where the root filesystem is on a USB device!

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: move bus_suspend and bus_resume method calls

This patch (as885) moves the root-hub bus_suspend() and bus_resume()
method calls from the hub driver's suspend and resume methods into the
usb_generic driver methods, where they make just as much sense.

Their old locations were not fully correct. For example, in a kernel
compiled without CONFIG_USB_SUSPEND, if one were to do:

echo -n 1-0:1.0 >/sys/bus/usb/drivers/hub/unbind

to unbind the hub driver from a root hub, there would then be no way
to suspend that root hub. Attempts to put the system to sleep would
fail; the USB controller driver would refuse to suspend because the
root hub was still active.

The patch also makes a very slight change in the way devices with no
driver are handled during suspend. Rather than doing a standard USB
port-suspend directly, now the suspend routine in usb_generic is
called. In practice this should never affect anyone.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: Implement PM FREEZE and PRETHAW

This patch (as884) finally implements the time-saving semantics
possible with the Power Management FREEZE and PRETHAW events. Their
proper handling requires only that devices be quiesced, with
interrupts and DMA turned off; non-root USB devices don't actually
need to be put in a suspended state. The patch checks and avoids
doing the suspend call when possible.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: interface PM state

This patch (as880) strives to keep the PM core's idea of a USB
interface's power state in synch with usbcore's own idea. In the end
this doesn't really matter, but it's better to be consistent.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: more autosuspend timer stuff

This patch (as879) ties up some loose ends from an earlier patch.
These are things I didn't think to include at the time but which
clearly belonged there.

If an autosuspend fails because driver activity races with
the autosuspend call, restart the autosuspend timer.

When a device is resumed by an external request, it counts
as device activity and should update the last_busy time so
that the next autoresume won't occur immediately.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: fix signed jiffies issue in autosuspend logic

This patch (as897) changes the autosuspend timer code to use the
standard types and macros in dealing with jiffies values.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: add "last_busy" field for use in autosuspend

This patch (as877) adds a "last_busy" field to struct usb_device, for
use by the autosuspend framework. Now if an autosuspend call comes at
a time when the device isn't busy but hasn't yet been idle for long
enough, the timer can be set to exactly the desired value. And we
will be ready to handle things like HID drivers, which can't maintain
a useful usage count and must rely on the time-of-last-use to decide
when to autosuspend.

The patch also makes some related minor improvements:

Move the calls to the autosuspend condition-checking routine
into usb_suspend_both(), which is the only place where it
really matters.

If the autosuspend timer is already running, don't stop
and restart it.

Replace immediate returns with gotos so that the optional
debugging ouput won't be bypassed.

If autoresume is disabled but the device is already awake,
don't return an error for an autoresume call.

Don't try to autoresume a device if it isn't suspended.
(Yes, this undercuts the previous change -- so sue me.)

Don't duplicate existing code in the autosuspend work routine.

Fix the kerneldoc in usb_autopm_put_interface(): If an
autoresume call fails, the usage counter is left unchanged.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: make usbdevices export their device nodes instead of using a separate class

o The "real" usb-devices export now a device node which can
populate /dev/bus/usb.

o The usb_device class is optional now and can be disabled in the
kernel config. Major/minor of the "real" devices and class devices
are the same.

o The environment of the usb-device event contains DEVNUM and BUSNUM to
help udev and get rid of the ugly udev rule we need for the class
devices.

o The usb-devices and usb-interfaces share the same bus, so I used
the new "struct device_type" to let these devices identify
themselves. This also removes the current logic of using a magic
platform-pointer.
The name of the device_type is also added to the environment
which makes it easier to distinguish the different kinds of devices
on the same subsystem.

It looks like this:
add@/devices/pci0000:00/0000:00:1d.1/usb2/2-1
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1d.1/usb2/2-1
SUBSYSTEM=usb
SEQNUM=1533
MAJOR=189
MINOR=131
DEVTYPE=usb_device
PRODUCT=46d/c03e/2000
TYPE=0/0/0
BUSNUM=002
DEVNUM=004

This udev rule works as a replacement for usb_device class devices:
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", \
NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0644"

Updated patch, which needs the device_type patches in Greg's tree.

I also got a bugzilla assigned for this. :)
https://bugzilla.novell.com/show_bug.cgi?id=250659


Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: add power/level sysfs attribute

This patch (as874) adds another piece to the user-visible part of the
USB autosuspend interface. The new power/level sysfs attribute allows
users to force the device on (with autosuspend off), force the device
to sleep (with autoresume off), or return to normal automatic operation.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: Allow autosuspend delay to equal 0

This patch (as867) adds an entry for the new power/autosuspend
attribute in Documentation/ABI/testing, and it changes the behavior of
the delay value. Now a delay of 0 means to autosuspend as soon as
possible, and negative values will prevent autosuspend.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: separate autosuspend from external suspend

This patch (as866) adds new entry points for external USB device
suspend and resume requests, as opposed to internally-generated
autosuspend or autoresume. It also changes the existing
remote-wakeup code paths to use the new routines, since remote wakeup
is not the same as autoresume.

As part of the change, it turns out to be necessary to do remote
wakeup of root hubs from a workqueue. We had been using khubd, but it
does autoresume rather than an external resume. Using the
ksuspend_usb_wq workqueue for this purpose seemed a logical choice.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

usbcore: move usb_autosuspend_work

This patch (as864) moves the work routine for USB autosuspend from one
source file to another. This permits the removal of one whole global
symbol (!) and should smooth the way for more changes in the future.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: remove use of the bus rwsem, as it doesn't really protect anything.

The driver core stopped using the rwsem a long time ago, yet the USB
core still grabbed the lock, thinking it protected something. This
patch removes that useless use.

Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.de>
Cc: David Brownell <david-b@pacbell.net>
Cc: linux-usb-devel <linux-usb-devel@lists.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: export autosuspend delay in sysfs

This patch (as861) adds sysfs attributes to expose the autosuspend
delay value for each USB device. If the user changes the delay from 0
(no autosuspend) to a positive value, an autosuspend is attempted.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: make autosuspend delay a module parameter

This patch (as859) makes the default USB autosuspend delay a module
parameter of usbcore. By setting the delay value at boot time, users
will be able to prevent the system from autosuspending devices which
for some reason can't handle it.

The patch also stores the autosuspend delay as a per-device value. A
later patch will allow the user to change the value, tailoring the
delay for each individual device. A delay value of 0 will prevent
autosuspend.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: refactor usb device matching and create usb_device_match

This is needed for the quirk match code.

Cc: Oliver Neukum <oliver@neukum.name>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: kernel-doc fixes

Fix kernel-doc warnings and in USB core.

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB serial: add dynamic id support to usb-serial core

Thanks to Johannes Hölzl <johannes.hoelzl@gmx.de> for fixing a few
things and getting it all working properly.

This adds support for dynamic usb ids to the usb serial core. The file
"new_id" will show up under the usb serial driver, not the usb driver
associated with the usb-serial driver (yeah, it can be a bit confusing
at first glance...)

This patch also modifies the USB core to allow the usb-serial core to
reuse much of the dynamic id logic.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Johannes Hölzl <johannes.hoelzl@gmx.de>

USB: add the sysfs driver name to all modules

This adds the module name to all USB drivers, if they are built into the
kernel or not. It will show up in /sys/modules/MODULE_NAME/drivers/

Cc: Kay Sievers <kay.sievers@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

usbcore: remove unused argument in autosuspend

Thanks to several earlier patches, usb_autosuspend_device() and
usb_autoresume_device() are never called with a second argument other
than 1. This patch (as819) removes the now-redundant argument.

It also consolidates some common code between those two routines,
putting it into a new subroutine called usb_autopm_do_device(). And
it includes a sizable kerneldoc update for the affected functions.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: keep count of unsuspended children

This patch (as818b) simplifies autosuspend processing by keeping track
of the number of unsuspended children of each USB hub. This will
permit us to avoid a good deal of unnecessary work all the time; we
will no longer have to create a bunch of workqueue entries to carry
out autosuspend requests, only to have them fail because one of the
hub's children isn't suspended.

The basic idea is simple. There already is a usage counter in the
usb_device structure for preventing autosuspends. The patch just
increments that counter for every unsuspended child. There's only one
tricky part: When a device disconnects we need to remember whether it
was suspended at the time (leave the counter alone) or not (decrement
the counter).

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: make drivers/usb/core/driver.c:usb_device_match() static

usb_device_match() can now become static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: resume_device symbol conflict

Several functions in USB core overlap with global functions.
The linker appears to do the right thing, but it is bad practice and makes
debugging harder.

Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: expand autosuspend/autoresume API

This patch (as814) adds usb_autopm_set_interface() to the autosuspend
API. It also provides convenient wrapper routines,
usb_autopm_enable() and usb_autopm_disable(), for drivers that want
to specify directly whether autosuspend should be allowed.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: autosuspend code consolidation

This patch (as813) gathers together common code for USB interface
autosuspend/autoresume.

It also adds some simple checking at the time an autosuspend request
is made, to see whether the request will fail. This way we don't
add a workqueue entry when it would end up doing nothing.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB core: don't match interface descriptors for vendor-specific devices

This patch (as804) makes USB driver matching ignore the interface
class, subclass, and protocol if the device class is Vendor Specific.
Drivers can override this policy by specifying a Vendor ID as part
of the match; then vendor-specific matches are allowed.

Linus Walleij has reported a problem this patch fixes. When a
particular mass-storage device is switched from mass-storage mode to
Media Transfer Protocol, the interface class remains set to mass-storage
and usb-storage binds to it erroneously, even though the device class
changes to Vendor-Specific.

This may cause a problem for some drivers until their match records can
be updated to include Vendor IDs. But if it does, then those records
were broken to begin with.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: fix autosuspend when CONFIG_PM isn't set

This patch (as791b) fixes things up to avoid compiler warnings or
errors when CONFIG_USB_SUSPEND or CONFIG_PM isn't set.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: create new workqueue thread for USB autosuspend

This patch (as787) creates a new workqueue thread to handle delayed
USB autosuspend requests. Previously the code used keventd. However
it turns out that the hub driver's suspend routine calls
flush_scheduled_work(), making it a poor candidate for running in
keventd (the call immediately deadlocks). The solution is to use a
new thread instead of keventd.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: fixes kerneldoc errors in usbcore-auto(susp/res)-patch

Fixes kerneldoc errors on usb/core/driver.c, which occured in 2.6.18-rc6-mm2
gregkh-usb-usbcore-add-autosuspend-autoresume-infrastructure.patch

Signed-off-by: Henrik Kretzschmar <henne@nachtwindheim.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: fix __must_check warnings in drivers/usb/core/

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

USB: fix root-hub resume when CONFIG_USB_SUSPEND is not set

This patch (as786) removes a redundant test and fixes a problem
involving repeated system sleeps when CONFIG_USB_SUSPEND is not set.
During the first wakeup, the root hub's dev.power.power_state.event
field doesn't get updated, causing it not to be suspended during the
second sleep transition.

This takes care of the issue raised by Rafael J. Wysocki and Mattia
Dongili.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

usbcore: add autosuspend/autoresume infrastructure

This patch (as739) adds the basic infrastructure for USB autosuspend
and autoresume. The main features are:

PM usage counters added to struct usb_device and struct
usb_interface, indicating whether it's okay to autosuspend
them or they are currently in use.

Flag added to usb_device indicating whether the current
suspend/resume operation originated from outside or as an
autosuspend/autoresume.

Flag added to usb_driver indicating whether the driver
supports autosuspend. If not, no device bound to the driver
will be autosuspended.

Mutex added to usb_device for protecting PM operations.
Unlike the device semaphore, the locking rule for the pm_mutex
is that you must acquire the locks going _up_ the device tree.

New routines handling autosuspend/autoresume requests for
interfaces and devices.

Suspend and resume requests are propagated up the device tree
(but not outside the USB subsystem).

work_struct added to usb_device, for carrying out delayed
autosuspend requests.

Autoresume added (and autosuspend prevented) during probe and
disconnect.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

usbcore: suspending devices with no driver

Since usb_generic can be unbound from a USB device, we need to be able
to handle the possibility that a suspend or resume request arrives for a
device with no driver. This patch (as735) arranges things so that
resume requests will fail and suspend requests will use the standard USB
port-suspend code. Attempts to suspend or resume an unbound interface
are handled similarly (although the error caused by trying to resume an
unbound interface is dropped by the calling routine).


Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

usbcore: fix up device and power state tests

This patch (as734) rationalizes the various tests of device state and
power states. There are duplications and mistaken tests in several
places.

Perhaps the most interesting challenge is where the hub driver tests to
see that all the child devices are suspended before allowing itself to
be suspended. When CONFIG_USB_SUSPEND is set the test is
straightforward, since we expect that the children _will_ be suspended.
But when CONFIG_USB_SUSPEND isn't set, it's not so clear what should be
done. The code compromises by checking the child's
power.power_state.event field.


Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

usbcore: set device and power states properly

This patch (as733) fixes up the places where device states and power
states are set in usbcore. Right now things are duplicated or missing;
this should straighten things out.

The idea is that udev->state is USB_STATE_SUSPENDED exactly when the
device's upstream port has been suspended, whereas
udev->dev.power.power_state.event reflects the result of the last call
to the suspend/resume routines (which might not actually change the
device state, especially if CONFIG_USB_SUSPEND isn't set).


Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

usbcore: resume device resume recursion

This patch (as717b) removes the existing recursion in hub resume code:
Resuming a hub will no longer automatically resume the devices attached
to the hub.

At the same time, it adds one level of recursion: Suspending a USB
device will automatically suspend all the device's interfaces. Failure
at an intermediate stage will cause all the already-suspended interfaces
to be resumed. Attempts to suspend or resume an interface by itself will
do nothing, although they won't return an error. Thus the regular
system-suspend and system-resume procedures should continue to work as
before; only runtime PM will be affected.

The patch also removes the code that tests state of the interfaces
before suspending a device. It's no longer needed, since everything
gets suspended together.


Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

usbcore: split suspend/resume for device and interfaces

This patch (as716b) splits up the core suspend and resume routines into
two parts each: one for handling devices and one for handling
interfaces. The behavior of the parts should be the same as in the old
unified code.


Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

usbcore: make usb_generic a usb_device_driver

This patch (as714b) makes usb_generic into a usb_device_driver capable
of being probed and unbound, just like other drivers. A fair amount of
the work that used to get done during discovery or removal of a USB
device have been moved to the probe and disconnect methods of
usb_generic: creating the sysfs attributes and selecting an initial
configuration. However the normal behavior should continue to be the
same as before.

We will now have the possibility of creating other USB device drivers,
They will assist with exporting devices to remote systems
(USB-over-TCPIP) or to paravirtual guest operating systems.


Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

usbcore: add usb_device_driver definition

This patch (as732) adds a usb_device_driver structure, for representing
drivers that manage an entire USB device as opposed to just an
interface. Support routines like usb_register_device_driver,
usb_deregister_device_driver, usb_probe_device, and usb_unbind_device
are also added.

Unlike an earlier version of this patch, the new code is type-safe. To
accomplish this, the existing struct driver embedded in struct
usb_driver had to be wrapped in an intermediate wrapper. This enables
the core to tell at runtime whether a particular struct driver belongs
to a device driver or to an interface driver.


Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

usbcore: move code among source files

This revised patch (as713b) moves a few routines among source files in
usbcore. Some driver-related code in usb.c (claiming interfaces and
matching IDs) is moved to driver.c, where it belongs. Also the
usb_generic stuff in driver.c is moved to a new source file: generic.c.
(That's the reason for revising the patch.) Although not very big now,
it will get bigger in a later patch.

None of the code has been changed; it has only been re-arranged.


Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Remove obsolete #include <linux/config.h>

Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

[PATCH] add EXPORT_SYMBOL_GPL_FUTURE() to USB subsystem

The USB core symbols will be converted to GPL-only in a few years. Mark
this as such and update the documentation explaining why, and provide a
pointer for developers to receive help if they need it.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

[PATCH] USB: Fix GPL markings on usb core functions.

I thought we had fixed up all non-gpl USB drivers, and was wrong to do
this.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

[PATCH] USB: Remove USB private semaphore

This patch (as605) removes the private udev->serialize semaphore,
relying instead on the locking provided by the embedded struct device's
semaphore. The changes are confined to the core, except that the
usb_trylock_device routine now uses the return convention of
down_trylock rather than down_read_trylock (they return opposite values
for no good reason).

A couple of other associated changes are included as well:

Now that we aren't concerned about HCDs that avoid using the
hcd glue layer, usb_disconnect no longer needs to acquire the
usb_bus_lock -- that can be done by usb_remove_hcd where it
belongs.

Devices aren't locked over the same scope of code in
usb_new_device and hub_port_connect_change as they used to be.
This shouldn't cause any trouble.

Along with the preceding driver core patch, this needs a lot of testing.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

[PATCH] USB: make registering a usb driver automatically set the module owner

This fixes the driver that forgot to set the module owner up. Now we
can remove the unneeded pointer from the usb driver structure. The idea
for how to do this was from Al Viro, who did this for the PCI drivers.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

[PATCH] USB: allow usb drivers to disable dynamic ids

This lets drivers, like the usb-serial ones, disable the ability to add
ids from sysfs.

The usb-serial drivers are "odd" in that they are really usb-serial bus
drivers, not usb bus drivers, so the dynamic id logic will have to go
into the usb-serial bus core for those drivers to get that ability.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

[PATCH] USB: add dynamic id functionality to USB core

Echo the usb vendor and product id to the "new_id" file in the driver's
sysfs directory, and then that driver will be able to bind to a device
with those ids if it is present.

Example:
echo 0557 2008 > /sys/bus/usb/drivers/foo_driver/new_id
adds the hex values 0557 and 2008 to the device id table for the foo_driver.

Note, usb-serial drivers do not currently work with this capability yet.
usb-storage also might have some oddities.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

[PATCH] USB: reorg some functions out of the main usb.c file

This will make the dynamic-id stuff easier to do, as it will be
self-contained.

No logic was changed at all.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>