From: Greg Ungerer <gerg@linux-m68k.org>
To: linux-m68k@lists.linux-m68k.org
Cc: linux-kernel@vger.kernel.org, arnd@kernel.org,
netdev@vger.kernel.org, linux-mmc@vger.kernel.org,
dmaengine@vger.kernel.org, linux-can@vger.kernel.org,
linux-spi@vger.kernel.org, olteanv@gmail.com, wei.fang@nxp.com,
frank.li@nxp.com, shenwei.wang@nxp.com, nico@fluxnic.net,
adureghello@baylibre.com, Greg Ungerer <gerg@linux-m68k.org>
Subject: [RFC 0/4] m68k: coldfire: fix non-standard readX()/writeX() functions
Date: Thu, 7 May 2026 00:11:41 +1000 [thread overview]
Message-ID: <20260506141629.3233399-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.
Looking for comments on the approach taken here, or if there is a better
way forward?
Note also 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.
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 | 254 +++++++++++++++---------------
drivers/net/ethernet/freescale/fec_ptp.c | 78 ++++-----
drivers/net/ethernet/smsc/smc91x.h | 12 -
drivers/spi/spi-fsl-dspi.c | 2
9 files changed, 217 insertions(+), 251 deletions(-)
reply other threads:[~2026-05-06 14:17 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260506141629.3233399-1-gerg@linux-m68k.org \
--to=gerg@linux-m68k.org \
--cc=adureghello@baylibre.com \
--cc=arnd@kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=frank.li@nxp.com \
--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=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