summaryrefslogtreecommitdiff
path: root/rust/helpers/irq.c
diff options
context:
space:
mode:
authorJunnan Wu <junnan01.wu@samsung.com>2025-08-12 15:53:43 +0800
committerSudeep Holla <sudeep.holla@arm.com>2025-08-21 14:36:20 +0100
commite8faa8a466f61f4ae07069ed6b0872f602f1cba9 (patch)
tree6d081f816b5f723c44d172fd8ba958bb3038fe75 /rust/helpers/irq.c
parent224dcf2968cad72adabd4f8258291d6675bc301e (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/irq.c')
0 files changed, 0 insertions, 0 deletions