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]
Date:	Tue, 12 Feb 2013 11:29:34 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Michal Simek <monstr@...str.eu>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Alexey Brodkin <Alexey.Brodkin@...opsys.com>,
	Vineet Gupta <Vineet.Gupta1@...opsys.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	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 Mon, 2013-02-11 at 16:08 +0000, Arnd Bergmann wrote:
> I tend to disagree. You should never assume that a device is the same
> endianess as the the CPU, and you should try not to use the __raw_*
> accessors in device drivers either.
> 
> In particular, ARM can run both big- and little-endian even though
> big-endian is rarely used, so you need to know the endianess for
> the device you are talking to rather than assume that it knows
> what the CPU does at the time.

Part of the problem he might be having is that the way a device is wired
to the bus may be different depending on whether the CPU is running LE
or BE ... or rather should be (in order to preserve byte addresses).

However, not all logic out there might do it right, which means that you
may end up with the wrong wiring if you switch the core around in SW.

It depends how the ARM core operates vs. IO when switched between BE and
LE, does it keep the same lines doing byte 0 or does it keep the MSB/LSB
in the same place (and thus changes which lanes contain byte 0) ?

Depending on how the core does the mode change it may require a wiring
change of IO devices as well... If it changes where byte 0 is, then data
cycles must have the lanes reversed. If it changes where the MSB is,
then address cycles must have the lanes reversed.

I wouldn't be surprised if most SOC bus logic out there gets it wired up
for one and only one case.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ