kernel/linux.git/drivers/i3c, branch v6.13.6

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

2025-02-21T13:10:53+00:00

[ 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:52+00:00

[ 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:54+00:00

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:57+00:00

[ 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:43+00:00

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:13+00:00

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:01+00:00

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

i3c: dw: Add quirk to address OD/PP timing issue on AMD platform

2024-11-18T13:27:29+00:00

The AMD Legacy I3C is having a problem with its IP, specifically with the push-pull and open-drain pull-up registers. These registers need to be manually programmed for every CCC submission to align with the duty cycle. Therefore, add a quirk to address this issue. Reviewed-by: Jarkko Nikula Co-developed-by: Sanket Goswami Signed-off-by: Sanket Goswami Signed-off-by: Shyam Sundar S K Link: https://lore.kernel.org/r/20241114110239.660551-3-Shyam-sundar.S-k@amd.com Signed-off-by: Alexandre Belloni

i3c: dw: Add support for AMDI0015 ACPI ID

2024-11-18T13:27:29+00:00

Add AMDI0015 _HID for Designware I3C driver so that the dw-i3c-master driver can be probed on AMD platforms. Reviewed-by: Jarkko Nikula Signed-off-by: Shyam Sundar S K Link: https://lore.kernel.org/r/20241114110239.660551-2-Shyam-sundar.S-k@amd.com Signed-off-by: Alexandre Belloni

i3c: master: svc: Modify enabled_events bit 7:0 to act as IBI enable counter

2024-11-02T21:56:56+00:00

Fix issue where disabling IBI on one device disables the entire IBI interrupt. Modify bit 7:0 of enabled_events to serve as an IBI enable counter, ensuring that the system IBI interrupt is disabled only when all I3C devices have IBI disabled. Cc: stable@kernel.org Fixes: 7ff730ca458e ("i3c: master: svc: enable the interrupt in the enable ibi function") Reviewed-by: Miquel Raynal Signed-off-by: Frank Li Link: https://lore.kernel.org/r/20241101165002.2479794-1-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni