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

Date:	Tue, 21 Aug 2012 07:15:07 -0700
From:	Havard Skinnemoen <havard@...nnemoen.net>
To:	Arnd Bergmann <arnd.bergmann@...aro.org>
Cc:	Viresh Kumar <viresh.kumar@...aro.org>,
	Hein Tibosch <hein_tibosch@...oo.es>,
	Hans-Christian Egtvedt <hans-christian.egtvedt@...el.com>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	"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 Tue, Aug 21, 2012 at 1:31 AM, Arnd Bergmann <arnd.bergmann@...aro.org> wrote:
> 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.

A native-endian accessor would really help in this case. Back in 2006
when I did the AVR32 port, that's what I thought __raw_ was, but I
suspect I was both wrong, and the semantics of the I/O accessors have
changed slightly over time. But since __raw_ did exactly what was
needed on both AVR32 (big endian) and AT91 ARM (little endian)
devices, I ended up using it for all on-chip devices.

read[bwl] on the other hand was implemented for external device
access. Since the SMC controller on AP7000 is really bizarre
(basically big endian data with little endian addressing), these
accessors became pretty weird too.

Anyway, if we want to purge all those inappropriate __raw accesses
from the Atmel drivers, we're going to need a replacement for internal
native-endian access. Right now, we don't have any.

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