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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing .remove callback leads to PM notifier use-after-free and IRQ domain memory leak on module unload.
--

commit 6a7d774cdf490c33501d839d753ee001e1219166
Author: Luca Leonardo Scorcia <l.scorcia@gmail.com>

mfd: mt6397: Use MFD_CELL_* to describe sub-devices

Use the MFD_CELL_* macros to describe sub-devices. No functional changes.

> diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> index 9ec9519965887..3e08179002fad 100644
> --- a/drivers/mfd/mt6397-core.c
> +++ b/drivers/mfd/mt6397-core.c
> @@ -124,165 +124,92 @@ static const struct resource mt6323_pwrc_resources[] = {

[ ... ]

>  static const struct mfd_cell mt6397_devs[] = {
> -	{
> -		.name = "mt6397-rtc",
> -		.num_resources = ARRAY_SIZE(mt6397_rtc_resources),
> -		.resources = mt6397_rtc_resources,
> -		.of_compatible = "mediatek,mt6397-rtc",
> -	}, {
> -		.name = "mt6397-regulator",
> -		.of_compatible = "mediatek,mt6397-regulator",
> -	}, {

[ ... ]

> +	MFD_CELL_OF("mt6397-keys", mt6397_keys_resources, NULL, 0, 0,
> +		    "mediatek,mt6397-keys"),
>  };
>  
>  struct chip_data {

[Severity: High]
This is a pre-existing issue, but looking at the platform driver definition:

drivers/mfd/mt6397-core.c:
    static struct platform_driver mt6397_driver = {
        .probe = mt6397_probe,
        .driver = {
            .name = "mt6397",
            ...
        },
        ...
    };

Could the absence of a .remove callback lead to a PM notifier use-after-free
and IRQ domain memory leak on module unload?

During probe, mt6397_probe() calls mt6397_irq_init() which registers a PM
notifier with register_pm_notifier(&chip->pm_nb) and creates an IRQ domain
with irq_domain_create_linear().

Because the mt6397_driver struct lacks a .remove callback, unbinding the
driver (via module unload or sysfs) triggers standard devm teardown, freeing
the chip structure that was allocated via devm_kzalloc().

Doesn't this leave the kernel's PM notifier chain with a dangling pointer
to the freed chip->pm_nb, causing a crash on the next suspend/resume cycle,
and leave the IRQ domain unremoved?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260902193351.185771-1-l.scorcia@gmail.com?part=4