linux-dev/drivers/usb, branch linus/master

usb: gadget: f_fs: change ep->ep safe in ffs_epfile_io()

2022-06-10T12:45:38Z

In ffs_epfile_io(), when read/write data in blocking mode, it will wait the completion in interruptible mode, if task receive a signal, it will terminate the wait, at same time, if function unbind occurs, ffs_func_unbind() will kfree all eps, ffs_epfile_io() still try to dequeue request by dereferencing ep which may become invalid. Fix it by add ep spinlock and will not dereference ep if it is not valid. Cc: # 5.15 Reported-by: Michael Wu Tested-by: Michael Wu Reviewed-by: John Keeping Signed-off-by: Linyu Yuan Link: https://lore.kernel.org/r/1654863478-26228-3-git-send-email-quic_linyyuan@quicinc.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_fs: change ep->status safe in ffs_epfile_io()

2022-06-10T12:45:38Z

If a task read/write data in blocking mode, it will wait the completion in ffs_epfile_io(), if function unbind occurs, ffs_func_unbind() will kfree ffs ep, once the task wake up, it still dereference the ffs ep to obtain the request status. Fix it by moving the request status to io_data which is stack-safe. Cc: # 5.15 Reported-by: Michael Wu Tested-by: Michael Wu Reviewed-by: John Keeping Signed-off-by: Linyu Yuan Link: https://lore.kernel.org/r/1654863478-26228-2-git-send-email-quic_linyyuan@quicinc.com Signed-off-by: Greg Kroah-Hartman

xhci: Fix null pointer dereference in resume if xhci has only one roothub

2022-06-10T11:57:20Z

In the re-init path xhci_resume() passes 'hcd->primary_hcd' to hci_init(), however this field isn't initialized by __usb_create_hcd() for a HCD without secondary controller. xhci_resume() is called once per xHC device, not per hcd, so the extra checking for primary hcd can be removed. Fixes: e0fe986972f5 ("usb: host: xhci-plat: prepare operation w/o shared hcd") Reported-by: Matthias Kaehlcke Tested-by: Matthias Kaehlcke Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20220610115338.863152-2-mathias.nyman@linux.intel.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:42Z

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: cdnsp: Fixed setting last_trb incorrectly

2022-06-10T09:15:23Z

When ZLP occurs in bulk transmission, currently cdnsp will set last_trb for the last two TRBs, it will trigger an error "ERROR Transfer event TRB DMA ptr not part of current TD ...". Fixes: e913aada0683 ("usb: cdnsp: Fixed issue with ZLP") Cc: stable Acked-by: Pawel Laszczak Signed-off-by: Jing Leng Link: https://lore.kernel.org/r/20220609021134.1606-1-3090101217@zju.edu.cn Signed-off-by: Greg Kroah-Hartman

usb: gadget: u_ether: fix regression in setting fixed MAC address

2022-06-10T09:12:53Z

In systemd systems setting a fixed MAC address through the "dev_addr" module argument fails systematically. When checking the MAC address after the interface is created it always has the same but different MAC address to the one supplied as argument. This is partially caused by systemd which by default will set an internally generated permanent MAC address for interfaces that are marked as having a randomly generated address. Commit 890d5b40908bfd1a ("usb: gadget: u_ether: fix race in setting MAC address in setup phase") didn't take into account the fact that the interface must be marked as having a set MAC address when it's set as module argument. Fixed by marking the interface with NET_ADDR_SET when the "dev_addr" module argument is supplied. Fixes: 890d5b40908bfd1a ("usb: gadget: u_ether: fix race in setting MAC address in setup phase") Cc: stable@vger.kernel.org Signed-off-by: Marian Postevca Link: https://lore.kernel.org/r/20220603153459.32722-1-posteuca@mutex.one Signed-off-by: Greg Kroah-Hartman

usb: gadget: lpc32xx_udc: Fix refcount leak in lpc32xx_udc_probe

2022-06-10T09:12:39Z

of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() will check NULL pointer. Fixes: 24a28e428351 ("USB: gadget driver for LPC32xx") Cc: stable Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220603140246.64529-1-linmq006@gmail.com Signed-off-by: Greg Kroah-Hartman

usb: dwc2: Fix memory leak in dwc2_hcd_init

2022-06-10T09:12:20Z

usb_create_hcd will alloc memory for hcd, and we should call usb_put_hcd to free it when platform_get_resource() fails to prevent memory leak. goto error2 label instead error1 to fix this. Fixes: 856e6e8e0f93 ("usb: dwc2: check return value after calling platform_get_resource()") Cc: stable Acked-by: Minas Harutyunyan Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220530085413.44068-1-linmq006@gmail.com Signed-off-by: Greg Kroah-Hartman

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

2022-06-10T09:11:01Z

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:43Z

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