Re: [PATCHv3 1/3] net: fec: do not use readl()/writel() for ColdFire

[Greg Ungerer]

On 23/9/26 23:23, Andrew Lunn wrote:
> On Wed, Sep 23, 2026 at 11:07:17PM +1000, Greg Ungerer wrote:
>> Ping...
> 
> To: linux-m68k@xxxxxxxxxxxxxxxxxxxx
> 
> ICMP redirect.
> 
>>> The FEC driver works today because the m68k architecture io.h has a
>>> kludge in the definitions of the readl() and writel() functions for
>>> ColdFire that allow big-endian access if the address of the register to
>>> access is within the SoC's internal peripheral registers. This is being
>>> fixed in the near future to define readl() and writel() correctly - with
>>> no byte swapping. Thus the motivation for this fix here.
>>>
>>> __raw_readl()/__raw_writel() access methods are used instead of the more
>>> commonly used ioread32be()/iowrite32be() here because those are broken too,
>>> because of the current readl()/writel() kludge. They are implemented in
>>> asm-generic/io.h in terms of readl()/writel().
>>>
>>> Note that even when readl() and writel() are fixed on ColdFire they will
>>> not be the right thing to use within the FEC driver on ColdFire hardware.
> 
> So what is the end goal here? This patch. Then fix
> readl()/writel(). Then fix ioread32be()/iowrite32be()?

Yes, definitely. Patch 3 in this series completes the fixing of readl()/writel().
That also has the effect of fixing ioread32be()/iowrite32be().


> And then change
> these macros to use ioread32be()/iowrite32be()?

Happy to do that if that is want you want. Ultimately probably the cleanest.


> Are we always going to be using fec_read()/fec_write()?

The driver will always need to support big and little endian hardware, so I
am not sure how to avoid some abstraction like this.

Regards
Greg