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

[Angelo Dureghello]

Hi all,

sorry that i could check this now only, hope is not too late.

On Thu, May 07, 2026 at 10:43:01PM +1000, Greg Ungerer wrote:
> 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?
>

I was some years far from this driver (and the kernel itself), but i have
seen there are several changes in the edma common part from that time.
I remember i reviewed/tested some of them, some other unfortunately not.

I realized last month, that i was back working on this board (stmark2)
that somehting related to edma or dspi looks broken in mainline now:

[    2.270000] fsl-dspi fsl-dspi.0: Not able to get desc for DMA xfer
[    2.280000] fsl-dspi fsl-dspi.0: DMA transfer failed
[    2.280000] spi_master spi0: failed to transfer one message from queue
[    2.290000] spi_master spi0: noqueue transfer failed
[    2.290000] spi-nor spi0.1: probe with driver spi-nor failed with error -5

DSPI is using edma, i will try to understand where the issue is asap.

About how it works:
- for accesses to edma module (IP) mmio registers, must be native
big_endian, so using the "be" suffix in "mcf"_edma looks ok for me.
- for accessing the "tcd" memory structure, that must be, from what i
remember, anyway in little endian, independently from the cpu core
endiannes, this is the reason that big_endian flag is needed, it is
used for tcd area accesses, so the IP module was built.
The tcd area may be similar to pci accesses (see mcf54415 RM 19.4.16).

Anyway, tested the patch, nothing looks changed nor in better or worst.
Will look into this in the next days.

>
> > > 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
>

Regards,
angelo