linux-kernel - Re: [PATCH] drivers/block/xsysace - replace in(out)_8/in(out)_be16/in(out)

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: <1360271743.2650.38.camel@pasglop>
Date:	Fri, 08 Feb 2013 08:15:43 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Alexey Brodkin <Alexey.Brodkin@...opsys.com>,
	Michal Simek <monstr@...str.eu>, Arnd Bergmann <arnd@...db.de>,
	Vineet Gupta <Vineet.Gupta1@...opsys.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	dahinds@...rs.sourceforge.net
Subject: Re: [PATCH] drivers/block/xsysace - replace
 in(out)_8/in(out)_be16/in(out)_le16 with generic iowrite(read)8/16(be)

On Thu, 2013-02-07 at 16:44 +0000, Grant Likely wrote:
> 
> I've just spent some quality time with a piece of paper, and I think
> I've figured it out...

http://linuxplumbers.ubicast.tv/videos/big-and-little-endian-inside-out/

Watch the last part on IO busses....

This all has to do which which byte of the bus is the lowest byte
*address* regardless of significance. That's how the wiring should be
consistent between CPU and device, in order for a data port to work
properly.

The data port then requires no swapping (which also means it works
nicely with dumb DMA engines etc...)

Whether the registers need swapping or not depends on which half is the
MSB, which is somewhat a semantically higher level than the bus
transport, and depends on whether the device exposes them as BE or LE
registers. But data ports are just "windows" to a byte stream and
shouldn't be affected by endianess (again, unless you get a moron doing
the HW which seems to be still too common).

There is only one right way to connect devices to CPUs basically, which
is called byte address invariance, and preserves the order of bytes in
term of byte addresses.

(Note that for busses that also carry addresses such as PCI, this can
get tricky as you might need to have the lanes routed in a different
order for address vs. data cycles).

Cheers,
Ben.

--
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/