All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Francesco Valla" <francesco@valla.it>
Cc: "Eugenio Perez" <eperezma@redhat.com>,
	imx@lists.linux.dev, virtualization@lists.linux.dev,
	Frank.Li@kernel.org, devicetree@vger.kernel.org,
	conor+dt@kernel.org, robh@kernel.org,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [PATCH RFC 12/12] PoC: arm64: dts: imx93-11x11-frdm: add multiple vdevs
Date: Wed, 16 Sep 2026 22:07:34 +0000	[thread overview]
Message-ID: <20260916220735.4D73D1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260916-remoteproc_virtio_map-v1-12-dac8c5eb4aa9@valla.it>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] dts: virtio device nodes are ignored due to missing of_node linkage in remoteproc
- [Medium] Process: Patch is a Proof-Of-Concept and not meant for integration
--

commit a7b0e29a0ba6644ce08c06f5c058683c28280b67
Author: Francesco Valla <francesco@valla.it>

PoC: arm64: dts: imx93-11x11-frdm: add multiple vdevs

This commit adds rings for multiple vdevs and the required virtio nodes for
I2C, SPI, and GPIO functionalities to the imx93-11x11-frdm devicetree. It
also includes example peripherals to demonstrate these virtio interfaces.

>     NOTE: this is a Proof-Of-Concept, not meant to be integrated!

[Severity: Medium]
Since this patch is explicitly marked as a Proof-Of-Concept and not meant for
integration, should it be dropped from the queue to prevent merging unstable
or incomplete code?

> diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts
> index bd14ba28690c0..dfa3b122ac5f4 100644
> --- a/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts
> +++ b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts
> @@ -53,6 +53,32 @@ button-k3 {
>  		};
>  	};
>  
> +	gpio-keys-virtio {
> +		compatible = "gpio-keys-polled";
> +		poll-interval = <100>;
> +
> +		button-v1 {
> +			label = "Button V1";
> +			linux,code = <BTN_3>;
> +			gpios = <&v_gpio 23 GPIO_ACTIVE_LOW>;
> +		};

[Severity: High]
Will the v_gpio phandle fail to resolve because the v_gpio node is not
recognized as a valid OF GPIO controller by the system?

[ ... ]

> @@ -149,8 +200,67 @@ &cm33 {
>  		 <&mu1 3 1>;
>  	mbox-names = "tx", "rx", "rxdb";
>  	memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
> -			<&vdev1vring0>, <&vdev1vring1>, <&rsc_table>;
> +			<&vdev1vring0>, <&vdev2vring0>, <&vdev2vring1>,
> +			<&vdev3vring0>, <&vdev4vring0>,
> +			<&vdev5vring0>, <&vdev5vring1>, <&vdev5vring2>;
>  	status = "okay";
> +
> +	virtio {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		vdev@2 {
> +			reg = <2>;
> +
> +			v_gpio: gpio {
> +				compatible = "virtio,device29";

[Severity: High]
Will these virtio subnodes remain unlinked to the actual devices?

virtio_device_of_init() attempts to match devicetree nodes by checking
dev_of_node(dev->dev.parent). For remoteproc-created virtio devices, the
parent is the dynamically created rproc-virtio platform device (created in
rproc_handle_vdev()), which is never assigned an of_node.

Does this result in the devicetree matching failing silently, causing
dependent peripheral drivers (e.g., gpio-keys) to defer probing indefinitely?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260916-remoteproc_virtio_map-v1-0-dac8c5eb4aa9@valla.it?part=12

  reply	other threads:[~2026-09-16 22:07 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-16 21:10 [PATCH RFC 00/12] remoteproc: add support for any virtio device Francesco Valla
2026-09-16 21:10 ` [PATCH RFC 01/12] remoteproc: virtio: cleanup rproc_add_virtio_dev error path Francesco Valla
2026-09-16 21:56   ` sashiko-bot
2026-09-16 21:10 ` [PATCH RFC 02/12] remoteproc: virtio: replace commas with semicolons Francesco Valla
2026-09-16 21:58   ` sashiko-bot
2026-09-16 21:10 ` [PATCH RFC 03/12] remoteproc: virtio: support dynamic number of vrings Francesco Valla
2026-09-16 22:00   ` sashiko-bot
2026-09-16 21:10 ` [PATCH RFC 04/12] dma-coherent: add base and size APIs Francesco Valla
2026-09-16 21:55   ` sashiko-bot
2026-09-16 21:10 ` [PATCH RFC 05/12] remoteproc: always report VIRTIO_F_VERSION_1 feature Francesco Valla
2026-09-16 22:00   ` sashiko-bot
2026-09-21 15:47   ` Mathieu Poirier
2026-09-22  6:32     ` Francesco Valla
2026-09-22 15:10       ` Mathieu Poirier
2026-09-16 21:10 ` [PATCH RFC 06/12] remoteproc: virtio: add bounce buffering for data buffers Francesco Valla
2026-09-16 22:03   ` sashiko-bot
2026-09-22 15:58   ` Mathieu Poirier
2026-09-22 19:39     ` Francesco Valla
2026-09-23 14:44       ` Mathieu Poirier
2026-09-23 16:05         ` Francesco Valla
2026-09-25 15:07           ` Mathieu Poirier
2026-09-25 16:48             ` Robin Murphy
2026-09-25 19:05               ` Francesco Valla
2026-09-27 22:12                 ` Francesco Valla
2026-09-25 17:03   ` Robin Murphy
2026-09-16 21:10 ` [PATCH RFC 07/12] dt-bindings: spi: add bindings for spi-virtio Francesco Valla
2026-09-16 21:52   ` sashiko-bot
2026-09-16 21:10 ` [PATCH RFC 08/12] dt-bindings: remoteproc: add remoteproc-virtio Francesco Valla
2026-09-16 21:56   ` sashiko-bot
2026-09-22 15:40   ` Mathieu Poirier
2026-09-22 19:44     ` Francesco Valla
2026-09-23 14:56       ` Mathieu Poirier
2026-10-06 18:39       ` Rob Herring
2026-10-07  0:51         ` Mathieu Poirier
2026-10-07 13:42           ` Rob Herring
2026-10-07 16:34             ` Francesco Valla
2026-09-16 21:10 ` [PATCH RFC 09/12] remoteproc: search for a fwnode during vdev registration Francesco Valla
2026-09-16 21:58   ` sashiko-bot
2026-09-16 21:10 ` [PATCH RFC 10/12] remoteproc: imx_rproc: always use non-blocking mailboxes Francesco Valla
2026-09-16 22:05   ` sashiko-bot
2026-09-16 21:10 ` [PATCH RFC 11/12] dt-bindings: remoteproc: imx-rproc: support virtio Francesco Valla
2026-09-16 22:04   ` sashiko-bot
2026-09-16 21:10 ` [PATCH RFC 12/12] PoC: arm64: dts: imx93-11x11-frdm: add multiple vdevs Francesco Valla
2026-09-16 22:07   ` sashiko-bot [this message]
2026-09-22 15:43   ` Mathieu Poirier
2026-09-22 20:19     ` Francesco Valla
2026-09-23 15:48       ` Mathieu Poirier
2026-09-23 18:42         ` Francesco Valla
2026-09-24 15:49           ` Mathieu Poirier
2026-09-25 19:13             ` Francesco Valla
2026-10-09  4:27           ` Peng Fan
2026-09-25  8:39   ` Alexander Stein
2026-09-25 19:26     ` Francesco Valla
2026-09-18 16:53 ` [PATCH RFC 00/12] remoteproc: add support for any virtio device Mathieu Poirier
2026-09-19  7:33   ` Francesco Valla
2026-09-21  3:31     ` Mathieu Poirier
2026-09-22  6:28       ` Francesco Valla
2026-09-22 13:53         ` Mathieu Poirier
2026-09-23 15:13 ` Robin Murphy

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=20260916220735.4D73D1F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=eperezma@redhat.com \
    --cc=francesco@valla.it \
    --cc=imx@lists.linux.dev \
    --cc=mst@redhat.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=virtualization@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.