Re: [PATCH v9 4/9] mfd: mt6397: Use MFD_CELL_* to describe sub-devices

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 <[email protected]>

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.

> 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

[ ... ]

> @@ -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/[email protected]?part=4