[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <4B443E30-4B6C-4E37-A038-AB05214EE78C@embeddedalley.com>
Date: Thu, 29 May 2008 14:05:48 +0300
From: Pantelis Antoniou <panto@...eddedalley.com>
To: Haavard Skinnemoen <haavard.skinnemoen@...el.com>
Cc: benh@...nel.crashing.org, Matthew Wilcox <matthew@....cx>,
Linus Torvalds <torvalds@...ux-foundation.org>,
David Miller <davem@...emloft.net>, linux-arch@...r.kernel.org,
scottwood@...escale.com, linuxppc-dev@...abs.org,
alan@...rguk.ukuu.org.uk, linux-kernel@...r.kernel.org,
tpiepho@...escale.com
Subject: Re: MMIO and gcc re-ordering issue
On 28 Μαϊ 2008, at 11:36 ΠΜ, Haavard Skinnemoen wrote:
> Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote:
>>>> I'm happy to say that __raw is purely about ordering and make them
>>>> byteswap on powerpc tho (ie, make them little endian like the non-
>>>> raw
>>>> counterpart).
>>>
>>> That would break a lot of drivers.
>>
>> How many actually use __raw_ * ?
>
> I do -- in all the drivers for on-chip peripherals that are shared
> between AT91 ARM (LE) and AVR32 (BE). Since everything goes on inside
> the chip, we must use LE accesses on ARM and BE accesses on AVR32.
>
> Currently, this is the only interface I know that can do native-endian
> accesses, so if you take it away, I'm gonna need an alternative
> interface that doesn't do byteswapping.
>
> Haavard
I certainly do too.
Quite a lot of SoC specific drivers use __raw for accessing their
on-chip peripherals.
Please don't change the __raw semantics, you'll end up breaking almost
everything that's BE.
-- Pantelis
--
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