linux-toradex.git/drivers/usb, branch v5.10-rc2

Merge tag 'usb-v5.10-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb into usb-linus

2020-10-30T10:46:49+00:00

Peter writes:

4 bug fixes for Cadence 3 driver.
The biggest fix is changing endpoint configuration method to
avoid FIFO overflow at multiple endpoints situation.

* tag 'usb-v5.10-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb:
  usb: cdns3: gadget: own the lock wrongly at the suspend routine
  usb: cdns3: Fix on-chip memory overflow issue
  usb: cdns3: gadget: suspicious implicit sign extension
  usb: cdns3: Variable 'length' set but not used

usb: cdns3: gadget: own the lock wrongly at the suspend routine

2020-10-30T03:40:54+00:00

When the system goes to suspend, if the controller is at device mode with
cable connecting to host, the call stack is: cdns3_suspend->
cdns3_gadget_suspend -> cdns3_disconnect_gadget, after cdns3_disconnect_gadget
is called, it owns lock wrongly, it causes the system being deadlock after
resume due to at cdns3_device_thread_irq_handler, it tries to get the lock,
but can't get it forever.

To fix it, we delete the unlock-lock operations at cdns3_disconnect_gadget,
and do it at the caller.

Fixes: b1234e3b3b26 ("usb: cdns3: add runtime PM support")
Acked-by: Pawel Laszczak 
Signed-off-by: Peter Chen

usb: cdns3: Fix on-chip memory overflow issue

2020-10-30T03:40:54+00:00

Patch fixes issue caused setting On-chip memory overflow bit in usb_sts
register. The issue occurred because EP_CFG register was set twice
before USB_STS.CFGSTS was set. Every write operation on EP_CFG.BUFFERING
causes that controller increases internal counter holding the number
of reserved on-chip buffers. First time this register was updated in
function cdns3_ep_config before delegating SET_CONFIGURATION request
to class driver and again it was updated when class wanted to enable
endpoint.  This patch fixes this issue by configuring endpoints
enabled by class driver in cdns3_gadget_ep_enable and others just
before status stage.

Cc: stable@vger.kernel.org#v5.8+
Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
Reported-and-tested-by: Peter Chen 
Signed-off-by: Pawel Laszczak 
Signed-off-by: Peter Chen

usb: cdns3: gadget: suspicious implicit sign extension

2020-10-29T10:01:47+00:00

The code:
trb->length = cpu_to_le32(TRB_BURST_LEN(priv_ep->trb_burst_size)
	       	| TRB_LEN(length));

TRB_BURST_LEN(priv_ep->trb_burst_size) may be overflow for int 32 if
priv_ep->trb_burst_size is equal or larger than 0x80;

Below is the Coverity warning:
sign_extension: Suspicious implicit sign extension: priv_ep->trb_burst_size
with type u8 (8 bits, unsigned) is promoted in priv_ep->trb_burst_size << 24
to type int (32 bits, signed), then sign-extended to type unsigned long
(64 bits, unsigned). If priv_ep->trb_burst_size << 24 is greater than 0x7FFFFFFF,
the upper bits of the result will all be 1.

To fix it, it needs to add an explicit cast to unsigned int type for ((p) << 24).

Reviewed-by: Jun Li 
Signed-off-by: Peter Chen

xhci: Don't create stream debugfs files with spinlock held.

2020-10-29T07:29:21+00:00

Creating debugfs files while loding the spin_lock_irqsave(xhci->lock)
creates a lock dependecy that could possibly deadlock.

Lockdep warns:

=====================================================
WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
5.10.0-rc1pdx86+ #8 Not tainted
-----------------------------------------------------
systemd-udevd/386 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
ffffffffb1a94038 (pin_fs_lock){+.+.}-{2:2}, at: simple_pin_fs+0x22/0xa0

and this task is already holding:
ffff9e7b87fbc430 (&xhci->lock){-.-.}-{2:2}, at: xhci_alloc_streams+0x5f9/0x810
which would create a new lock dependency:
(&xhci->lock){-.-.}-{2:2} -> (pin_fs_lock){+.+.}-{2:2}

Create the files a bit later after lock is released.

Fixes: 673d74683627 ("usb: xhci: add debugfs support for ep with stream")
CC: Li Jun 
Reported-by: Hans de Goede 
Reported-by: Mike Galbraith 
Tested-by: Hans de Goede 
Signed-off-by: Mathias Nyman 
Link: https://lore.kernel.org/r/20201028203124.375344-4-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

usb: xhci: Workaround for S3 issue on AMD SNPS 3.0 xHC

2020-10-29T07:29:16+00:00

On some platform of AMD, S3 fails with HCE and SRE errors. To fix this,
need to disable a bit which is enable in sparse controller.

Cc: stable@vger.kernel.org #v4.19+
Signed-off-by: Sanket Goswami 
Signed-off-by: Sandeep Singh 
Signed-off-by: Mathias Nyman 
Link: https://lore.kernel.org/r/20201028203124.375344-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

xhci: Fix sizeof() mismatch

2020-10-29T07:29:12+00:00

An incorrect sizeof() is being used, sizeof(rhub->ports) is not
correct, it should be sizeof(*rhub->ports).  This bug did not
cause any issues because it just so happens the sizes are the same.

Fixes: bcaa9d5c5900 ("xhci: Create new structures to store xhci port information")
Signed-off-by: Colin Ian King 
Signed-off-by: Mathias Nyman 
Link: https://lore.kernel.org/r/20201028203124.375344-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

usb: typec: stusb160x: fix signedness comparison issue with enum variables

2020-10-29T07:26:08+00:00

chip->port_type and chip->pwr_opmode are enums and when GCC considers them
as unsigned, the conditions are never met.
This patch takes advantage of the ret variable and fixes the following
warnings:
drivers/usb/typec/stusb160x.c:548 stusb160x_get_fw_caps() warn: unsigned 'chip->port_type' is never less than zero.
drivers/usb/typec/stusb160x.c:570 stusb160x_get_fw_caps() warn: unsigned 'chip->pwr_opmode' is never less than zero.

Fixes: da0cb6310094 ("usb: typec: add support for STUSB160x Type-C controller family")
Reported-by: kernel test robot 
Signed-off-by: Amelie Delaunay 
Link: https://lore.kernel.org/r/20201028163309.12878-1-amelie.delaunay@st.com
Signed-off-by: Greg Kroah-Hartman

usb: typec: add missing MODULE_DEVICE_TABLE() to stusb160x

2020-10-29T07:26:08+00:00

When stusb160x driver is built as a module, no modalias information is
available, and it prevents the module to be loaded by udev.
Add MODULE_DEVICE_TABLE() to fix this issue.

Fixes: da0cb6310094 ("usb: typec: add support for STUSB160x Type-C controller family")
Signed-off-by: Amelie Delaunay 
Link: https://lore.kernel.org/r/20201028151703.31195-1-amelie.delaunay@st.com
Signed-off-by: Greg Kroah-Hartman

USB: apple-mfi-fastcharge: don't probe unhandled devices

2020-10-28T12:25:01+00:00

From: Bastien Nocera 

Contrary to the comment above the id table, we didn't implement a match
function. This meant that every single Apple device that was already
plugged in to the computer would have its device driver reprobed
when the apple-mfi-fastcharge driver was loaded, eg. the SD card reader
could be reprobed when the apple-mfi-fastcharge after pivoting root
during boot up and the module became available.

Make sure that the driver probe isn't being run for unsupported
devices by adding a match function that checks the product ID, in
addition to the id_table checking the vendor ID.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1878347
Link: https://lore.kernel.org/linux-usb/CAE3RAxt0WhBEz8zkHrVO5RiyEOasayy1QUAjsv-pB0fAbY1GSw@mail.gmail.com/
Fixes: 249fa8217b84 ("USB: Add driver to control USB fast charge for iOS devices")
Cc:  # 5.8
Cc: Greg Kroah-Hartman 
Cc: Alan Stern 
[m.v.b: Add Link and Reported-by tags to the commit message]
Reported-by: Pany 
Tested-by: Pan (Pany) YUAN 
Tested-by: Bastien Nocera 
Signed-off-by: Bastien Nocera 
Signed-off-by: M. Vefa Bicakci 
Link: https://lore.kernel.org/r/20201022135521.375211-3-m.v.b@runbox.com
Signed-off-by: Greg Kroah-Hartman