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

Andrew Lunn <[email protected]>
Newsgroups org.kernel.vger.linux-m68k,dev.linux.lists.imx,org.kernel.vger.linux-can,org.kernel.vger.linux-kernel,org.kernel.vger.linux-mmc,org.kernel.vger.linux-spi,org.kernel.vger.netdev
Message-ID <[email protected]>
On Wed, Jun 10, 2026 at 12:12:58AM +1000, Greg Ungerer wrote:
> Modify the FEC driver to not directly use readl() and writel() to access
> hardware registers but instead local fec_readl() and fec_writel() methods.
> This allows for different architecture users of this driver to have
> different underlying access functions - to support both little and big
> endian hardware.
> 
> The FEC hardware block in ColdFire SoC parts is accessed big-endian.
> The usual kernel readl()/writel() IO memory access methods are defined to
> access little endian data. Change access for ColdFire to use __raw_readl()
> and __raw_writel() access methods - which do not modify or swap bytes
> on access.
> 
> 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.
> 
> Signed-off-by: Greg Ungerer <[email protected]>

Reviewed-by: Andrew Lunn <[email protected]>

    Andrew
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.