From: sashiko-bot@kernel.org
To: "Link Mauve" <linkmauve@linkmauve.fr>
Cc: linux-amlogic@lists.infradead.org, ojeda@kernel.org,
gary@garyguo.net, Frank.Li@kernel.org, imx@lists.linux.dev,
neil.armstrong@linaro.org
Subject: Re: [PATCH v6 4/4] nvmem: enable COMPILE_TEST for more drivers
Date: Sun, 20 Sep 2026 11:23:51 +0000 [thread overview]
Message-ID: <20260920112351.E67771F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260920111000.2404131-5-linkmauve@linkmauve.fr>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] kconfig: missing HAS_IOMEM dependency for MMIO nvmem drivers under COMPILE_TEST
--
commit 0ff6b9a5ebbc0d11589f22b1d652ffd1483b0718
Author: Link Mauve <linkmauve@linkmauve.fr>
nvmem: enable COMPILE_TEST for more drivers
This commit enables COMPILE_TEST for three nvmem drivers (NVMEM_S32G_OCOTP,
NVMEM_SUNXI_SID, and NVMEM_ZYNQMP) that previously depended strictly on their
target architectures. This allows the drivers to be built for coverage testing
across different architectures.
> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> index c36c2a4c2a0b7..d38097d6648bd 100644
> --- a/drivers/nvmem/Kconfig
> +++ b/drivers/nvmem/Kconfig
> @@ -354,7 +354,7 @@ config NVMEM_NINTENDO_OTP
>
> config NVMEM_S32G_OCOTP
> tristate "S32G SoC OCOTP support"
> - depends on ARCH_S32
> + depends on ARCH_S32 || COMPILE_TEST
[Severity: Low]
Does adding COMPILE_TEST here expose this driver to build errors on
architectures without HAS_IOMEM?
Because config NVMEM_S32G_OCOTP exposes MMIO operations, a user configuring
the kernel with COMPILE_TEST enabled on an architecture that does not select
HAS_IOMEM (such as User Mode Linux) will encounter linker errors. Adding a
dependency on HAS_IOMEM would prevent this build failure.
> help
> This is a driver for the 'OCOTP' peripheral available on S32G
> platforms.
[ ... ]
> @@ -518,7 +518,7 @@ config NVMEM_SUNPLUS_OCOTP
>
> config NVMEM_SUNXI_SID
> tristate "Allwinner SoCs SID support"
> - depends on ARCH_SUNXI
> + depends on ARCH_SUNXI || COMPILE_TEST
[Severity: Low]
Can this cause an undefined reference to __ioread32_copy during the build?
The NVMEM_SUNXI_SID driver calls __ioread32_copy() in sunxi_sid.c. This
function is implemented in lib/iomap_copy.c, which is only compiled if
CONFIG_HAS_IOMEM is set. Compiling this driver under COMPILE_TEST on
architectures without HAS_IOMEM results in a linker error. Should this
config also depend on HAS_IOMEM?
> help
> This is a driver for the 'security ID' available on various Allwinner
> devices.
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260920111000.2404131-1-linkmauve@linkmauve.fr?part=4
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Link Mauve" <linkmauve@linkmauve.fr>
Cc: linux-amlogic@lists.infradead.org, ojeda@kernel.org,
gary@garyguo.net, Frank.Li@kernel.org, imx@lists.linux.dev,
neil.armstrong@linaro.org
Subject: Re: [PATCH v6 4/4] nvmem: enable COMPILE_TEST for more drivers
Date: Sun, 20 Sep 2026 11:23:51 +0000 [thread overview]
Message-ID: <20260920112351.E67771F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260920111000.2404131-5-linkmauve@linkmauve.fr>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] kconfig: missing HAS_IOMEM dependency for MMIO nvmem drivers under COMPILE_TEST
--
commit 0ff6b9a5ebbc0d11589f22b1d652ffd1483b0718
Author: Link Mauve <linkmauve@linkmauve.fr>
nvmem: enable COMPILE_TEST for more drivers
This commit enables COMPILE_TEST for three nvmem drivers (NVMEM_S32G_OCOTP,
NVMEM_SUNXI_SID, and NVMEM_ZYNQMP) that previously depended strictly on their
target architectures. This allows the drivers to be built for coverage testing
across different architectures.
> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> index c36c2a4c2a0b7..d38097d6648bd 100644
> --- a/drivers/nvmem/Kconfig
> +++ b/drivers/nvmem/Kconfig
> @@ -354,7 +354,7 @@ config NVMEM_NINTENDO_OTP
>
> config NVMEM_S32G_OCOTP
> tristate "S32G SoC OCOTP support"
> - depends on ARCH_S32
> + depends on ARCH_S32 || COMPILE_TEST
[Severity: Low]
Does adding COMPILE_TEST here expose this driver to build errors on
architectures without HAS_IOMEM?
Because config NVMEM_S32G_OCOTP exposes MMIO operations, a user configuring
the kernel with COMPILE_TEST enabled on an architecture that does not select
HAS_IOMEM (such as User Mode Linux) will encounter linker errors. Adding a
dependency on HAS_IOMEM would prevent this build failure.
> help
> This is a driver for the 'OCOTP' peripheral available on S32G
> platforms.
[ ... ]
> @@ -518,7 +518,7 @@ config NVMEM_SUNPLUS_OCOTP
>
> config NVMEM_SUNXI_SID
> tristate "Allwinner SoCs SID support"
> - depends on ARCH_SUNXI
> + depends on ARCH_SUNXI || COMPILE_TEST
[Severity: Low]
Can this cause an undefined reference to __ioread32_copy during the build?
The NVMEM_SUNXI_SID driver calls __ioread32_copy() in sunxi_sid.c. This
function is implemented in lib/iomap_copy.c, which is only compiled if
CONFIG_HAS_IOMEM is set. Compiling this driver under COMPILE_TEST on
architectures without HAS_IOMEM results in a linker error. Should this
config also depend on HAS_IOMEM?
> help
> This is a driver for the 'security ID' available on various Allwinner
> devices.
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260920111000.2404131-1-linkmauve@linkmauve.fr?part=4
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2026-09-20 11:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-20 11:09 [PATCH v6 0/4] nvmem: migrate to const void * in reg_write Link Mauve
2026-09-20 11:09 ` Link Mauve
2026-09-20 11:09 ` [PATCH v6 1/4] firmware: meson: pass a const buffer to meson_sm_call_write() Link Mauve
2026-09-20 11:09 ` Link Mauve
2026-09-20 11:09 ` [PATCH v6 2/4] nvmem: core: deprecate reg_write callback with reg_write_const Link Mauve
2026-09-20 11:09 ` Link Mauve
2026-09-20 11:19 ` sashiko-bot
2026-09-20 11:19 ` sashiko-bot
2026-09-20 11:09 ` [PATCH v6 3/4] nvmem: make all reg_write callbacks take const void * Link Mauve
2026-09-20 11:09 ` Link Mauve
2026-09-20 11:09 ` [PATCH v6 4/4] nvmem: enable COMPILE_TEST for more drivers Link Mauve
2026-09-20 11:09 ` Link Mauve
2026-09-20 11:23 ` sashiko-bot [this message]
2026-09-20 11:23 ` sashiko-bot
2026-09-20 11:18 ` [PATCH v6 0/4] nvmem: migrate to const void * in reg_write Link Mauve
2026-09-20 11:18 ` Link Mauve
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=20260920112351.E67771F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=gary@garyguo.net \
--cc=imx@lists.linux.dev \
--cc=linkmauve@linkmauve.fr \
--cc=linux-amlogic@lists.infradead.org \
--cc=neil.armstrong@linaro.org \
--cc=ojeda@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.