linux-can.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@kernel.org>
To: "Jakub Kicinski" <kuba@kernel.org>, "Greg Ungerer" <gerg@linux-m68k.org>
Cc: linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org,
	"Wei Fang" <wei.fang@nxp.com>, "Frank Li" <frank.li@nxp.com>,
	"Shenwei Wang" <shenwei.wang@nxp.com>,
	imx@lists.linux.dev, Netdev <netdev@vger.kernel.org>,
	"Nicolas Pitre" <nico@fluxnic.net>,
	linux-can@vger.kernel.org, linux-spi@vger.kernel.org,
	"Vladimir Oltean" <olteanv@gmail.com>,
	andrew+netdev@lunn.ch, "David S . Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Paolo Abeni" <pabeni@redhat.com>, "Andrew Lunn" <andrew@lunn.ch>
Subject: Re: [PATCHv3 1/3] net: fec: do not use readl()/writel() for ColdFire
Date: Fri, 11 Sep 2026 09:39:08 +0200	[thread overview]
Message-ID: <2449d19c-42f3-4ad9-aece-87ce7c3079e3@app.fastmail.com> (raw)
In-Reply-To: <20260910174210.0f8a4ad2@kernel.org>

On Fri, Sep 11, 2026, at 02: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.

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

> What is the motivation for this cleanup? 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?
>
> 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.

Coldfire at the moment is weird because it defines the readl()/writel()
helpers the opposite way from everything else. Greg has been working
towards fixing this so we can avoid special hacks for it in other
parts of the kernel and share the code with Arm and other SoCs using
the same peripherals.

fec is an exception to this because it happened to rely on the
unusual macros: all the Arm SoCs using this hardware have little-endian
registers (regardless of whether the CPU runs as BE or LE), while
all the coldfire chips use big-endian registers (and don't support
LE kernels). The powerpc variant of fec also uses big-endian registers
but has a separate copy of the driver that hardcodes this. Other
Freescale drivers already have a runtime endianess detection that
is needed because they built both BE and LE variants of the hardware
on Arm SoCs that could run the same kernel.

I very much hope we can merge this bit.

       Arnd

  reply	other threads:[~2026-09-11  7:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-07 13:37 [PATCHv3 0/3] m68k: coldfire: fix non-standard readX()/writeX() functions Greg Ungerer
2026-09-07 13:37 ` [PATCHv3 1/3] net: fec: do not use readl()/writel() for ColdFire Greg Ungerer
2026-09-08 13:43   ` sashiko-bot
2026-09-11 13:09     ` Greg Ungerer
2026-09-11  0:42   ` Jakub Kicinski
2026-09-11  7:39     ` Arnd Bergmann [this message]
2026-09-11 13:03     ` Greg Ungerer
2026-09-11 23:04       ` Jakub Kicinski
2026-09-07 13:37 ` [PATCHv3 2/3] net: smc91x: do not use readw()/writew() on ColdFire platforms Greg Ungerer
2026-09-07 13:37 ` [PATCHv3 3/3] m68k: coldfire: fix non-standard readX()/writeX() functions Greg Ungerer
2026-09-08 13:43   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2449d19c-42f3-4ad9-aece-87ce7c3079e3@app.fastmail.com \
    --to=arnd@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=frank.li@nxp.com \
    --cc=gerg@linux-m68k.org \
    --cc=imx@lists.linux.dev \
    --cc=kuba@kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nico@fluxnic.net \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=shenwei.wang@nxp.com \
    --cc=wei.fang@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).