From: sashiko-bot@kernel.org
To: "Jisheng Zhang" <jszhang@kernel.org>
Cc: conor+dt@kernel.org, Frank.Li@kernel.org, lee@kernel.org,
devicetree@vger.kernel.org, linux-i3c@lists.infradead.org,
linux-serial@vger.kernel.org, robh@kernel.org,
mfd@lists.linux.dev,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
linux-clk@vger.kernel.org
Subject: Re: [PATCH 11/20] pinctrl: berlin: enable module build support
Date: Tue, 29 Sep 2026 06:45:51 +0000 [thread overview]
Message-ID: <20260929064552.1D7591F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260929061417.20733-12-jszhang@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] pinctrl: berlin: missing Kconfig/Makefile changes for module build
--
commit 90017c53ecb9e3f7c921f299ee20085471283f78
Author: Jisheng Zhang <jszhang@kernel.org>
pinctrl: berlin: enable module build support
This commit updates the berlin pinctrl library to use devres allocation APIs,
exports necessary symbols, and adds module metadata. This is intended to allow
building the drivers as loadable modules for vendor_dlkm deployments.
> For Android GKI + vendor_dlkm deployments, where vendor-specific
> drivers must be kept separate from the GKI vmlinux and loaded as
> modules from the vendor partition, we need to enable module build
> support for berlin pinctrl drivers.
[Severity: High]
Are Kconfig and Makefile updates also needed to fully enable module support?
The commit message states the goal is to enable module builds, but Kconfig
and Makefile changes appear to be missing from the patch.
In drivers/pinctrl/berlin/Kconfig, PINCTRL_BERLIN is currently restricted
to bool:
config PINCTRL_BERLIN
bool
In drivers/pinctrl/berlin/Makefile, berlin.o is unconditionally built-in:
obj-y += berlin.o
Without changing these to use a tristate and obj-$(CONFIG_PINCTRL_BERLIN),
the object is compiled into a built-in archive during a module build. It is
never linked into the loadable module, which causes undefined references to
berlin_pinctrl_probe during driver loading.
Additionally, does builtin_platform_driver() in the SoC drivers prevent them
from being built as modules?
For example, in drivers/pinctrl/berlin/berlin-bg2.c:
builtin_platform_driver(berlin2_pinctrl_driver);
Would this need to be updated to module_platform_driver() to allow existing
SoC drivers to be built as loadable modules alongside the core library?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260929061417.20733-1-jszhang@kernel.org?part=11
next prev parent reply other threads:[~2026-09-29 6:45 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 6:13 [PATCH 00/20] arm64: add Synaptics SL261X SoCs and RDK boards Jisheng Zhang
2026-09-29 6:13 ` [PATCH 01/20] dt-bindings: serial: snps-dw-apb-uart: Add Synaptics sl261x uart Jisheng Zhang
2026-09-29 6:44 ` sashiko-bot
2026-09-29 6:13 ` [PATCH 02/20] dt-bindings: i2c: dw: Add Synaptics sl261x i2c Jisheng Zhang
2026-09-29 6:39 ` sashiko-bot
2026-09-29 20:57 ` Andi Shyti
2026-09-29 6:14 ` [PATCH 03/20] spi: dt-bindings: snps,dw-apb-ssi: Add Synaptics sl261x spi Jisheng Zhang
2026-09-29 6:39 ` sashiko-bot
2026-09-29 6:14 ` [PATCH 04/20] dt-bindings: i3c: dw: support up to two reset lines Jisheng Zhang
2026-09-29 6:43 ` sashiko-bot
2026-09-29 19:40 ` Conor Dooley
2026-09-29 6:14 ` [PATCH 05/20] i3c: dw: switch to array-based exclusive reset control Jisheng Zhang
2026-09-29 6:45 ` sashiko-bot
2026-09-29 15:01 ` Frank Li
2026-09-29 6:14 ` [PATCH 06/20] dt-bindings: i3c: Add Synaptics sl261x i3c Jisheng Zhang
2026-09-29 6:41 ` sashiko-bot
2026-09-29 6:14 ` [PATCH 07/20] arm64: kconfig: let ARCH_BERLIN cover Synaptics arm64 SoCs Jisheng Zhang
2026-09-29 6:40 ` sashiko-bot
2026-09-29 6:14 ` [PATCH 08/20] dt-bindings: reset: add Synaptics SL261X SoCs Jisheng Zhang
2026-09-29 6:42 ` sashiko-bot
2026-09-29 19:44 ` Conor Dooley
2026-09-30 15:15 ` Jisheng Zhang
2026-09-30 16:49 ` Conor Dooley
2026-10-02 15:35 ` Jisheng Zhang
2026-10-05 10:50 ` Conor Dooley
2026-09-29 6:14 ` [PATCH 09/20] reset: add Synaptics SL261x reset support Jisheng Zhang
2026-09-29 6:47 ` sashiko-bot
2026-09-29 6:14 ` [PATCH 10/20] pinctrl: berlin: use u16 instead of u8 for the offset Jisheng Zhang
2026-09-29 6:42 ` sashiko-bot
2026-09-29 6:14 ` [PATCH 11/20] pinctrl: berlin: enable module build support Jisheng Zhang
2026-09-29 6:45 ` sashiko-bot [this message]
2026-09-29 6:14 ` [PATCH 12/20] pinctrl: berlin: add optional pinconf support Jisheng Zhang
2026-09-29 6:45 ` sashiko-bot
2026-09-29 6:14 ` [PATCH 13/20] dt-bindings: pinctrl: berlin: Support Synaptics SL261X SoCs Jisheng Zhang
2026-09-29 6:45 ` sashiko-bot
2026-09-29 6:14 ` [PATCH 14/20] pinctrl: berlin: support " Jisheng Zhang
2026-09-29 6:47 ` sashiko-bot
2026-09-29 15:34 ` Uwe Kleine-König
2026-09-29 6:14 ` [PATCH 15/20] dt-bindings: clock: add Synaptics SL261X clock Jisheng Zhang
2026-09-29 6:44 ` sashiko-bot
2026-09-29 19:46 ` Conor Dooley
2026-09-29 20:49 ` Rob Herring (Arm)
2026-09-30 14:18 ` Jisheng Zhang
2026-09-29 6:14 ` [PATCH 16/20] clk: berlin: add Synaptics SL261X SoC clocks and plls Jisheng Zhang
2026-09-29 6:50 ` sashiko-bot
2026-09-29 6:14 ` [PATCH 17/20] dt-bindings: mfd: Add Synaptics SL261x global block binding Jisheng Zhang
2026-09-29 6:45 ` sashiko-bot
2026-09-29 19:55 ` Conor Dooley
2026-09-29 6:14 ` [PATCH 18/20] regulator: dt-bindings: sy8827n: support standard properties Jisheng Zhang
2026-09-29 6:40 ` sashiko-bot
2026-09-29 19:40 ` Conor Dooley
2026-09-29 6:14 ` [PATCH 19/20] dt-bindings: arm: berlin: Add Synaptics SL261X SoC and RDK board Jisheng Zhang
2026-09-29 6:53 ` sashiko-bot
2026-09-29 6:14 ` [PATCH 20/20] arm64: dts: synaptics: " Jisheng Zhang
2026-09-29 6:52 ` sashiko-bot
2026-09-29 19:38 ` [PATCH 00/20] arm64: add Synaptics SL261X SoCs and RDK boards Conor Dooley
2026-09-30 14:15 ` Jisheng Zhang
2026-09-30 14:32 ` Jisheng Zhang
2026-09-30 16:35 ` Conor Dooley
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=20260929064552.1D7591F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jszhang@kernel.org \
--cc=lee@kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-i3c@lists.infradead.org \
--cc=linux-serial@vger.kernel.org \
--cc=mfd@lists.linux.dev \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox