diff options
author | Junnan Wu <junnan01.wu@samsung.com> | 2025-08-12 15:53:43 +0800 |
---|---|---|
committer | Sudeep Holla <sudeep.holla@arm.com> | 2025-08-21 14:36:20 +0100 |
commit | e8faa8a466f61f4ae07069ed6b0872f602f1cba9 (patch) | |
tree | 6d081f816b5f723c44d172fd8ba958bb3038fe75 /rust/helpers/security.c | |
parent | 224dcf2968cad72adabd4f8258291d6675bc301e (diff) |
firmware: arm_scmi: Mark VirtIO ready before registering scmi_virtio_driver
After commit 20bda12a0ea0 (“firmware: arm_scmi: Make VirtIO transport a
standalone driver”), the VirtIO transport probes independently. During
scmi_virtio_probe, scmi_probe() is called, which intune invokes
scmi_protocol_acquire() that sends a message over the virtqueue and
waits for a reply.
Previously, DRIVER_OK was only set after scmi_vio_probe, in the core
virtio via virtio_dev_probe(). According to the Virtio spec (3.1 Device
Initialization):
| The driver MUST NOT send any buffer available notifications to the
| device before setting DRIVER_OK.
Some type-1 hypervisors block available-buffer notifications until the
driver is marked OK. In such cases, scmi_vio_probe stalls in
scmi_wait_for_reply(), and the probe never completes.
Resolve this by setting DRIVER_OK immediately after the device-specific
setup, so scmi_probe() can safely send notifications.
Note after splitting the transports into modules, the probe sequence
changed a bit. We can no longer rely on virtio_device_ready() being
called by the core in virtio_dev_probe(), because scmi_vio_probe()
doesn’t complete until the core SCMI stack runs scmi_probe(), which
immediately issues the initial BASE protocol exchanges.
Fixes: 20bda12a0ea0 ("firmware: arm_scmi: Make VirtIO transport a standalone driver")
Signed-off-by: Junnan Wu <junnan01.wu@samsung.com>
Message-Id: <20250812075343.3201365-1-junnan01.wu@samsung.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Diffstat (limited to 'rust/helpers/security.c')
0 files changed, 0 insertions, 0 deletions