USB: document some API requirements on disconnection

A call to usb_set_interface() crashes if the device is deallocated
concurrently, such as due to physical removal or a serious IO error.
It could

USB: document some API requirements on disconnection

A call to usb_set_interface() crashes if the device is deallocated
concurrently, such as due to physical removal or a serious IO error.
It could also interfere with other drivers using the device if the
current driver is unbound before the call is finished.

Document the need to delay driver unbinding until this call returns,
which solves both issues.

Document the same regarding usb_clear_halt(), which is equally known
to be routinely called by drivers.

Explicitly mention finishing pending operations in the documentation
of the driver disconnect callback.

Signed-off-by: Michal Pecio <[email protected]>
Link: https://lore.kernel.org/r/20240218092515.7635ff8c@foxbook
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

usb: core: constify the struct device_type usage

Since commit aed65af1cc2f ("drivers: make device_type const"), the driver
core can properly handle constant struct device_type. Move the
usb_device_t

usb: core: constify the struct device_type usage

Since commit aed65af1cc2f ("drivers: make device_type const"), the driver
core can properly handle constant struct device_type. Move the
usb_device_type, usb_if_device_type, usb_ep_device_type and
usb_port_device_type variables to be constant structures as well, placing
it into read-only memory which can not be modified at runtime.

Signed-off-by: Ricardo B. Marliere <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

USB: core: Change usb_get_device_descriptor() API

The usb_get_device_descriptor() routine reads the device descriptor
from the udev device and stores it directly in udev->descriptor. This
interface

USB: core: Change usb_get_device_descriptor() API

The usb_get_device_descriptor() routine reads the device descriptor
from the udev device and stores it directly in udev->descriptor. This
interface is error prone, because the USB subsystem expects in-memory
copies of a device's descriptors to be immutable once the device has
been initialized.

The interface is changed so that the device descriptor is left in a
kmalloc-ed buffer, not copied into the usb_device structure. A
pointer to the buffer is returned to the caller, who is then
responsible for kfree-ing it. The corresponding changes needed in the
various callers are fairly small.

Signed-off-by: Alan Stern <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

usb: Explicitly include correct DT includes

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that mer

usb: Explicitly include correct DT includes

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Acked-by: Herve Codina <[email protected]>
Signed-off-by: Rob Herring <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

USB: core: Fix docs warning caused by wireless_status feature

Fix wrongly named 'dev' parameter in doc block, should have been iface:
drivers/usb/core/message.c:1939: warning: Function parameter or

USB: core: Fix docs warning caused by wireless_status feature

Fix wrongly named 'dev' parameter in doc block, should have been iface:
drivers/usb/core/message.c:1939: warning: Function parameter or member 'iface' not described in 'usb_set_wireless_status'
drivers/usb/core/message.c:1939: warning: Excess function parameter 'dev' description in 'usb_set_wireless_status'

And fix missing struct member doc in kernel API, and reorder to
match struct:
include/linux/usb.h:270: warning: Function parameter or member 'wireless_status_work' not described in 'usb_interface'

Reported-by: Stephen Rothwell <[email protected]>
Link: https://lore.kernel.org/linux-next/[email protected]/T/#t
Fixes: 0a4db185f078 ("USB: core: Add API to change the wireless_status")
Signed-off-by: Bastien Nocera <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[bentiss: fix checkpatch warning]
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

USB: core: Add API to change the wireless_status

This adds the API that allows device specific drivers to tell user-space
about whether the wireless device is connected to its receiver dongle.

See

USB: core: Add API to change the wireless_status

This adds the API that allows device specific drivers to tell user-space
about whether the wireless device is connected to its receiver dongle.

See "USB: core: Add wireless_status sysfs attribute" for a detailed
explanation of what this attribute should be used for.

Signed-off-by: Bastien Nocera <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Alan Stern <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Benjamin Tissoires <[email protected]>

show more ...

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

The uevent() callback in struct device_type should not be modifying the
device that is passed into it, so mark it as a const * and propag

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

The uevent() callback in struct device_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.

Cc: Alan Stern <[email protected]>
Cc: Andreas Noever <[email protected]>
Cc: Andy Shevchenko <[email protected]>
Cc: Bard Liao <[email protected]>
Cc: Chaitanya Kulkarni <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: Dmitry Torokhov <[email protected]>
Cc: Frank Rowand <[email protected]>
Cc: Ira Weiny <[email protected]>
Cc: Jason Gunthorpe <[email protected]>
Cc: Jens Axboe <[email protected]>
Cc: Jilin Yuan <[email protected]>
Cc: Jiri Slaby <[email protected]>
Cc: Len Brown <[email protected]>
Cc: Mark Gross <[email protected]>
Cc: "Martin K. Petersen" <[email protected]>
Cc: "Matthew Wilcox (Oracle)" <[email protected]>
Cc: Maximilian Luz <[email protected]>
Cc: Michael Jamet <[email protected]>
Cc: Ming Lei <[email protected]>
Cc: Pierre-Louis Bossart <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Sakari Ailus <[email protected]>
Cc: Sanyog Kale <[email protected]>
Cc: Sean Young <[email protected]>
Cc: Stefan Richter <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Won Chung <[email protected]>
Cc: Yehezkel Bernat <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Acked-by: Mika Westerberg <[email protected]> # for Thunderbolt
Acked-by: Mauro Carvalho Chehab <[email protected]>
Acked-by: Alexandre Belloni <[email protected]>
Acked-by: Heikki Krogerus <[email protected]>
Acked-by: Wolfram Sang <[email protected]>
Acked-by: Vinod Koul <[email protected]>
Acked-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

USB: core: export usb_cache_string()

usb_cache_string() can also be useful for the drivers so export it.

Signed-off-by: Vincent Mailhol <[email protected]>
Acked-by: Greg Kroah-Hartman <gr

USB: core: export usb_cache_string()

usb_cache_string() can also be useful for the drivers so export it.

Signed-off-by: Vincent Mailhol <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
Signed-off-by: Marc Kleine-Budde <[email protected]>

show more ...

USB: core: Avoid WARNings for 0-length descriptor requests

The USB core has utility routines to retrieve various types of
descriptors. These routines will now provoke a WARN if they are asked
to re

USB: core: Avoid WARNings for 0-length descriptor requests

The USB core has utility routines to retrieve various types of
descriptors. These routines will now provoke a WARN if they are asked
to retrieve 0 bytes (USB "receive" requests must not have zero
length), so avert this by checking the size argument at the start.

CC: Johan Hovold <[email protected]>
Reported-and-tested-by: [email protected]
Reviewed-by: Johan Hovold <[email protected]>
Signed-off-by: Alan Stern <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

USB: core: drop pipe-type check from new control-message helpers

The new control-message helpers include a pipe-type check which is
almost completely redundant.

Control messages are generally sent

USB: core: drop pipe-type check from new control-message helpers

The new control-message helpers include a pipe-type check which is
almost completely redundant.

Control messages are generally sent to the default pipe which always
exists and is of the correct type since its endpoint representation is
created by USB core as part of enumeration for all devices.

There is currently only one instance of a driver in the tree which use
a control endpoint other than endpoint 0 (and it does not use the new
helpers).

Drivers should be testing for the existence of their resources at probe
rather than at runtime, but to catch drivers failing to do so USB core
already does a sanity check on URB submission and triggers a WARN().
Having the same sanity check done in the helper only suppresses the
warning without allowing us to find and fix the drivers.

Signed-off-by: Johan Hovold <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

USB: core: return -EREMOTEIO on short usb_control_msg_recv()

Return -EREMOTEIO instead of -EINVAL on short control transfers when
using the new usb_control_msg_recv() helper.

EINVAL is used to repo

USB: core: return -EREMOTEIO on short usb_control_msg_recv()

Return -EREMOTEIO instead of -EINVAL on short control transfers when
using the new usb_control_msg_recv() helper.

EINVAL is used to report invalid arguments (e.g. to the helper) and
should not be used for unrelated errors.

Many driver currently return -EIO on short control transfers but since
host-controller drivers already use -EREMOTEIO for short transfers
whenever the URB_SHORT_NOT_OK flag is set, let's use that here as well.

This also allows usb_control_msg_recv() to eventually use
URB_SHORT_NOT_OK without changing the return value again.

Signed-off-by: Johan Hovold <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

USB: core: drop short-transfer check from usb_control_msg_send()

A failure to send a complete control message is always an error so
there's no need to check for short transfers in usb_control_msg_se

USB: core: drop short-transfer check from usb_control_msg_send()

A failure to send a complete control message is always an error so
there's no need to check for short transfers in usb_control_msg_send().

Signed-off-by: Johan Hovold <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

usb: core: Replace in_interrupt() in comments

The usage of in_interrupt() in drivers is phased out for various reasons.

Various comments use !in_interrupt() to describe calling context for
function

usb: core: Replace in_interrupt() in comments

The usage of in_interrupt() in drivers is phased out for various reasons.

Various comments use !in_interrupt() to describe calling context for
functions which might sleep. That's wrong because the calling context has
to be preemptible task context, which is not what !in_interrupt()
describes.

Replace !in_interrupt() with more accurate plain text descriptions.

The comment for usb_hcd_poll_rh_status() is misleading as this function is
called from all kinds of contexts including preemptible task
context. Remove it as there is obviously no restriction.

Signed-off-by: Ahmed S. Darwish <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Acked-by: Alan Stern <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

USB: correct API of usb_control_msg_send/recv

They need to specify how memory is to be allocated,
as control messages need to work in contexts that require GFP_NOIO.

Signed-off-by: Oliver Neukum <o

USB: correct API of usb_control_msg_send/recv

They need to specify how memory is to be allocated,
as control messages need to work in contexts that require GFP_NOIO.

Signed-off-by: Oliver Neukum <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

USB: core: message.c: use usb_control_msg_send() in a few places

There are a few calls to usb_control_msg() that can be converted to use
usb_control_msg_send() instead, so do that in order to make t

USB: core: message.c: use usb_control_msg_send() in a few places

There are a few calls to usb_control_msg() that can be converted to use
usb_control_msg_send() instead, so do that in order to make the error
checking a bit simpler.

Cc: Alan Stern <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

USB: add usb_control_msg_send() and usb_control_msg_recv()

New core functions to make sending/receiving USB control messages easier
and saner.

In discussions, it turns out that the large majority o

USB: add usb_control_msg_send() and usb_control_msg_recv()

New core functions to make sending/receiving USB control messages easier
and saner.

In discussions, it turns out that the large majority of users of
usb_control_msg() do so in potentially incorrect ways. The most common
issue is where a "short" message is received, yet never detected
properly due to "incorrect" error handling.

Handle all of this in the USB core with two new functions to try to make
working with USB control messages simpler.

No more need for dynamic data, messages can be on the stack, and only
"complete" send/receive will work without causing an error.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

usb: don't inherity DMA properties for USB devices

As the comment in usb_alloc_dev correctly states, drivers can't use
the DMA API on usb device, and at least calling dma_set_mask on them
is highly

usb: don't inherity DMA properties for USB devices

As the comment in usb_alloc_dev correctly states, drivers can't use
the DMA API on usb device, and at least calling dma_set_mask on them
is highly dangerous. Unlike what the comment states upper level drivers
also can't really use the presence of a dma mask to check for DMA
support, as the dma_mask is set by default for most busses.

Setting the dma_mask comes from "[PATCH] usbcore dma updates (and doc)"
in BitKeeper times, as it seems like it was primarily for setting the
NETIF_F_HIGHDMA flag in USB drivers, something that has long been
fixed up since.

Setting the dma_pfn_offset comes from commit b44bbc46a8bb
("usb: core: setup dma_pfn_offset for USB devices and, interfaces"),
which worked around the fact that the scsi_calculate_bounce_limits
functions wasn't going through the proper driver interface to query
DMA information, but that function was removed in commit 21e07dba9fb1
("scsi: reduce use of block bounce buffers") years ago.

Signed-off-by: Christoph Hellwig <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>

show more ...

usb: Fix out of sync data toggle if a configured device is reconfigured

Userspace drivers that use a SetConfiguration() request to "lightweight"
reset an already configured usb device might cause da

usb: Fix out of sync data toggle if a configured device is reconfigured

Userspace drivers that use a SetConfiguration() request to "lightweight"
reset an already configured usb device might cause data toggles to get out
of sync between the device and host, and the device becomes unusable.

The xHCI host requires endpoints to be dropped and added back to reset the
toggle. If USB core notices the new configuration is the same as the
current active configuration it will avoid these extra steps by calling
usb_reset_configuration() instead of usb_set_configuration().

A SetConfiguration() request will reset the device side data toggles.
Make sure usb_reset_configuration() function also drops and adds back the
endpoints to ensure data toggles are in sync.

To avoid code duplication split the current usb_disable_device() function
and reuse the endpoint specific part.

Cc: stable <[email protected]>
Tested-by: Martin Thierer <[email protected]>
Signed-off-by: Mathias Nyman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

USB: core: Fix misleading driver bug report

The syzbot fuzzer found a race between URB submission to endpoint 0
and device reset. Namely, during the reset we call usb_ep0_reinit()
because the chara

USB: core: Fix misleading driver bug report

The syzbot fuzzer found a race between URB submission to endpoint 0
and device reset. Namely, during the reset we call usb_ep0_reinit()
because the characteristics of ep0 may have changed (if the reset
follows a firmware update, for example). While usb_ep0_reinit() is
running there is a brief period during which the pointers stored in
udev->ep_in[0] and udev->ep_out[0] are set to NULL, and if an URB is
submitted to ep0 during that period, usb_urb_ep_type_check() will
report it as a driver bug. In the absence of those pointers, the
routine thinks that the endpoint doesn't exist. The log message looks
like this:

------------[ cut here ]------------
usb 2-1: BOGUS urb xfer, pipe 2 != type 2
WARNING: CPU: 0 PID: 9241 at drivers/usb/core/urb.c:478
usb_submit_urb+0x1188/0x1460 drivers/usb/core/urb.c:478

Now, although submitting an URB while the device is being reset is a
questionable thing to do, it shouldn't count as a driver bug as severe
as submitting an URB for an endpoint that doesn't exist. Indeed,
endpoint 0 always exists, even while the device is in its unconfigured
state.

To prevent these misleading driver bug reports, this patch updates
usb_disable_endpoint() to avoid clearing the ep_in[] and ep_out[]
pointers when the endpoint being disabled is ep0. There's no danger
of leaving a stale pointer in place, because the usb_host_endpoint
structure being pointed to is stored permanently in udev->ep0; it
doesn't get deallocated until the entire usb_device structure does.

Reported-and-tested-by: [email protected]
Signed-off-by: Alan Stern <[email protected]>

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

USB: core: Fix free-while-in-use bug in the USB S-Glibrary

FuzzUSB (a variant of syzkaller) found a free-while-still-in-use bug
in the USB scatter-gather library:

BUG: KASAN: use-after-free in atom

USB: core: Fix free-while-in-use bug in the USB S-Glibrary

FuzzUSB (a variant of syzkaller) found a free-while-still-in-use bug
in the USB scatter-gather library:

BUG: KASAN: use-after-free in atomic_read
include/asm-generic/atomic-instrumented.h:26 [inline]
BUG: KASAN: use-after-free in usb_hcd_unlink_urb+0x5f/0x170
drivers/usb/core/hcd.c:1607
Read of size 4 at addr ffff888065379610 by task kworker/u4:1/27

CPU: 1 PID: 27 Comm: kworker/u4:1 Not tainted 5.5.11 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1ubuntu1 04/01/2014
Workqueue: scsi_tmf_2 scmd_eh_abort_handler
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xce/0x128 lib/dump_stack.c:118
print_address_description.constprop.4+0x21/0x3c0 mm/kasan/report.c:374
__kasan_report+0x153/0x1cb mm/kasan/report.c:506
kasan_report+0x12/0x20 mm/kasan/common.c:639
check_memory_region_inline mm/kasan/generic.c:185 [inline]
check_memory_region+0x152/0x1b0 mm/kasan/generic.c:192
__kasan_check_read+0x11/0x20 mm/kasan/common.c:95
atomic_read include/asm-generic/atomic-instrumented.h:26 [inline]
usb_hcd_unlink_urb+0x5f/0x170 drivers/usb/core/hcd.c:1607
usb_unlink_urb+0x72/0xb0 drivers/usb/core/urb.c:657
usb_sg_cancel+0x14e/0x290 drivers/usb/core/message.c:602
usb_stor_stop_transport+0x5e/0xa0 drivers/usb/storage/transport.c:937

This bug occurs when cancellation of the S-G transfer races with
transfer completion. When that happens, usb_sg_cancel() may continue
to access the transfer's URBs after usb_sg_wait() has freed them.

The bug is caused by the fact that usb_sg_cancel() does not take any
sort of reference to the transfer, and so there is nothing to prevent
the URBs from being deallocated while the routine is trying to use
them. The fix is to take such a reference by incrementing the
transfer's io->count field while the cancellation is in progres and
decrementing it afterward. The transfer's URBs are not deallocated
until io->complete is triggered, which happens when io->count reaches
zero.

Signed-off-by: Alan Stern <[email protected]>
Reported-and-tested-by: Kyungtae Kim <[email protected]>
CC: <[email protected]>

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

usb: core: Add ACPI support for USB interface devices

Currently on ACPI-enabled systems the USB interface device has no link to
the actual firmware node and thus drivers may not parse additional inf

usb: core: Add ACPI support for USB interface devices

Currently on ACPI-enabled systems the USB interface device has no link to
the actual firmware node and thus drivers may not parse additional information
given in the table. The new feature, proposed here, allows to pass properties
or other information to the drivers.

The ACPI companion of the device has to be set for USB interface devices
to achieve above. Use ACPI_COMPANION_SET macro to set this.

Note, OF already does link of_node and this is the same for ACPI case.

Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Rafael J. Wysocki <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

USB: CDC: fix sanity checks in CDC union parser

A few checks checked for the size of the pointer to a structure
instead of the structure itself. Copy & paste issue presumably.

Fixes: e4c6fb7794982

USB: CDC: fix sanity checks in CDC union parser

A few checks checked for the size of the pointer to a structure
instead of the structure itself. Copy & paste issue presumably.

Fixes: e4c6fb7794982 ("usbnet: move the CDC parser into USB core")
Cc: stable <[email protected]>
Reported-by: [email protected]
Signed-off-by: Oliver Neukum <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

USB: core: Fix unterminated string returned by usb_string()

Some drivers (such as the vub300 MMC driver) expect usb_string() to
return a properly NUL-terminated string, even when an error occurs.
(I

USB: core: Fix unterminated string returned by usb_string()

Some drivers (such as the vub300 MMC driver) expect usb_string() to
return a properly NUL-terminated string, even when an error occurs.
(In fact, vub300's probe routine doesn't bother to check the return
code from usb_string().) When the driver goes on to use an
unterminated string, it leads to kernel errors such as
stack-out-of-bounds, as found by the syzkaller USB fuzzer.

An out-of-range string index argument is not at all unlikely, given
that some devices don't provide string descriptors and therefore list
0 as the value for their string indexes. This patch makes
usb_string() return a properly terminated empty string along with the
-EINVAL error code when an out-of-range index is encountered.

And since a USB string index is a single-byte value, indexes >= 256
are just as invalid as values of 0 or below.

Signed-off-by: Alan Stern <[email protected]>
Reported-by: [email protected]
CC: <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

usb: core: skip interfaces disabled in devicetree

If an interface has an associated devicetree node with status disabled,
do not register the device. This is useful for boards with a built-in
multi

usb: core: skip interfaces disabled in devicetree

If an interface has an associated devicetree node with status disabled,
do not register the device. This is useful for boards with a built-in
multifunction USB device where some functions are broken or otherwise
undesired.

Signed-off-by: Mans Rullgard <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

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_000

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 <[email protected]>
Cc: stable <[email protected]> # after much soaking
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...