Re: [RFC 4/4] m68k: coldfire: fix non-standard readX()/writeX() functions

From: Greg Ungerer

Date: Thu May 07 2026 - 08:43:16 EST


Hi Arnd,

On 7/5/26 05:12, Arnd Bergmann wrote:
On Wed, May 6, 2026, at 16:26, Greg Ungerer wrote:

drivers/dma/mcf-edma-main.c
Supports big-endian access by setting the big-endian flag of
the drivers struct fsl_edma_engine. But locally should be using
ioread32be() and iowrite32be() instead of ioread32() and iowrite32().

I'm still a bit confused about how this works at the moment,
since the drivers/dma/fsl-edma-common.h file already contains
checks for the edma->big_endian flag, which is set in
mcf_edma_probe(). The version after your patch makes sense
to me, but it looks like the existing code cannot work.

Yes, it certainly doesn't look right to me either.

Angelo: you look to be the original author of this driver, can you shed any
light on its working status in mainline currently?


drivers/spi/spi-fsl-dspi.c
Setting the regmap format_endian flags to use native endian will
force driver to use appropriate big or little endian access on
whatever platform it is built for.

These drivers have only been compile tested.

I would suggest marking these as explicit BIG_ENDIAN rather than
NATIVE_ENDIAN. The effect should be the same since coldfire CPUs
cannot run little-endian code, but the way that hardware usually
works is that the endianess is fixed at the bus level to one way
or the other. NATIVE_ENDIAN to me implies that the registers
have configurable endianess that is switched along with the CPU
mode.

Ok, will change. I chose native endian in this case since the regmap config
entry used for the m5441x family is also used by the vf610 devce (which looks
to be an ARM imx SoC). So it will need a duplicate setup with those endian
flags set to BIG_ENDIAN. But that is no problem.

Thanks
Greg