All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Roman Vivchar" <rva333@protonmail.com>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v2 2/3] nvmem: mtk-efuse: add support for 32-bit aligned reads
Date: Fri, 24 Jul 2026 11:40:18 +0000	[thread overview]
Message-ID: <20260724114019.1DF161F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260724-6572-nvmem-v2-2-e58d16a29621@protonmail.com>

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

New issues:
- [Medium] The mt6572 configuration and OF match entries are missing, rendering `mtk_reg_read_aligned` dead code.

Pre-existing issues:
- [High] Dereference of `pdata` without a NULL pointer check causes a kernel panic if `device_get_match_data()` returns NULL.
--

--- Patch [2]: [PATCH v2 2/3] nvmem: mtk-efuse: add support for 32-bit aligned reads ---
commit 9dba40bd7cf45894283042b51926cffdb798412f
Author: Roman Vivchar <rva333@protonmail.com>

nvmem: mtk-efuse: add support for 32-bit aligned reads

This commit introduces a helper mtk_reg_read_aligned to enforce 32-bit
aligned register access for MediaTek SoCs like mt6572 that do not support
8-bit reads. It conditionally uses this new read function based on the
needs_aligned_read flag in the device's platform data.

> diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
> index af953e1d92302..178b9d85f813e 100644
> --- a/drivers/nvmem/mtk-efuse.c
> +++ b/drivers/nvmem/mtk-efuse.c
[ ... ]
> @@ -82,7 +108,12 @@ static int mtk_efuse_probe(struct platform_device *pdev)
>  	econfig.add_legacy_fixed_of_cells = true;
>  	econfig.stride = 1;
>  	econfig.word_size = 1;
> -	econfig.reg_read = mtk_reg_read;
> +
> +	if (pdata->needs_aligned_read)

[Severity: High]
This is a pre-existing issue, but it appears pdata can be NULL if the
device is instantiated without an OF/ACPI node (e.g., via sysfs manual
binding).

Since pdata is acquired via device_get_match_data(), won't unconditionally
dereferencing it here cause a kernel panic when matched by name instead of
device tree?

> +		econfig.reg_read = mtk_reg_read_aligned;
> +	else
> +		econfig.reg_read = mtk_reg_read;
> +
>  	econfig.size = resource_size(res);
>  	econfig.priv = priv;
>  	econfig.dev = dev;
> @@ -103,10 +134,12 @@ static int mtk_efuse_probe(struct platform_device *pdev)
>  
>  static const struct mtk_efuse_pdata mtk_mt8186_efuse_pdata = {
>  	.uses_post_processing = true,
> +	.needs_aligned_read = false,
>  };
>  
>  static const struct mtk_efuse_pdata mtk_efuse_pdata = {
>  	.uses_post_processing = false,
> +	.needs_aligned_read = false,
>  };
>  
>  static const struct of_device_id mtk_efuse_of_match[] = {

[Severity: Medium]
The commit message mentions adding support for the mt6572 SoC, but are the
mtk_mt6572_efuse_pdata struct and the mediatek,mt6572-efuse compatible string
missing from mtk_efuse_of_match[]?

Without these entries, will mtk_reg_read_aligned() remain unreachable dead
code since needs_aligned_read is never true?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260724-6572-nvmem-v2-0-e58d16a29621@protonmail.com?part=2

  reply	other threads:[~2026-07-24 11:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-24 11:07 [PATCH v2 0/3] nvmem: mtk-efuse: mt6572 support Roman Vivchar via B4 Relay
2026-07-24 11:07 ` Roman Vivchar
2026-07-24 11:07 ` [PATCH v2 1/3] dt-bindings: nvmem: mediatek: efuse: add mt6572 Roman Vivchar via B4 Relay
2026-07-24 11:07   ` Roman Vivchar
2026-07-24 11:37   ` sashiko-bot
2026-07-24 11:07 ` [PATCH v2 2/3] nvmem: mtk-efuse: add support for 32-bit aligned reads Roman Vivchar via B4 Relay
2026-07-24 11:07   ` Roman Vivchar
2026-07-24 11:40   ` sashiko-bot [this message]
2026-07-24 11:07 ` [PATCH v2 3/3] nvmem: mtk-efuse: add mt6572 support Roman Vivchar via B4 Relay
2026-07-24 11:07   ` Roman Vivchar
2026-07-24 11:40   ` sashiko-bot

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=20260724114019.1DF161F000E9@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.