From: Andrew Lunn <andrew@lunn.ch>
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, kuba@kernel.org, pabeni@redhat.com
Subject: Re: [PATCHv3 1/3] net: fec: do not use readl()/writel() for ColdFire
Date: Mon, 28 Sep 2026 16:12:42 +0200 [thread overview]
Message-ID: <06910e8b-5717-41cd-b18a-d1c4f92fb8dc@lunn.ch> (raw)
In-Reply-To: <b9a686cf-0d28-4feb-b971-f1bf2264964f@linux-m68k.org>
On Mon, Sep 28, 2026 at 10:59:52PM +1000, Greg Ungerer wrote:
>
> On 24/9/26 00:15, Andrew Lunn wrote:
> >> The driver will always need to support big and little endian hardware, so I
> >> am not sure how to avoid some abstraction like this.
> >
> > I was wondering if there is a linux standard set of macros which is
> > supposed to handle this big/little difference, the macro knows the
> > architecture and does the correct thing?
>
> There is regmap, but that is way more than just access macros.
> At least one driver shared across big and little endian architectures
> does use that - the freescale dspi driver (drivers/spi/spi-fsl-dspi.c).
> There is probably others.
>
> If the issue is more to do with code churn then a simpler approach here
> might be to just essentially keep the same work around but move it locally
> into fec.h. Something like the patch below.
>
> This could be cleaned up to use ioread32be()/iowrite32be() after the final
> readl()/writel() changes have been applied.
The changes are fine, i just did not know all the background and
wanted to make sure we were not missing something. Thanks for the
explanations.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
next prev parent reply other threads:[~2026-09-28 14:12 UTC|newest]
Thread overview: 21+ 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-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-23 13:07 ` Greg Ungerer
2026-09-23 13:23 ` Andrew Lunn
2026-09-23 14:00 ` Greg Ungerer
2026-09-23 14:15 ` Andrew Lunn
2026-09-23 14:40 ` Geert Uytterhoeven
2026-09-24 2:32 ` Michael Schmitz
2026-09-28 12:59 ` Greg Ungerer
2026-09-28 14:12 ` Andrew Lunn [this message]
2026-09-07 13:37 ` [PATCHv3 2/3] net: smc91x: do not use readw()/writew() on ColdFire platforms Greg Ungerer
2026-09-23 13:04 ` Greg Ungerer
2026-09-23 21:31 ` Arnd Bergmann
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=06910e8b-5717-41cd-b18a-d1c4f92fb8dc@lunn.ch \
--to=andrew@lunn.ch \
--cc=andrew+netdev@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=kuba@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.