From: Greg Ungerer <gerg@linux-m68k.org>
To: linux-m68k@lists.linux-m68k.org
Cc: 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,
adureghello@baylibre.com, ulfh@kernel.org,
linux-mmc@vger.kernel.org, linux-can@vger.kernel.org,
linux-spi@vger.kernel.org, olteanv@gmail.com,
Greg Ungerer <gerg@linux-m68k.org>
Subject: [PATCHv2 0/4] m68k: coldfire: fix non-standard readX()/writeX() functions
Date: Wed, 10 Jun 2026 00:12:56 +1000 [thread overview]
Message-ID: <20260609142139.1563360-1-gerg@linux-m68k.org> (raw)
This odd 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, 2 and 3 in this series are specific driver changes that can be
made independently of the final ColdFire readX()/writeX() change.
Patch 4 is the actual switch to ColdFire building using asm-generic
readX()/writeX(), but also contains three driver fixes that are not easily
handled independently.
Note that I don't have access to all supported hardware needed to fully
test all these changes. I have tested what I have, a bunch of the standard
Freescale ColdFire eval boards, and inspected generated code for differences.
Note also that patch 3 relies on changes that are currently only in
linux-next, and are scheduled to hit mainline during the next v7.2
merge window. Those changes are also available in an immutable git tree
at git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git
cf-internal-io branch.
This v2 series moves from an RFC to a patch series. There is only minor
changes overall to address comments. Changes include formatting, separating
out the mcf5441x regmap in spi-fsl-dspi.c (patch 4) and reordering the
quirks in flexcan-core.c (patch 4).
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
---
arch/m68k/include/asm/io_no.h | 68 -------
drivers/dma/mcf-edma-main.c | 14 -
drivers/mmc/host/sdhci-esdhc-mcf.c | 24 +-
drivers/net/can/flexcan/flexcan-core.c | 1
drivers/net/ethernet/freescale/fec.h | 15 +
drivers/net/ethernet/freescale/fec_main.c | 257 +++++++++++++++---------------
drivers/net/ethernet/freescale/fec_ptp.c | 78 ++++-----
drivers/net/ethernet/smsc/smc91x.h | 12 -
drivers/spi/spi-fsl-dspi.c | 14 +
9 files changed, 230 insertions(+), 253 deletions(-)
next reply other threads:[~2026-06-09 14:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-09 14:12 Greg Ungerer [this message]
2026-06-09 14:12 ` [PATCHv2 1/4] net: fec: do not use readl()/writel() for ColdFire Greg Ungerer
2026-06-10 8:05 ` Andrew Lunn
2026-06-09 14:12 ` [PATCHv2 2/4] net: smc91x: do not use readw()/writew() on ColdFire platforms Greg Ungerer
2026-06-09 14:13 ` [PATCHv2 3/4] mmc: sdhci-esdhc-mcf: do not use readl()/writel() on ColdFire Greg Ungerer
2026-06-09 14:13 ` [PATCHv2 4/4] m68k: coldfire: fix non-standard readX()/writeX() functions Greg Ungerer
2026-06-09 15:26 ` Frank Li
2026-06-13 9:22 ` [PATCHv2 0/4] " Paolo Abeni
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=20260609142139.1563360-1-gerg@linux-m68k.org \
--to=gerg@linux-m68k.org \
--cc=adureghello@baylibre.com \
--cc=arnd@kernel.org \
--cc=frank.li@nxp.com \
--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-mmc@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nico@fluxnic.net \
--cc=olteanv@gmail.com \
--cc=shenwei.wang@nxp.com \
--cc=ulfh@kernel.org \
--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