linux-kernel - Re: [PATCH] Fixes for dw_dmac and atmel-mci for AP700x

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-next>] [day] [month] [year] [list]

Date:	Tue, 21 Aug 2012 08:31:32 +0000
From:	Arnd Bergmann <arnd.bergmann@...aro.org>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	Hein Tibosch <hein_tibosch@...oo.es>,
	"Hans-Christian Egtvedt" <hans-christian.egtvedt@...el.com>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	Havard Skinnemoen <havard@...nnemoen.net>,
	"ludovic.desroches" <ludovic.desroches@...el.com>,
	linux-kernel@...r.kernel.org,
	"spear-devel" <spear-devel@...t.st.com>
Subject: Re: [PATCH] Fixes for dw_dmac and atmel-mci for AP700x

On Tuesday 21 August 2012, Viresh Kumar wrote:
> > Is AVR32 a big-endian system? Probably big-endian, that's why values are
> > > getting
> > > swapped. And dw_dmac is the standard one, can call it little endian for
> > the
> > > time being.
> > >
> > > @Arnd: What should we do here?
> >
> > Yes, AVR32 is big-endian. I assume that dw_dmac can be either configured
> > as little-endian or big-endian and that it is configured as big-endian
> > on AVR32.
> >
> 
> Just to understand a bit more on this always confusing endianess concept:
> - For AVR32, readl is calling swab everytime. So whatever we write will get
> swapped.
> - What are the implications of dw_dmac configured in little/big endian?
> 
> When we write something to register of a peripheral, whose endianess
> property decides how it will get written. Processor or Peripheral?

The device decides which accessor we need to use (readl, ioread, ioread_be,
in_be, in_le, ...). The architecture code must ensure that this is
implemented properly based on the CPU endianess. We don't have a proper
accessor function that implements "device has same endianess as CPU".
Using __raw_* is not a replacement for that.

I don't mind adding such an accessor at all, and a number people have
complained about the lack of this for some time, but you should be
aware that a lot of peripherals that are intended to be used in
"CPU-endian" mode eventually end up getting used in "wrong-endian"
mode, e.g. when someone decides to put that peripheral on a PCI
card and someone else sticks it into a machine that has a CPU
with the opposed (or configurable) endianess. It would be nice if
the likes of designware could at least pick one endianess per
device they do, but the reality is that we have to deal with both
variants and only the device driver can find out what it is.

	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/