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: <1360239636.2650.26.camel@pasglop>
Date:	Thu, 07 Feb 2013 23:20:36 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Alexey Brodkin <Alexey.Brodkin@...opsys.com>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	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:09 +0400, Alexey Brodkin wrote:
> 
> BTW I've just realized that in case if there's no bridge between CPU and 
> CF-controller or if this bridge is "transparent" (does no swapping
> neither bytes nor bits) our data accessors here should be changed.
> 
> Isn't it strange in "ace_datain_le16" use "ioread16be" or the one it was 
> here initially "in_be16"?
> With BE ones I'd say similar changes should be done.

This is part of the problem with those bloody attempts at dealing with
broken shit, they get the "right" case wrong :-)

So yes, if the bridge is wired up properly:

 - Register access is LE

 - Data port access is native endian (always) because what matters here
is not endianness but byte ordering (ie, which byte is 0) and if things
are wired properly, this is preserved.

So the correct things is in that case is to use ioread16_rep which will
do the right thing (and avoid the extra barriers and C loop) for the
data in/out code, and ioread16/iowrite16 for the registers.

For the "swapped" case, I would suggest using ioread16be for the registers
for the data port, use ioread16_rep followed by a pass of byteswap. I assume
that this incorrect wiring case only happens on BE platforms right ?

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/