From: sashiko-bot@kernel.org
To: "Shenwei Wang" <shenwei.wang@oss.nxp.com>
Cc: imx@lists.linux.dev, conor+dt@kernel.org, robh@kernel.org,
Frank.Li@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v14 3/5] rpmsg: core: match rpmsg device IDs by prefix
Date: Thu, 25 Jun 2026 16:06:26 +0000 [thread overview]
Message-ID: <20260625160627.25F911F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260625155432.815185-4-shenwei.wang@oss.nxp.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Forcing global prefix matching on all rpmsg drivers without a 'longest-prefix match' rule can cause unintended device binding and collisions.
- [Medium] Module auto-loading via udev is broken for dynamically suffixed devices because module alias generation remains exact and lacks a trailing wildcard.
--
commit 7cf465d01393f57a212484ddaf8a931c40ec4179
Author: Shenwei Wang <shenwei.wang@nxp.com>
rpmsg: core: match rpmsg device IDs by prefix
This commit updates the rpmsg device matching logic to compare only the
length of the id->name string. This allows id_table entries to act as
prefixes, enabling drivers to bind to dynamically suffixed devices.
> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> index e7f7831d37f89..f95bfc9965d4c 100644
> --- a/drivers/rpmsg/rpmsg_core.c
> +++ b/drivers/rpmsg/rpmsg_core.c
> @@ -414,7 +414,9 @@ ATTRIBUTE_GROUPS(rpmsg_dev);
> static inline int rpmsg_id_match(const struct rpmsg_device *rpdev,
> const struct rpmsg_device_id *id)
> {
> - return strncmp(id->name, rpdev->id.name, RPMSG_NAME_SIZE) == 0;
> + size_t len = strnlen(id->name, RPMSG_NAME_SIZE);
> +
> + return strncmp(id->name, rpdev->id.name, len) == 0;
> }
[Severity: High]
Will this change cause unintended driver binding for existing drivers that
expect an exact match?
Because this modifies the global match behavior for all rpmsg drivers without
an opt-in flag or longest-prefix match logic, a shorter existing prefix could
hijack a new device.
For example, if a remote processor creates a channel named rpmsg-tty-control,
would it be incorrectly matched by an existing driver registered as rpmsg-tty?
Looking at rpmsg_dev_match(), the iteration returns on the first successful
match:
drivers/rpmsg/rpmsg_core.c:rpmsg_dev_match() {
...
for (i = 0; ids[i].name[0]; i++)
if (rpmsg_id_match(rpdev, &ids[i])) {
rpdev->id.driver_data = ids[i].driver_data;
return 1;
}
...
}
Could this result in a collision if multiple IDs share the same prefix?
[Severity: Medium]
Does this change break module auto-loading via udev for dynamically suffixed
devices?
When a dynamically suffixed device is registered, rpmsg_uevent() emits the
exact name:
drivers/rpmsg/rpmsg_core.c:rpmsg_uevent() {
...
return add_uevent_var(env, "MODALIAS=" RPMSG_DEVICE_MODALIAS_FMT,
rpdev->id.name);
}
However, the module alias generated by file2alias.c does not append a
wildcard for prefix matching:
scripts/mod/file2alias.c:do_rpmsg_entry() {
...
module_alias_printf(mod, false, RPMSG_DEVICE_MODALIAS_FMT, *name);
}
Since module_alias_printf() is called with append_wildcard set to false, the
generated alias will be an exact match (e.g., rpmsg:rpmsg-io-) which won't
match the uevent string (e.g., MODALIAS=rpmsg:rpmsg-io-1).
Will this prevent the module from loading automatically?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625155432.815185-1-shenwei.wang@oss.nxp.com?part=3
next prev parent reply other threads:[~2026-06-25 16:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 15:54 [PATCH v14 0/5] Enable Remote GPIO over RPMSG on i.MX Platform Shenwei Wang
2026-06-25 15:54 ` [PATCH v14 1/5] docs: driver-api: gpio: rpmsg gpio driver over rpmsg bus Shenwei Wang
2026-06-25 16:03 ` sashiko-bot
2026-06-25 15:54 ` [PATCH v14 2/5] dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode support Shenwei Wang
2026-06-25 16:00 ` sashiko-bot
2026-06-25 15:54 ` [PATCH v14 3/5] rpmsg: core: match rpmsg device IDs by prefix Shenwei Wang
2026-06-25 16:06 ` sashiko-bot [this message]
2026-06-25 15:54 ` [PATCH v14 4/5] gpio: rpmsg: add generic rpmsg GPIO driver Shenwei Wang
2026-06-25 16:04 ` sashiko-bot
2026-06-25 20:32 ` Andrew Davis
2026-06-25 22:17 ` Julian Braha
2026-06-25 15:54 ` [PATCH v14 5/5] arm64: dts: imx8ulp: Add rpmsg node under imx_rproc Shenwei Wang
2026-06-25 16:06 ` 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=20260625160627.25F911F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=imx@lists.linux.dev \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=shenwei.wang@oss.nxp.com \
/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.