kernel/drivers/usb/misc, branch linux-6.12.y

usb: chaoskey: fix locking for O_NONBLOCK

2025-12-18T12:55:04Z

[ Upstream commit a2fa8a12e6bc9d89c0505b8dd7ae38ec173d25de ] A failure to take a lock with O_NONBLOCK needs to result in -EAGAIN. Change it. Fixes: 66e3e591891da ("usb: Add driver for Altus Metrum ChaosKey device (v2)") Signed-off-by: Oliver Neukum Link: https://patch.msgid.link/20251030093918.2248104-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: misc: qcom_eud: Access EUD_MODE_MANAGER2 through secure calls

2025-10-15T10:00:05Z

[ Upstream commit c0485e864a2eaa1d5a84c71e573dd236d0e885ae ] EUD_MODE_MANAGER2 register is mapped to a memory region that is marked as read-only for operating system running at EL1, enforcing access restrictions that prohibit direct memory-mapped writes via writel(). Attempts to write to this region from HLOS can result in silent failures or memory access violations, particularly when toggling EUD (Embedded USB Debugger) state. To ensure secure register access, modify the driver to use qcom_scm_io_writel(), which routes the write operation to Qualcomm Secure Channel Monitor (SCM). SCM has the necessary permissions to access protected memory regions, enabling reliable control over EUD state. SC7280, the only user of EUD is also affected, indicating that this could never have worked on a properly fused device. Fixes: 9a1bf58ccd44 ("usb: misc: eud: Add driver support for Embedded USB Debugger(EUD)") Signed-off-by: Melody Olvera Reviewed-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Reviewed-by: Souradeep Chowdhury Signed-off-by: Komal Bajaj Link: https://lore.kernel.org/r/20250731-eud_mode_manager_secure_access-v8-1-4a5dcbb79f41@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: misc: apple-mfi-fastcharge: Make power supply names unique

2025-08-15T10:13:34Z

[ Upstream commit 43007b89fb2de746443fbbb84aedd1089afdf582 ] When multiple Apple devices are connected concurrently, the apple-mfi-fastcharge driver fails to probe the subsequent devices with the following error: sysfs: cannot create duplicate filename '/class/power_supply/apple_mfi_fastcharge' apple-mfi-fastcharge 5-2.4.3.3: probe of 5-2.4.3.3 failed with error -17 This happens because the driver uses a fixed power supply name ("apple_mfi_fastcharge") for all devices, causing a sysfs name conflict when a second device is connected. Fix this by generating unique names using the USB bus and device number (e.g., "apple_mfi_fastcharge_5-12"). This ensures each connected device gets a unique power supply entry in sysfs. The change requires storing a copy of the power_supply_desc structure in the per-device mfi_device struct, since the name pointer needs to remain valid for the lifetime of the power supply registration. Fixes: 249fa8217b84 ("USB: Add driver to control USB fast charge for iOS devices") Signed-off-by: Charalampos Mitrodimas Link: https://lore.kernel.org/r/20250602-apple-mfi-fastcharge-duplicate-sysfs-v1-1-5d84de34fac6@posteo.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: misc: onboard_usb_dev: fix build warning for CONFIG_USB_ONBOARD_DEV_USB5744=n

2025-06-19T13:32:37Z

commit 662a9ece32add94469138ae66999ee16cb37a531 upstream. When the USB5744 option is disabled, the onboard_usb driver warns about unused functions: drivers/usb/misc/onboard_usb_dev.c:358:12: error: 'onboard_dev_5744_i2c_write_byte' defined but not used [-Werror=unused-function] 358 | static int onboard_dev_5744_i2c_write_byte(struct i2c_client *client, u16 addr, u8 data) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/usb/misc/onboard_usb_dev.c:313:12: error: 'onboard_dev_5744_i2c_read_byte' defined but not used [-Werror=unused-function] 313 | static int onboard_dev_5744_i2c_read_byte(struct i2c_client *client, u16 addr, u8 *data) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Extend the #ifdef block a little further to cover all of these functions. Ideally we'd use use if(IS_ENABLED()) instead, but that doesn't currently work because the i2c_transfer() and i2c_smbus_write_word_data() function declarations are hidden when CONFIG_I2C is disabled. Fixes: 1143d41922c0 ("usb: misc: onboard_usb_dev: Fix usb5744 initialization sequence") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20250523120947.2170302-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman

usb: misc: onboard_usb_dev: Fix usb5744 initialization sequence

2025-06-19T13:32:35Z

commit 1143d41922c0f87504f095417ba1870167970143 upstream. Introduce i2c APIs to read/write for proper configuration register programming. It ensures that read-modify-write sequence is performed and reserved bit in Runtime Flags 2 register are not touched. Also legacy smbus block write inserted an extra count value into the i2c data stream which breaks the register write on the usb5744. Switching to new read/write i2c APIs fixes both issues. Fixes: 6782311d04df ("usb: misc: onboard_usb_dev: add Microchip usb5744 SMBus programming support") Cc: stable Signed-off-by: Jonathan Stroud Co-developed-by: Radhey Shyam Pandey Signed-off-by: Radhey Shyam Pandey Link: https://lore.kernel.org/r/1747398760-284021-1-git-send-email-radhey.shyam.pandey@amd.com Signed-off-by: Greg Kroah-Hartman

usb: misc: onboard_usb_dev: fix support for Cypress HX3 hubs

2025-05-18T06:24:55Z

commit 9f657a92805cfc98e11cf5da9e8f4e02ecff2260 upstream. The Cypress HX3 USB3.0 hubs use different PID values depending on the product variant. The comment in compatibles table is misleading, as the currently used PIDs (0x6504 and 0x6506 for USB 3.0 and USB 2.0, respectively) are defaults for the CYUSB331x, while CYUSB330x and CYUSB332x variants use different values. Based on the datasheet [1], update the compatible usb devices table to handle different types of the hub. The change also includes vendor mode PIDs, which are used by the hub in I2C Master boot mode, if connected EEPROM contains invalid signature or is blank. This allows to correctly boot the hub even if the EEPROM will have broken content. Number of vcc supplies and timing requirements are the same for all HX variants, so the platform driver's match table does not have to be extended. [1] https://www.infineon.com/dgdl/Infineon-HX3_USB_3_0_Hub_Consumer_Industrial-DataSheet-v22_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ecb53f644b8 Table 9. PID Values Fixes: b43cd82a1a40 ("usb: misc: onboard-hub: add support for Cypress HX3 USB 3.0 family") Cc: stable Signed-off-by: Lukasz Czechowski Link: https://lore.kernel.org/r/20250425-onboard_usb_dev-v2-1-4a76a474a010@thaumatec.com Signed-off-by: Greg Kroah-Hartman

usb: misc: onboard_usb_dev: skip suspend/resume sequence for USB5744 SMBus support

2024-12-19T17:12:58Z

commit ce15d6b3d5c3c6f78290066be0f0a4fd89cdeb5b upstream. USB5744 SMBus initialization is done once in probe() and doing it in resume is not supported so avoid going into suspend and reset the HUB. There is a sysfs property 'always_powered_in_suspend' to implement this feature but since default state should be set to a working configuration so override this property value. It fixes the suspend/resume testcase on Kria KR260 Robotics Starter Kit. Fixes: 6782311d04df ("usb: misc: onboard_usb_dev: add Microchip usb5744 SMBus programming support") Cc: stable@vger.kernel.org Signed-off-by: Radhey Shyam Pandey Link: https://lore.kernel.org/r/1733165302-1694891-1-git-send-email-radhey.shyam.pandey@amd.com Signed-off-by: Greg Kroah-Hartman

usb: misc: ljca: move usb_autopm_put_interface() after wait for response

2024-12-05T13:03:00Z

commit 5c5d8eb8af06df615e8b1dc88e5847196c846045 upstream. Do not mark interface as ready to suspend when we are still waiting for response messages from the device. Fixes: acd6199f195d ("usb: Add support for Intel LJCA device") Cc: stable@vger.kernel.org Reviewed-by: Hans de Goede Tested-by: Hans de Goede # ThinkPad X1 Yoga Gen 8, ov2740 Acked-by: Sakari Ailus Signed-off-by: Stanislaw Gruszka Link: https://lore.kernel.org/r/20241112075514.680712-1-stanislaw.gruszka@linux.intel.com Signed-off-by: Greg Kroah-Hartman

usb: misc: ljca: set small runtime autosuspend delay

2024-12-05T13:03:00Z

commit 2481af79671a6603fce201cbbc48f31e488e9fae upstream. On some Lenovo platforms, the patch works around problems with ov2740 sensor initialization, which manifest themself like below: [ 4.540476] ov2740 i2c-INT3474:01: error -EIO: failed to find sensor [ 4.542066] ov2740 i2c-INT3474:01: probe with driver ov2740 failed with error -5 or [ 7.742633] ov2740 i2c-INT3474:01: chip id mismatch: 2740 != 0 [ 7.742638] ov2740 i2c-INT3474:01: error -ENXIO: failed to find sensor and also by random failures of video stream start. Issue can be reproduced by this script: n=0 k=0 while [ $n -lt 50 ] ; do sudo modprobe -r ov2740 sleep `expr $RANDOM % 5` sudo modprobe ov2740 if media-ctl -p | grep -q ov2740 ; then let k++ fi let n++ done echo Success rate $k/$n Without the patch, success rate is approximately 15 or 50 tries. With the patch it does not fail. This problem is some hardware or firmware malfunction, that can not be easy debug and fix. While setting small autosuspend delay is not perfect workaround as user can configure it to any value, it will prevent the failures by default. Additionally setting small autosuspend delay should have positive effect on power consumption as for most ljca workloads device is used for just a few milliseconds flowed by long periods of at least 100ms of inactivity (usually more). Fixes: acd6199f195d ("usb: Add support for Intel LJCA device") Cc: stable@vger.kernel.org Reviewed-by: Hans de Goede Tested-by: Hans de Goede # ThinkPad X1 Yoga Gen 8, ov2740 Acked-by: Sakari Ailus Signed-off-by: Stanislaw Gruszka Link: https://lore.kernel.org/r/20241112075514.680712-2-stanislaw.gruszka@linux.intel.com Signed-off-by: Greg Kroah-Hartman

USB: chaoskey: Fix possible deadlock chaoskey_list_lock

2024-12-05T13:02:36Z

[ Upstream commit d73dc7b182be4238b75278bfae16afb4c5564a58 ] [Syzbot reported two possible deadlocks] The first possible deadlock is: WARNING: possible recursive locking detected 6.12.0-rc1-syzkaller-00027-g4a9fe2a8ac53 #0 Not tainted -------------------------------------------- syz-executor363/2651 is trying to acquire lock: ffffffff89b120e8 (chaoskey_list_lock){+.+.}-{3:3}, at: chaoskey_release+0x15d/0x2c0 drivers/usb/misc/chaoskey.c:322 but task is already holding lock: ffffffff89b120e8 (chaoskey_list_lock){+.+.}-{3:3}, at: chaoskey_release+0x7f/0x2c0 drivers/usb/misc/chaoskey.c:299 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(chaoskey_list_lock); lock(chaoskey_list_lock); *** DEADLOCK *** The second possible deadlock is: WARNING: possible circular locking dependency detected 6.12.0-rc1-syzkaller-00027-g4a9fe2a8ac53 #0 Not tainted ------------------------------------------------------ kworker/0:2/804 is trying to acquire lock: ffffffff899dadb0 (minor_rwsem){++++}-{3:3}, at: usb_deregister_dev+0x7c/0x1e0 drivers/usb/core/file.c:186 but task is already holding lock: ffffffff89b120e8 (chaoskey_list_lock){+.+.}-{3:3}, at: chaoskey_disconnect+0xa8/0x2a0 drivers/usb/misc/chaoskey.c:235 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (chaoskey_list_lock){+.+.}-{3:3}: __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x175/0x9c0 kernel/locking/mutex.c:752 chaoskey_open+0xdd/0x220 drivers/usb/misc/chaoskey.c:274 usb_open+0x186/0x220 drivers/usb/core/file.c:47 chrdev_open+0x237/0x6a0 fs/char_dev.c:414 do_dentry_open+0x6cb/0x1390 fs/open.c:958 vfs_open+0x82/0x3f0 fs/open.c:1088 do_open fs/namei.c:3774 [inline] path_openat+0x1e6a/0x2d60 fs/namei.c:3933 do_filp_open+0x1dc/0x430 fs/namei.c:3960 do_sys_openat2+0x17a/0x1e0 fs/open.c:1415 do_sys_open fs/open.c:1430 [inline] __do_sys_openat fs/open.c:1446 [inline] __se_sys_openat fs/open.c:1441 [inline] __x64_sys_openat+0x175/0x210 fs/open.c:1441 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (minor_rwsem){++++}-{3:3}: check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain kernel/locking/lockdep.c:3904 [inline] __lock_acquire+0x250b/0x3ce0 kernel/locking/lockdep.c:5202 lock_acquire.part.0+0x11b/0x380 kernel/locking/lockdep.c:5825 down_write+0x93/0x200 kernel/locking/rwsem.c:1577 usb_deregister_dev+0x7c/0x1e0 drivers/usb/core/file.c:186 chaoskey_disconnect+0xb7/0x2a0 drivers/usb/misc/chaoskey.c:236 usb_unbind_interface+0x1e8/0x970 drivers/usb/core/driver.c:461 device_remove drivers/base/dd.c:569 [inline] device_remove+0x122/0x170 drivers/base/dd.c:561 __device_release_driver drivers/base/dd.c:1273 [inline] device_release_driver_internal+0x44a/0x610 drivers/base/dd.c:1296 bus_remove_device+0x22f/0x420 drivers/base/bus.c:576 device_del+0x396/0x9f0 drivers/base/core.c:3864 usb_disable_device+0x36c/0x7f0 drivers/usb/core/message.c:1418 usb_disconnect+0x2e1/0x920 drivers/usb/core/hub.c:2304 hub_port_connect drivers/usb/core/hub.c:5361 [inline] hub_port_connect_change drivers/usb/core/hub.c:5661 [inline] port_event drivers/usb/core/hub.c:5821 [inline] hub_event+0x1bed/0x4f40 drivers/usb/core/hub.c:5903 process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(chaoskey_list_lock); lock(minor_rwsem); lock(chaoskey_list_lock); lock(minor_rwsem); *** DEADLOCK *** [Analysis] The first is AA lock, it because wrong logic, it need a unlock. The second is AB lock, it needs to rearrange the order of lock usage. Fixes: 422dc0a4d12d ("USB: chaoskey: fail open after removal") Reported-by: syzbot+685e14d04fe35692d3bc@syzkaller.appspotmail.com Reported-by: syzbot+1f8ca5ee82576ec01f12@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=685e14d04fe35692d3bc Signed-off-by: Edward Adam Davis Tested-by: syzbot+685e14d04fe35692d3bc@syzkaller.appspotmail.com Reported-by: syzbot+5f1ce62e956b7b19610e@syzkaller.appspotmail.com Tested-by: syzbot+5f1ce62e956b7b19610e@syzkaller.appspotmail.com Tested-by: syzbot+1f8ca5ee82576ec01f12@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/tencent_84EB865C89862EC22EE94CB3A7C706C59206@qq.com Cc: Oliver Neukum Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin