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

[Greg Ungerer]

Hi Jakub,

On 11/9/26 10:42, Jakub Kicinski wrote:
> On Mon,  7 Sep 2026 23:37:09 +1000 Greg Ungerer wrote:
>> 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.
> 
> What is the motivation for this cleanup?

Sorry, maybe you were not in the CC list of the cover email. From that:

  This collection of patches is aimed at fixing the non-standard ColdFire
  set of readX()/writeX() IO access functions. Instead switching to using the
  asm-generic definitions in include/asm-generic/io.h. The difficulty comes
  in trying not to break any drivers with this change.

  The implementation of the readX()/writeX() family of IO access functions
  is non-standard on ColdFire platforms. They either return big-endian (that
  is native endian) data, or on platforms with PCI bus support check the
  supplied address and return either big or little endian data based on that
  check. This is non-standard, they are expected to always return
  little-endian byte ordered data. Unfortunately this behavior also means
  that ioreadX()/iowroteX() and their big-endian counter parts
  ioreadXbe()/iowriteXbe() are currently broken because they are implemented
  using the readX()/writeX() functions.

  Patches 1 and 2 in this series are specific net driver changes that can be
  applied independently of the final ColdFire readX()/writeX() change.


> Is someone still making
> new SKUs of Coldfire boards? Or (and please don't take this the wrong
> way) it was a long standing TODO that was tempting to feed to an LLM?

It is a long standing todo/fix, but there is nothing LLM anywhere here.
This was all manually coded and tested. This patch is 95% textual
substitution, so it wasn't exactly very difficult.


> IMO keeping the hacks in m68k is a better choice. FEC was used on more
> modern SoCs, definitely on PPC ones. So we'll be able to get rid of
> m68k before we can get rid of FEC. Sprinkling m68k workarounds in 
> the FEC driver is backwards.

These changes are not work arounds, they are made to make the FEC driver
explicitly aware of endianess of the underlying processor and FEC hardware
block. The code as it is now, that is carrying hacks inside readX and writeX
for m68k, is trying to hide that from the driver.

Regards
Greg