Re: m68k: coldfire: create internal register access defines

["Arnd Bergmann" <arnd@kernel.org>]

On Thu, Apr 30, 2026, at 13:22, Greg Ungerer wrote:
> On 30/4/26 17:39, Arnd Bergmann wrote:
>
>> There are still open questions about how to continue from here
>> to change the existing readl() and ioread32be() style helpers
>> to have normal endianess and type characteristics without
>> breaking things, but this is a good step in that direction.
>
> I have been playing with one idea. I have been working through the affected
> drivers and changing them to use raw primitives only for their IO access
> on ColdFire (so only the __raw_readx/__raw_writex macros). My thinking is
> that these can then be pushed via driver subsystem maintainers if and when
> they are ready. When all are affected drivers are fixed then we can correct
> the definitions in arch/m68k/include/asm/io_no.h. At a later time if we choose
> we can then make changes to effected drivers again to use the now corrected
> readx/writex family.
>
> At least this way we can keep everything working and avoid a single patch that
> makes changes to io_no.h and drivers across multiple subsystems in one go.
> What do you think?

I think that should work for most of them, but perhaps not for the
spi-fsl-dspi with its extra abstraction through regmap-mmio.

I would probably still do an atomic change for that one, adding
the explict regmap endianess flag at the same time as redefining
the readl() function. As long as it's only one or two drivers that
need this, the change should still be simple enough to merge with
the respective subsystem maintainer Ack.

> So far I have modified the fec and smc91x ethernet drivers in this way.
> That was strait forward, though I may get a little resistance in the fec
> driver since I abstracted the IO access from readl/writel to local internal
> functions to keep it clean and avoid redefining readl/wrtel. But the change
> is simple in concept. I am working through the handful of other drivers
> that we identified.

Ok.

     Arnd