From: "Arend van Spriel" <arend@broadcom.com>
To: "Randy Dunlap" <rdunlap@xenotime.net>
Cc: "george@znau.edu.ua" <george@znau.edu.ua>,
"zajec5@gmail.com" <zajec5@gmail.com>,
"mb@bu3sch.de" <mb@bu3sch.de>,
"linville@tuxdriver.com" <linville@tuxdriver.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [RFC] drivers: brcmaxi: provide amba axi functionality in separate module
Date: Wed, 23 Mar 2011 11:51:16 +0100 [thread overview]
Message-ID: <op.vsslrqf23ri7v4@arend-laptop> (raw)
In-Reply-To: <20110321132848.e4e846a5.rdunlap@xenotime.net>
On Mon, 21 Mar 2011 21:28:48 +0100, Randy Dunlap <rdunlap@xenotime.net>
wrote:
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code
> ***
>
Hi Randy,
One of the things I am facing in the code is the use of the volatile
keyword so I browsed another file in the Documentation folder:
volatile-considered-harmful.txt. As your name popped up I would like to
ask some questions. The register access macros in the brcmaxi module make
use of the accessor functions readb/w/l and writeb/w/l and the pointer
parameter is cast with volatile keyword, which I assume to be unneccessary
(reading the doc). Another instance uses it to avoid optimization. Here is
how the function is coded currently:
void foobar(void *r, u32 val)
{
volatile u32 dummy;
WR_REG(r, val);
dummy = RD_REG(r);
}
The register read is necessary to assure the register write is properly
flushed out in hardware. Could removing the volatile for the dummy
variable cause removal of the register read due to code optimization.
Gr. AvS
--
"The most merciful thing in the world, I think, is the inability of the
human
mind to correlate all its contents." - "The Call of Cthulhu"
next prev parent reply other threads:[~2011-03-23 10:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-21 20:16 [RFC] drivers: brcmaxi: AMBA AXI functionality library module Arend van Spriel
2011-03-21 20:16 ` [RFC] drivers: brcmaxi: provide amba axi functionality in separate module Arend van Spriel
2011-03-21 20:28 ` Randy Dunlap
2011-03-21 20:38 ` Johannes Berg
2011-03-21 20:42 ` Randy Dunlap
2011-03-21 20:45 ` Johannes Berg
2011-03-23 10:51 ` Arend van Spriel [this message]
[not found] ` <1300888183.18815.5.camel@Nokia-N900>
2011-03-23 13:54 ` Arend van Spriel
2011-03-23 14:09 ` Michael Büsch
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=op.vsslrqf23ri7v4@arend-laptop \
--to=arend@broadcom.com \
--cc=george@znau.edu.ua \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=mb@bu3sch.de \
--cc=rdunlap@xenotime.net \
--cc=zajec5@gmail.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.