[PATCH] virtio: ignore ENODEV for boot device hunting

[Simon Glass]

Hi Ludwig,

On 2026-04-28T13:36:02, Ludwig Nussel <ludwig.nussel at siemens.com> wrote:
> virtio: ignore ENODEV for boot device hunting
>
> 'Commit 70101c3217ae ("virtio: mmio: Return error codes on probe
> failures")' returns -ENODEV in some situations. That breaks boot device
> discovery. Ignoring that error seems to fix the issue. Not sure it's the
> correct thing to do though.
>
> Signed-off-by: Ludwig Nussel <ludwig.nussel at siemens.com>
>
> drivers/virtio/virtio-uclass.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

>     'Commit 70101c3217ae ("virtio: mmio: Return error codes on probe
>     failures")' returns -ENODEV in some situations. That breaks boot device
>     discovery. Ignoring that error seems to fix the issue. Not sure it's the
>     correct thing to do though.

Will need to firm up this commit message :-) Also drop the quotes
around the leading Commit reference — the convention is just:

   Commit 70101c3217ae ("virtio: mmio: Return error codes on probe
failures") ...

A Fixes: tag pointing to it would be useful too.

> diff --git a/drivers/virtio/virtio-uclass.c b/drivers/virtio/virtio-uclass.c
> @@ -382,7 +382,7 @@ static int virtio_bootdev_hunt(struct bootdev_hunter *info, bool show)
>       ret = uclass_probe_all(UCLASS_VIRTIO);
> -     if (ret && ret != -ENOENT)
> +     if (ret && ret != -ENOENT && ret != -ENODEV)
>               return log_msg_ret('vir', ret);

I don't think this is the right layer. uclass_probe_all() walks every
device in the uclass and returns whichever error came back last, so a
single bogus mmio slot poisons the result for every other working
virtio device. -ENXIO is also returned from virtio_mmio_probe() for an
unsupported version and would still bail out here, which is
inconsistent with what you are trying to achieve.

As I understand it, the placeholder/empty mmio slots should not be
reaching probe at all, i.e. the bind step should reject them - or
virtio_mmio_probe() should keep returning 0 for the 'no device
present' case (wrong magic, ID 0) and let DM treat that as nothing to
probe. The unsupported-version case is the only real error.

Could you take another look at 70101c3217ae and see whether the fix
belongs there (or in the bind path) instead?

Regards,
Simon