lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a16O57dvUYUPVZJpvZ7Hm6WA-jc_svQHTAEdDpbyLRv7w@mail.gmail.com>
Date:   Sun, 28 Apr 2019 20:44:03 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Greg Ungerer <gerg@...ux-m68k.org>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Angelo Dureghello <angelo@...am.it>,
        Logan Gunthorpe <logang@...tatee.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        Philippe Ombredanne <pombredanne@...b.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        "Linux/m68k" <linux-m68k@...r.kernel.org>,
        Linux-Arch <linux-arch@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: endianness swapped

On Sun, Apr 28, 2019 at 3:59 PM Greg Ungerer <gerg@...ux-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@...ux-m68k.org> wrote:
> >> On Sat, Apr 27, 2019 at 10:22 PM Angelo Dureghello <angelo@...am.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ