linux-dev/drivers/usb/gadget/udc, branch master

usb: bdc: change state when port disconnected

2022-10-22T10:51:53Z

When port is connected and then disconnected, the state stays as configured. Which is incorrect as the port is no longer configured, but in a not attached state. Signed-off-by: Justin Chen Acked-by: Florian Fainelli Fixes: efed421a94e6 ("usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC") Cc: stable Link: https://lore.kernel.org/r/1664997235-18198-1-git-send-email-justinpopo6@gmail.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: aspeed: Fix probe regression

2022-10-22T10:38:43Z

Since commit fc274c1e9973 ("USB: gadget: Add a new bus for gadgets"), the gadget devices are proper driver core devices, which caused each device to request pinmux settings: aspeed_vhub 1e6a0000.usb-vhub: Initialized virtual hub in USB2 mode aspeed-g5-pinctrl 1e6e2080.pinctrl: pin A7 already requested by 1e6a0000.usb-vhub; cannot claim for gadget.0 aspeed-g5-pinctrl 1e6e2080.pinctrl: pin-232 (gadget.0) status -22 aspeed-g5-pinctrl 1e6e2080.pinctrl: could not request pin 232 (A7) from group USB2AD on device aspeed-g5-pinctrl g_mass_storage gadget.0: Error applying setting, reverse things back The vhub driver has already claimed the pins, so prevent the gadgets from requesting them too by setting the magic of_node_reused flag. This causes the driver core to skip the mux request. Reported-by: Zev Weiss Reported-by: Jae Hyun Yoo Fixes: fc274c1e9973 ("USB: gadget: Add a new bus for gadgets") Cc: stable@vger.kernel.org Signed-off-by: Joel Stanley Tested-by: Zev Weiss Tested-by: Jae Hyun Yoo Link: https://lore.kernel.org/r/20221017053006.358520-1-joel@jms.id.au Signed-off-by: Greg Kroah-Hartman

USB: omap_udc: Fix spelling mistake: "tranceiver_ctrl" -> "transceiver_ctrl"

2022-09-30T11:55:36Z

There is a spelling mistake in the control name. Fix it. Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20220928221140.67495-1-colin.i.king@gmail.com Signed-off-by: Greg Kroah-Hartman

USB/ARM: Switch S3C2410 UDC to GPIO descriptors

2022-09-07T14:23:54Z

This converts the S3C2410 UDC USB device controller to use GPIO descriptor tables and modern GPIO. Cc: Krzysztof Kozlowski Cc: Alim Akhtar Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Acked-by: Krzysztof Kozlowski Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20220901081649.564348-1-linus.walleij@linaro.org Signed-off-by: Greg Kroah-Hartman

usb: gadget: udc: at91: switch to using fwnode_gpiod_get_index()

2022-09-05T11:09:13Z

I would like to stop exporting OF-specific gpiod_get_from_of_node() so that gpiolib can be cleaned a bit, so let's switch to the generic fwnode property API. Signed-off-by: Dmitry Torokhov Link: https://lore.kernel.org/r/20220903-gpiod_get_from_of_node-remove-v1-5-b29adfb27a6c@gmail.com Signed-off-by: Greg Kroah-Hartman

Merge 6.0-rc4 into usb-next

2022-09-05T06:03:23Z

We need the USB fixes in here and this resolves the merge issue in: drivers/usb/dwc3/gadget.c Reported-by: Stephen Rothwell Signed-off-by: Greg Kroah-Hartman

Revert "usb: gadget: udc-xilinx: replace memcpy with memcpy_toio"

2022-09-02T07:10:08Z

This reverts commit 8cb339f1c1f04baede9d54c1e40ac96247a6393b as it throws up a bunch of sparse warnings as reported by the kernel test robot. Reported-by: kernel test robot Link: https://lore.kernel.org/r/202209020044.CX2PfZzM-lkp@intel.com Fixes: 8cb339f1c1f0 ("usb: gadget: udc-xilinx: replace memcpy with memcpy_toio") Cc: stable@vger.kernel.org Cc: Linus Walleij Cc: Piyush Mehta Signed-off-by: Greg Kroah-Hartman

usb: gadget: at91_udc: Fix comments typo

2022-08-31T07:07:52Z

Delete the rebundant word "also" in comments. Signed-off-by: Shaomin Deng Link: https://lore.kernel.org/r/20220827153313.5754-1-dengshaomin@cdjrlc.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: net2272: Remove the initialization of statics to 0

2022-08-31T07:07:52Z

It is always unnecessary to initialise statics to 0. Signed-off-by: Shaomin Deng Link: https://lore.kernel.org/r/20220827153009.4768-1-dengshaomin@cdjrlc.com Signed-off-by: Greg Kroah-Hartman

USB: gadget: Fix obscure lockdep violation for udc_mutex

2022-08-30T13:31:55Z

A recent commit expanding the scope of the udc_lock mutex in the gadget core managed to cause an obscure and slightly bizarre lockdep violation. In abbreviated form: ====================================================== WARNING: possible circular locking dependency detected 5.19.0-rc7+ #12510 Not tainted ------------------------------------------------------ udevadm/312 is trying to acquire lock: ffff80000aae1058 (udc_lock){+.+.}-{3:3}, at: usb_udc_uevent+0x54/0xe0 but task is already holding lock: ffff000002277548 (kn->active#4){++++}-{0:0}, at: kernfs_seq_start+0x34/0xe0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kn->active#4){++++}-{0:0}: lock_acquire+0x68/0x84 __kernfs_remove+0x268/0x380 kernfs_remove_by_name_ns+0x58/0xac sysfs_remove_file_ns+0x18/0x24 device_del+0x15c/0x440 -> #2 (device_links_lock){+.+.}-{3:3}: lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 device_link_remove+0x3c/0xa0 _regulator_put.part.0+0x168/0x190 regulator_put+0x3c/0x54 devm_regulator_release+0x14/0x20 -> #1 (regulator_list_mutex){+.+.}-{3:3}: lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 regulator_lock_dependent+0x54/0x284 regulator_enable+0x34/0x80 phy_power_on+0x24/0x130 __dwc2_lowlevel_hw_enable+0x100/0x130 dwc2_lowlevel_hw_enable+0x18/0x40 dwc2_hsotg_udc_start+0x6c/0x2f0 gadget_bind_driver+0x124/0x1f4 -> #0 (udc_lock){+.+.}-{3:3}: __lock_acquire+0x1298/0x20cc lock_acquire.part.0+0xe0/0x230 lock_acquire+0x68/0x84 __mutex_lock+0x9c/0x430 mutex_lock_nested+0x38/0x64 usb_udc_uevent+0x54/0xe0 Evidently this was caused by the scope of udc_mutex being too large. The mutex is only meant to protect udc->driver along with a few other things. As far as I can tell, there's no reason for the mutex to be held while the gadget core calls a gadget driver's ->bind or ->unbind routine, or while a UDC is being started or stopped. (This accounts for link #1 in the chain above, where the mutex is held while the dwc2_hsotg_udc is started as part of driver probing.) Gadget drivers' ->disconnect callbacks are problematic. Even though usb_gadget_disconnect() will now acquire the udc_mutex, there's a window in usb_gadget_bind_driver() between the times when the mutex is released and the ->bind callback is invoked. If a disconnect occurred during that window, we could call the driver's ->disconnect routine before its ->bind routine. To prevent this from happening, it will be necessary to prevent a UDC from connecting while it has no gadget driver. This should be done already but it doesn't seem to be; currently usb_gadget_connect() has no check for this. Such a check will have to be added later. Some degree of mutual exclusion is required in soft_connect_store(), which can dereference udc->driver at arbitrary times since it is a sysfs callback. The solution here is to acquire the gadget's device lock rather than the udc_mutex. Since the driver core guarantees that the device lock is always held during driver binding and unbinding, this will make the accesses in soft_connect_store() mutually exclusive with any changes to udc->driver. Lastly, it turns out there is one place which should hold the udc_mutex but currently does not: The function_show() routine needs protection while it dereferences udc->driver. The missing lock and unlock calls are added. Link: https://lore.kernel.org/all/b2ba4245-9917-e399-94c8-03a383e7070e@samsung.com/ Fixes: 2191c00855b0 ("USB: gadget: Fix use-after-free Read in usb_udc_uevent()") Cc: Felipe Balbi Cc: stable@vger.kernel.org Reported-by: Marek Szyprowski Tested-by: Marek Szyprowski Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/YwkfhdxA/I2nOcK7@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman