Linux kernel and device drivers for NXP i.MX platforms
 help / color / mirror / Atom feed
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,
	linux-can@vger.kernel.org, linux-spi@vger.kernel.org,
	olteanv@gmail.com, Greg Ungerer <gerg@linux-m68k.org>
Subject: [PATCHv3 0/3] m68k: coldfire: fix non-standard readX()/writeX() functions
Date: Mon,  7 Sep 2026 23:37:08 +1000	[thread overview]
Message-ID: <20260907134037.1855408-1-gerg@linux-m68k.org> (raw)

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.

Patch 3 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 that the v1 and v2 versions of this series carried a change to the
sdhci-esdhc-mcf.c driver that is now in mainline - so dropped from this
current v3 series.

The v2 series moved from an RFC to a patch series. There was only minor
changes overall to address comments. Changes include formatting, separating
out the mcf5441x regmap in spi-fsl-dspi.c (patch 3) and reordering the
quirks in flexcan-core.c (patch 3).

This v3 series has no new code changes. It is sent with an expanded CC
list in the hope of getting the net driver changes (patches 1 and 2)
picked up so the final readl/writel fix (patch 3) that depends on them
can be applied.

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/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 +
 8 files changed, 218 insertions(+), 241 deletions(-)



             reply	other threads:[~2026-09-07 13:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-07 13:37 Greg Ungerer [this message]
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
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=20260907134037.1855408-1-gerg@linux-m68k.org \
    --to=gerg@linux-m68k.org \
    --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-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