Re: [PATCH v9 4/9] mfd: mt6397: Use MFD_CELL_* to describe sub-devices
From: sashiko-bot@kernel.org
Date: 2026-08-20 12:47:48
Also in:
linux-devicetree
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: Pre-existing issues: - [High] This problem wasn't introduced by this patch, but missing PM notifier cleanup in the probe error path and lack of a .remove hook leads to a use-after-free on suspend/resume or driver unbind. --
--- Patch [4]: [PATCH v9 4/9] mfd: mt6397: Use MFD_CELL_* to describe sub-devices ---commit 0c24567f61112fe4c7555b7e30256529aae1d5d6
Author: Luca Leonardo Scorcia [off-list ref]
mfd: mt6397: Use MFD_CELL_* to describe sub-devices
This commit updates the mfd_cell arrays for various MediaTek MT6397 family
PMICs to use the standard MFD_CELL_OF() and MFD_CELL_NAME() macros instead of
manual field initialization. No functional changes are intended.
quoted hunk ↗ jump to hunk
diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c index 1bdacda9a933f..ccd97d66d7f1c 100644 --- a/drivers/mfd/mt6397-core.c +++ b/drivers/mfd/mt6397-core.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -272,11 +202,14 @@ static const struct mfd_cell mt6397_devs[] = { - }, { - .name = "mt6397-keys", - .num_resources = ARRAY_SIZE(mt6397_keys_resources), - .resources = mt6397_keys_resources, - .of_compatible = "mediatek,mt6397-keys" - } + MFD_CELL_OF("mt6397-keys", mt6397_keys_resources, NULL, 0, 0, + "mediatek,mt6397-keys"), };
[Severity: High] This isn't a bug introduced by this patch, but I noticed a potential use-after-free issue in the driver's error handling and unbind paths. In drivers/mfd/mt6397-irq.c:mt6397_irq_init(), the PM notifier is registered globally with register_pm_notifier() but without devres management. In drivers/mfd/mt6397-core.c:mt6397_probe(), if devm_mfd_add_devices() fails, the error path removes the IRQ domain but fails to unregister the PM notifier before returning. Furthermore, mt6397_driver lacks a .remove hook entirely. Unbinding the driver via sysfs completely bypasses cleanup for both the PM notifier and the IRQ domain. In both the probe failure and driver unbind scenarios, the devres subsystem subsequently frees the memory containing the notifier block and IRQ domain host data. When the system later enters suspend or resume, pm_notifier_call_chain() will iterate over the freed memory. Could this lead to a kernel panic? Should a .remove hook be added and the probe error path updated to ensure the PM notifier is properly unregistered? -- Sashiko AI review · https://sashiko.dev/#/patchset/20260820122242.120039-1-l.scorcia@gmail.com?part=4