All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Barkowski <michaelbarkowski@ruggedcom.com>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org, Timur Tabi <timur@freescale.com>
Subject: Re: Is volatile always verboten for FSL QE structures?
Date: Fri, 02 Oct 2009 12:57:54 -0400	[thread overview]
Message-ID: <4AC63112.7080404@ruggedcom.com> (raw)
In-Reply-To: <C3FE6281-04FA-48B3-96EA-D6E68AF65D6B@kernel.crashing.org>

Kumar Gala wrote:
> 
> On Oct 2, 2009, at 9:46 AM, Timur Tabi wrote:
> 
>> Michael Barkowski wrote:
>>> Just wondering - is there a case where using volatile for UCC
>>> parameter RAM for example will not work, or is the use of I/O
>>> accessors everywhere an attempt to be portable to other architectures?
>>
>> 'volatile' just doesn't really do what you think it should do.  The
>> PowerPC architecture is too complicated w.r.t. ordering of reads and
>> writes.  In other words, you can't trust it.
>>
>> No one should be using 'volatile' to access I/O registers.
> 
> See Documentation/volatile-considered-harmful.txt
> 

I'm happy to adopt your interpretation of it, and I appreciate the explanation.

from Documentation/volatile-considered-harmful.txt:
>   - The above-mentioned accessor functions might use volatile on
>     architectures where direct I/O memory access does work.  Essentially,
>     each accessor call becomes a little critical section on its own and
>     ensures that the access happens as expected by the programmer.

Part of it was that I wondered if this was one of those architectures.  I guess not.

-- 
Michael Barkowski
905-482-4577

  reply	other threads:[~2009-10-02 16:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-02 14:14 Is volatile always verboten for FSL QE structures? Michael Barkowski
2009-10-02 14:46 ` Timur Tabi
2009-10-02 16:41   ` Kumar Gala
2009-10-02 16:57     ` Michael Barkowski [this message]
2009-10-02 18:08       ` Guillaume Knispel
2009-10-03  9:55         ` Simon Richter
2009-10-03 11:20           ` Benjamin Herrenschmidt

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=4AC63112.7080404@ruggedcom.com \
    --to=michaelbarkowski@ruggedcom.com \
    --cc=galak@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=timur@freescale.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.