[PATCH v3 0/5] Add virtio-mmio support to m68k virt machine

[PATCH v3 0/5] Add virtio-mmio support to m68k virt machine

[Daniel Palmer]

Lets start making the m68k virt machine support useful.

First we need to fix some m68k endian issues.

Then allow virtio mmio driver instances to be created with
platform data and fix a minor endian issue.

Finally, add the code for the board to create the instances.

v3:
  - Fix the bug with the vendor string in virtio-blk properly,
    this removes the last endian hack in virtio-mmio
  - Leave the current behaviour for readl() for coldfire as it
    breaks thing.

v2:
  - Added patch to fix readl() etc on m68k, hopefully this
    doesn't break everything. This should match Linux now.
  - Added patch to fix sys reset which is broken by the above
  - Hacks to virtio-mmio are gone because they aren't needed
    anymore, just one minor endian fix now.
  - Removed RFC because it looks good to me*.


* I wouldn't trust me. :)

Daniel Palmer (5):
  sysreset: qemu virt: Use __raw_writel()
  m68k: Fix writew(), writel(), readw(), readl() endianness for classic
    m68k
  virtio: mmio: Allow instantiation via platform data
  virtio: blk: Fix converting the vendor id to a string
  board: qemu: m68k: Create virtio mmio instances

 arch/m68k/Kconfig                          | 14 ++++---
 arch/m68k/include/asm/io.h                 | 31 +++++++++-----
 board/emulation/qemu-m68k/qemu-m68k.c      | 47 ++++++++++++++++++++++
 drivers/sysreset/sysreset_qemu_virt_ctrl.c |  2 +-
 drivers/virtio/virtio_blk.c                | 12 +++---
 drivers/virtio/virtio_mmio.c               | 27 ++++++++-----
 include/virtio_mmio.h                      | 14 +++++++
 7 files changed, 113 insertions(+), 34 deletions(-)
 create mode 100644 include/virtio_mmio.h

-- 
2.51.0

[PATCH v3 1/5] sysreset: qemu virt: Use __raw_writel()

[Daniel Palmer]

The virt ctrl register seems to be native endian, currently this driver
uses writel(), which works by luck because its currently broken on m68k.

Use __raw_writel() instead to avoid breaking this driver when the
endianness of writel() is fixed.

Signed-off-by: Daniel Palmer <daniel@thingy.jp>
Acked-by: Kuan-Wei Chiu <visitorckw@gmail.com>
---
 drivers/sysreset/sysreset_qemu_virt_ctrl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/sysreset/sysreset_qemu_virt_ctrl.c b/drivers/sysreset/sysreset_qemu_virt_ctrl.c
index e7cacc9b6e98..5ab16001922b 100644
--- a/drivers/sysreset/sysreset_qemu_virt_ctrl.c
+++ b/drivers/sysreset/sysreset_qemu_virt_ctrl.c
@@ -38,7 +38,7 @@ static int qemu_virt_ctrl_request(struct udevice *dev, enum sysreset_t type)
 		return -EPROTONOSUPPORT;
 	}
 
-	writel(val, plat->reg + VIRT_CTRL_REG_CMD);
+	__raw_writel(val, plat->reg + VIRT_CTRL_REG_CMD);
 
 	return -EINPROGRESS;
 }
-- 
2.51.0

Re: [PATCH v3 1/5] sysreset: qemu virt: Use __raw_writel()

[Simon Glass]

On 2026-04-08T22:09:23, Daniel Palmer <daniel@thingy.jp> wrote:
> sysreset: qemu virt: Use __raw_writel()
>
> The virt ctrl register seems to be native endian, currently this driver
> uses writel(), which works by luck because its currently broken on m68k.
>
> Use __raw_writel() instead to avoid breaking this driver when the
> endianness of writel() is fixed.
>
> Signed-off-by: Daniel Palmer <daniel@thingy.jp>
> Acked-by: Kuan-Wei Chiu <visitorckw@gmail.com>
>
> drivers/sysreset/sysreset_qemu_virt_ctrl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

Re: [PATCH v3 1/5] sysreset: qemu virt: Use __raw_writel()

[Angelo Dureghello]

Reviewed-by: Angelo Dureghello <angelo@kernel-space.org>

On 4/9/26 00:09, Daniel Palmer wrote:
> The virt ctrl register seems to be native endian, currently this driver
> uses writel(), which works by luck because its currently broken on m68k.
> 
> Use __raw_writel() instead to avoid breaking this driver when the
> endianness of writel() is fixed.
> 
> Signed-off-by: Daniel Palmer <daniel@thingy.jp>
> Acked-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> ---
>  drivers/sysreset/sysreset_qemu_virt_ctrl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/sysreset/sysreset_qemu_virt_ctrl.c b/drivers/sysreset/sysreset_qemu_virt_ctrl.c
> index e7cacc9b6e98..5ab16001922b 100644
> --- a/drivers/sysreset/sysreset_qemu_virt_ctrl.c
> +++ b/drivers/sysreset/sysreset_qemu_virt_ctrl.c
> @@ -38,7 +38,7 @@ static int qemu_virt_ctrl_request(struct udevice *dev, enum sysreset_t type)
>  		return -EPROTONOSUPPORT;
>  	}
>  
> -	writel(val, plat->reg + VIRT_CTRL_REG_CMD);
> +	__raw_writel(val, plat->reg + VIRT_CTRL_REG_CMD);
>  
>  	return -EINPROGRESS;
>  }

-- Angelo

[PATCH v3 2/5] m68k: Fix writew(), writel(), readw(), readl() endianness for classic m68k

[Daniel Palmer]

In Linux these are meant to read a little-endian value and swap
to the CPU endian.

In u-boot for m68k this is currently broken and prevents
virtio-mmio from functioning.

This change is only for classic m68k. Coldfire has read big-endian,
no swap for these in u-boot and Linux and existing drivers probably
depend on this.

Signed-off-by: Daniel Palmer <daniel@thingy.jp>
---
 arch/m68k/include/asm/io.h | 31 ++++++++++++++++++++-----------
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
index 35ad4a1c0444..2577081d8363 100644
--- a/arch/m68k/include/asm/io.h
+++ b/arch/m68k/include/asm/io.h
@@ -23,18 +23,27 @@
 #define __raw_writew(w,addr) ((*(volatile u16 *) (addr)) = (w))
 #define __raw_writel(l,addr) ((*(volatile u32 *) (addr)) = (l))
 
-#define readb(addr)		in_8((volatile u8 *)(addr))
-#define writeb(b,addr)		out_8((volatile u8 *)(addr), (b))
-#if !defined(__BIG_ENDIAN)
-#define readw(addr)		(*(volatile u16 *) (addr))
-#define readl(addr)		(*(volatile u32 *) (addr))
-#define writew(b,addr)		((*(volatile u16 *) (addr)) = (b))
-#define writel(b,addr)		((*(volatile u32 *) (addr)) = (b))
+#define readb(addr)	in_8((volatile u8 *)(addr))
+#define writeb(b, addr)	out_8((volatile u8 *)(addr), (b))
+#ifdef CONFIG_M680x0
+/*
+ * For classic m68k these work the same way as Linux:
+ * Read a little endian value, swap to the CPU endian.
+ */
+#define readw(addr)	in_le16((volatile u16 *)(addr))
+#define readl(addr)	in_le32((volatile u32 *)(addr))
+#define writew(b, addr)	out_le16((volatile u16 *)(addr), (b))
+#define writel(b, addr)	out_le32((volatile u32 *)(addr), (b))
 #else
-#define readw(addr)		in_be16((volatile u16 *)(addr))
-#define readl(addr)		in_be32((volatile u32 *)(addr))
-#define writew(b,addr)		out_be16((volatile u16 *)(addr),(b))
-#define writel(b,addr)		out_be32((volatile u32 *)(addr),(b))
+/*
+ * For coldfire these read a big endian value and use it
+ * as-is. This means that for little endian devices on the
+ * bus like PCI device these won't work as expected currently.
+ */
+#define readw(addr)	in_be16((volatile u16 *)(addr))
+#define readl(addr)	in_be32((volatile u32 *)(addr))
+#define writew(b, addr)	out_be16((volatile u16 *)(addr), (b))
+#define writel(b, addr)	out_be32((volatile u32 *)(addr), (b))
 #endif
 
 /*
-- 
2.51.0

Re: [PATCH v3 2/5] m68k: Fix writew(), writel(), readw(), readl() endianness for classic m68k

[Simon Glass]

On 2026-04-08T22:09:23, Daniel Palmer <daniel@thingy.jp> wrote:
> m68k: Fix writew(), writel(), readw(), readl() endianness for classic m68k
>
> In Linux these are meant to read a little-endian value and swap
> to the CPU endian.
>
> In u-boot for m68k this is currently broken and prevents
> virtio-mmio from functioning.
>
> This change is only for classic m68k. Coldfire has read big-endian,
> no swap for these in u-boot and Linux and existing drivers probably
> depend on this.
>
> Signed-off-by: Daniel Palmer <daniel@thingy.jp>
>
> arch/m68k/include/asm/io.h | 31 ++++++++++++++++++++-----------
>  1 file changed, 20 insertions(+), 11 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

Re: [PATCH v3 2/5] m68k: Fix writew(), writel(), readw(), readl() endianness for classic m68k

[Angelo Dureghello]

Tested-by: Angelo Dureghello <angelo@kernel-space.org>


it's mainly ok, btw, since you need still probably a v4,
see below:

On 4/9/26 00:09, Daniel Palmer wrote:
> In Linux these are meant to read a little-endian value and swap
> to the CPU endian.
> 
> In u-boot for m68k this is currently broken and prevents
> virtio-mmio from functioning.
> 
> This change is only for classic m68k. Coldfire has read big-endian,
> no swap for these in u-boot and Linux and existing drivers probably
> depend on this.
> 
> Signed-off-by: Daniel Palmer <daniel@thingy.jp>
> ---
>  arch/m68k/include/asm/io.h | 31 ++++++++++++++++++++-----------
>  1 file changed, 20 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
> index 35ad4a1c0444..2577081d8363 100644
> --- a/arch/m68k/include/asm/io.h
> +++ b/arch/m68k/include/asm/io.h
> @@ -23,18 +23,27 @@
>  #define __raw_writew(w,addr) ((*(volatile u16 *) (addr)) = (w))
>  #define __raw_writel(l,addr) ((*(volatile u32 *) (addr)) = (l))
>  
> -#define readb(addr)		in_8((volatile u8 *)(addr))
> -#define writeb(b,addr)		out_8((volatile u8 *)(addr), (b))
> -#if !defined(__BIG_ENDIAN)
> -#define readw(addr)		(*(volatile u16 *) (addr))
> -#define readl(addr)		(*(volatile u32 *) (addr))
> -#define writew(b,addr)		((*(volatile u16 *) (addr)) = (b))
> -#define writel(b,addr)		((*(volatile u32 *) (addr)) = (b))
> +#define readb(addr)	in_8((volatile u8 *)(addr))
> +#define writeb(b, addr)	out_8((volatile u8 *)(addr), (b))
> +#ifdef CONFIG_M680x0
> +/*
> + * For classic m68k these work the same way as Linux:
> + * Read a little endian value, swap to the CPU endian.
> + */
> +#define readw(addr)	in_le16((volatile u16 *)(addr))
> +#define readl(addr)	in_le32((volatile u32 *)(addr))
> +#define writew(b, addr)	out_le16((volatile u16 *)(addr), (b))
> +#define writel(b, addr)	out_le32((volatile u32 *)(addr), (b))

My understanding is that, even if m68k is big endian, you need 
LE r/w for usage with virtio. 

Would M680x0 non-qemu work still with this change ?
Maybe an #if defined (CONFIG_VIRTIO) && defined(CONFIG_M680x0)
would be better ?


>  #else
> -#define readw(addr)		in_be16((volatile u16 *)(addr))
> -#define readl(addr)		in_be32((volatile u32 *)(addr))
> -#define writew(b,addr)		out_be16((volatile u16 *)(addr),(b))
> -#define writel(b,addr)		out_be32((volatile u32 *)(addr),(b))
> +/*
> + * For coldfire these read a big endian value and use it
> + * as-is. This means that for little endian devices on the
> + * bus like PCI device these won't work as expected currently.
> + */
> +#define readw(addr)	in_be16((volatile u16 *)(addr))
> +#define readl(addr)	in_be32((volatile u32 *)(addr))
> +#define writew(b, addr)	out_be16((volatile u16 *)(addr), (b))
> +#define writel(b, addr)	out_be32((volatile u32 *)(addr), (b))
>  #endif
>  
>  /*

Regards,
-- Angelo

Re: [PATCH v3 2/5] m68k: Fix writew(), writel(), readw(), readl() endianness for classic m68k

[Daniel Palmer]

Hi Angelo,

On Sun, 12 Apr 2026 at 06:07, Angelo Dureghello <angelo@kernel-space.org> wrote:

> Would M680x0 non-qemu work still with this change ?
> Maybe an #if defined (CONFIG_VIRTIO) && defined(CONFIG_M680x0)
> would be better ?

I think we need this change even for non-virtio. The bug just showed
up because of virtio.
I think this would have shown up if/when PCI support is added. I have
PCI on my Amiga working in Linux so that's not totally impossible. :)

Cheers,

Daniel

[PATCH v3 3/5] virtio: mmio: Allow instantiation via platform data

[Daniel Palmer]

The m68k QEMU virt machine doesn't use devicetree, yet, so
allow it to create virtio-mmio instances via platform data.

Signed-off-by: Daniel Palmer <daniel@thingy.jp>
---
 drivers/virtio/virtio_mmio.c | 27 ++++++++++++++++++---------
 include/virtio_mmio.h        | 12 ++++++++++++
 2 files changed, 30 insertions(+), 9 deletions(-)
 create mode 100644 include/virtio_mmio.h

diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index 1cd737aca249..28b46ab66238 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -12,6 +12,7 @@
 #include <virtio_types.h>
 #include <virtio.h>
 #include <virtio_ring.h>
+#include <virtio_mmio.h>
 #include <linux/bug.h>
 #include <linux/compat.h>
 #include <linux/err.h>
@@ -335,21 +336,28 @@ static int virtio_mmio_notify(struct udevice *udev, struct virtqueue *vq)
 
 static int virtio_mmio_of_to_plat(struct udevice *udev)
 {
-	struct virtio_mmio_priv *priv = dev_get_priv(udev);
+	struct virtio_mmio_plat *plat = dev_get_plat(udev);
+	fdt_addr_t addr;
+
+	addr = dev_read_addr(udev);
 
-	priv->base = (void __iomem *)(ulong)dev_read_addr(udev);
-	if (priv->base == (void __iomem *)FDT_ADDR_T_NONE)
+	if (addr == FDT_ADDR_T_NONE)
 		return -EINVAL;
 
+	plat->base = addr;
+
 	return 0;
 }
 
 static int virtio_mmio_probe(struct udevice *udev)
 {
+	struct virtio_mmio_plat *plat = dev_get_plat(udev);
 	struct virtio_mmio_priv *priv = dev_get_priv(udev);
 	struct virtio_dev_priv *uc_priv = dev_get_uclass_priv(udev);
 	u32 magic;
 
+	priv->base = (void __iomem *)plat->base;
+
 	/* Check magic value */
 	magic = readl(priv->base + VIRTIO_MMIO_MAGIC_VALUE);
 	if (magic != ('v' | 'i' << 8 | 'r' << 16 | 't' << 24)) {
@@ -405,11 +413,12 @@ static const struct udevice_id virtio_mmio_ids[] = {
 };
 
 U_BOOT_DRIVER(virtio_mmio) = {
-	.name	= "virtio-mmio",
-	.id	= UCLASS_VIRTIO,
-	.of_match = virtio_mmio_ids,
-	.ops	= &virtio_mmio_ops,
-	.probe	= virtio_mmio_probe,
+	.name       = "virtio-mmio",
+	.id         = UCLASS_VIRTIO,
+	.of_match   = virtio_mmio_ids,
+	.ops        = &virtio_mmio_ops,
+	.probe      = virtio_mmio_probe,
 	.of_to_plat = virtio_mmio_of_to_plat,
-	.priv_auto	= sizeof(struct virtio_mmio_priv),
+	.priv_auto  = sizeof(struct virtio_mmio_priv),
+	.plat_auto  = sizeof(struct virtio_mmio_plat),
 };
diff --git a/include/virtio_mmio.h b/include/virtio_mmio.h
new file mode 100644
index 000000000000..8c072826db55
--- /dev/null
+++ b/include/virtio_mmio.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+#ifndef __VIRTIO_MMIO_H__
+#define __VIRTIO_MMIO_H__
+
+#include <linux/types.h>
+
+struct virtio_mmio_plat {
+	phys_addr_t base;
+};
+
+#endif /* __VIRTIO_MMIO_H__ */
-- 
2.51.0

Re: [PATCH v3 3/5] virtio: mmio: Allow instantiation via platform data

[Simon Glass]

On 2026-04-08T22:09:23, Daniel Palmer <daniel@thingy.jp> wrote:
> virtio: mmio: Allow instantiation via platform data
>
> The m68k QEMU virt machine doesn't use devicetree, yet, so
> allow it to create virtio-mmio instances via platform data.
>
> Signed-off-by: Daniel Palmer <daniel@thingy.jp>
>
> drivers/virtio/virtio_mmio.c | 27 ++++++++++++++++++---------
>  include/virtio_mmio.h        | 12 ++++++++++++
>  2 files changed, 30 insertions(+), 9 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

Re: [PATCH v3 3/5] virtio: mmio: Allow instantiation via platform data

[Angelo Dureghello]

A question here,

this driver would still work for other devicetree cases ?

Also, there are some coding style changes that should be in a separate
patch.

 
On 4/9/26 00:09, Daniel Palmer wrote:
> The m68k QEMU virt machine doesn't use devicetree, yet, so
> allow it to create virtio-mmio instances via platform data.
> 
> Signed-off-by: Daniel Palmer <daniel@thingy.jp>
> ---
>  drivers/virtio/virtio_mmio.c | 27 ++++++++++++++++++---------
>  include/virtio_mmio.h        | 12 ++++++++++++
>  2 files changed, 30 insertions(+), 9 deletions(-)
>  create mode 100644 include/virtio_mmio.h
> 
> diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
> index 1cd737aca249..28b46ab66238 100644
> --- a/drivers/virtio/virtio_mmio.c
> +++ b/drivers/virtio/virtio_mmio.c
> @@ -12,6 +12,7 @@
>  #include <virtio_types.h>
>  #include <virtio.h>
>  #include <virtio_ring.h>
> +#include <virtio_mmio.h>
>  #include <linux/bug.h>
>  #include <linux/compat.h>
>  #include <linux/err.h>
> @@ -335,21 +336,28 @@ static int virtio_mmio_notify(struct udevice *udev, struct virtqueue *vq)
>  
>  static int virtio_mmio_of_to_plat(struct udevice *udev)
>  {
> -	struct virtio_mmio_priv *priv = dev_get_priv(udev);
> +	struct virtio_mmio_plat *plat = dev_get_plat(udev);
> +	fdt_addr_t addr;
> +
> +	addr = dev_read_addr(udev);
>  
> -	priv->base = (void __iomem *)(ulong)dev_read_addr(udev);
> -	if (priv->base == (void __iomem *)FDT_ADDR_T_NONE)
> +	if (addr == FDT_ADDR_T_NONE)
>  		return -EINVAL;
>  
> +	plat->base = addr;
> +
>  	return 0;
>  }
>  
>  static int virtio_mmio_probe(struct udevice *udev)
>  {
> +	struct virtio_mmio_plat *plat = dev_get_plat(udev);
>  	struct virtio_mmio_priv *priv = dev_get_priv(udev);
>  	struct virtio_dev_priv *uc_priv = dev_get_uclass_priv(udev);
>  	u32 magic;
>  
> +	priv->base = (void __iomem *)plat->base;
> +
>  	/* Check magic value */
>  	magic = readl(priv->base + VIRTIO_MMIO_MAGIC_VALUE);
>  	if (magic != ('v' | 'i' << 8 | 'r' << 16 | 't' << 24)) {
> @@ -405,11 +413,12 @@ static const struct udevice_id virtio_mmio_ids[] = {
>  };
>  
>  U_BOOT_DRIVER(virtio_mmio) = {
> -	.name	= "virtio-mmio",
> -	.id	= UCLASS_VIRTIO,
> -	.of_match = virtio_mmio_ids,
> -	.ops	= &virtio_mmio_ops,
> -	.probe	= virtio_mmio_probe,
> +	.name       = "virtio-mmio",
> +	.id         = UCLASS_VIRTIO,
> +	.of_match   = virtio_mmio_ids,
> +	.ops        = &virtio_mmio_ops,
> +	.probe      = virtio_mmio_probe,
>  	.of_to_plat = virtio_mmio_of_to_plat,
> -	.priv_auto	= sizeof(struct virtio_mmio_priv),
> +	.priv_auto  = sizeof(struct virtio_mmio_priv),
> +	.plat_auto  = sizeof(struct virtio_mmio_plat),
>  };
> diff --git a/include/virtio_mmio.h b/include/virtio_mmio.h
> new file mode 100644
> index 000000000000..8c072826db55
> --- /dev/null
> +++ b/include/virtio_mmio.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +
> +#ifndef __VIRTIO_MMIO_H__
> +#define __VIRTIO_MMIO_H__
> +
> +#include <linux/types.h>
> +
> +struct virtio_mmio_plat {
> +	phys_addr_t base;
> +};
> +
> +#endif /* __VIRTIO_MMIO_H__ */

Regards,
angelo

Re: [PATCH v3 3/5] virtio: mmio: Allow instantiation via platform data

[Daniel Palmer]

Hi Angelo,

On Sun, 12 Apr 2026 at 06:15, Angelo Dureghello <angelo@kernel-space.org> wrote:
>
> A question here,
>
> this driver would still work for other devicetree cases ?

Yeah, I hadn't actually tested that though so I just built this series
for the ARM virt machine to test it still works and it does so there
shouldn't be any problems for the current users.

> Also, there are some coding style changes that should be in a separate
> patch.

mmm I think it's minimal enough that it's ok but if whoever ends up
merging this wants that I will split it into two commits.

Thanks,

Daniel

[PATCH v3 4/5] virtio: blk: Fix converting the vendor id to a string

[Daniel Palmer]

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.

Signed-off-by: Daniel Palmer <daniel@thingy.jp>
---
 drivers/virtio/virtio_blk.c | 12 +++++-------
 include/virtio_mmio.h       |  2 ++
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/virtio/virtio_blk.c b/drivers/virtio/virtio_blk.c
index 3dd0cf36268b..d876c40deb05 100644
--- a/drivers/virtio/virtio_blk.c
+++ b/drivers/virtio/virtio_blk.c
@@ -11,6 +11,7 @@
 #include <part.h>
 #include <virtio_types.h>
 #include <virtio.h>
+#include <virtio_mmio.h>
 #include <virtio_ring.h>
 #include <linux/log2.h>
 #include "virtio_blk.h"
@@ -164,14 +165,11 @@ static int virtio_blk_bind(struct udevice *dev)
 		return devnum;
 	desc->devnum = devnum;
 	desc->part_type = PART_TYPE_UNKNOWN;
-	/*
-	 * virtio mmio transport supplies string identification for us,
-	 * while pci trnasport uses a 2-byte subvendor value.
-	 */
-	if (uc_priv->vendor >> 16)
-		sprintf(desc->vendor, "%s", (char *)&uc_priv->vendor);
+
+	if (uc_priv->vendor == VIRTIO_MMIO_VENDOR_QEMU)
+		strcpy(desc->vendor, "QEMU");
 	else
-		sprintf(desc->vendor, "%04x", uc_priv->vendor);
+		sprintf(desc->vendor, "%08x", uc_priv->vendor);
 	desc->bdev = dev;
 
 	/* Indicate what driver features we support */
diff --git a/include/virtio_mmio.h b/include/virtio_mmio.h
index 8c072826db55..cc59bc516c2c 100644
--- a/include/virtio_mmio.h
+++ b/include/virtio_mmio.h
@@ -5,6 +5,8 @@
 
 #include <linux/types.h>
 
+#define VIRTIO_MMIO_VENDOR_QEMU	0x554d4551
+
 struct virtio_mmio_plat {
 	phys_addr_t base;
 };
-- 
2.51.0

Re: [PATCH v3 4/5] virtio: blk: Fix converting the vendor id to a string

[Simon Glass]

Hi Daniel,

On 2026-04-08T22:09:23, Daniel Palmer <daniel@thingy.jp> wrote:
> virtio: blk: Fix converting the vendor id to a string
>
> 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.
>
> Signed-off-by: Daniel Palmer <daniel@thingy.jp>
>
> drivers/virtio/virtio_blk.c | 12 +++++-------
>  include/virtio_mmio.h       |  2 ++
>  2 files changed, 7 insertions(+), 7 deletions(-)

> diff --git a/include/virtio_mmio.h b/include/virtio_mmio.h
> @@ -5,6 +5,8 @@
> +#define VIRTIO_MMIO_VENDOR_QEMU      0x554d4551

This vendor ID applies to all virtio transports, not just virtio-mmio,
e.g. virtio_blk.c must include virtio_mmio.h even when built for
platforms that only have virtio-pci

Please can you move this to include/virtio.h instead? Something like
VIRTIO_VENDOR_QEMU would be more appropriate.

With that:
Reviewed-by: Simon Glass <sjg@chromium.org>

Regards,
Simon

Re: [PATCH v3 4/5] virtio: blk: Fix converting the vendor id to a string

[Kuan-Wei Chiu]

Hi Daniel,

On Thu, Apr 09, 2026 at 07:09:27AM +0900, Daniel Palmer wrote:
> 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.
> 
> Signed-off-by: Daniel Palmer <daniel@thingy.jp>
> ---
>  drivers/virtio/virtio_blk.c | 12 +++++-------
>  include/virtio_mmio.h       |  2 ++
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/virtio/virtio_blk.c b/drivers/virtio/virtio_blk.c
> index 3dd0cf36268b..d876c40deb05 100644
> --- a/drivers/virtio/virtio_blk.c
> +++ b/drivers/virtio/virtio_blk.c
> @@ -11,6 +11,7 @@
>  #include <part.h>
>  #include <virtio_types.h>
>  #include <virtio.h>
> +#include <virtio_mmio.h>
>  #include <virtio_ring.h>
>  #include <linux/log2.h>
>  #include "virtio_blk.h"
> @@ -164,14 +165,11 @@ static int virtio_blk_bind(struct udevice *dev)
>  		return devnum;
>  	desc->devnum = devnum;
>  	desc->part_type = PART_TYPE_UNKNOWN;
> -	/*
> -	 * virtio mmio transport supplies string identification for us,
> -	 * while pci trnasport uses a 2-byte subvendor value.
> -	 */
> -	if (uc_priv->vendor >> 16)
> -		sprintf(desc->vendor, "%s", (char *)&uc_priv->vendor);
> +
> +	if (uc_priv->vendor == VIRTIO_MMIO_VENDOR_QEMU)
> +		strcpy(desc->vendor, "QEMU");

Is there a chance that other non qemu virtio-mmio devices also use a
4 character string for their vendor ID? If so, this patch will regress
their output from a human-readable string to a raw hex value.

Regards,
Kuan-Wei

>  	else
> -		sprintf(desc->vendor, "%04x", uc_priv->vendor);
> +		sprintf(desc->vendor, "%08x", uc_priv->vendor);
>  	desc->bdev = dev;
>  
>  	/* Indicate what driver features we support */
> diff --git a/include/virtio_mmio.h b/include/virtio_mmio.h
> index 8c072826db55..cc59bc516c2c 100644
> --- a/include/virtio_mmio.h
> +++ b/include/virtio_mmio.h
> @@ -5,6 +5,8 @@
>  
>  #include <linux/types.h>
>  
> +#define VIRTIO_MMIO_VENDOR_QEMU	0x554d4551
> +
>  struct virtio_mmio_plat {
>  	phys_addr_t base;
>  };
> -- 
> 2.51.0
> 

Re: [PATCH v3 4/5] virtio: blk: Fix converting the vendor id to a string

[Daniel Palmer]

Hi Kuan-Wei,

On Mon, 13 Apr 2026 at 06:34, Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> Is there a chance that other non qemu virtio-mmio devices also use a
> 4 character string for their vendor ID? If so, this patch will regress
> their output from a human-readable string to a raw hex value.

There might be other implementations of virtio but probably not used
together with u-boot.
I think this goes the other way too, we are assuming the ids are
printable ascii chars and it's possible to have an id that isn't.
What is currently happening looks like luck and seems unsafe to me so
I think regressing to printing hex is better.

Re: [PATCH v3 4/5] virtio: blk: Fix converting the vendor id to a string

[Kuan-Wei Chiu]

Hi Daniel,

On Mon, Apr 13, 2026 at 06:47:37AM +0900, Daniel Palmer wrote:
> Hi Kuan-Wei,
> 
> On Mon, 13 Apr 2026 at 06:34, Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> > Is there a chance that other non qemu virtio-mmio devices also use a
> > 4 character string for their vendor ID? If so, this patch will regress
> > their output from a human-readable string to a raw hex value.
> 
> There might be other implementations of virtio but probably not used
> together with u-boot.
> I think this goes the other way too, we are assuming the ids are
> printable ascii chars and it's possible to have an id that isn't.
> What is currently happening looks like luck and seems unsafe to me so
> I think regressing to printing hex is better.

I just took a quick look through the virtio spec, and indeed it never
mentions that the mmio vendor id should be a string.

Given this, should we even treat qemu as a special case here?
Perhaps the simplest and most spec-compliant approach is to never
assume it's a string, and just uniformly print the hex value for all
devices. What do you think?

Regards,
Kuan-Wei

Re: [PATCH v3 4/5] virtio: blk: Fix converting the vendor id to a string

[Daniel Palmer]

Hi Kuan-Wei,

On Mon, 13 Apr 2026 at 07:00, Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> I just took a quick look through the virtio spec, and indeed it never
> mentions that the mmio vendor id should be a string.
>
> Given this, should we even treat qemu as a special case here?
> Perhaps the simplest and most spec-compliant approach is to never
> assume it's a string, and just uniformly print the hex value for all
> devices. What do you think?

I think printing a pretty vendor name makes sense and since it's
basically just QEMU right now the little special case for it isn't too
bad.
I think not confusing people by showing them a bunch of hex where they
are used to seeing QEMU is also worthwhile.

Thanks,

Daniel

[PATCH v3 5/5] board: qemu: m68k: Create virtio mmio instances

[Daniel Palmer]

So that you can use virtio network, block etc create the virtio mmio
instances. There are 128 of these even if they are not all used, a
single mmio base value is passed via bootinfo.

Signed-off-by: Daniel Palmer <daniel@thingy.jp>
---
 arch/m68k/Kconfig                     | 14 ++++----
 board/emulation/qemu-m68k/qemu-m68k.c | 47 +++++++++++++++++++++++++++
 2 files changed, 55 insertions(+), 6 deletions(-)

diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 6ce8f577e3a1..20a112880c87 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -195,12 +195,14 @@ config TARGET_STMARK2
         select M54418
 
 config TARGET_QEMU_M68K
-    bool "Support QEMU m68k virt"
-    select M68040
-    imply CMD_DM
-    help
-      This target supports the QEMU m68k virtual machine (-M virt).
-      It simulates a Motorola 68040 CPU with Goldfish peripherals.
+	bool "Support QEMU m68k virt"
+	select M68040
+	select BOARD_EARLY_INIT_R
+	select VIRTIO_MMIO
+	imply CMD_DM
+	help
+	  This target supports the QEMU m68k virtual machine (-M virt).
+	  It simulates a Motorola 68040 CPU with Goldfish peripherals.
 
 endchoice
 
diff --git a/board/emulation/qemu-m68k/qemu-m68k.c b/board/emulation/qemu-m68k/qemu-m68k.c
index d3527aee1128..3617c61b5c1f 100644
--- a/board/emulation/qemu-m68k/qemu-m68k.c
+++ b/board/emulation/qemu-m68k/qemu-m68k.c
@@ -14,9 +14,14 @@
 #include <asm/bootinfo.h>
 #include <asm/global_data.h>
 #include <asm/io.h>
+#include <dm.h>
+#include <dm/device-internal.h>
+#include <dm/lists.h>
 #include <dm/platdata.h>
+#include <dm/root.h>
 #include <linux/errno.h>
 #include <linux/sizes.h>
+#include <virtio_mmio.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -25,6 +30,38 @@ static struct goldfish_rtc_plat rtc_plat;
 static struct goldfish_timer_plat timer_plat;
 static struct qemu_virt_ctrl_plat reset_plat;
 
+#define VIRTIO_MMIO_NUM	128
+#define VIRTIO_MMIO_SZ	0x200
+
+static struct virtio_mmio_plat virtio_mmio_plat[VIRTIO_MMIO_NUM];
+static char virtio_mmio_names[VIRTIO_MMIO_NUM][11];
+static phys_addr_t virtio_mmio_base;
+
+static inline int create_virtio_mmios(void)
+{
+	struct driver *drv;
+	int i, ret;
+
+	if (!virtio_mmio_base)
+		return -ENODEV;
+
+	drv = lists_driver_lookup_name("virtio-mmio");
+	if (!drv)
+		return -ENOENT;
+
+	for (i = 0; i < VIRTIO_MMIO_NUM; i++) {
+		virtio_mmio_plat[i].base = virtio_mmio_base + (VIRTIO_MMIO_SZ * i);
+		sprintf(virtio_mmio_names[i], "virtio-%d", i);
+
+		ret = device_bind(dm_root(), drv, virtio_mmio_names[i],
+				  &virtio_mmio_plat[i], ofnode_null(), NULL);
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
 /*
  * Theoretical limit derivation:
  * Max Bootinfo Size (Standard Page) = 4096 bytes
@@ -65,6 +102,9 @@ static void parse_bootinfo(void)
 		case BI_VIRT_CTRL_BASE:
 			reset_plat.reg = base;
 			break;
+		case BI_VIRT_VIRTIO_BASE:
+			virtio_mmio_base = base;
+			break;
 		case BI_MEMCHUNK:
 			gd->ram_size = record->data[1];
 			break;
@@ -80,6 +120,13 @@ int board_early_init_f(void)
 	return 0;
 }
 
+int board_early_init_r(void)
+{
+	create_virtio_mmios();
+
+	return 0;
+}
+
 int checkboard(void)
 {
 	puts("Board: QEMU m68k virt\n");
-- 
2.51.0

Re: [PATCH v3 5/5] board: qemu: m68k: Create virtio mmio instances

[Angelo Dureghello]

Hi Daniel,

After applying this patch i got an error building

on a test build i am getting this error:

      m68k:  +   qemu-m68k
+  422 |                 sep = memchr(fixup_str, ':', fixup_len);
+      |                     ^
+  432 |                 sep = memchr(name, ':', fixup_len);
+m68k-linux-ld: cmd/virtio.o: in function `do_virtio':
+cmd/virtio.c:42:(.text.do_virtio+0xa6): undefined reference to `blk_common_cmd'
+m68k-linux-ld: final link failed: bad value
+make[1]: *** [Makefile:2105: u-boot] Error 1
+make: *** [Makefile:189: __sub-make] Error 2

Looks like a "select BLK" is missing.

Regards,
angelo

On 4/9/26 00:09, Daniel Palmer wrote:
> So that you can use virtio network, block etc create the virtio mmio
> instances. There are 128 of these even if they are not all used, a
> single mmio base value is passed via bootinfo.
> 
> Signed-off-by: Daniel Palmer <daniel@thingy.jp>
> ---
>  arch/m68k/Kconfig                     | 14 ++++----
>  board/emulation/qemu-m68k/qemu-m68k.c | 47 +++++++++++++++++++++++++++
>  2 files changed, 55 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
> index 6ce8f577e3a1..20a112880c87 100644
> --- a/arch/m68k/Kconfig
> +++ b/arch/m68k/Kconfig
> @@ -195,12 +195,14 @@ config TARGET_STMARK2
>          select M54418
>  
>  config TARGET_QEMU_M68K
> -    bool "Support QEMU m68k virt"
> -    select M68040
> -    imply CMD_DM
> -    help
> -      This target supports the QEMU m68k virtual machine (-M virt).
> -      It simulates a Motorola 68040 CPU with Goldfish peripherals.
> +	bool "Support QEMU m68k virt"
> +	select M68040
> +	select BOARD_EARLY_INIT_R
> +	select VIRTIO_MMIO
> +	imply CMD_DM
> +	help
> +	  This target supports the QEMU m68k virtual machine (-M virt).
> +	  It simulates a Motorola 68040 CPU with Goldfish peripherals.
>  
>  endchoice
>  
> diff --git a/board/emulation/qemu-m68k/qemu-m68k.c b/board/emulation/qemu-m68k/qemu-m68k.c
> index d3527aee1128..3617c61b5c1f 100644
> --- a/board/emulation/qemu-m68k/qemu-m68k.c
> +++ b/board/emulation/qemu-m68k/qemu-m68k.c
> @@ -14,9 +14,14 @@
>  #include <asm/bootinfo.h>
>  #include <asm/global_data.h>
>  #include <asm/io.h>
> +#include <dm.h>
> +#include <dm/device-internal.h>
> +#include <dm/lists.h>
>  #include <dm/platdata.h>
> +#include <dm/root.h>
>  #include <linux/errno.h>
>  #include <linux/sizes.h>
> +#include <virtio_mmio.h>
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -25,6 +30,38 @@ static struct goldfish_rtc_plat rtc_plat;
>  static struct goldfish_timer_plat timer_plat;
>  static struct qemu_virt_ctrl_plat reset_plat;
>  
> +#define VIRTIO_MMIO_NUM	128
> +#define VIRTIO_MMIO_SZ	0x200
> +
> +static struct virtio_mmio_plat virtio_mmio_plat[VIRTIO_MMIO_NUM];
> +static char virtio_mmio_names[VIRTIO_MMIO_NUM][11];
> +static phys_addr_t virtio_mmio_base;
> +
> +static inline int create_virtio_mmios(void)
> +{
> +	struct driver *drv;
> +	int i, ret;
> +
> +	if (!virtio_mmio_base)
> +		return -ENODEV;
> +
> +	drv = lists_driver_lookup_name("virtio-mmio");
> +	if (!drv)
> +		return -ENOENT;
> +
> +	for (i = 0; i < VIRTIO_MMIO_NUM; i++) {
> +		virtio_mmio_plat[i].base = virtio_mmio_base + (VIRTIO_MMIO_SZ * i);
> +		sprintf(virtio_mmio_names[i], "virtio-%d", i);
> +
> +		ret = device_bind(dm_root(), drv, virtio_mmio_names[i],
> +				  &virtio_mmio_plat[i], ofnode_null(), NULL);
> +		if (ret)
> +			return ret;
> +	}
> +
> +	return 0;
> +}
> +
>  /*
>   * Theoretical limit derivation:
>   * Max Bootinfo Size (Standard Page) = 4096 bytes
> @@ -65,6 +102,9 @@ static void parse_bootinfo(void)
>  		case BI_VIRT_CTRL_BASE:
>  			reset_plat.reg = base;
>  			break;
> +		case BI_VIRT_VIRTIO_BASE:
> +			virtio_mmio_base = base;
> +			break;
>  		case BI_MEMCHUNK:
>  			gd->ram_size = record->data[1];
>  			break;
> @@ -80,6 +120,13 @@ int board_early_init_f(void)
>  	return 0;
>  }
>  
> +int board_early_init_r(void)
> +{
> +	create_virtio_mmios();
> +
> +	return 0;
> +}
> +
>  int checkboard(void)
>  {
>  	puts("Board: QEMU m68k virt\n");

-- Angelo

Re: [PATCH v3 5/5] board: qemu: m68k: Create virtio mmio instances

[Daniel Palmer]

Hi Angelo

On Sun, 12 Apr 2026 at 05:28, Angelo Dureghello <angelo@kernel-space.org> wrote:
>       m68k:  +   qemu-m68k
> +  422 |                 sep = memchr(fixup_str, ':', fixup_len);
> +      |                     ^
> +  432 |                 sep = memchr(name, ':', fixup_len);
> +m68k-linux-ld: cmd/virtio.o: in function `do_virtio':
> +cmd/virtio.c:42:(.text.do_virtio+0xa6): undefined reference to `blk_common_cmd'
> +m68k-linux-ld: final link failed: bad value
> +make[1]: *** [Makefile:2105: u-boot] Error 1
> +make: *** [Makefile:189: __sub-make] Error 2
>
> Looks like a "select BLK" is missing.

Yeah, I guess whatever config causes the virtio command to be enabled
should depend on or select it.
I'll take a look and add a fix for v4.

Re: [PATCH v3 5/5] board: qemu: m68k: Create virtio mmio instances

[Simon Glass]

Hi Daniel,

On 2026-04-08T22:09:23, Daniel Palmer <daniel@thingy.jp> wrote:
> board: qemu: m68k: Create virtio mmio instances
>
> So that you can use virtio network, block etc create the virtio mmio
> instances. There are 128 of these even if they are not all used, a
> single mmio base value is passed via bootinfo.
>
> Signed-off-by: Daniel Palmer <daniel@thingy.jp>
>
> arch/m68k/Kconfig                     | 14 ++++++-----
>  board/emulation/qemu-m68k/qemu-m68k.c | 47 +++++++++++++++++++++++++++++++++++
>  2 files changed, 55 insertions(+), 6 deletions(-)

> diff --git a/board/emulation/qemu-m68k/qemu-m68k.c b/board/emulation/qemu-m68k/qemu-m68k.c
> @@ -25,6 +30,38 @@ static struct qemu_virt_ctrl_plat reset_plat;
> +static inline int create_virtio_mmios(void)

Please can you drop the inline keyword here? It is not needed for a
function called only once and not in a header file.

> diff --git a/board/emulation/qemu-m68k/qemu-m68k.c b/board/emulation/qemu-m68k/qemu-m68k.c
> @@ -80,6 +120,13 @@ int board_early_init_f(void)
> +int board_early_init_r(void)
> +{
> +     create_virtio_mmios();
> +
> +     return 0;
> +}

The return value from create_virtio_mmios() is discarded - really this
should be checked. If not, perhaps log_debug() or log_warning() would
help report when virtio-mmio devices are not created?

Regards,
Simon