Netdev List
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: Greg Ungerer <gerg@linux-m68k.org>, 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
Subject: Re: [PATCHv2 0/4] m68k: coldfire: fix non-standard readX()/writeX() functions
Date: Sat, 13 Jun 2026 11:22:24 +0200	[thread overview]
Message-ID: <fe40891c-3fd1-417c-835e-6f1046db7844@redhat.com> (raw)
In-Reply-To: <20260609142139.1563360-1-gerg@linux-m68k.org>

On 6/9/26 4:12 PM, Greg Ungerer wrote:
> 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.

I understand that with this series you are targeting the m68K tree, am I
correct?

A possibly better option would be, after that the pre-req patches land
into Linus's tree, to share an immutable branch for this series, so that
both m68k and net-next could pull it.

/P


      parent reply	other threads:[~2026-06-13  9:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-09 14:12 [PATCHv2 0/4] m68k: coldfire: fix non-standard readX()/writeX() functions Greg Ungerer
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 ` Paolo Abeni [this message]

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=fe40891c-3fd1-417c-835e-6f1046db7844@redhat.com \
    --to=pabeni@redhat.com \
    --cc=adureghello@baylibre.com \
    --cc=arnd@kernel.org \
    --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-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