From: Jakub Kicinski <kuba@kernel.org>
To: Greg Ungerer <gerg@linux-m68k.org>
Cc: linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org,
arnd@kernel.org, wei.fang@nxp.com, frank.li@nxp.com,
shenwei.wang@nxp.com, imx@lists.linux.dev,
netdev@vger.kernel.org, nico@fluxnic.net,
linux-can@vger.kernel.org, linux-spi@vger.kernel.org,
olteanv@gmail.com, andrew+netdev@lunn.ch, davem@davemloft.net,
edumazet@google.com, pabeni@redhat.com,
Andrew Lunn <andrew@lunn.ch>
Subject: Re: [PATCHv3 1/3] net: fec: do not use readl()/writel() for ColdFire
Date: Thu, 10 Sep 2026 17:42:10 -0700 [thread overview]
Message-ID: <20260910174210.0f8a4ad2@kernel.org> (raw)
In-Reply-To: <20260907134037.1855408-2-gerg@linux-m68k.org>
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? 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.
next prev parent reply other threads:[~2026-09-11 0:42 UTC|newest]
Thread overview: 8+ 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-11 0:42 ` Jakub Kicinski [this message]
2026-09-11 7:39 ` Arnd Bergmann
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
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=20260910174210.0f8a4ad2@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=arnd@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=frank.li@nxp.com \
--cc=gerg@linux-m68k.org \
--cc=imx@lists.linux.dev \
--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