kernel/drivers/i3c, branch linux-6.13.y

i3c: Add NULL pointer check in i3c_master_queue_ibi()

2025-04-20T08:18:11Z

commit bd496a44f041da9ef3afe14d1d6193d460424e91 upstream. The I3C master driver may receive an IBI from a target device that has not been probed yet. In such cases, the master calls `i3c_master_queue_ibi()` to queue an IBI work task, leading to "Unable to handle kernel read from unreadable memory" and resulting in a kernel panic. Typical IBI handling flow: 1. The I3C master scans target devices and probes their respective drivers. 2. The target device driver calls `i3c_device_request_ibi()` to enable IBI and assigns `dev->ibi = ibi`. 3. The I3C master receives an IBI from the target device and calls `i3c_master_queue_ibi()` to queue the target device driver’s IBI handler task. However, since target device events are asynchronous to the I3C probe sequence, step 3 may occur before step 2, causing `dev->ibi` to be `NULL`, leading to a kernel panic. Add a NULL pointer check in `i3c_master_queue_ibi()` to prevent accessing an uninitialized `dev->ibi`, ensuring stability. Fixes: 3a379bbcea0af ("i3c: Add core I3C infrastructure") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/lkml/Z9gjGYudiYyl3bSe@lizhi-Precision-Tower-5810/ Signed-off-by: Manjunatha Venkatesh Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20250326123047.2797946-1-manjunatha.venkatesh@nxp.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman

i3c: master: svc: Use readsb helper for reading MDB

2025-04-20T08:18:11Z

commit c06acf7143bddaa3c0f7bedd8b99e48f6acb85c3 upstream. The target can send the MDB byte followed by additional data bytes. The readl on MRDATAB reads one actual byte, but the readsl advances the destination pointer by 4 bytes. This causes the subsequent payload to be copied to wrong position in the destination buffer. Cc: stable@kernel.org Fixes: dd3c52846d59 ("i3c: master: svc: Add Silvaco I3C master driver") Signed-off-by: Stanley Chu Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20250318053606.3087121-3-yschu@nuvoton.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman

i3c: master: svc: Fix missing the IBI rules

2025-04-10T12:41:49Z

[ Upstream commit 9cecad134d84d14dc72a0eea7a107691c3e5a837 ] The code does not add IBI rules for devices with controller capability. However, the secondary controller has the controller capability and works at target mode when the device is probed. Therefore, add IBI rules for such devices. Fixes: dd3c52846d59 ("i3c: master: svc: Add Silvaco I3C master driver") Signed-off-by: Stanley Chu Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20250318053606.3087121-2-yschu@nuvoton.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin

i3c: mipi-i3c-hci: Add support for MIPI I3C HCI on PCI bus

2025-02-21T13:10:53Z

[ Upstream commit 30bb1ce71215645fa6a92f4fa8cbb8f58db68f12 ] Add a glue code for the MIPI I3C HCI on PCI bus with Intel Panther Lake I3C controller PCI IDs. MIPI I3C HCI on Intel platforms has additional logic around the MIPI I3C HCI core logic. Those together create so called I3C slice on PCI bus. Intel specific initialization code does a reset cycle to the I3C slice before probing the MIPI I3C HCI part. Signed-off-by: Jarkko Nikula Link: https://lore.kernel.org/r/20241231115904.620052-2-jarkko.nikula@linux.intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin

i3c: mipi-i3c-hci: Add Intel specific quirk to ring resuming

2025-02-21T13:10:52Z

[ Upstream commit ccdb2e0e3b00d13df90ac7a0524dd855173f1171 ] MIPI I3C HCI on Intel hardware requires a quirk where ring needs to stop and set to run again after resuming the halted controller. This is not expected from the MIPI I3C HCI specification and is Intel specific. Add this quirk to generic aborted transfer handling and execute it only when ring is not in running state after a transfer error and attempted controller resume. This is the case on Intel hardware. It is not fully clear to me what is the ring running state in generic hardware in such case. I would expect if ring is not running, then stop request is a no-op and run request is either required or does the same what controller resume would do. Signed-off-by: Jarkko Nikula Link: https://lore.kernel.org/r/20241231115904.620052-1-jarkko.nikula@linux.intel.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin

i3c: master: Fix missing 'ret' assignment in set_speed()

2025-02-17T10:36:54Z

commit b266e0d4dac00eecdfaf50ec3f708fd0c3b39637 upstream. Fix a probe failure in the i3c master driver that occurs when no i3c devices are connected to the bus. The issue arises in `i3c_master_bus_init()` where the `ret` value is not updated after calling `master->ops->set_speed()`. If no devices are present, `ret` remains set to `I3C_ERROR_M2`, causing the code to incorrectly proceed to `err_bus_cleanup`. Cc: stable@vger.kernel.org Fixes: aef79e189ba2 ("i3c: master: support to adjust first broadcast address speed") Signed-off-by: Frank Li Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Acked-by: Mukesh Kumar Savaliya Reviewed-by: Miquel Raynal Link: https://lore.kernel.org/r/20250108225533.915334-1-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman

i3c: dw: Fix use-after-free in dw_i3c_master driver due to race condition

2025-02-08T09:01:57Z

[ Upstream commit b75439c945b94dd8a2b645355bdb56f948052601 ] In dw_i3c_common_probe, &master->hj_work is bound with dw_i3c_hj_work. And dw_i3c_master_irq_handler can call dw_i3c_master_irq_handle_ibis function to start the work. If we remove the module which will call dw_i3c_common_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | dw_i3c_hj_work dw_i3c_common_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in dw_i3c_common_remove. Fixes: 1dd728f5d4d4 ("i3c: master: Add driver for Synopsys DesignWare IP") Signed-off-by: Pei Xiao Acked-by: Mukesh Kumar Savaliya Link: https://lore.kernel.org/r/bfc49c9527be5b513e7ceafeba314ca40a5be4bc.1732703537.git.xiaopei01@kylinos.cn Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin

Get rid of 'remove_new' relic from platform driver struct

2024-12-01T23:12:43Z

The continual trickle of small conversion patches is grating on me, and is really not helping. Just get rid of the 'remove_new' member function, which is just an alias for the plain 'remove', and had a comment to that effect: /* * .remove_new() is a relic from a prototype conversion of .remove(). * New drivers are supposed to implement .remove(). Once all drivers are * converted to not use .remove_new any more, it will be dropped. */ This was just a tree-wide 'sed' script that replaced '.remove_new' with '.remove', with some care taken to turn a subsequent tab into two tabs to make things line up. I did do some minimal manual whitespace adjustment for places that used spaces to line things up. Then I just removed the old (sic) .remove_new member function, and this is the end result. No more unnecessary conversion noise. Signed-off-by: Linus Torvalds

i3c: Use i3cdev->desc->info instead of calling i3c_device_get_info() to avoid deadlock

2024-11-18T13:29:13Z

A deadlock may happen since the i3c_master_register() acquires &i3cbus->lock twice. See the log below. Use i3cdev->desc->info instead of calling i3c_device_info() to avoid acquiring the lock twice. v2: - Modified the title and commit message ============================================ WARNING: possible recursive locking detected 6.11.0-mainline -------------------------------------------- init/1 is trying to acquire lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_bus_normaluse_lock but task is already holding lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&i3cbus->lock); lock(&i3cbus->lock); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by init/1: #0: fcffff809b6798f8 (&dev->mutex){....}-{3:3}, at: __driver_attach #1: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register stack backtrace: CPU: 6 UID: 0 PID: 1 Comm: init Call trace: dump_backtrace+0xfc/0x17c show_stack+0x18/0x28 dump_stack_lvl+0x40/0xc0 dump_stack+0x18/0x24 print_deadlock_bug+0x388/0x390 __lock_acquire+0x18bc/0x32ec lock_acquire+0x134/0x2b0 down_read+0x50/0x19c i3c_bus_normaluse_lock+0x14/0x24 i3c_device_get_info+0x24/0x58 i3c_device_uevent+0x34/0xa4 dev_uevent+0x310/0x384 kobject_uevent_env+0x244/0x414 kobject_uevent+0x14/0x20 device_add+0x278/0x460 device_register+0x20/0x34 i3c_master_register_new_i3c_devs+0x78/0x154 i3c_master_register+0x6a0/0x6d4 mtk_i3c_master_probe+0x3b8/0x4d8 platform_probe+0xa0/0xe0 really_probe+0x114/0x454 __driver_probe_device+0xa0/0x15c driver_probe_device+0x3c/0x1ac __driver_attach+0xc4/0x1f0 bus_for_each_dev+0x104/0x160 driver_attach+0x24/0x34 bus_add_driver+0x14c/0x294 driver_register+0x68/0x104 __platform_driver_register+0x20/0x30 init_module+0x20/0xfe4 do_one_initcall+0x184/0x464 do_init_module+0x58/0x1ec load_module+0xefc/0x10c8 __arm64_sys_finit_module+0x238/0x33c invoke_syscall+0x58/0x10c el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x50/0xac el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1a8/0x1ac Signed-off-by: Defa Li Link: https://lore.kernel.org/r/20241107132549.25439-1-defa.li@mediatek.com Signed-off-by: Alexandre Belloni

i3c: mipi-i3c-hci: Support SETDASA CCC

2024-11-18T13:28:01Z

When the I3C subsystem wants to assign a dynamic address using the SETDASA CCC, it needs to attach the I3C device with device info that includes only the static address. In the HCI, if the driver want to send this SETDASA CCC, a DAT entry is required to temporarily fill the device's static address into the dynamic address field. Afterward, the reattach API will be executed to update the DAT with the correct dynamic addrees value. Signed-off-by: Billy Tsai Reviewed-by: Jarkko Nikula Link: https://lore.kernel.org/r/20241113035826.923918-1-billy_tsai@aspeedtech.com Signed-off-by: Alexandre Belloni