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: <1781360.cmQWHCW5SC@wuerfel>
Date:	Wed, 30 Jan 2013 15:36:10 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Michal Simek <monstr@...str.eu>
Cc:	Vineet Gupta <Vineet.Gupta1@...opsys.com>,
	Alexey Brodkin <Alexey.Brodkin@...opsys.com>,
	Arnd Bergmann <arnd.bergmann@...aro.org>,
	linux-kernel@...r.kernel.org, grant.likely@...retlab.ca,
	benh@...nel.crashing.org
Subject: Re: [PATCH] drivers/block/xsysace - replace in(out)_8/in(out)_be16/in(out)_le16 with generic iowrite(read)8/16(be)

On Wednesday 30 January 2013 13:31:58 Michal Simek wrote:
> Also from my understanding of arm we should use readl/b/w functions because
> they have memory barriers which should be probably performed.
> 
> And I haven't found any IO function which will behave on arm as LE and
> on PPC as BE.

There are none, except for the __raw_ versions that are generally
not recommended for other reasons.

There really is no easy solution, because most of the hardware IP
blocks have fixed endianess, e.g. an OHCI USB controller will normally
have little-endian registers on all architectures, but in very rare
cases it may be big-endian, because some hardware designer tried to
be helpful and put a byte swapping logic in front of it.

There are a few devices that tend to have the same endianess as the
CPU, again because some hardware designer tried to make things easy
for software by making the hardware confiurable. Again, what normally
happens is that the next hardware designer takes this block and 
hardwires it to some endianess that he sees as "correct" but puts
it on a system with a variable-endian CPU. Note that there are both
little-endian PowerPC systems and big-endian ARM systems, they just
happen to be the minority on an architecture where 99% of the users
prefer the opposite.

The outcome is basically you're screwed for every driver that is
not fixed endianess. The normal workaround is to do something like

#if defined(CONFIG_FOO_BIG_ENDIAN) && !defined(CONFIG_FOO_LITTLE_ENDIAN)
/* always big-endian
#define foo_readl(dev, reg) ioread32_be(dev->regs + reg)
#define foo_writel(dev, reg, val) iowrite32_be(val, dev->regs + reg)
#elif !defined(CONFIG_FOO_BIG_ENDIAN) && defined(CONFIG_FOO_LITTLE_ENDIAN)
/* always little-endian
#define foo_readl(dev, reg) ioread32(dev->regs + reg)
#define foo_writel(dev, reg, val) iowrite32e(val, dev->regs + reg)
#else
/* run-time configured */
#define foo_readl(dev, reg) dev->readl(dev->regs + reg)
#define foo_writel(dev, reg, val) dev->writel(val, dev->regs + reg)
#endif

and select the CONFIG_FOO_BIG_ENDIAN and CONFIG_FOO_LITTLE_ENDIAN
symbols in Kconfig based on the system you are building for.

This of course gets further complicated if you require different
accessors per architecture, like ARM wanting readl or ioread32
and PowerPC wanting in_le32 for a little-endian SoC component.

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