blaster4385/linux-IllusionX/drivers/usb, branch v6.12.10

usb: typec: fix pm usage counter imbalance in ucsi_ccg_sync_control()

2025-01-17T12:40:55Z

commit b0e525d7a22ea350e75e2aec22e47fcfafa4cacd upstream. The error handling for the case `con_index == 0` should involve dropping the pm usage counter, as ucsi_ccg_sync_control() gets it at the beginning. Fix it. Cc: stable Fixes: e56aac6e5a25 ("usb: typec: fix potential array underflow in ucsi_ccg_sync_control()") Signed-off-by: GONG Ruiqi Reviewed-by: Dan Carpenter Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20250107015750.2778646-1-gongruiqi1@huawei.com Signed-off-by: Greg Kroah-Hartman

usb: host: xhci-plat: set skip_phy_initialization if software node has XHCI_SKIP_PHY_INIT property

2025-01-17T12:40:55Z

commit e19852d0bfecbc80976b1423cf2af87ca514a58c upstream. The source of quirk XHCI_SKIP_PHY_INIT comes from xhci_plat_priv.quirks or software node property. This will set skip_phy_initialization if software node also has XHCI_SKIP_PHY_INIT property. Fixes: a6cd2b3fa894 ("usb: host: xhci-plat: Parse xhci-missing_cas_quirk and apply quirk") Cc: stable Signed-off-by: Xu Yang Link: https://lore.kernel.org/r/20241209111423.4085548-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: configfs: Ignore trailing LF for user strings to cdev

2025-01-17T12:40:55Z

commit 9466545720e231fc02acd69b5f4e9138e09a26f6 upstream. Since commit c033563220e0f7a8 ("usb: gadget: configfs: Attach arbitrary strings to cdev") a user can provide extra string descriptors to a USB gadget via configfs. For "manufacturer", "product", "serialnumber", setting the string via configfs ignores a trailing LF. For the arbitrary strings the LF was not ignored. This patch ignores a trailing LF to make this consistent with the existing behavior for "manufacturer", ... string descriptors. Fixes: c033563220e0 ("usb: gadget: configfs: Attach arbitrary strings to cdev") Cc: stable Signed-off-by: Ingo Rohloff Link: https://lore.kernel.org/r/20241212154114.29295-1-ingo.rohloff@lauterbach.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_fs: Remove WARN_ON in functionfs_bind

2025-01-17T12:40:55Z

commit dfc51e48bca475bbee984e90f33fdc537ce09699 upstream. This commit addresses an issue related to below kernel panic where panic_on_warn is enabled. It is caused by the unnecessary use of WARN_ON in functionsfs_bind, which easily leads to the following scenarios. 1.adb_write in adbd 2. UDC write via configfs ================= ===================== ->usb_ffs_open_thread() ->UDC write ->open_functionfs() ->configfs_write_iter() ->adb_open() ->gadget_dev_desc_UDC_store() ->adb_write() ->usb_gadget_register_driver_owner ->driver_register() ->StartMonitor() ->bus_add_driver() ->adb_read() ->gadget_bind_driver() ->configfs_composite_bind() ->usb_add_function() ->open_functionfs() ->ffs_func_bind() ->adb_open() ->functionfs_bind() state !=FFS_ACTIVE> The adb_open, adb_read, and adb_write operations are invoked from the daemon, but trying to bind the function is a process that is invoked by UDC write through configfs, which opens up the possibility of a race condition between the two paths. In this race scenario, the kernel panic occurs due to the WARN_ON from functionfs_bind when panic_on_warn is enabled. This commit fixes the kernel panic by removing the unnecessary WARN_ON. Kernel panic - not syncing: kernel: panic_on_warn set ... [ 14.542395] Call trace: [ 14.542464] ffs_func_bind+0x1c8/0x14a8 [ 14.542468] usb_add_function+0xcc/0x1f0 [ 14.542473] configfs_composite_bind+0x468/0x588 [ 14.542478] gadget_bind_driver+0x108/0x27c [ 14.542483] really_probe+0x190/0x374 [ 14.542488] __driver_probe_device+0xa0/0x12c [ 14.542492] driver_probe_device+0x3c/0x220 [ 14.542498] __driver_attach+0x11c/0x1fc [ 14.542502] bus_for_each_dev+0x104/0x160 [ 14.542506] driver_attach+0x24/0x34 [ 14.542510] bus_add_driver+0x154/0x270 [ 14.542514] driver_register+0x68/0x104 [ 14.542518] usb_gadget_register_driver_owner+0x48/0xf4 [ 14.542523] gadget_dev_desc_UDC_store+0xf8/0x144 [ 14.542526] configfs_write_iter+0xf0/0x138 Fixes: ddf8abd25994 ("USB: f_fs: the FunctionFS driver") Cc: stable Signed-off-by: Akash M Link: https://lore.kernel.org/r/20241219125221.1679-1-akash.m5@samsung.com Signed-off-by: Greg Kroah-Hartman

usb: typec: tcpm/tcpci_maxim: fix error code in max_contaminant_read_resistance_kohm()

2025-01-17T12:40:55Z

commit b9711ff7cde0cfbcdd44cb1fac55b6eec496e690 upstream. If max_contaminant_read_adc_mv() fails, then return the error code. Don't return zero. Fixes: 02b332a06397 ("usb: typec: maxim_contaminant: Implement check_contaminant callback") Cc: stable Signed-off-by: Dan Carpenter Reviewed-by: André Draszik Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/f1bf3768-419e-40dd-989c-f7f455d6c824@stanley.mountain Signed-off-by: Greg Kroah-Hartman

usb: gadget: f_uac2: Fix incorrect setting of bNumEndpoints

2025-01-17T12:40:55Z

commit 057bd54dfcf68b1f67e6dfc32a47a72e12198495 upstream. Currently afunc_bind sets std_ac_if_desc.bNumEndpoints to 1 if controls (mute/volume) are enabled. During next afunc_bind call, bNumEndpoints would be unchanged and incorrectly set to 1 even if the controls aren't enabled. Fix this by resetting the value of bNumEndpoints to 0 on every afunc_bind call. Fixes: eaf6cbe09920 ("usb: gadget: f_uac2: add volume and mute support") Cc: stable Signed-off-by: Prashanth K Link: https://lore.kernel.org/r/20241211115915.159864-1-quic_prashk@quicinc.com Signed-off-by: Greg Kroah-Hartman

usb: typec: tcpci: fix NULL pointer issue on shared irq case

2025-01-17T12:40:55Z

commit 862a9c0f68487fd6ced15622d9cdcec48f8b5aaa upstream. The tcpci_irq() may meet below NULL pointer dereference issue: [ 2.641851] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 [ 2.641951] status 0x1, 0x37f [ 2.650659] Mem abort info: [ 2.656490] ESR = 0x0000000096000004 [ 2.660230] EC = 0x25: DABT (current EL), IL = 32 bits [ 2.665532] SET = 0, FnV = 0 [ 2.668579] EA = 0, S1PTW = 0 [ 2.671715] FSC = 0x04: level 0 translation fault [ 2.676584] Data abort info: [ 2.679459] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 2.684936] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 2.689980] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 2.695284] [0000000000000010] user address but active_mm is swapper [ 2.701632] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 2.707883] Modules linked in: [ 2.710936] CPU: 1 UID: 0 PID: 87 Comm: irq/111-2-0051 Not tainted 6.12.0-rc6-06316-g7f63786ad3d1-dirty #4 [ 2.720570] Hardware name: NXP i.MX93 11X11 EVK board (DT) [ 2.726040] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.732989] pc : tcpci_irq+0x38/0x318 [ 2.736647] lr : _tcpci_irq+0x14/0x20 [ 2.740295] sp : ffff80008324bd30 [ 2.743597] x29: ffff80008324bd70 x28: ffff800080107894 x27: ffff800082198f70 [ 2.750721] x26: ffff0000050e6680 x25: ffff000004d172ac x24: ffff0000050f0000 [ 2.757845] x23: ffff000004d17200 x22: 0000000000000001 x21: ffff0000050f0000 [ 2.764969] x20: ffff000004d17200 x19: 0000000000000000 x18: 0000000000000001 [ 2.772093] x17: 0000000000000000 x16: ffff80008183d8a0 x15: ffff00007fbab040 [ 2.779217] x14: ffff00007fb918c0 x13: 0000000000000000 x12: 000000000000017a [ 2.786341] x11: 0000000000000001 x10: 0000000000000a90 x9 : ffff80008324bd00 [ 2.793465] x8 : ffff0000050f0af0 x7 : ffff00007fbaa840 x6 : 0000000000000031 [ 2.800589] x5 : 000000000000017a x4 : 0000000000000002 x3 : 0000000000000002 [ 2.807713] x2 : ffff80008324bd3a x1 : 0000000000000010 x0 : 0000000000000000 [ 2.814838] Call trace: [ 2.817273] tcpci_irq+0x38/0x318 [ 2.820583] _tcpci_irq+0x14/0x20 [ 2.823885] irq_thread_fn+0x2c/0xa8 [ 2.827456] irq_thread+0x16c/0x2f4 [ 2.830940] kthread+0x110/0x114 [ 2.834164] ret_from_fork+0x10/0x20 [ 2.837738] Code: f9426420 f9001fe0 d2800000 52800201 (f9400a60) This may happen on shared irq case. Such as two Type-C ports share one irq. After the first port finished tcpci_register_port(), it may trigger interrupt. However, if the interrupt comes by chance the 2nd port finishes devm_request_threaded_irq(), the 2nd port interrupt handler will run at first. Then the above issue happens due to tcpci is still a NULL pointer in tcpci_irq() when dereference to regmap. devm_request_threaded_irq() <-- port1 irq comes disable_irq(client->irq); tcpci_register_port() This will restore the logic to the state before commit (77e85107a771 "usb: typec: tcpci: support edge irq"). However, moving tcpci_register_port() earlier creates a problem when use edge irq because tcpci_init() will be called before devm_request_threaded_irq(). The tcpci_init() writes the ALERT_MASK to the hardware to tell it to start generating interrupts but we're not ready to deal with them yet, then the ALERT events may be missed and ALERT line will not recover to high level forever. To avoid the issue, this will also set ALERT_MASK register after devm_request_threaded_irq() return. Fixes: 77e85107a771 ("usb: typec: tcpci: support edge irq") Cc: stable Tested-by: Emanuele Ghidoli Signed-off-by: Xu Yang Reviewed-by: Francesco Dolcini Reviewed-by: Heikki Krogerus Reviewed-by: Dan Carpenter Link: https://lore.kernel.org/r/20241218095328.2604607-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman

usb: chipidea: ci_hdrc_imx: decrement device's refcount in .remove() and in the error path of .probe()

2025-01-17T12:40:54Z

commit 74adad500346fb07d69af2c79acbff4adb061134 upstream. Current implementation of ci_hdrc_imx_driver does not decrement the refcount of the device obtained in usbmisc_get_init_data(). Add a put_device() call in .remove() and in .probe() before returning an error. This bug was found by an experimental static analysis tool that I am developing. Cc: stable Fixes: f40017e0f332 ("chipidea: usbmisc_imx: Add USB support for VF610 SoCs") Signed-off-by: Joe Hattori Acked-by: Peter Chen Link: https://lore.kernel.org/r/20241216015539.352579-1-joe@pf.is.s.u-tokyo.ac.jp Signed-off-by: Greg Kroah-Hartman

usb: gadget: midi2: Reverse-select at the right place

2025-01-17T12:40:54Z

commit 6f660ffce7c938f2a5d8473c0e0b45e4fb25ef7f upstream. We should do reverse selection of other components from CONFIG_USB_F_MIDI2 which is tristate, instead of CONFIG_USB_CONFIGFS_F_MIDI2 which is bool, for satisfying subtle module dependencies. Fixes: 8b645922b223 ("usb: gadget: Add support for USB MIDI 2.0 function driver") Cc: stable Signed-off-by: Takashi Iwai Link: https://lore.kernel.org/r/20250101131124.27599-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman

usb: fix reference leak in usb_new_device()

2025-01-17T12:40:54Z

commit 0df11fa8cee5a9cf8753d4e2672bb3667138c652 upstream. When device_add(&udev->dev) succeeds and a later call fails, usb_new_device() does not properly call device_del(). As comment of device_add() says, 'if device_add() succeeds, you should call device_del() when you want to get rid of it. If device_add() has not succeeded, use only put_device() to drop the reference count'. Found by code review. Cc: stable Fixes: 9f8b17e643fe ("USB: make usbdevices export their device nodes instead of using a separate class") Signed-off-by: Ma Ke Reviewed-by: Alan Stern Link: https://lore.kernel.org/r/20241218071346.2973980-1-make_ruc2021@163.com Signed-off-by: Greg Kroah-Hartman