u-boot.git/drivers/virtio, branch next

Merge patch series "Clean up bloblist initialization"

2026-06-02T15:30:33Z

Tom Rini says: This series does a few small but important cleanups to how we check for, and initialize a bloblist. The first thing is that the way things are done today, our HANDOFF code can only work with a fixed bloblist location, so express that requirement in Kconfig. Next, we demote the scary message about "Bloblist at ... not found" to a debug because we most often see that because the bloblist doesn't (and can't) exist yet. Finally, we remove bloblist_maybe_init and split this in to an exists and a real init. This results in practically no growth (between 8 bytes growth to 12 bytes saved, with some outliers saving much more thanks to knowing it's impossible to have been passed a bloblist yet). This also cleans up some of the code around checking for / knowing about a bloblist existing. Link: https://lore.kernel.org/r/20260519162225.770071-1-trini@konsulko.com

Merge tag 'v2026.07-rc3' into next

2026-05-25T17:35:35Z

Prepare v2026.07-rc3

virtio: blk: Fix converting the vendor id to a string

2026-05-22T22:47:54Z

Currently we are trying to work out if the vendor id is from a virtio-mmio device and then casting a u32 to a char* and using it as a C-string. By chance there is usually a zero after the u32 and it works. Since the vendor id we are trying to convert to a string is QEMU's just define a value for the QEMU vendor id, check if the vendor id matches and then use a predefined string for "QEMU". I don't think we should have been assumming all virtio-mmio vendor ids are printable ASCII chars in the first place so do this special casing just for QEMU. If the vendor id isn't QEMU print the hex value of it. Reviewed-by: Simon Glass Reviewed-by: Kuan-Wei Chiu Signed-off-by: Daniel Palmer

virtio: mmio: Allow instantiation via platform data

2026-05-22T22:47:54Z

The m68k QEMU virt machine doesn't use devicetree, yet, so allow it to create virtio-mmio instances via platform data. Reviewed-by: Simon Glass Reviewed-by: Kuan-Wei Chiu Reviewed-by: Angelo Dureghello Signed-off-by: Daniel Palmer

virtio: Drop empty bootdev_ops structure

2026-05-19T14:18:54Z

We don't need to provide an empty struct here now that the caller can handle this being empty. Signed-off-by: Tom Rini

virtio: fix return value check

2026-05-12T18:38:49Z

The virtio_blk_do_single_req function returns ulong, which normally is the processed size, but in an error case can be the actual error. Use the special IS_ERR_VALUE macro to test for error. Addresses-Coverity-ID: CID 645833 (DEADCODE) & CID 645834 (NO_EFFECT) Signed-off-by: Christian Pötzsch Reviewed-by: Simon Glass

virtio: fix boot device hunting in qemu with virtio

2026-05-08T21:49:27Z

Commit 70101c3217ae ("virtio: mmio: Return error codes on probe failures") returns -ENODEV where it would return 0 before. That path is apparently hit in qemu and breaks boot device discovery (virtio_bootdev_hunt() expects only ENOENT). So return -ENOENT in that path instead. The remaining two error returns in the function are untouched as I don't know where they play a role. Signed-off-by: Ludwig Nussel Reviewed-by: Simon Glass Acked-by: Kuan-Wei Chiu

virtio: add support for SIZE_MAX & SEG_MAX features

2026-04-27T17:11:54Z

Some virtio implementations may forward the virtio requests directly to the underlying hw. The hw may have some restrictions in how many and how big the requests can be. Therefore, the corresponding virtio device will announce this limitations with the SIZE_MAX & SEG_MAX feature. Add support for those features. Split an io request into multiple virtio requests if more than seg_max segments would be used. Also split a single buffer request into multiple segments if the buffer is bigger then size_max. Signed-off-by: Christian Pötzsch Signed-off-by: Adam Lackorzynski

virtio: mmio: Return error codes on probe failures

2026-04-22T17:07:55Z

Currently, virtio_mmio_probe() returns 0 when it encounters an invalid magic value, an unsupported version, or a dummy device (ID 0). In U-Boot's driver model, returning 0 indicates a successful probe. This causes the system to incorrectly register and activate invalid or placeholder devices, potentially leading to undefined behavior or crashes later on. Update the probe function to return appropriate error codes (-ENODEV for invalid magic values and dummy devices, and -ENXIO for unsupported versions). This fix correctly instructs the DM to abort the binding process. Fixes: fdc4aca89ecb ("virtio: Add virtio over mmio transport driver") Signed-off-by: Kuan-Wei Chiu Acked-by: Daniel Palmer

virtio: Fix virtio initialization sequence

2026-03-25T20:33:00Z

The virtio spec clearly states in "3.1.1 Driver Requirements: Device Initialization" the sequence a client has to follow after device reset. Because u-boot resets here again, it also needs to set the "acknowledge" bit again even if this was done in virtio_uclass_child_post_bind already once before. Signed-off-by: Christian Pötzsch Signed-off-by: Adam Lackorzynski [trini: Add VIRTIO_CONFIG_S_ACKNOWLEDGE flag check to the test] Signed-off-by: Tom Rini