Re: [PATCH v2 4/4] ARM: dts: mediatek: mt6323: add EFUSE support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unchecked dereference of dev->parent when getting regmap.
--

commit f140540f16666ffd0b4a44edcb3b4ac15d83d749
Author: Roman Vivchar <rva333@protonmail.com>
ARM: dts: mediatek: mt6323: add EFUSE support

This commit adds the devicetree node for the mt6323 efuse to the mt6323
PMIC definition. It introduces the mediatek,mt6323-efuse compatible string
to instantiate the driver.

> diff --git a/arch/arm/boot/dts/mediatek/mt6323.dtsi b/arch/arm/boot/dts/mediatek/mt6323.dtsi
> index c230c865116d0..807e000a7ff64 100644
> --- a/arch/arm/boot/dts/mediatek/mt6323.dtsi
> +++ b/arch/arm/boot/dts/mediatek/mt6323.dtsi
> @@ -14,6 +14,10 @@ pmic: mt6323 {
>  		interrupt-controller;
>  		#interrupt-cells = <2>;
>  
> +		efuse {
> +			compatible = "mediatek,mt6323-efuse";

[Severity: High]
Does binding to this compatible string introduce a regression under certain
devicetree configurations?

Looking at drivers/nvmem/mt6323-efuse.c:mt6323_efuse_probe(), the driver
blindly traverses the parent hierarchy:

	/* efuse -> mfd -> pwrap */
	regmap = dev_get_regmap(dev->parent->parent, NULL);

If the device is instantiated directly at the root of a Device Tree
or via a malformed overlay, it lacks a grandparent. In this case,
dev->parent is initialized to &platform_bus, and evaluating
dev->parent->parent results in a null pointer.

Passing a null pointer as the device to dev_get_regmap() triggers an
immediate kernel panic during probe(), because the underlying
devres_find() unconditionally dereferences the dev pointer.

Could the driver verify that the parent hierarchy exists before
attempting to traverse it and retrieve the regmap?

> +		};
> +

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260617-mt6323-nvmem-v2-0-4f30e36aa0f4@protonmail.com?part=4