Thread (18 messages) 18 messages, 6 authors, 14d ago

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

flat view

From: Greg Ungerer <gerg@linux-m68k.org>
Date: 2026-09-23 14:00:11
Also in: imx, linux-can, linux-m68k, linux-spi, lkml


On 23/9/26 23:23, Andrew Lunn wrote:
On Wed, Sep 23, 2026 at 11:07:17PM +1000, Greg Ungerer wrote:
quoted
Ping...
To: linux-m68k@lists.linux-m68k.org

ICMP redirect.
quoted
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help