public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Matthieu CASTET" <castet.matthieu@free.fr>
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] [BFIN] Blackfin architecture patch for 2.6.18
Date: Fri, 22 Sep 2006 17:34:31 +0000 (UTC)	[thread overview]
Message-ID: <ef16r7$vjo$1@sea.gmane.org> (raw)
In-Reply-To: 489ecd0c0609220248m41749725t75ccf9ca8753b8dc@mail.gmail.com

On Fri, 22 Sep 2006 17:48:03 +0800, Luke Yang wrote:

>> 9.  In struct sport_register, what are all of those volatiles
>> for?  Use of volatile usually
>> indicates bad locking or bad memory barriers, etc., somewhere.
>  This is not a bug. In embedded, a memory mapped register should be
> defined as volatile, becasue the hardware may change it without
> notifying the software.
>
No this is bad design. Each time you want to access those memory map
register you should use read{bwl}/in{bwl} variants.
After all memory mapped register are not so different of mmio on standard
PC.

For example on au1x00 mips platform [1], some helper are defined to access
those memory map registers.

using volatile is awful : instead of a clean API to access those
registers, you often forgot that volatile is need which lead to very hard
to debug bugs (depend of compiler optimization, state of memory, ...).
For example on a embedded platform (ADI fusiv) where volatile are used
everywhere, some developers forgot some, which lead to random lockup on
boot.

Matthieu


[1]
include/asm-mips/mach-au1x00/au1000.h
static inline u32 au_readl(unsigned long reg)
{
    return (*(volatile u32 *)reg);
}


      reply	other threads:[~2006-09-22 17:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-22  5:04 [PATCH 1/3] [BFIN] Blackfin architecture patch for 2.6.18 Luke Yang
     [not found] ` <20060921232921.88d2aa5d.rdunlap@xenotime.net>
2006-09-22  9:48   ` Luke Yang
2006-09-22 17:34     ` Matthieu CASTET [this message]

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='ef16r7$vjo$1@sea.gmane.org' \
    --to=castet.matthieu@free.fr \
    --cc=linux-kernel@vger.kernel.org \
    /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