All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Roman Vivchar via B4 Relay" <devnull+rva333.protonmail.com@kernel.org>
Cc: robh@kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH 2/4] nvmem: add mt6323 PMIC EFUSE driver
Date: Thu, 11 Jun 2026 10:34:49 +0000	[thread overview]
Message-ID: <20260611103449.889D31F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260611-mt6323-nvmem-v1-2-b5e1b9ce51f2@protonmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Blind dereference of `dev->parent->parent` can lead to a kernel panic if the device is not instantiated with the expected MFD hierarchy.
--

commit 227574270c722d2b535d72fadcf31ba55bc47f8e
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. It introduces a new nvmem driver that reads 24 bytes of
hardware-related data using regmap over the PMIC wrapper.

> diff --git a/drivers/nvmem/mt6323-efuse.c b/drivers/nvmem/mt6323-efuse.c
> new file mode 100644
> index 0000000000000..c6fbfd96ac047
> --- /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]
Is it possible for dev->parent to be NULL here?

Because the driver defines an of_match_table, it might be instantiated directly
by the OF core or bound manually via sysfs, bypassing the MFD subsystem.

If dev->parent is NULL, evaluating dev->parent->parent will cause an immediate
NULL pointer dereference. Furthermore, if dev->parent is valid but has no
parent, dev->parent->parent evaluates to NULL. Passing a NULL device pointer to
dev_get_regmap() causes a fatal NULL pointer dereference inside devres_find()
when it attempts to acquire the devres_lock.

Would it be safer to explicitly verify that both dev->parent and
dev->parent->parent are non-NULL before dereferencing them?

> +	if (!regmap)
> +		return dev_err_probe(dev, -ENODEV, "failed to get regmap\n");
> +
> +	config.dev = dev;
> +	config.priv = regmap;
> +
> +	nvmem = devm_nvmem_register(dev, &config);
> +	return PTR_ERR_OR_ZERO(nvmem);
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260611-mt6323-nvmem-v1-0-b5e1b9ce51f2@protonmail.com?part=2

  reply	other threads:[~2026-06-11 10:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-11 10:20 [PATCH 0/4] nvmem: add support for the MediaTek mt6323 PMIC Roman Vivchar via B4 Relay
2026-06-11 10:20 ` Roman Vivchar
2026-06-11 10:20 ` [PATCH 1/4] dt-bindings: mfd: mediatek: mt6397: add mt6323 PMIC EFUSE Roman Vivchar via B4 Relay
2026-06-11 10:20   ` Roman Vivchar
2026-06-11 10:30   ` sashiko-bot
2026-06-11 17:22   ` Conor Dooley
2026-06-11 10:20 ` [PATCH 2/4] nvmem: add mt6323 PMIC EFUSE driver Roman Vivchar via B4 Relay
2026-06-11 10:20   ` Roman Vivchar
2026-06-11 10:34   ` sashiko-bot [this message]
2026-06-11 16:13   ` Andy Shevchenko
2026-06-11 10:20 ` [PATCH 3/4] mfd: mt6397-core: add mt6323 EFUSE support Roman Vivchar via B4 Relay
2026-06-11 10:20   ` Roman Vivchar
2026-06-11 10:20 ` [PATCH 4/4] ARM: dts: mediatek: mt6323: add " Roman Vivchar via B4 Relay
2026-06-11 10:20   ` 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=20260611103449.889D31F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=devnull+rva333.protonmail.com@kernel.org \
    --cc=robh@kernel.org \
    --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.