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 <[e-mail]>
Message-Id: <[e-mail]>
Signed-off-by: Sudeep Holla <[e-mail]>

drivers/firmware/arm_scmi/transports/virtio.c

···
 	/* 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;