public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Paulius Zaleckas <paulius.zaleckas@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org,
	Hans Ulli Kroll <ulli.kroll@googlemail.com>,
	Russell King <linux@arm.linux.org.uk>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARM: Gemini: Add support for PCI BUS
Date: Mon, 29 Nov 2010 21:02:40 +0100	[thread overview]
Message-ID: <201011292102.41155.arnd@arndb.de> (raw)
In-Reply-To: <4CF3F687.6040801@gmail.com>

On Monday 29 November 2010 19:52:55 Paulius Zaleckas wrote:
> On 11/29/2010 06:45 PM, Arnd Bergmann wrote:
> > There are many differences between readl and __raw_readl, including
> >
> > * __raw_readl does not have barriers and does not serialize with
> >    spinlocks, so it breaks on out-of-order CPUs.
> > * __raw_readl does not have a specific endianess, while readl is
> >    fixed little-endian, just as the hardware is in this case.
> >    The endian-conversion is a NOP on little-endian ARM, but required
> >    if you actually run on a big-endian ARM (you don't).
> > * __raw_readl may not be atomic, gcc is free to split the access
> >    into byte wise reads (it normally does not, unless you mark
> >    the pointer __attribute__((packed))).
> >
> > In essence, it is almost never a good idea to use __raw_readl, and
> > the double underscores should tell you so.
> 
> You are wrong:
> 
> Since CONFIG_ARM_DMA_MEM_BUFFERABLE is NOT defined for FA526 core,
> no barriers are in use when using readl. It just translates into
> le32_to_cpu(__raw_readl(x)). Now this CPU has physical pin for endianess
> configuration and if you will chose big-endian you will fail to read
> internal registers, because they ALSO change endianess and le32_to_cpu()
> will screw it. However it is different when accessing registers through
> PCI bus, then you need to use readl().

Ok, I only checked that the platform does not support big-endian Linux
kernel, not if the HW designers screwed up their registers, sorry about
that.

The other points are of course still valid: If the code ever gets
used on an out of order CPU, it is broken. More importantly, if someone
looks at the code as an example for writing another PCI support code,
it may end up getting copied to some place where it ends up causing
trouble.

The typical way to deal with mixed-endian hardware reliably is to have
a header file containing code like

#ifdef CONFIG_GEMINI_BIG_ENDIAN_IO
#define gemini_readl(x) __swab32(readl(x))
#define ...
#else
#define gemini_readl(x) readl(x))
#endif

This also takes care of the (not as unlikely as you'd hope) case that
the next person reusing the PCI hardware wires its endianess different
from the CPU endianess.

	Arnd

  reply	other threads:[~2010-11-29 20:03 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-27 12:24 [PATCH] ARM: Gemini: Add support for PCI BUS Hans Ulli Kroll
2010-11-28 19:56 ` Arnd Bergmann
2010-11-29 12:17   ` Hans Ulli Kroll
2010-11-29 15:02     ` Arnd Bergmann
2010-11-29 16:05   ` Paulius Zaleckas
2010-11-29 16:45     ` Arnd Bergmann
2010-11-29 18:52       ` Paulius Zaleckas
2010-11-29 20:02         ` Arnd Bergmann [this message]
2010-11-29 20:19           ` Paulius Zaleckas
2010-11-30  8:15             ` Hans Ulli Kroll
2010-11-30  9:34               ` Paulius Zaleckas
2010-12-01 11:52                 ` Hans Ulli Kroll
2010-12-01 13:08                   ` Paulius Zaleckas
2010-12-01 15:02                     ` Hans Ulli Kroll
2010-12-06 10:51       ` Sergei Shtylyov
2010-12-06 12:18         ` Arnd Bergmann
2010-11-29 19:32     ` Russell King - ARM Linux
2010-11-29 19:57       ` Paulius Zaleckas
  -- strict thread matches above, loose matches on Subject: below --
2010-11-20 14:27 [PATCH] ARM: Gemini: Add support for PCI Bus Hans Ulli Kroll
2010-11-20 19:30 ` Paulius Zaleckas
2010-11-26 11:18   ` Russell King - ARM Linux
2010-11-26 11:57 ` Michał Mirosław
2010-11-27 12:16   ` Hans Ulli Kroll
2010-11-27 13:01     ` Michał Mirosław
2010-11-27 15:39       ` Arnd Bergmann
2010-11-29  8:12         ` Hans Ulli Kroll
2010-11-29 14:22         ` Russell King - ARM Linux
2010-11-29 14:50           ` Hans Ulli Kroll
2010-11-29 15:57             ` Arnd Bergmann
2010-11-30 15:38               ` Hans Ulli Kroll
2010-11-30 16:05               ` Russell King - ARM Linux
2010-11-30 16:19                 ` Arnd Bergmann
2010-12-01 15:05                   ` Hans Ulli Kroll
2010-11-29 15:50           ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201011292102.41155.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=paulius.zaleckas@gmail.com \
    --cc=ulli.kroll@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox