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

[PATCH v2 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.

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' trust me. :)

Daniel Palmer (5):
  sysreset: qemu virt: Use __raw_writel()
  m68k: Fix writew(), writel(), readw(), readl() endianness
  virtio: mmio: Keep vendor id little endian
  virtio: mmio: Allow instantiation via platform data
  board: qemu: m68k: Create virtio mmio instances

 arch/m68k/Kconfig                          | 14 ++++---
 arch/m68k/include/asm/io.h                 | 17 +++-----
 board/emulation/qemu-m68k/qemu-m68k.c      | 47 ++++++++++++++++++++++
 drivers/sysreset/sysreset_qemu_virt_ctrl.c |  2 +-
 drivers/virtio/virtio_mmio.c               | 29 ++++++++-----
 include/virtio_mmio.h                      | 12 ++++++
 6 files changed, 92 insertions(+), 29 deletions(-)
 create mode 100644 include/virtio_mmio.h

-- 
2.51.0

[PATCH v2 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>
---
 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 v2 1/5] sysreset: qemu virt: Use __raw_writel()

[Kuan-Wei Chiu]

On Mon, Apr 06, 2026 at 11:24:07PM +0900, 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>

Regards,
Kuan-Wei

> ---
>  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 v2 1/5] sysreset: qemu virt: Use __raw_writel()

[Angelo Dureghello]

Hi,

On 4/6/26 16:24, 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.
> 

Still not clear why writel should be currently broken, it works
fine in bigendian for 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>
> ---
>  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;
>  }

Regards,

-- Angelo

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

[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 borken and prevents
virtio-mmio from functioning.

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

diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
index 35ad4a1c0444..f4877b0446cf 100644
--- a/arch/m68k/include/asm/io.h
+++ b/arch/m68k/include/asm/io.h
@@ -24,18 +24,11 @@
 #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))
-#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))
-#endif
+#define writeb(b, addr)		out_8((volatile u8 *)(addr), (b))
+#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))
 
 /*
  * The insw/outsw/insl/outsl macros don't do byte-swapping.
-- 
2.51.0

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

[Kuan-Wei Chiu]

Hi Daniel,

On Mon, Apr 06, 2026 at 11:24:08PM +0900, 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 borken and prevents
> virtio-mmio from functioning.
> 
> Signed-off-by: Daniel Palmer <daniel@thingy.jp>
> ---
>  arch/m68k/include/asm/io.h | 17 +++++------------
>  1 file changed, 5 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
> index 35ad4a1c0444..f4877b0446cf 100644
> --- a/arch/m68k/include/asm/io.h
> +++ b/arch/m68k/include/asm/io.h
> @@ -24,18 +24,11 @@
>  #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))
> -#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))
> -#endif
> +#define writeb(b, addr)		out_8((volatile u8 *)(addr), (b))
> +#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))

Just wondering could this global change break some drivers on coldfire?

I originally thought you were planning to split these IO macros between
coldfire and classic m68k.

Of course, if you've found that this doesn't actually break coldfire,
then this global approach is definitely ideal.

Regards,
Kuan-Wei

>  
>  /*
>   * The insw/outsw/insl/outsl macros don't do byte-swapping.
> -- 
> 2.51.0
> 

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

[Daniel Palmer]

Hi Kuan-Wei,

On Tue, 7 Apr 2026 at 02:15, Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> Just wondering could this global change break some drivers on coldfire?

It might. Really I'd like Angelo to see if it still works. Hopefully
it doesn't break anything or it's just one or two things that need to
be fixed to make it work again.
In Linux the range for the in-chip registers uses the current
behaviour and everything else uses the "correct" behaviour. I think we
want to avoid having that hack if possible.

> I originally thought you were planning to split these IO macros between
> coldfire and classic m68k.

Yeah, but then we have to fix it again if a coldfire virt machine
happens. If it breaks coldfire so badly it's difficult to fix I'll
split them.

> Of course, if you've found that this doesn't actually break coldfire,
> then this global approach is definitely ideal.

Yep. I forgot that there is actually a coldfire machine in qemu so I
will build and test this on that a bit later.

Cheers,

Daniel

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

[Angelo Dureghello]

Hi Daniel,


On 4/6/26 16:24, 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 borken and prevents
> virtio-mmio from functioning.
> 

mmm, "currently broken" ?

If you remove bigendian read/write the driver framework will fail
to work with coldfire/m68k stuff.

I tested the patchset over master in stmark2 board, seems this patch is
breaking dspi cs init:

stmark2 $ saveenv
Saving Environment to SPIFlash... *** Warning - spi_flash_probe_bus_cs() failed, using default environment

Failed (-1)
stmark2 $ sf probe
spi_coldfire dspi@fc05c000: Invalid chip select 0:0 (err=-19)
Failed to initialize SPI flash at 0:0 (error -19)
stmark2 $ 

Please find a different solution, that may be using "xxx_le" stuff directly
from your code.

> Signed-off-by: Daniel Palmer <daniel@thingy.jp>
> ---
>  arch/m68k/include/asm/io.h | 17 +++++------------
>  1 file changed, 5 insertions(+), 12 deletions(-)
> 
> diff --git a/arch/m68k/include/asm/io.h b/arch/m68k/include/asm/io.h
> index 35ad4a1c0444..f4877b0446cf 100644
> --- a/arch/m68k/include/asm/io.h
> +++ b/arch/m68k/include/asm/io.h
> @@ -24,18 +24,11 @@
>  #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))
> -#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))
> -#endif
> +#define writeb(b, addr)		out_8((volatile u8 *)(addr), (b))
> +#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))
>  
>  /*
>   * The insw/outsw/insl/outsl macros don't do byte-swapping.

Regards,

-- Angelo

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

[Daniel Palmer]

Hi Angelo.

On Wed, 8 Apr 2026 at 21:12, Angelo Dureghello <angelo@kernel-space.org> wrote:
> mmm, "currently broken" ?
> If you remove bigendian read/write the driver framework will fail
> to work with coldfire/m68k stuff.

I'm not sure who/what decided this but in Linux at least these are
meant to be read little endian and convert to cpu endian.
Classic m68k in linux works like that. Coldfire in Linux is currently
the same as u-boot on internal registers and but everything else has
the "correct" behaviour. I think that is so PCI can work.

> I tested the patchset over master in stmark2 board, seems this patch is
> breaking dspi cs init:

Thank you for checking and sorry for the breakage.

> Please find a different solution, that may be using "xxx_le" stuff directly
> from your code.

mmm so I did try that for nommu classic m68k in Linux because it's
also "broken" there and got told to fix readl() etc.

Would putting this in some #ifdefs so coldfire keeps the current
behaviour and classic m68k matches Linux be acceptable?

Thanks,

Daniel

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

[Angelo Dureghello]

Hi Daniel,

On 4/8/26 14:49, Daniel Palmer wrote:
> Hi Angelo.
> 
> On Wed, 8 Apr 2026 at 21:12, Angelo Dureghello <angelo@kernel-space.org> wrote:
>> mmm, "currently broken" ?
>> If you remove bigendian read/write the driver framework will fail
>> to work with coldfire/m68k stuff.
> 
> I'm not sure who/what decided this but in Linux at least these are
> meant to be read little endian and convert to cpu endian.
> Classic m68k in linux works like that. Coldfire in Linux is currently
> the same as u-boot on internal registers and but everything else has
> the "correct" behaviour. I think that is so PCI can work.
> 
>> I tested the patchset over master in stmark2 board, seems this patch is
>> breaking dspi cs init:
> 
> Thank you for checking and sorry for the breakage.
> 
no problem.

>> Please find a different solution, that may be using "xxx_le" stuff directly
>> from your code.
> 
> mmm so I did try that for nommu classic m68k in Linux because it's
> also "broken" there and got told to fix readl() etc.
> 
> Would putting this in some #ifdefs so coldfire keeps the current
> behaviour and classic m68k matches Linux be acceptable?
> 

yes, thanks, please try to find a solution protecting coldfire for now.

I will try to understand better why Linux operates differently from u-boot,
i think pci was involved here but actually i don't remember, need to 
study this deeper.


> Thanks,
> 
> Daniel

Regards,
-- Angelo

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

[Daniel Palmer]

Hi Angelo,

On Wed, 8 Apr 2026 at 22:26, Angelo Dureghello <angelo@kernel-space.org> wrote:
> yes, thanks, please try to find a solution protecting coldfire for now.

So for now I have put #ifdefs in so coldfire retains its current behaviour.

> I will try to understand better why Linux operates differently from u-boot,
> i think pci was involved here but actually i don't remember, need to
> study this deeper.

I thought maybe this change in m68k might be recent but in Linux it
seems to have been there since the import into git 22 years ago.

In the linux docs (https://docs.kernel.org/driver-api/device-io.html)
it says this:

Note: On some architectures, the normal readl()/writel() functions
traditionally assume that devices are the same endianness as the CPU,
while using a hardware byte-reverse on the PCI bus when running a
big-endian kernel. Drivers that use readl()/writel() this way are
generally not portable, but tend to be limited to a particular SoC.

So I think maybe coldfire got a "reads native endian, no swap"
readl()/writel() and then when PCI support was added a hack was
needed. But somehow normal m68k got it the other way around. <shrug>

Anyhow, sorry again for breaking your board.

Cheers,

Daniel

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

[Angelo Dureghello]

Hi Daniel,

On 4/8/26 15:40, Daniel Palmer wrote:
> Hi Angelo,
> 
> On Wed, 8 Apr 2026 at 22:26, Angelo Dureghello <angelo@kernel-space.org> wrote:
>> yes, thanks, please try to find a solution protecting coldfire for now.
> 
> So for now I have put #ifdefs in so coldfire retains its current behaviour.
> 
>> I will try to understand better why Linux operates differently from u-boot,
>> i think pci was involved here but actually i don't remember, need to
>> study this deeper.
> 
> I thought maybe this change in m68k might be recent but in Linux it
> seems to have been there since the import into git 22 years ago.
> 
> In the linux docs (https://docs.kernel.org/driver-api/device-io.html)
> it says this:
> 
> Note: On some architectures, the normal readl()/writel() functions
> traditionally assume that devices are the same endianness as the CPU,
> while using a hardware byte-reverse on the PCI bus when running a
> big-endian kernel. Drivers that use readl()/writel() this way are
> generally not portable, but tend to be limited to a particular SoC.
> 
> So I think maybe coldfire got a "reads native endian, no swap"
> readl()/writel() and then when PCI support was added a hack was
> needed. But somehow normal m68k got it the other way around. <shrug>

mmm, so from a fast look:

apart for M5235EVB_defconfig:CONFIG_CMD_PCI=y  
but this board has no PCI bus, so it should be some config copy/paste,  

there is no other board using pci for coldfire, maybe either no pci driver
working (NXP driver may work ?) or tested for them, so there was never
any need for swapping LE for pci. But just an assumption, i can be totally 
wrong since some nxp board has been removed and some coldfire have pci.

So this part 

#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))
#else

is probably non functional from a pci driver since still "be" r/w. Should
be replaced with _le stuff. But should go deeper when i have some time.

> 
> Anyhow, sorry again for breaking your board.
> 

as i said, no problem. We tested it before, that's ok.


> Cheers,
> 
> Daniel

Regards,
-- Angelo

[PATCH v2 3/5] virtio: mmio: Keep vendor id little endian

[Daniel Palmer]

The vendor id is used as a little endian value but it gets
swapped to the CPU endian in readl(). Swap it back to le
to avoid the below weird output from `virtio info`.

Device 0: UMEQ VirtIO Block Device
            Type: Hard Disk
            Capacity: 1.0 MB = 0.0 GB (2056 x 512)

Signed-off-by: Daniel Palmer <daniel@thingy.jp>
---
 drivers/virtio/virtio_mmio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index 1cd737aca249..ddf873fa96fb 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -374,7 +374,7 @@ static int virtio_mmio_probe(struct udevice *udev)
 		 */
 		return 0;
 	}
-	uc_priv->vendor = readl(priv->base + VIRTIO_MMIO_VENDOR_ID);
+	uc_priv->vendor = cpu_to_le32(readl(priv->base + VIRTIO_MMIO_VENDOR_ID));
 
 	if (priv->version == 1)
 		writel(PAGE_SIZE, priv->base + VIRTIO_MMIO_GUEST_PAGE_SIZE);
-- 
2.51.0

Re: [PATCH v2 3/5] virtio: mmio: Keep vendor id little endian

[Kuan-Wei Chiu]

Hi Daniel,

On Mon, Apr 06, 2026 at 11:24:09PM +0900, Daniel Palmer wrote:
> The vendor id is used as a little endian value but it gets
> swapped to the CPU endian in readl(). Swap it back to le
> to avoid the below weird output from `virtio info`.
> 
> Device 0: UMEQ VirtIO Block Device
>             Type: Hard Disk
>             Capacity: 1.0 MB = 0.0 GB (2056 x 512)
> 
> Signed-off-by: Daniel Palmer <daniel@thingy.jp>
> ---
>  drivers/virtio/virtio_mmio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
> index 1cd737aca249..ddf873fa96fb 100644
> --- a/drivers/virtio/virtio_mmio.c
> +++ b/drivers/virtio/virtio_mmio.c
> @@ -374,7 +374,7 @@ static int virtio_mmio_probe(struct udevice *udev)
>  		 */
>  		return 0;
>  	}
> -	uc_priv->vendor = readl(priv->base + VIRTIO_MMIO_VENDOR_ID);
> +	uc_priv->vendor = cpu_to_le32(readl(priv->base + VIRTIO_MMIO_VENDOR_ID));

Hi Daniel,

Thanks for the patch!

While using cpu_to_le32() here does fix the visual output, it feels a
bit hacky because it alters the actual core data value just to satisfy
a display quirk.

For example, if someone in the future writes hardware specific logic
like if (uc_priv->vendor == 0x554D4551), it would silently fail on
m68k.

It looks more like a issue in virtio-blk driver to me.
The code currently does this:

sprintf(desc->vendor, "%s", (char *)&uc_priv->vendor);

This direct memory cast relies on little endian byte ordering to spell
"QEMU". On big endian machines, the memory layout naturally spells
"UMEQ".

So maybe we can extract the characters safely using bitwise shifts like
this?

diff --git a/drivers/virtio/virtio_blk.c b/drivers/virtio/virtio_blk.c
index 3dd0cf36268..af61939270d 100644
--- a/drivers/virtio/virtio_blk.c
+++ b/drivers/virtio/virtio_blk.c
@@ -168,10 +168,15 @@ static int virtio_blk_bind(struct udevice *dev)
         * 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);
-       else
+       if (uc_priv->vendor >> 16) {
+               desc->vendor[0] = (uc_priv->vendor >>  0) & 0xff;
+               desc->vendor[1] = (uc_priv->vendor >>  8) & 0xff;
+               desc->vendor[2] = (uc_priv->vendor >> 16) & 0xff;
+               desc->vendor[3] = (uc_priv->vendor >> 24) & 0xff;
+               desc->vendor[4] = '\0';
+       } else {
                sprintf(desc->vendor, "%04x", uc_priv->vendor);
+       }
        desc->bdev = dev;

        /* Indicate what driver features we support */

Regards,
Kuan-Wei

Re: [PATCH v2 3/5] virtio: mmio: Keep vendor id little endian

[Daniel Palmer]

Hi Kuan-Wei,

On Tue, 7 Apr 2026 at 01:54, Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> For example, if someone in the future writes hardware specific logic
> like if (uc_priv->vendor == 0x554D4551), it would silently fail on
> m68k.

Yeah, you're totally right. I did think "hmmm, maybe it's actually
just an issue with whatever is doing the printing" right after sending
the patch. :)
I will move the fix to virtio-blk for v3.

Thanks

Daniel

Re: [PATCH v2 3/5] virtio: mmio: Keep vendor id little endian

[Daniel Palmer]

Hi Kuan-Wei,

On Tue, 7 Apr 2026 at 01:54, Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> This direct memory cast relies on little endian byte ordering to spell
> "QEMU". On big endian machines, the memory layout naturally spells
> "UMEQ".
>
> So maybe we can extract the characters safely using bitwise shifts like
> this?

I think this has uncovered a more important bug..

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

The comment makes no sense. uc_priv->vendor is a u32. The id might be
ASCII chars but it's not a C-string. It's only working right now
because by luck after the chars in the u32 there is a 0.

Anyhow, I think I've fixed this properly so I will send that in v3.

Cheers,

Daniel

[PATCH v2 4/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 ddf873fa96fb..51ef90c768af 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 v2 4/5] virtio: mmio: Allow instantiation via platform data

[Kuan-Wei Chiu]

Hi Daniel,

On Mon, Apr 06, 2026 at 11:24:10PM +0900, 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 ddf873fa96fb..51ef90c768af 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,

Just realized this didn't send earlier.

The patch looks good overall.
However, I noticed some changes involving tabs vs. spaces.
Do we have a specific style rule requiring spaces instead of tabs here?

Regards,
Kuan-Wei

>  	.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 v2 4/5] virtio: mmio: Allow instantiation via platform data

[Daniel Palmer]

Hi Kuan-Wei,

On Wed, 8 Apr 2026 at 10:47, Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> >
> >  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,
>
> Just realized this didn't send earlier.
>
> The patch looks good overall.
> However, I noticed some changes involving tabs vs. spaces.
> Do we have a specific style rule requiring spaces instead of tabs here?

From memory, when I aligned it using tabs it didn't look very nice so
aligning with spaces worked out better.

Cheers,

Daniel

[PATCH v2 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