kernel/linux.git/drivers/i3c/master.c, branch v5.15.208

i3c: Move device name assignment after i3c_bus_init

2026-03-04T12:19:21+00:00

[ Upstream commit 3502cea99c7ceb331458cbd34ef6792c83144687 ] Move device name initialization to occur after i3c_bus_init() so that i3cbus->id is guaranteed to be assigned before it is used. Fixes: 9d4f219807d5 ("i3c: fix refcount inconsistency in i3c_master_register") Signed-off-by: Billy Tsai Reviewed-by: Frank Li Link: https://patch.msgid.link/20260112-upstream_i3c_fix-v1-1-cbbf2cb71809@aspeedtech.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin

i3c: remove i2c board info from i2c_dev_desc

2026-03-04T12:19:21+00:00

[ Upstream commit 31b9887c7258ca47d9c665a80f19f006c86756b1 ] I2C board info is only required during adapter setup so there is no requirement to keeping a pointer to it once running. To support dynamic device addition we can't rely on board info - user-space creation through sysfs won't have a boardinfo. Cc: Alexandre Belloni Signed-off-by: Jamie Iles Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20220117174816.1963463-2-quic_jiles@quicinc.com Stable-dep-of: 3502cea99c7c ("i3c: Move device name assignment after i3c_bus_init") Signed-off-by: Sasha Levin

i3c: fix refcount inconsistency in i3c_master_register

2026-01-19T12:09:25+00:00

[ Upstream commit 9d4f219807d5ac11fb1d596e4ddb09336b040067 ] In `i3c_master_register`, a possible refcount inconsistency has been identified, causing possible resource leak. Function `of_node_get` increases the refcount of `parent->of_node`. If function `i3c_bus_init` fails, the function returns immediately without a corresponding decrease, resulting in an inconsistent refcounter. Move call i3c_bus_init() after device_initialize() to let callback i3c_masterdev_release() release of_node. Reported-by: Shuhao Fu Closes: https://lore.kernel.org/linux-i3c/aO2tjp_FsV_WohPG@osx.local/T/#m2c05a982beeb14e7bf039c1d8db856734bf234c7 Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Signed-off-by: Frank Li Link: https://patch.msgid.link/20251016143814.2551256-1-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin

i3c: don't fail if GETHDRCAP is unsupported

2025-08-28T14:24:24+00:00

[ Upstream commit 447270cdb41b1c8c3621bb14b93a6749f942556e ] 'I3C_BCR_HDR_CAP' is still spec v1.0 and has been renamed to 'advanced capabilities' in v1.1 onwards. The ST pressure sensor LPS22DF does not have HDR, but has the 'advanced cap' bit set. The core still wants to get additional information using the CCC 'GETHDRCAP' (or GETCAPS in v1.1 onwards). Not all controllers support this CCC and will notify the upper layers about it. For instantiating the device, we can ignore this unsupported CCC as standard communication will work. Without this patch, the device will not be instantiated at all. Signed-off-by: Wolfram Sang Reviewed-by: Frank Li Link: https://lore.kernel.org/r/20250704204524.6124-1-wsa+renesas@sang-engineering.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin

i3c: Add NULL pointer check in i3c_master_queue_ibi()

2025-05-02T05:44:03+00:00

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: Use i3cdev->desc->info instead of calling i3c_device_get_info() to avoid deadlock

2024-12-14T18:51:42+00:00

[ Upstream commit 6cf7b65f7029914dc0cd7db86fac9ee5159008c6 ] 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 Signed-off-by: Sasha Levin

i3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs()

2024-12-14T18:51:23+00:00

commit 3082990592f7c6d7510a9133afa46e31bbe26533 upstream. if (dev->boardinfo && dev->boardinfo->init_dyn_addr) ^^^ here check "init_dyn_addr" i3c_bus_set_addr_slot_status(&master->bus, dev->info.dyn_addr, ...) ^^^^ free "dyn_addr" Fix copy/paste error "dyn_addr" by replacing it with "init_dyn_addr". Cc: stable@kernel.org Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Reviewed-by: Miquel Raynal Signed-off-by: Frank Li Link: https://lore.kernel.org/r/20241001162608.224039-1-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman

i3c: Fix potential refcount leak in i3c_master_register_new_i3c_devs

2023-11-20T10:08:27+00:00

[ Upstream commit cab63f64887616e3c4e31cfd8103320be6ebc8d3 ] put_device() needs to be called on failure of device_register() to give up the reference initialized in it to avoid refcount leak. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Signed-off-by: Dinghao Liu Link: https://lore.kernel.org/r/20230921082410.25548-1-dinghao.liu@zju.edu.cn Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin

i3c: fix incorrect address slot lookup on 64-bit

2022-03-08T18:12:35+00:00

[ Upstream commit f18f98110f2b179792cb70d85cba697320a3790f ] The address slot bitmap is an array of unsigned long's which are the same size as an int on 32-bit platforms but not 64-bit. Loading the bitmap into an int could result in the incorrect status being returned for a slot and slots being reported as the wrong status. Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Cc: Boris Brezillon Cc: Alexandre Belloni Signed-off-by: Jamie Iles Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210922165600.179394-1-quic_jiles@quicinc.com Signed-off-by: Sasha Levin

bus: Make remove callback return void

2021-07-21T09:53:42+00:00

The driver core ignores the return value of this callback because there is only little it can do when a device disappears. This is the final bit of a long lasting cleanup quest where several buses were converted to also return void from their remove callback. Additionally some resource leaks were fixed that were caused by drivers returning an error code in the expectation that the driver won't go away. With struct bus_type::remove returning void it's prevented that newly implemented buses return an ignored error code and so don't anticipate wrong expectations for driver authors. Reviewed-by: Tom Rix (For fpga) Reviewed-by: Mathieu Poirier Reviewed-by: Cornelia Huck (For drivers/s390 and drivers/vfio) Acked-by: Russell King (Oracle) (For ARM, Amba and related parts) Acked-by: Mark Brown Acked-by: Chen-Yu Tsai (for sunxi-rsb) Acked-by: Pali Rohár Acked-by: Mauro Carvalho Chehab (for media) Acked-by: Hans de Goede (For drivers/platform) Acked-by: Alexandre Belloni Acked-By: Vinod Koul Acked-by: Juergen Gross (For xen) Acked-by: Lee Jones (For mfd) Acked-by: Johannes Thumshirn (For mcb) Acked-by: Johan Hovold Acked-by: Srinivas Kandagatla (For slimbus) Acked-by: Kirti Wankhede (For vfio) Acked-by: Maximilian Luz Acked-by: Heikki Krogerus (For ulpi and typec) Acked-by: Samuel Iglesias Gonsálvez (For ipack) Acked-by: Geoff Levand (For ps3) Acked-by: Yehezkel Bernat (For thunderbolt) Acked-by: Alexander Shishkin (For intel_th) Acked-by: Dominik Brodowski (For pcmcia) Acked-by: Rafael J. Wysocki (For ACPI) Acked-by: Bjorn Andersson (rpmsg and apr) Acked-by: Srinivas Pandruvada (For intel-ish-hid) Acked-by: Dan Williams (For CXL, DAX, and NVDIMM) Acked-by: William Breathitt Gray (For isa) Acked-by: Stefan Richter (For firewire) Acked-by: Benjamin Tissoires (For hid) Acked-by: Thorsten Scherer (For siox) Acked-by: Sven Van Asbroeck (For anybuss) Acked-by: Ulf Hansson (For MMC) Acked-by: Wolfram Sang # for I2C Acked-by: Sudeep Holla Acked-by: Geert Uytterhoeven Acked-by: Dmitry Torokhov Acked-by: Finn Thain Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20210713193522.1770306-6-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman