From: Cristian Marussi <cristian.marussi@arm.com>
To: Junnan Wu <junnan01.wu@samsung.com>
Cc: sudeep.holla@arm.com, cristian.marussi@arm.com,
florian.fainelli@broadcom.com, arm-scmi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, lei19.wang@samsung.com,
q1.huang@samsung.com
Subject: Re: [PATCH] firmware: arm_scmi: Set device ready before register scmi_virtio_driver
Date: Tue, 19 Aug 2025 13:33:10 +0100 [thread overview]
Message-ID: <aKRvBrRstEFDu93g@pluto> (raw)
In-Reply-To: <20250812075343.3201365-1-junnan01.wu@samsung.com>
On Tue, Aug 12, 2025 at 03:53:43PM +0800, Junnan Wu wrote:
> Fix irregularities in scmi driver probe.
>
Good catch, thanks for this: indeed after the transports have been
converted to modules the probe sequence changed a bit and we cannot
leverage anymore the virtio_device_ready() called by the core in
virtio_dev_probe() since the scmi_vio_probe() does not complete until
the core SCMI stack has probed with scmi_probe() which in turn transmits
the first BASE protocol exchanges.
I did not know about this behaviour of type_1 hyp..
> After 'commit 20bda12a0ea0 ("firmware: arm_scmi: Make VirtIO transport a standalone driver")'
> making SCMI VirtIO transport a standalone driver,
> `scmi_virtio_probe` will follow `scmi_vio_probe`,
> and during `scmi_virtio_probe`, it will do `scmi_probe` which will invoke
> function `scmi_protocol_acquire(handle, SCMI_PROTOCOL_BASE)`,
> and this function will send message via virtqueue and wait device's reply
>
> Before this patch, only after `scmi_vio_probe`,
> frontend will mark device DRIVER_OK by function `virtio_dev_probe`
> in 'drivers/virtio/virtio.c' itself.
>
> Accroding to chapter '3.1 Device Initialization' in virtio-spec,
> ```
> The driver MUST NOT send any buffer available notifications
> to the device before setting DRIVER_OK.
> ```
>
> In some type1-hypervisor, available buffer notifications
> will be intercepted until virtio driver is okay. In this case,
> `scmi_vio_probe` will be blocked at `scmi_wait_for_reply`
> and probe can never complete.
>
> Therefore, the operation to set DRIVER_OK must follow
> perform device-specific setup immediately,
> then available buffer notifications can be sent in function `scmi_probe`.
>
> Fixes: 20bda12a0ea0 ("firmware: arm_scmi: Make VirtIO transport a standalone driver")
> Signed-off-by: Junnan Wu <junnan01.wu@samsung.com>
> ---
> drivers/firmware/arm_scmi/transports/virtio.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/firmware/arm_scmi/transports/virtio.c b/drivers/firmware/arm_scmi/transports/virtio.c
> index cb934db9b2b4..326c4a93e44b 100644
> --- a/drivers/firmware/arm_scmi/transports/virtio.c
> +++ b/drivers/firmware/arm_scmi/transports/virtio.c
> @@ -871,6 +871,9 @@ static int scmi_vio_probe(struct virtio_device *vdev)
> /* Ensure initialized scmi_vdev is visible */
> smp_store_mb(scmi_vdev, vdev);
>
> + /* Set device ready */
> + virtio_device_ready(vdev);
> +
> ret = platform_driver_register(&scmi_virtio_driver);
> if (ret) {
> vdev->priv = NULL;
...also, I suppose, that here nothing is to be done on the error path
regarding the vdedv status, becasue is already taken care in the error
path of virtio_dev_probe()...am I right ? (just confirming..)
Maybe you could simplify a bit the commit message but other than this
LGTM.
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Tested-by: Cristian Marussi <cristian.marussi@arm.com>
Thanks,
Cristian
next prev parent reply other threads:[~2025-08-19 15:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20250812075350epcas5p1cc4533582704978ec3a4a8b73dc1535c@epcas5p1.samsung.com>
2025-08-12 7:53 ` [PATCH] firmware: arm_scmi: Set device ready before register scmi_virtio_driver Junnan Wu
2025-08-12 8:06 ` 回复: " yizhijiao2025
2025-08-19 12:33 ` Cristian Marussi [this message]
2025-08-20 1:01 ` Junnan Wu
2025-08-26 10:39 ` Sudeep Holla
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=aKRvBrRstEFDu93g@pluto \
--to=cristian.marussi@arm.com \
--cc=arm-scmi@vger.kernel.org \
--cc=florian.fainelli@broadcom.com \
--cc=junnan01.wu@samsung.com \
--cc=lei19.wang@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=q1.huang@samsung.com \
--cc=sudeep.holla@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox