linux.git/drivers/usb/dwc3, branch v5.19

usb: dwc3-am62: remove unnecesary clk_put()

2022-06-29T19:04:55+00:00

The clk get by devm_clk_get() will be released in devres_release_all(),
so there is no need explicitly call clk_put(), or it will cause UAF.

Fixes: e8784c0aec03 ("drivers: usb: dwc3: Add AM62 USB wrapper driver")
Reported-by: Hulk Robot 
Signed-off-by: Yang Yingliang 
Link: https://lore.kernel.org/r/20220629094635.3116961-1-yangyingliang@huawei.com
Signed-off-by: Greg Kroah-Hartman

usb: dwc3: gadget: Fix event pending check

2022-06-29T19:04:54+00:00

The DWC3_EVENT_PENDING flag is used to protect against invalid call to
top-half interrupt handler, which can occur when there's a delay in
software detection of the interrupt line deassertion.

However, the clearing of this flag was done prior to unmasking the
interrupt line, creating opportunity where the top-half handler can
come. This breaks the serialization and creates a race between the
top-half and bottom-half handler, resulting in losing synchronization
between the controller and the driver when processing events.

To fix this, make sure the clearing of the DWC3_EVENT_PENDING is done at
the end of the bottom-half handler.

Fixes: d325a1de49d6 ("usb: dwc3: gadget: Prevent losing events in event cache")
Cc: stable@vger.kernel.org
Signed-off-by: Thinh Nguyen 
Link: https://lore.kernel.org/r/8670aaf1cf52e7d1e6df2a827af2d77263b93b75.1656380429.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman

USB: fixup for merge issue with "usb: dwc3: Don't switch OTG -> peripheral if extcon is present"

2022-06-10T09:19:42+00:00

Today's linux-next merge of the extcon tree got a conflict in:

  drivers/usb/dwc3/drd.c

between commit:

  0f0101719138 ("usb: dwc3: Don't switch OTG -> peripheral if extcon is present")

from the usb tree and commit:

  88490c7f43c4 ("extcon: Fix extcon_get_extcon_dev() error handling")

from the extcon tree.

I fixed it up (the former moved the code modified by the latter, so I
used the former version of this files and added the following merge fix
patch) and can carry the fix as necessary.

Signed-off-by: Stephen Rothwell 
Link: https://lore.kernel.org/r/20220426152739.62f6836e@canb.auug.org.au
Signed-off-by: Greg Kroah-Hartman

usb: dwc3: pci: Restore line lost in merge conflict resolution

2022-06-10T09:11:01+00:00

Commit 582ab24e096f ("usb: dwc3: pci: Set "linux,phy_charger_detect"
property on some Bay Trail boards") added a new swnode similar to the
existing ones for boards where the PHY handles charger detection.

Unfortunately, the "linux,sysdev_is_parent" property got lost in the
merge conflict resolution of commit ca9400ef7f67 ("Merge 5.17-rc6 into
usb-next"). Now dwc3_pci_intel_phy_charger_detect_properties is the
only swnode in dwc3-pci that is missing "linux,sysdev_is_parent".

It does not seem to cause any obvious functional issues, but it's
certainly unintended so restore the line to make the properties
consistent again.

Fixes: ca9400ef7f67 ("Merge 5.17-rc6 into usb-next")
Cc: stable@vger.kernel.org
Signed-off-by: Stephan Gerhold 
Link: https://lore.kernel.org/r/20220528170913.9240-1-stephan@gerhold.net
Signed-off-by: Greg Kroah-Hartman

usb: dwc3: gadget: Fix IN endpoint max packet size allocation

2022-06-10T09:10:43+00:00

The current logic to assign the max packet limit for IN endpoints attempts
to take the default HW value and apply the optimal endpoint settings based
on it.  However, if the default value reports a TxFIFO size large enough
for only one max packet, it will divide the value and assign a smaller ep
max packet limit.

For example, if the default TxFIFO size fits 1024B, current logic will
assign 1024/3 = 341B to ep max packet size.  If function drivers attempt to
request for an endpoint with a wMaxPacketSize of 1024B (SS BULK max packet
size) then it will fail, as the gadget is unable to find an endpoint which
can fit the requested size.

Functionally, if the TxFIFO has enough space to fit one max packet, it will
be sufficient, at least when initializing the endpoints.

Fixes: d94ea5319813 ("usb: dwc3: gadget: Properly set maxpacket limit")
Cc: stable 
Signed-off-by: Wesley Cheng 
Link: https://lore.kernel.org/r/20220523213948.22142-1-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman

usb: dwc3: core: Add error log when core soft reset failed

2022-05-19T16:15:18+00:00

DWC3 controller soft reset is important operation for USB functionality.
In case when it fails, currently there is no failure log. Hence add
error log when core soft reset failed.

Signed-off-by: Mayank Rana 
Link: https://lore.kernel.org/r/1652897572-14461-1-git-send-email-quic_mrana@quicinc.com
Signed-off-by: Greg Kroah-Hartman

usb: dwc3: gadget: Move null pinter check to proper place

2022-05-19T16:15:03+00:00

When dwc3_gadget_ep_cleanup_completed_requests() called to
dwc3_gadget_giveback() where the dwc3 lock is released, other thread is
able to execute. In this situation, usb_ep_disable() gets the chance to
clear endpoint descriptor pointer which leds to the null pointer
dereference problem. So needs to move the null pointer check to a proper
place.

Example call stack:

Thread#1:
dwc3_thread_interrupt()
  spin_lock
  -> dwc3_process_event_buf()
   -> dwc3_process_event_entry()
    -> dwc3_endpoint_interrupt()
     -> dwc3_gadget_endpoint_trbs_complete()
      -> dwc3_gadget_ep_cleanup_completed_requests()
       ...
       -> dwc3_giveback()
          spin_unlock
          Thread#2 executes

Thread#2:
configfs_composite_disconnect()
  -> __composite_disconnect()
   -> ffs_func_disable()
    -> ffs_func_set_alt()
     -> ffs_func_eps_disable()
      -> usb_ep_disable()
         wait for dwc3 spin_lock
         Thread#1 released lock
         clear endpoint.desc

Fixes: 26288448120b ("usb: dwc3: gadget: Fix null pointer exception")
Cc: stable 
Signed-off-by: Albert Wang 
Link: https://lore.kernel.org/r/20220518061315.3359198-1-albertccwang@google.com
Signed-off-by: Greg Kroah-Hartman

usb: dwc3: Fix ep0 handling when getting reset while doing control transfer

2022-05-19T16:14:16+00:00

According to the databook ep0 should be in setup phase during reset.
If host issues reset between control transfers, ep0 will be  in an
invalid state. Fix this by issuing stall and restart on ep0 if it
is not in setup phase.

Also SW needs to complete pending control transfer and setup core for
next setup stage as per data book. Hence check ep0 state during reset
interrupt handling and make sure active transfers on ep0 out/in
endpoint are stopped by queuing ENDXFER command for that endpoint and
restart ep0 out again to receive next setup packet.

Signed-off-by: Mayank Rana 
Link: https://lore.kernel.org/r/1651693001-29891-1-git-send-email-quic_mrana@quicinc.com
Signed-off-by: Greg Kroah-Hartman

USB / dwc3: Fix a checkpatch warning in core.c

2022-05-12T09:36:36+00:00

This patch fixes the following checkpatch.pl warning in core.c:
    WARNING: braces {} are not necessary for any arm of this statement

Signed-off-by: Kushagra Verma 
Link: https://lore.kernel.org/r/TYZPR01MB39354534E2F9EE4E022DDAFFF8C89@TYZPR01MB3935.apcprd01.prod.exchangelabs.com
Signed-off-by: Greg Kroah-Hartman

usb: dwc3: gadget: Delay issuing End Transfer

2022-05-05T20:03:24+00:00

If the controller hasn't DMA'ed the Setup data from its fifo, it won't
process the End Transfer command. Polling for the command completion may
block the driver from servicing the Setup phase and cause a timeout.
Previously we only check and delay issuing End Transfer in the case of
endpoint dequeue. Let's do that for all End Transfer scenarios.

Signed-off-by: Thinh Nguyen 
Link: https://lore.kernel.org/r/2fcf3b5d90068d549589a57a27a79f76c6769b04.1650593829.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman