From: sashiko-bot@kernel.org
To: "Roman Vivchar" <rva333@protonmail.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v3 2/3] nvmem: add mt6323 PMIC EFUSE driver
Date: Mon, 13 Jul 2026 10:26:41 +0000 [thread overview]
Message-ID: <20260713102642.385C31F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260713-mt6323-nvmem-v3-2-205c39267a24@protonmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The driver blindly dereferences `dev->parent->parent` to retrieve the regmap, which causes a NULL pointer dereference kernel panic if instantiated outside the expected MFD hierarchy, and violates MFD subsystem guidelines.
--
--- Patch [2]: [PATCH v3 2/3] nvmem: add mt6323 PMIC EFUSE driver ---
commit 25fbde0741e1e6a18bf5c1f7cc92f4eb70b9d17e
Author: Roman Vivchar <rva333@protonmail.com>
nvmem: add mt6323 PMIC EFUSE driver
This commit adds support for the EFUSE controller found in the Mediatek
MT6323 PMIC, which stores 24 bytes of hardware-related data.
> diff --git a/drivers/nvmem/mt6323-efuse.c b/drivers/nvmem/mt6323-efuse.c
> new file mode 100644
> index 0000000000000..41678915d5b62
> --- /dev/null
> +++ b/drivers/nvmem/mt6323-efuse.c
[ ... ]
> +static int mt6323_efuse_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct nvmem_config config = {
> + .name = "mt6323-efuse",
> + .stride = 2,
> + .word_size = 2,
> + .size = MT6323_EFUSE_SIZE,
> + .reg_read = mt6323_efuse_read,
> + };
> + struct nvmem_device *nvmem;
> + struct regmap *regmap;
> +
> + /* efuse -> mfd -> pwrap */
> + regmap = dev_get_regmap(dev->parent->parent, NULL);
[Severity: High]
Can this cause a NULL pointer dereference if the device is instantiated
outside the expected MFD hierarchy?
If the device is instantiated directly via a Device Tree root node overlay or
through sysfs, dev->parent could be the platform_bus. Because the
platform_bus has no parent, evaluating dev->parent->parent would result in
NULL.
Passing NULL to dev_get_regmap() leads to an immediate kernel panic when
devres_find() unconditionally locks the devres_lock.
Additionally, MFD subsystem guidelines recommend that child drivers retrieve
data using standard APIs without relying on hard-coded assumptions about
grandparent device topology.
> + if (!regmap)
> + return dev_err_probe(dev, -ENODEV, "failed to get regmap\n");
> +
> + config.dev = dev;
> + config.priv = regmap;
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260713-mt6323-nvmem-v3-0-205c39267a24@protonmail.com?part=2
next prev parent reply other threads:[~2026-07-13 10:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-13 10:11 [PATCH v3 0/3] nvmem: add support for the MediaTek mt6323 PMIC Roman Vivchar via B4 Relay
2026-07-13 10:11 ` Roman Vivchar
2026-07-13 10:11 ` [PATCH v3 1/3] dt-bindings: mfd: mediatek: mt6397: add mt6323 PMIC EFUSE Roman Vivchar via B4 Relay
2026-07-13 10:11 ` Roman Vivchar
2026-07-13 10:19 ` sashiko-bot
2026-07-13 10:11 ` [PATCH v3 2/3] nvmem: add mt6323 PMIC EFUSE driver Roman Vivchar via B4 Relay
2026-07-13 10:11 ` Roman Vivchar
2026-07-13 10:26 ` sashiko-bot [this message]
2026-07-13 10:11 ` [PATCH v3 3/3] ARM: dts: mediatek: mt6323: add EFUSE support Roman Vivchar via B4 Relay
2026-07-13 10:11 ` Roman Vivchar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260713102642.385C31F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=robh@kernel.org \
--cc=rva333@protonmail.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.