Re: [RFC PATCH] m68k: nommu: Fix behaviour of io macros on non-CF

[Greg Ungerer]

Hi Arnd,

On 14/4/26 23:24, Arnd Bergmann wrote:
> On Tue, Apr 14, 2026, at 14:55, Daniel Palmer wrote:
> > On Tue, 14 Apr 2026 at 21:18, Greg Ungerer <gerg@xxxxxxxxxxxxxx> wrote:
> > > This change, in this form at least, breaks most of the non-MMU ColdFire targets.
> > > Try compiling any of m5208evb, m5249evb, m5272c3, m5275evb, m5307c3 or
> > > m5407c3 defconfigs and you get build failures. Targets that do not have
> > > a PCI bus and so do not define IOMEMBASE will fail, which is most of them.
>
> Indeed, I had assumed that coldfire just uses the regular semantics
> here since it has PCI support, but I see now that it actually relies
> on both the big-endian access and on passing a physical address as
> an integer instead of an '__iomem' pointer into writel(), which
> is something we should probably fix.

Yeah, it feels like a real kludge.


> > Oof, that's the second time I broke coldfire this week (I broke it
> > trying to make virtio work for m68k in u-boot too).
> > Your patch works for my mc68000 virt and dragonball builds. I will
> > build/boot test nommu CF in QEMU.
>
> Right, this is hopefully fine as a quick fix.
>
> In order to have coldfire behave more like other targets
> (now including 68000/68328), I would suggest removing the
> custom readl/writel helpers for coldfire as well, and changing
> the few callers to something else. A new set of helpers that
> takes a phys_addr_t would work, or possibly just using
> the existing __raw_readl()/__raw_writel() or
> ioread32be()/iowrite32be() where appropriate, see the patch
> below for the arch/m68k portion of that.

I like the idea of a specific set if internal register read/write helpers.
I would like to move in that direction.


> There are other coldfire specific drivers (fec, spi, ...)
> that would need a similar change.

Right, and this is really the work that needs to be done first before
we will be able to remove the io_no.h specific readl/write code.
This is what I see:

Drivers that are used on ColdFire targets that use some of
readb/readw/readl and writeb/writew/writel:

    drivers/net/ethernet/freescale/fec*
    drivers/net/ethernet/smsc/smc9x.[hc]
    drivers/net/ethernet/davicom/dm9000.c
    drivers/spi/spi-coldfire-qspi.c

Obviously spi-coldfire-qspi.c is ColdFire specific, so easy to change
and not affect anything else. The FEC ethernet driver is widely used on
ARM and ColdFire, though the change to a register reading helper looks
pretty strait forward but will be a largish patch. Changing the smc91x
driver looks easy enough, the ColdFire multi-byte access macros in the
header are specific to ColdFire. Need to give some thought to changes
to the dm9000 driver.

Drivers that are used on ColdFire that use only 8-bit readb and writeb:

    drivers/tty/serial/mcf.c
    drivers/i2c/busses/i2c-imx.c

We could ignore these for now I guess, since readb and writeb will always
work the same. Though it might be nice to clean them up with proper helpers.
mcf.c is only used on ColdFire so won't affect anything else.

Drivers that are used on ColdFire that use iowrite32/iowrite32be:

    drivers/net/can/flexcan/flexcan-core.c

Although this driver has support for differentiating big and little endian
access I think for ColdFire it is relying on the kludgy overrides in io_no.h
to actually work right. So will need a fix too.

Did I miss any?

Regards
Greg