All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Greg Ungerer <gerg@linux-m68k.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Angelo Dureghello <angelo@sysam.it>,
	Logan Gunthorpe <logang@deltatee.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	Philippe Ombredanne <pombredanne@nexb.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	"Linux/m68k" <linux-m68k@vger.kernel.org>,
	Linux-Arch <linux-arch@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: endianness swapped
Date: Sun, 28 Apr 2019 20:44:03 +0200	[thread overview]
Message-ID: <CAK8P3a16O57dvUYUPVZJpvZ7Hm6WA-jc_svQHTAEdDpbyLRv7w@mail.gmail.com> (raw)
In-Reply-To: <c75092d5-0bbf-cd8e-d0a2-ff1384ac5a48@linux-m68k.org>

On Sun, Apr 28, 2019 at 3:59 PM Greg Ungerer <gerg@linux-m68k.org> wrote:
> On 28/4/19 7:21 pm, Arnd Bergmann wrote:
> > On Sun, Apr 28, 2019 at 10:46 AM Geert Uytterhoeven
> > <geert@linux-m68k.org> wrote:
> >> On Sat, Apr 27, 2019 at 10:22 PM Angelo Dureghello <angelo@sysam.it> wrote:
> >>> On Sat, Apr 27, 2019 at 05:32:22PM +0200, Angelo Dureghello wrote:
> >
> > Coldfire makes the behavior of readw()/readl() depend on the
> > MMIO address, presumably since that was the easiest way to
> > get drivers working originally, but it breaks the assumption
> > in the asm-generic code.
>
> Yes, that is right.
>
> There is a number of common hardware modules that Freescale have
> used in the ColdFire SoC parts and in their ARM based parts (iMX
> families). The ARM parts are pretty much always little endian, and
> the ColdFire is always big endian. The hardware registers in those
> hardware blocks are always accessed in native endian of the processor.

In later Freescale/NXP ARM SoCs (i.MX and Layerscape), we
also get a lot of devices pulled over from PowerPC, with random
endianess. In some cases, the same device that had big-endian
registers originally ends up in two different ARM products and one of
them uses big-endian while the other one uses little-endian registers.

> So the address range checks are to deal with those internal
> hardware blocks (i2c, spi, dma, etc), since we know those are
> at fixed addresses. That leaves the usual endian swapping in place for
> other general (ie external) devices (PCI devices, network chips, etc).

Is there a complete list of coldfire on-chip device drivers?

Looking at some of the drivers:

- drivers/i2c/busses/i2c-imx.c uses only 8-bit accesses and works either way,
  same for drivers/tty/serial/mcf.c
- drivers/spi/spi-coldfire-qspi.c is apparently coldfire-only and could use
  ioread32be for a portable to do big-endian register access.
- edma-common has a wrapper to support both big-endian and little-endian
  configurations in the same kernel image, but the mcf interrupt handler
  is hardcoded to the (normally) little-endian ioread32 function.
- drivers/net/ethernet/freescale/fec_main.c is shared between coldfire
  and i.MX (but not mpc52xx), and is hardcoded to readl/writel, and
  would need the same trick as edma to make it portable.

      Arnd

  reply	other threads:[~2019-04-28 18:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190427153222.GA9613@jerusalem>
     [not found] ` <20190427202150.GB9613@jerusalem>
2019-04-28  8:46   ` endianness swapped Geert Uytterhoeven
2019-04-28  9:21     ` Arnd Bergmann
2019-04-28 13:59       ` Greg Ungerer
2019-04-28 18:44         ` Arnd Bergmann [this message]
2019-04-28 21:31           ` Angelo Dureghello
2019-04-29  7:03           ` Greg Ungerer
2019-04-29  8:40             ` Arnd Bergmann
2019-04-29  8:44         ` Geert Uytterhoeven
2019-04-29 11:13           ` Arnd Bergmann

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=CAK8P3a16O57dvUYUPVZJpvZ7Hm6WA-jc_svQHTAEdDpbyLRv7w@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=angelo@sysam.it \
    --cc=geert@linux-m68k.org \
    --cc=gerg@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=logang@deltatee.com \
    --cc=pombredanne@nexb.com \
    --cc=tglx@linutronix.de \
    /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.