linux.git/drivers/usb/core, branch v5.16

USB: NO_LPM quirk Lenovo USB-C to Ethernet Adapher(RTL8153-04)

2021-12-15T22:42:33+00:00

This device doesn't work well with LPM, losing connectivity intermittently.
Disable LPM to resolve the issue.

Reviewed-by: 
Signed-off-by: Jimmy Wang 
Cc: stable 
Link: https://lore.kernel.org/r/20211214012652.4898-1-wangjm221@gmail.com
Signed-off-by: Greg Kroah-Hartman

usb: core: config: using bit mask instead of individual bits

2021-12-12T12:06:39+00:00

Using standard USB_EP_MAXP_MULT_MASK instead of individual bits for
extracting multiple-transactions bits from wMaxPacketSize value.

Acked-by: Alan Stern 
Signed-off-by: Pavel Hofman 
Link: https://lore.kernel.org/r/20211210085219.16796-2-pavel.hofman@ivitera.com
Signed-off-by: Greg Kroah-Hartman

usb: core: config: fix validation of wMaxPacketValue entries

2021-12-12T12:06:35+00:00

The checks performed by commit aed9d65ac327 ("USB: validate
wMaxPacketValue entries in endpoint descriptors") require that initial
value of the maxp variable contains both maximum packet size bits
(10..0) and multiple-transactions bits (12..11). However, the existing
code assings only the maximum packet size bits. This patch assigns all
bits of wMaxPacketSize to the variable.

Fixes: aed9d65ac327 ("USB: validate wMaxPacketValue entries in endpoint descriptors")
Cc: stable 
Acked-by: Alan Stern 
Signed-off-by: Pavel Hofman 
Link: https://lore.kernel.org/r/20211210085219.16796-1-pavel.hofman@ivitera.com
Signed-off-by: Greg Kroah-Hartman

USB: NO_LPM quirk Lenovo Powered USB-C Travel Hub

2021-11-29T12:16:11+00:00

This is another branded 8153 device that doesn't work well with LPM:
r8152 2-2.1:1.0 enp0s13f0u2u1: Stop submitting intr, status -71

Disable LPM to resolve the issue.

Signed-off-by: Ole Ernst 
Signed-off-by: David S. Miller

usb: hub: Fix locking issues with address0_mutex

2021-11-23T13:05:28+00:00

Fix the circular lock dependency and unbalanced unlock of addess0_mutex
introduced when fixing an address0_mutex enumeration retry race in commit
ae6dc22d2d1 ("usb: hub: Fix usb enumeration issue due to address0 race")

Make sure locking order between port_dev->status_lock and address0_mutex
is correct, and that address0_mutex is not unlocked in hub_port_connect
"done:" codepath which may be reached without locking address0_mutex

Fixes: 6ae6dc22d2d1 ("usb: hub: Fix usb enumeration issue due to address0 race")
Cc: 
Reported-by: Marek Szyprowski 
Tested-by: Hans de Goede 
Tested-by: Marek Szyprowski 
Acked-by: Hans de Goede 
Signed-off-by: Mathias Nyman 
Link: https://lore.kernel.org/r/20211123101656.1113518-1-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

usb: hub: Fix usb enumeration issue due to address0 race

2021-11-17T14:04:52+00:00

xHC hardware can only have one slot in default state with address 0
waiting for a unique address at a time, otherwise "undefined behavior
may occur" according to xhci spec 5.4.3.4

The address0_mutex exists to prevent this across both xhci roothubs.

If hub_port_init() fails, it may unlock the mutex and exit with a xhci
slot in default state. If the other xhci roothub calls hub_port_init()
at this point we end up with two slots in default state.

Make sure the address0_mutex protects the slot default state across
hub_port_init() retries, until slot is addressed or disabled.

Note, one known minor case is not fixed by this patch.
If device needs to be reset during resume, but fails all hub_port_init()
retries in usb_reset_and_verify_device(), then it's possible the slot is
still left in default state when address0_mutex is unlocked.

Cc: 
Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel")
Signed-off-by: Mathias Nyman 
Link: https://lore.kernel.org/r/20211115221630.871204-1-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

Revert "usb: core: hcd: Add support for deferring roothub registration"

2021-11-05T07:41:02+00:00

This reverts commit 58877b0824da15698bd85a0a9dbfa8c354e6ecb7.

It has been reported to be causing problems in Arch and Fedora bug
reports.

Reported-by: Hans de Goede 
Link: https://bbs.archlinux.org/viewtopic.php?pid=2000956#p2000956
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2019542
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2019576
Link: https://lore.kernel.org/r/42bcbea6-5eb8-16c7-336a-2cb72e71bc36@redhat.com
Cc: Mathias Nyman 
Cc: Chris Chiu 
Cc: Alan Stern 
Cc: Kishon Vijay Abraham I 
Signed-off-by: Greg Kroah-Hartman

usb: core: config: Change sizeof(struct ...) to sizeof(*...)

2021-10-06T06:25:47+00:00

This fixes the following checkpatch.pl warnings:

drivers/usb/core/config.c:989: CHECK:ALLOC_SIZEOF_STRUCT: Prefer kzalloc(sizeof(*bos)...) over kzalloc(sizeof(struct usb_bos_descriptor)...)
drivers/usb/core/config.c:1010: CHECK:ALLOC_SIZEOF_STRUCT: Prefer kzalloc(sizeof(*dev->bos)...) over kzalloc(sizeof(struct usb_host_bos)...)

Signed-off-by: Robert Greener 
Link: https://lore.kernel.org/r/20211001151350.ijiexr3ebwvypmdd@shortbread
Signed-off-by: Greg Kroah-Hartman

Merge 5.15-rc3 into usb-next

2021-09-27T14:34:40+00:00

We need the USB fixes in here as well.

Signed-off-by: Greg Kroah-Hartman

usb: core: hcd: fix messages in usb_hcd_request_irqs()

2021-09-21T14:34:14+00:00

Two dev_info() calls in usb_hcd_request_irqs() mistreat the I/O port base
address, calling it just "io base" instead of "io port".

While fixing this, make indenataion of the argument lists more sane...

Signed-off-by: Sergey Shtylyov 
Link: https://lore.kernel.org/r/5d10014d-e58b-d081-ed7c-7424f649ce0b@omp.ru
Signed-off-by: Greg Kroah-Hartman