summaryrefslogtreecommitdiff
path: root/drivers/usb/misc
AgeCommit message (Collapse)AuthorFilesLines
9 daysusb: chaoskey: fix locking for O_NONBLOCKOliver Neukum1-3/+13
[ 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 <oneukum@suse.com> Link: https://patch.msgid.link/20251030093918.2248104-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-15usb: misc: qcom_eud: Access EUD_MODE_MANAGER2 through secure callsKomal Bajaj2-9/+25
[ 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 <quic_molvera@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250731-eud_mode_manager_secure_access-v8-1-4a5dcbb79f41@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15usb: misc: apple-mfi-fastcharge: Make power supply names uniqueCharalampos Mitrodimas1-3/+21
[ 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 <charmitro@posteo.net> Link: https://lore.kernel.org/r/20250602-apple-mfi-fastcharge-duplicate-sysfs-v1-1-5d84de34fac6@posteo.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-08of: remove internal arguments from of_property_for_each_u32()Luca Ceresoli1-3/+1
[ Upstream commit 9722c3b66e21ff08aec570d02a97d331087fd70f ] The of_property_for_each_u32() macro needs five parameters, two of which are primarily meant as internal variables for the macro itself (in the for() clause). Yet these two parameters are used by a few drivers, and this can be considered misuse or at least bad practice. Now that the kernel uses C11 to build, these two parameters can be avoided by declaring them internally, thus changing this pattern: struct property *prop; const __be32 *p; u32 val; of_property_for_each_u32(np, "xyz", prop, p, val) { ... } to this: u32 val; of_property_for_each_u32(np, "xyz", val) { ... } However two variables cannot be declared in the for clause even with C11, so declare one struct that contain the two variables we actually need. As the variables inside this struct are not meant to be used by users of this macro, give the struct instance the noticeable name "_it" so it is visible during code reviews, helping to avoid new code to use it directly. Most usages are trivially converted as they do not use those two parameters, as expected. The non-trivial cases are: - drivers/clk/clk.c, of_clk_get_parent_name(): easily doable anyway - drivers/clk/clk-si5351.c, si5351_dt_parse(): this is more complex as the checks had to be replicated in a different way, making code more verbose and somewhat uglier, but I refrained from a full rework to keep as much of the original code untouched having no hardware to test my changes All the changes have been build tested. The few for which I have the hardware have been runtime-tested too. Reviewed-by: Andre Przywara <andre.przywara@arm.com> # drivers/clk/sunxi/clk-simple-gates.c, drivers/clk/sunxi/clk-sun8i-bus-gates.c Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> # drivers/gpio/gpio-brcmstb.c Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> # drivers/irqchip/irq-atmel-aic-common.c Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # drivers/iio/adc/ti_am335x_adc.c Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> # drivers/pwm/pwm-samsung.c Acked-by: Richard Leitner <richard.leitner@linux.dev> # drivers/usb/misc/usb251xb.c Acked-by: Mark Brown <broonie@kernel.org> # sound/soc/codecs/arizona.c Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com> # sound/soc/codecs/arizona.c Acked-by: Michael Ellerman <mpe@ellerman.id.au> # arch/powerpc/sysdev/xive/spapr.c Acked-by: Stephen Boyd <sboyd@kernel.org> # clk Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Acked-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20240724-of_property_for_each_u32-v3-1-bea82ce429e2@bootlin.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Stable-dep-of: 28fa3291cad1 ("clk: fix an OF node reference leak in of_clk_get_parent_name()") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-09USB: chaoskey: Fix possible deadlock chaoskey_list_lockEdward Adam Davis1-2/+2
[ 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 <eadavis@qq.com> 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 <oneukum@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-09USB: chaoskey: fail open after removalOliver Neukum1-11/+24
[ Upstream commit 422dc0a4d12d0b80dd3aab3fe5943f665ba8f041 ] chaoskey_open() takes the lock only to increase the counter of openings. That means that the mutual exclusion with chaoskey_disconnect() cannot prevent an increase of the counter and chaoskey_open() returning a success. If that race is hit, chaoskey_disconnect() will happily free all resources associated with the device after it has dropped the lock, as it has read the counter as zero. To prevent this race chaoskey_open() has to check the presence of the device under the lock. However, the current per device lock cannot be used, because it is a part of the data structure to be freed. Hence an additional global mutex is needed. The issue is as old as the driver. Signed-off-by: Oliver Neukum <oneukum@suse.com> Reported-by: syzbot+422188bce66e76020e55@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=422188bce66e76020e55 Fixes: 66e3e591891da ("usb: Add driver for Altus Metrum ChaosKey device (v2)") Rule: add Link: https://lore.kernel.org/stable/20241002132201.552578-1-oneukum%40suse.com Link: https://lore.kernel.org/r/20241002132201.552578-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-09usb: yurex: make waiting on yurex_write interruptibleOliver Neukum2-5/+4
[ Upstream commit e0aa9614ab0fd35b404e4b16ebe879f9fc152591 ] The IO yurex_write() needs to wait for in order to have a device ready for writing again can take a long time time. Consequently the sleep is done in an interruptible state. Therefore others waiting for yurex_write() itself to finish should use mutex_lock_interruptible. Signed-off-by: Oliver Neukum <oneukum@suse.com> Fixes: 6bc235a2e24a5 ("USB: add driver for Meywa-Denki & Kayac YUREX") Rule: add Link: https://lore.kernel.org/stable/20240924084415.300557-1-oneukum%40suse.com Link: https://lore.kernel.org/r/20240924084415.300557-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-09usb: using mutex lock and supporting O_NONBLOCK flag in iowarrior_read()Jeongjun Park1-10/+36
[ Upstream commit 44feafbaa66ec86232b123bb8437a6a262442025 ] iowarrior_read() uses the iowarrior dev structure, but does not use any lock on the structure. This can cause various bugs including data-races, so it is more appropriate to use a mutex lock to safely protect the iowarrior dev structure. When using a mutex lock, you should split the branch to prevent blocking when the O_NONBLOCK flag is set. In addition, it is unnecessary to check for NULL on the iowarrior dev structure obtained by reading file->private_data. Therefore, it is better to remove the check. Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.") Signed-off-by: Jeongjun Park <aha310510@gmail.com> Link: https://lore.kernel.org/r/20240919103403.3986-1-aha310510@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-17Revert "usb: yurex: Replace snprintf() with the safer scnprintf() variant"Oliver Neukum1-11/+8
commit 71c717cd8a2e180126932cc6851ff21c1d04d69a upstream. This reverts commit 86b20af11e84c26ae3fde4dcc4f490948e3f8035. This patch leads to passing 0 to simple_read_from_buffer() as a fifth argument, turning the read method into a nop. The change is fundamentally flawed, as it breaks the driver. Signed-off-by: Oliver Neukum <oneukum@suse.com> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20241007094004.242122-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-04usb: yurex: Fix inconsistent locking bug in yurex_read()Harshit Mogalapalli1-1/+3
commit e7d3b9f28654dbfce7e09f8028210489adaf6a33 upstream. Unlock before returning on the error path. Fixes: 86b20af11e84 ("usb: yurex: Replace snprintf() with the safer scnprintf() variant") Reported-by: Dan Carpenter <error27@gmail.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/202312170252.3udgrIcP-lkp@intel.com/ Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Link: https://lore.kernel.org/r/20231219063639.450994-1-harshit.m.mogalapalli@oracle.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-04USB: misc: yurex: fix race between read and writeOliver Neukum1-4/+6
[ Upstream commit 93907620b308609c72ba4b95b09a6aa2658bb553 ] The write code path touches the bbu member in a non atomic manner without taking the spinlock. Fix it. The bug is as old as the driver. Signed-off-by: Oliver Neukum <oneukum@suse.com> CC: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240912132126.1034743-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-04usb: yurex: Replace snprintf() with the safer scnprintf() variantLee Jones1-5/+7
[ Upstream commit 86b20af11e84c26ae3fde4dcc4f490948e3f8035 ] There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Whilst we're at it, let's define some magic numbers to increase readability and ease of maintenance. Link: https://lwn.net/Articles/69419/ Link: https://github.com/KSPP/linux/issues/105 Cc: Tomoki Sekiyama <tomoki.sekiyama@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-9-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 93907620b308 ("USB: misc: yurex: fix race between read and write") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-04USB: misc: cypress_cy7c63: check for short transferOliver Neukum1-0/+4
commit 49cd2f4d747eeb3050b76245a7f72aa99dbd3310 upstream. As we process the second byte of a control transfer, transfers of less than 2 bytes must be discarded. This bug is as old as the driver. SIgned-off-by: Oliver Neukum <oneukum@suse.com> CC: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240912125449.1030536-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-04USB: appledisplay: close race between probe and completion handlerOliver Neukum1-4/+11
commit 8265d06b7794493d82c5c21a12d7ba43eccc30cb upstream. There is a small window during probing when IO is running but the backlight is not registered. Processing events during that time will crash. The completion handler needs to check for a backlight before scheduling work. The bug is as old as the driver. Signed-off-by: Oliver Neukum <oneukum@suse.com> CC: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240912123317.1026049-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-27usb: misc: uss720: check for incompatible versions of the Belkin F5U002Alex Henrie1-7/+13
[ Upstream commit 3295f1b866bfbcabd625511968e8a5c541f9ab32 ] The incompatible device in my possession has a sticker that says "F5U002 Rev 2" and "P80453-B", and lsusb identifies it as "050d:0002 Belkin Components IEEE-1284 Controller". There is a bug report from 2007 from Michael Trausch who was seeing the exact same errors that I saw in 2024 trying to use this cable. Link: https://lore.kernel.org/all/46DE5830.9060401@trausch.us/ Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Link: https://lore.kernel.org/r/20240326150723.99939-5-alexhenrie24@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-12-03usb: misc: onboard-hub: add support for Microchip USB5744Stefan Eichenberger2-0/+9
commit 6972b38ca05235f6142715db7062ecc87a422e22 upstream. Add support for the Microchip USB5744 USB3.0 and USB2.0 Hub. The Microchip USB5744 supports two power supplies, one for 1V2 and one for 3V3. According to the datasheet there is no need for a delay between power on and reset, so this value is set to 0. Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Cc: stable <stable@kernel.org> Acked-by: Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20231113145921.30104-3-francesco@dolcini.it Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-02usb: misc: onboard_hub: add support for Microchip USB2412 USB 2.0 hubJavier Carrasco2-0/+2
The USB2412 is a 2-Port USB 2.0 hub controller that provides a reset pin and a single 3v3 powre source, which makes it suitable to be controlled by the onboard_hub driver. This hub has the same reset timings as USB2514/2517 and the same onboard hub specific-data can be reused for USB2412. Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> Cc: stable <stable@kernel.org> Acked-by: Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20230911-topic-2412_onboard_hub-v1-1-7704181ddfff@wolfvision.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-08USB: misc: Remove unused include file usb_u132.hYue Haibing1-97/+0
Since commit 8be174835f07 ("usb: ftdi-elan: Delete driver") this include file is not used anymore, so can remove it. Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20230807141128.39092-1-yuehaibing@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04USB: misc: Remove unnecessary NULL valuesRuan Jinjie3-3/+3
The NULL initialization of the pointers assigned by kzalloc() first is not necessary, because if the kzalloc() failed, the pointers will be assigned NULL, otherwise it works as usual. so remove it. Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com> Link: https://lore.kernel.org/r/20230804093253.91647-3-ruanjinjie@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-08-04USB: cytherm: Correct the code style issue of redundant spacesRuan Jinjie1-5/+5
Ther are many redundant spaces, which is not consistent with the kernel code style, so remove it. Signed-off-by: Ruan Jinjie <ruanjinjie@huawei.com> Link: https://lore.kernel.org/r/20230804091713.41503-1-ruanjinjie@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-31Merge 6.5-rc4 into usb-nextGreg Kroah-Hartman1-4/+4
We need the USB fixes in here for testing and for other patches to be applied on top of. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-30usb: misc: onboard-hub: add support for Cypress HX3 USB 3.0 familyBenjamin Bara2-0/+10
The HX3 comes in different variants (up to 4 USB 3.0 ports; multi-TT), e.g. CYUSB330x/CYUSB331x/CYUSB332x/CYUSB230x. It operates with two different power supplies: 1V2 and 3V3. Add the support for this hub, for controlling the reset pin and the power supplies. Reset time is extracted from data sheet, page 24: "The RESETN pin can be tied to VDD_IO through an external resistor and to ground (GND) through an external capacitor (minimum 5 ms time constant)." V_IH min is given at 0.7 * 3V3 (page 34), therefore use 10ms. Also add USB PIDs for the USB 2.0 and USB 3.0 root hub. Acked-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com> Link: https://lore.kernel.org/r/20230620-hx3-v7-2-f79b4b22a1bf@skidata.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-30usb: misc: onboard-hub: support multiple power suppliesBenjamin Bara2-8/+36
As some of the onboard hubs require multiple power supplies, provide the environment to support them. Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com> Acked-by: Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20230620-hx3-v7-1-f79b4b22a1bf@skidata.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-27usb: misc: ehset: fix wrong if conditionXu Yang1-4/+4
A negative number from ret means the host controller had failed to send usb message and 0 means succeed. Therefore, the if logic is wrong here and this patch will fix it. Fixes: f2b42379c576 ("usb: misc: ehset: Rework test mode entry") Cc: stable <stable@kernel.org> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://lore.kernel.org/r/20230705095231.457860-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-25usb: Explicitly include correct DT includesRob Herring1-1/+1
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Acked-by: Herve Codina <herve.codina@bootlin.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230718143027.1064731-1-robh@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-25usb: misc: onboard_usb_hub: add Genesys Logic GL3523 hub supportAnand Moon2-0/+2
Genesys Logic GL3523 is a 4-port USB 3.1 hub that has a reset pin to toggle and a 5.0V core supply exported though an integrated LDO is available for powering it. Add the support for this hub, for controlling the reset pin and the core power supply. Signed-off-by: Anand Moon <linux.amoon@gmail.com> [m.felsch@pengutronix.de: include review feedback & port to 6.4] Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Link: https://lore.kernel.org/r/20230623142228.4069084-2-m.felsch@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-13usb: usb251xb: Use of_property_read_u16()Christophe JAILLET1-5/+4
Use of_property_read_u16() instead of of_property_read_u16_array() when only 1 element is read. This slightly simplifies the code. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Message-ID: <97478908a814d4fa694e0ca44212c3776cf3e6e9.1685877052.git.christophe.jaillet@wanadoo.fr> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-30usb: misc: onboard_hub: Don't warn twice about problems during removeUwe Kleine-König1-3/+3
If onboard_hub_power_off() called by onboard_hub_remove() fails it emits an error message. Forwarding the returned error value to the driver core results in another error message. As the return value is otherwise ignored, just drop the return value. There is no side effect apart from suppressing the core's warning. Instead of returning zero unconditionally, convert to .remove_new() which has the same semantics as .remove() that unconditionally returns zero. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230530073633.2193618-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-29usb: misc: eud: Fix indentation issuesBhupesh Sharma1-2/+2
Fix a couple of indentation issues in EUD driver. Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> Link: https://lore.kernel.org/r/20230517211756.2483552-4-bhupesh.sharma@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-29usb: Switch i2c drivers back to use .probe()Uwe Kleine-König3-3/+3
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. While touching hd3ss3220.c fix a minor white space issue in the definition of struct hd3ss3220_driver. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230517181528.167115-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-28usb: misc: usb3503: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230517230239.187727-88-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-28usb: misc: eud: Convert to platform remove callback returning voidUwe Kleine-König1-4/+2
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() is renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Bhupesh Sharma <bhupesh.sharma@linaro.org> Link: https://lore.kernel.org/r/20230517230239.187727-87-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-04-20USB: sisusbvga: Add endpoint checksAlan Stern1-0/+14
The syzbot fuzzer was able to provoke a WARNING from the sisusbvga driver: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 26 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Modules linked in: CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.2.0-rc5-syzkaller-00199-g5af6ce704936 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Code: 7c 24 18 e8 6c 50 80 fb 48 8b 7c 24 18 e8 62 1a 01 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 60 b1 fa 8a e8 84 b0 be 03 <0f> 0b e9 58 f8 ff ff e8 3e 50 80 fb 48 81 c5 c0 05 00 00 e9 84 f7 RSP: 0018:ffffc90000a1ed18 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: ffff888012783a80 RSI: ffffffff816680ec RDI: fffff52000143d95 RBP: ffff888079020000 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000080000000 R11: 0000000000000000 R12: 0000000000000003 R13: ffff888017d33370 R14: 0000000000000003 R15: ffff888021213600 FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005592753a60b0 CR3: 0000000022899000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> sisusb_bulkout_msg drivers/usb/misc/sisusbvga/sisusbvga.c:224 [inline] sisusb_send_bulk_msg.constprop.0+0x904/0x1230 drivers/usb/misc/sisusbvga/sisusbvga.c:379 sisusb_send_bridge_packet drivers/usb/misc/sisusbvga/sisusbvga.c:567 [inline] sisusb_do_init_gfxdevice drivers/usb/misc/sisusbvga/sisusbvga.c:2077 [inline] sisusb_init_gfxdevice+0x87b/0x4000 drivers/usb/misc/sisusbvga/sisusbvga.c:2177 sisusb_probe+0x9cd/0xbe2 drivers/usb/misc/sisusbvga/sisusbvga.c:2869 ... The problem was caused by the fact that the driver does not check whether the endpoints it uses are actually present and have the appropriate types. This can be fixed by adding a simple check of the endpoints. Link: https://syzkaller.appspot.com/bug?extid=23be03b56c5259385d79 Reported-and-tested-by: syzbot+23be03b56c5259385d79@syzkaller.appspotmail.com Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/48ef98f7-51ae-4f63-b8d3-0ef2004bb60a@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-29usb: move config USB_USS720 to usb's misc KconfigLukas Bulwahn1-0/+29
The USS720 parport driver source code is in drivers/usb/misc/, the corresponding config is defined in drivers/usb/Kconfig. Some digging in the kernel's history revealed no good reason why it needs to be defined in USB's top-level Kconfig file, and why the config for the USS720 parport driver should be the first in the list of USB port drivers, while all other configs for drivers in drivers/usb/misc are in the USB Miscellaneous driver configuration file. Most probably, it was simply considered a bit more special when the USB Miscellaneous driver configuration file (drivers/usb/misc/Config.in back then) was initially created, and this config simply survived to remain at the top-level USB Kconfig file with all further code/Kconfig transformations and additions later on. Users rarely notice this config being at this position, as CONFIG_PARPORT (Parallel port support) needs to be enabled and only few users enable that. Nowadays, this USB_USS720 driver is probably not that special that it needs to be listed as first item of the USB port drivers. Move the configuration of the USS720 parport driver to the top of the USB Miscellaneous drivers section, as the configurations does not have a lot of specific ordering USB Miscellaneous drivers. This way, the USS720 parport driver is moved to the comment "USB Miscellaneous drivers", fitting to the driver's source code location, but still is at the top of the list for those few acquainted users of Kconfig UIs that might be looking for the config that was once at the top of the list of the USB port drivers. Put this config definition to a more local place. No semantic change. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20230329075125.32352-1-lukas.bulwahn@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-27Merge 6.3-rc4 into usb-nextGreg Kroah-Hartman2-0/+2
We need the USB fixes here, and the USB gadget update for future development patches to be based on. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-21usb: ftdi-elan: Delete driverUwe Kleine-König3-2801/+0
This driver didn't see real maintainance since several years. It has several trivial issues (check $(scripts/checkpatch.pl -f drivers/usb/misc/ftdi-elan.c)) and some harder ones (difficult locking, explict kref handling, ...). Also today it's hard to find hardware to make actually use of such a card and I suspect the driver is completely unused. So remove it. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230321150919.351947-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-21usb: host: u132-hcd: Delete driverUwe Kleine-König1-2/+0
This driver got its last actual change in 2006 and is probably unused as nowbody should use a cardbus to USB adapter any more. If it were still used, the driver was in urgent need for maintainer love. (Explicit kref handling, underdocumented locking, .remove() can return errors ...) Also the link in the (now removed) help text doesn't look actively maintained. According to archive.org it forwarded to http://www.copenhagen-hotel.net/ already back in 2018. So don't waste more time on this driver and just delete it. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230321103638.343886-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-16usb: misc: usb3503: support usb3803 and bypass modeEmanuele Ghidoli1-1/+21
Add support for USB3803 and bypass mode, with this change is also possible to move the component out of bypass mode. In bypass mode the downstream port 3 is connected to the upstream port with low switch resistance R_on. Controlling mode of operations: | RESET_N | BYPASS_N | Mode | -------------------------------- | 0 | 0 | standby | | 1 | 0 | bypass | | 1 | 1 | hub | Datasheet: https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/00001691D.pdf Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://lore.kernel.org/r/20230313165039.255579-4-francesco@dolcini.it Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-16usb: misc: usb3503: refactor code to prepare for usb3803 additionEmanuele Ghidoli1-25/+19
Refactor code to simplify adding support for USB3803 and bypass mode. Remove static usb3503_reset() and move it to usb3503_switch_mode(), with the addition of the bypass mode we need to drive the various control signals to the expected configuration, not just to assert/release the reset. In addition to that the usb3503_connect() needs to be called only for HUB mode. No functional changes expected nor intended because of this change. Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com> Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://lore.kernel.org/r/20230313165039.255579-3-francesco@dolcini.it Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-16usb: misc: usb251xb: drop of_match_ptr for ID tableKrzysztof Kozlowski1-9/+1
The driver will match mostly by DT table (even thought there is regular ID table) so there is little benefit in of_match_ptr (this also allows ACPI matching via PRP0001, even though it might not be relevant here). drivers/usb/misc/usb251xb.c:223:35: error: ‘usb2517i_data’ defined but not used [-Werror=unused-const-variable=] drivers/usb/misc/usb251xb.c:215:35: error: ‘usb2517_data’ defined but not used [-Werror=unused-const-variable=] drivers/usb/misc/usb251xb.c:207:35: error: ‘usb2514bi_data’ defined but not used [-Werror=unused-const-variable=] Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Richard Leitner <richard.leitner@skidata.com> Link: https://lore.kernel.org/r/20230311173624.263189-7-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-16usb: Use of_property_read_bool() for boolean propertiesRob Herring1-18/+15
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. Convert reading boolean properties to to of_property_read_bool(). Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Richard Leitner <richard.leitner@skidata.com> Link: https://lore.kernel.org/r/20230310144729.1545857-1-robh@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-03-09usb: misc: onboard-hub: add support for Microchip USB2517 USB 2.0 hubAlexander Stein2-0/+2
Add support for Microchip USB2517 USB 2.0 hub to the onboard usb hub driver. Adopt the generic usb-device compatible ("usbVID,PID"). This hub has the same reset timings as USB2514, so reuse that one. There is also an USB2517I which just has industrial temperature range. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Cc: stable <stable@kernel.org> Acked-by: Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20230223073920.2912298-1-alexander.stein@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-01-23Merge 6.2-rc5 into usb-nextGreg Kroah-Hartman2-10/+10
We need the USB fixes in here and this resolves merge conflicts as reported in linux-next in the following files: drivers/usb/host/xhci.c drivers/usb/host/xhci.h drivers/usb/typec/ucsi/ucsi.c Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-01-20USB: misc: iowarrior: fix up header size for USB_DEVICE_ID_CODEMERCS_IOW100Greg Kroah-Hartman1-1/+1
The USB_DEVICE_ID_CODEMERCS_IOW100 header size was incorrect, it should be 12, not 13. Cc: stable <stable@kernel.org> Fixes: 17a82716587e ("USB: iowarrior: fix up report size handling for some devices") Reported-by: Christoph Jung <jung@codemercs.com> Link: https://lore.kernel.org/r/20230120135330.3842518-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-01-19usb: misc: onboard_usb_hub: add VIA LAB VL817 hub supportAnand Moon2-0/+9
VIA LAB VL817 is a 4-port USB 3.1 hub and USB 2.0 root hub that has a reset pin to toggle and a 5.0V core supply exported though an integrated LDO is available for powering it. Add the support for this hub, for controlling the reset pin and the core power supply. Add USB device id's for USB 2.0 and USB 3.0 root hub. Signed-off-by: Anand Moon <linux.amoon@gmail.com> Acked-by: Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20230118044418.875-9-linux.amoon@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-01-19usb: misc: onboard_usb_hub: add Genesys Logic GL852G hub supportAnand Moon2-0/+6
Genesys Logic GL852G is a 4-port USB 2.0 STT hub that has a reset pin to toggle and a 5.0V core supply exported though an integrated LDO is available for powering it. Add the support for this hub, for controlling the reset pin and the core power supply. Signed-off-by: Anand Moon <linux.amoon@gmail.com> Acked-by: Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20230118044418.875-5-linux.amoon@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-01-17usb: misc: onboard_hub: Move 'attach' work to the driverMatthias Kaehlcke1-6/+6
Currently each onboard_hub platform device owns an 'attach' work, which is scheduled when the device probes. With this deadlocks have been reported on a Raspberry Pi 3 B+ [1], which has nested onboard hubs. The flow of the deadlock is something like this (with the onboard_hub driver built as a module) [2]: - USB root hub is instantiated - core hub driver calls onboard_hub_create_pdevs(), which creates the 'raw' platform device for the 1st level hub - 1st level hub is probed by the core hub driver - core hub driver calls onboard_hub_create_pdevs(), which creates the 'raw' platform device for the 2nd level hub - onboard_hub platform driver is registered - platform device for 1st level hub is probed - schedules 'attach' work - platform device for 2nd level hub is probed - schedules 'attach' work - onboard_hub USB driver is registered - device (and parent) lock of hub is held while the device is re-probed with the onboard_hub driver - 'attach' work (running in another thread) calls driver_attach(), which blocks on one of the hub device locks - onboard_hub_destroy_pdevs() is called by the core hub driver when one of the hubs is detached - destroying the pdevs invokes onboard_hub_remove(), which waits for the 'attach' work to complete - waits forever, since the 'attach' work can't acquire the device lock Use a single work struct for the driver instead of having a work struct per onboard hub platform driver instance. With that it isn't necessary to cancel the work in onboard_hub_remove(), which fixes the deadlock. The work is only cancelled when the driver is unloaded. [1] https://lore.kernel.org/r/d04bcc45-3471-4417-b30b-5cf9880d785d@i2se.com/ [2] https://lore.kernel.org/all/Y6OrGbqaMy2iVDWB@google.com/ Cc: stable@vger.kernel.org Fixes: 8bc063641ceb ("usb: misc: Add onboard_usb_hub driver") Link: https://lore.kernel.org/r/d04bcc45-3471-4417-b30b-5cf9880d785d@i2se.com/ Link: https://lore.kernel.org/all/Y6OrGbqaMy2iVDWB@google.com/ Reported-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20230110172954.v2.2.I16b51f32db0c32f8a8532900bfe1c70c8572881a@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-01-17usb: misc: onboard_hub: Invert driver registration orderMatthias Kaehlcke1-3/+3
The onboard_hub 'driver' consists of two drivers, a platform driver and a USB driver. Currently when the onboard hub driver is initialized it first registers the platform driver, then the USB driver. This results in a race condition when the 'attach' work is executed, which is scheduled when the platform device is probed. The purpose of fhe 'attach' work is to bind elegible USB hub devices to the onboard_hub USB driver. This fails if the work runs before the USB driver has been registered. Register the USB driver first, then the platform driver. This increases the chances that the onboard_hub USB devices are probed before their corresponding platform device, which the USB driver tries to locate in _probe(). The driver already handles this situation and defers probing if the onboard hub platform device doesn't exist yet. Cc: stable@vger.kernel.org Fixes: 8bc063641ceb ("usb: misc: Add onboard_usb_hub driver") Link: https://lore.kernel.org/lkml/Y6W00vQm3jfLflUJ@hovoldconsulting.com/T/#m0d64295f017942fd988f7c53425db302d61952b4 Reported-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Link: https://lore.kernel.org/r/20230110172954.v2.1.I75494ebee7027a50235ce4b1e930fa73a578fbe2@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-16Merge tag 'driver-core-6.2-rc1' of ↵Linus Torvalds2-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core updates from Greg KH: "Here is the set of driver core and kernfs changes for 6.2-rc1. The "big" change in here is the addition of a new macro, container_of_const() that will preserve the "const-ness" of a pointer passed into it. The "problem" of the current container_of() macro is that if you pass in a "const *", out of it can comes a non-const pointer unless you specifically ask for it. For many usages, we want to preserve the "const" attribute by using the same call. For a specific example, this series changes the kobj_to_dev() macro to use it, allowing it to be used no matter what the const value is. This prevents every subsystem from having to declare 2 different individual macros (i.e. kobj_const_to_dev() and kobj_to_dev()) and having the compiler enforce the const value at build time, which having 2 macros would not do either. The driver for all of this have been discussions with the Rust kernel developers as to how to properly mark driver core, and kobject, objects as being "non-mutable". The changes to the kobject and driver core in this pull request are the result of that, as there are lots of paths where kobjects and device pointers are not modified at all, so marking them as "const" allows the compiler to enforce this. So, a nice side affect of the Rust development effort has been already to clean up the driver core code to be more obvious about object rules. All of this has been bike-shedded in quite a lot of detail on lkml with different names and implementations resulting in the tiny version we have in here, much better than my original proposal. Lots of subsystem maintainers have acked the changes as well. Other than this change, included in here are smaller stuff like: - kernfs fixes and updates to handle lock contention better - vmlinux.lds.h fixes and updates - sysfs and debugfs documentation updates - device property updates All of these have been in the linux-next tree for quite a while with no problems" * tag 'driver-core-6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (58 commits) device property: Fix documentation for fwnode_get_next_parent() firmware_loader: fix up to_fw_sysfs() to preserve const usb.h: take advantage of container_of_const() device.h: move kobj_to_dev() to use container_of_const() container_of: add container_of_const() that preserves const-ness of the pointer driver core: fix up missed drivers/s390/char/hmcdrv_dev.c class.devnode() conversion. driver core: fix up missed scsi/cxlflash class.devnode() conversion. driver core: fix up some missing class.devnode() conversions. driver core: make struct class.devnode() take a const * driver core: make struct class.dev_uevent() take a const * cacheinfo: Remove of_node_put() for fw_token device property: Add a blank line in Kconfig of tests device property: Rename goto label to be more precise device property: Move PROPERTY_ENTRY_BOOL() a bit down device property: Get rid of __PROPERTY_ENTRY_ARRAY_EL*SIZE*() kernfs: fix all kernel-doc warnings and multiple typos driver core: pass a const * into of_device_uevent() kobject: kset_uevent_ops: make name() callback take a const * kobject: kset_uevent_ops: make filter() callback take a const * kobject: make kobject_namespace take a const * ...
2022-12-16Merge tag 'usb-6.2-rc1' of ↵Linus Torvalds14-2985/+21
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB and Thunderbolt driver updates from Greg KH: "Here is the large set of USB and Thunderbolt driver changes for 6.2-rc1. Overall, thanks to the removal of a driver, more lines were removed than added, a nice change. Highlights include: - removal of the sisusbvga driver that was not used by anyone anymore - minor thunderbolt driver changes and tweaks - chipidea driver updates - usual set of typec driver features and hardware support added - musb minor driver fixes - fotg210 driver fixes, bringing that hardware back from the "dead" - minor dwc3 driver updates - addition, and then removal, of a list.h helper function for many USB and other subsystem drivers, that ended up breaking the build. That will come back for 6.3-rc1, it missed this merge window. - usual xhci updates and enhancements - usb-serial driver updates and support for new devices - other minor USB driver updates All of these have been in linux-next for a while with no reported problems" * tag 'usb-6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (153 commits) usb: gadget: uvc: Rename bmInterfaceFlags -> bmInterlaceFlags usb: dwc2: power on/off phy for peripheral mode in dual-role mode usb: dwc2: disable lpm feature on Rockchip SoCs dt-bindings: usb: mtk-xhci: add support for mt7986 usb: dwc3: core: defer probe on ulpi_read_id timeout usb: ulpi: defer ulpi_register on ulpi_read_id timeout usb: misc: onboard_usb_hub: add Genesys Logic GL850G hub support dt-bindings: usb: Add binding for Genesys Logic GL850G hub controller dt-bindings: vendor-prefixes: add Genesys Logic usb: fotg210-udc: fix potential memory leak in fotg210_udc_probe() usb: typec: tipd: Set mode of operation for USB Type-C connector usb: gadget: udc: drop obsolete dependencies on COMPILE_TEST usb: musb: remove extra check in musb_gadget_vbus_draw usb: gadget: uvc: Prevent buffer overflow in setup handler usb: dwc3: qcom: Fix memory leak in dwc3_qcom_interconnect_init usb: typec: wusb3801: fix fwnode refcount leak in wusb3801_probe() usb: storage: Add check for kcalloc USB: sisusbvga: use module_usb_driver() USB: sisusbvga: rename sisusb.c to sisusbvga.c USB: sisusbvga: remove console support ...
generated by cgit v1.2.3 (git 2.39.0) at 2026-01-20 20:37:49 +0300