linux-kernel - Re: [PATCH 01/11] irqchip: Allow irq_reg_{readl,writel} to use __raw_{readl

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJiQ=7DWEr9Oej6=+3vqKL_fJd2-wvQjx2Xw4dYwyE3AGDXOUA@mail.gmail.com>
Date:	Wed, 29 Oct 2014 16:05:21 -0700
From:	Kevin Cernekee <cernekee@...il.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Florian Fainelli <f.fainelli@...il.com>,
	Jason Cooper <jason@...edaemon.net>,
	Ralf Baechle <ralf@...ux-mips.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Maxime Bizon <mbizon@...ebox.fr>,
	Jonas Gorski <jogo@...nwrt.org>,
	Linux MIPS Mailing List <linux-mips@...ux-mips.org>
Subject: Re: [PATCH 01/11] irqchip: Allow irq_reg_{readl,writel} to use __raw_{readl_writel}

On Wed, Oct 29, 2014 at 2:13 PM, Arnd Bergmann <arnd@...db.de> wrote:
> On Wednesday 29 October 2014 13:09:47 Kevin Cernekee wrote:
>> On Wed, Oct 29, 2014 at 12:14 PM, Arnd Bergmann <arnd@...db.de> wrote:
>> >> The host CPU is connected to the peripheral/register interface using a
>> >> 32-bit wide data bus.  A simple 32-bit store originating from the host
>> >> CPU, targeted to an onchip SoC peripheral, will never need endian
>> >> swapping.  i.e. this code works equally well on all supported systems
>> >> regardless of endianness:
>> >>
>> >>     volatile u32 *foo = (void *)MY_REG_VA;
>> >>     *foo = 0x12345678;
>> >>
>> >> 8-bit and 16-bit accesses may be another story, but only appear in a
>> >> few very special peripherals.
>> >
>> > Sorry, but this makes no sense. If you run a little-endian kernel
>> > on one of the MIPS systems that you marked as "always BE", or a
>> > big-endian kernel on the systems that are marked "always LE",
>> > then you have to byte swap.
>>
>> If I ran an LE MIPS kernel on a BE system, it would hang on boot.  I
>> know this through experience.
>
> What is a "BE system" then? Is the CPU core not capable of running
> code either way?

On the MIPS BCM7xxx chips, LE/BE support was a design requirement.  So:

 - The chips include a strap pin for LE/BE so it can be configured
through board jumpers.  This is the only supported method of switching
endianness.

 - Endianness interactions and performance concerns have been analyzed
for all peripherals, buses, and data flows.

 - As Florian mentioned earlier, the LE/BE strap preconfigures several
hardware blocks at boot time, e.g. telling the SPI controller how to
arrange the incoming data such that the MSB of each instruction word
read from flash shows up in the right place.

 - The entire software stack (and even the cross toolchain) needs to
be compiled for either LE or BE.

So in this context a "BE system" is a BCM7xxx MIPS chip strapped for
BE, or one of the BCM33xx/BCM63xx/BCM68xx MIPS chips that is hardwired
and verified for BE only.

>> Does this actually work on other architectures like ARM?  I still see
>> compile-time checks for CONFIG_CPU_ENDIAN* in a couple of places under
>> arch/arm.
>
> Yes, it should work on any architecture that supports both modes. It
> definitely works on all ARM cores I know, and on most PowerPC cores.
> I always assumed that MIPS was bi-endian as well, but according to
> what you say I guess it is not.
>
> ARM and PowerPC can actually switch endianess in the kernel, and this
> is what they do in the first instruction when you run a different
> endianess from what the boot loader runs as it calls into the kernel.
> The ARM boot protocol requires entering the kernel in little-endian
> mode, while I think on PowerPC the boot loader is supposed to detect
> the format of the kernel binary and pick the right mode before calling
> it.

Is it the intention to allow runtime endian switching on any
ARM/PowerPC platform (even the Samsung products you mentioned)?  Or
only on the boards that were designed to operate this way?

Our problem becomes much simpler if we assume that the majority of
systems have a fixed endianness, and only a few special cases need to
accommodate the different kernel/register endianness permutations
you've listed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/