Re: [PATCH 04/11] mfd: rz-mtu3: store &pdev->dev in local variable

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The parent driver exports numerous bespoke accessors (e.g., rz_mtu3_shared_reg_read, rz_mtu3_enable) for child drivers, violating MFD subsystem guidelines.
- [High] The driver passes 0 instead of PLATFORM_DEVID_AUTO as the ID in devm_mfd_add_devices, risking sysfs naming collisions.
--

--- Patch [4]: [PATCH 04/11] mfd: rz-mtu3: store &pdev->dev in local variable ---
commit 99cfbc12a5f5e788a17b9baa33f5115c64650afc
Author: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>

mfd: rz-mtu3: store &pdev->dev in local variable

This commit introduces a local dev variable in rz_mtu3_probe() to store
&pdev->dev. It replaces multiple occurrences of &pdev->dev with this new
variable to simplify the code.

> diff --git a/drivers/mfd/rz-mtu3.c b/drivers/mfd/rz-mtu3.c
> index 3be6f6c900b82..37d12030e069c 100644
> --- a/drivers/mfd/rz-mtu3.c
> +++ b/drivers/mfd/rz-mtu3.c
[ ... ]
> @@ -347,7 +348,7 @@ static int rz_mtu3_probe(struct platform_device *pdev)
>  		mutex_init(&ddata->channels[i].lock);
>  	}
>  
> -	return devm_mfd_add_devices(&pdev->dev, 0, rz_mtu3_devs,
> +	return devm_mfd_add_devices(dev, 0, rz_mtu3_devs,
>  				    ARRAY_SIZE(rz_mtu3_devs), NULL, 0, NULL);
>  }

[Severity: High]
This isn't a bug introduced by this patch, but is a pre-existing API violation.
Does passing 0 instead of PLATFORM_DEVID_AUTO as the ID in
devm_mfd_add_devices() risk sysfs naming collisions?

According to MFD subsystem guidelines, using hard-coded IDs maps all cell
IDs to instance numbers, which can lead to device naming collisions in sysfs
and driver load failures.

While reviewing the file, I also noticed another pre-existing issue in the
parent driver:

[Severity: High]
This is a pre-existing issue, but the parent driver exports bespoke accessors
for child drivers. For example:

drivers/mfd/rz-mtu3.c:rz_mtu3_shared_reg_read() {
	struct rz_mtu3 *mtu = dev_get_drvdata(ch->dev->parent);
	struct rz_mtu3_priv *priv = mtu->priv_data;
...
}

Does exporting custom accessors like rz_mtu3_shared_reg_read() create tight
coupling between parent and child drivers?

The MFD guidelines indicate that custom parent-child accessors make refactoring
fragile and can lead to silent use-after-free bugs if lifetime mismatches
occur. Child drivers should prefer using standard APIs directly instead.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260327192425.438263-1-cosmin-gabriel.tanislav.xa@renesas.com?part=4