From: Arnd Bergmann <arnd@arndb.de>
To: "Russell King - ARM Linux" <linux@arm.linux.org.uk>
Cc: Stephen Boyd <sboyd@codeaurora.org>,
Catalin Marinas <catalin.marinas@arm.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 01/19] ARM: Make the argument to virt_to_phys() "const volatile"
Date: Tue, 25 Jan 2011 15:14:43 +0100 [thread overview]
Message-ID: <201101251514.43808.arnd@arndb.de> (raw)
In-Reply-To: <20110125102905.GC11507@n2100.arm.linux.org.uk>
On Tuesday 25 January 2011, Russell King - ARM Linux wrote:
> > Stephen, you might want to have a look at why the warning even appears
> > on MSM. Most uses of 'volatile' are misguided, and there could be an
> > actual bug in there.
>
> It's actually the right thing - look at x86's definition:
>
> static inline phys_addr_t virt_to_phys(volatile void *address)
Yes, the definition of virt_to_phys using a volatile pointer makes sense
because it allows you to pass volatile pointers, even if it doesn't
make any volatile accesses itself, hence my Acked-by.
However, marking variables as volatile needs to be done very carefully,
and the particular use in arch/arm/mach-msm/smd.c looks suspicious.
I don't think it can cause any actual harm to add volatile to the
smd_half_channel variables, but it disables some optimizations that
gcc can otherwise make, and it's not a replacement for locking or
atomic accesses.
Arnd
next prev parent reply other threads:[~2011-01-25 14:15 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-24 17:55 [PATCH v4 00/19] ARM: Add support for the Large Physical Address Extensions Catalin Marinas
2011-01-24 17:55 ` [PATCH v4 01/19] ARM: Make the argument to virt_to_phys() "const volatile" Catalin Marinas
2011-01-24 19:19 ` Stephen Boyd
2011-01-24 23:38 ` Russell King - ARM Linux
2011-01-25 10:00 ` Arnd Bergmann
2011-01-25 10:29 ` Russell King - ARM Linux
2011-01-25 14:14 ` Arnd Bergmann [this message]
2011-01-24 17:55 ` [PATCH v4 02/19] ARM: LPAE: Fix early_pte_alloc() assumption about the Linux PTE Catalin Marinas
2011-02-12 9:56 ` Russell King - ARM Linux
2011-01-24 17:55 ` [PATCH v4 03/19] ARM: LPAE: use long long format when printing physical addresses and ptes Catalin Marinas
2011-02-12 9:59 ` Russell King - ARM Linux
2011-01-24 17:55 ` [PATCH v4 04/19] ARM: LPAE: Use PMD_(SHIFT|SIZE|MASK) instead of PGDIR_* Catalin Marinas
2011-01-24 17:55 ` [PATCH v4 05/19] ARM: LPAE: Factor out 2-level page table definitions into separate files Catalin Marinas
2011-01-24 17:55 ` [PATCH v4 06/19] ARM: LPAE: Add (pte|pmd|pgd|pgprot)val_t type definitions as u32 Catalin Marinas
2011-02-03 17:13 ` Catalin Marinas
2011-01-24 17:55 ` [PATCH v4 07/19] ARM: LPAE: Use a mask for physical addresses in page table entries Catalin Marinas
2011-01-24 17:55 ` [PATCH v4 08/19] ARM: LPAE: Introduce the 3-level page table format definitions Catalin Marinas
2011-01-24 21:26 ` Nick Piggin
2011-01-24 21:42 ` Russell King - ARM Linux
2011-01-25 10:04 ` Catalin Marinas
2011-03-21 12:36 ` Catalin Marinas
2011-03-21 12:56 ` Russell King - ARM Linux
2011-03-21 13:19 ` Catalin Marinas
2011-02-03 17:11 ` Catalin Marinas
2011-01-24 17:55 ` [PATCH v4 09/19] ARM: LPAE: Page table maintenance for the 3-level format Catalin Marinas
2011-02-03 17:09 ` Catalin Marinas
2011-02-03 17:56 ` Russell King - ARM Linux
2011-02-03 22:00 ` Catalin Marinas
2011-01-24 17:55 ` [PATCH v4 10/19] ARM: LPAE: MMU setup for the 3-level page table format Catalin Marinas
2011-01-24 17:55 ` [PATCH v4 11/19] ARM: LPAE: Add fault handling support Catalin Marinas
2011-01-24 17:55 ` [PATCH v4 12/19] ARM: LPAE: Add context switching support Catalin Marinas
2011-02-12 10:44 ` Russell King - ARM Linux
2011-02-14 13:24 ` Catalin Marinas
2011-02-19 18:30 ` Russell King - ARM Linux
2011-02-19 23:16 ` Catalin Marinas
2011-01-24 17:55 ` [PATCH v4 13/19] ARM: LPAE: Add identity mapping support for the 3-level page table format Catalin Marinas
2011-01-24 17:55 ` [PATCH v4 14/19] ARM: LPAE: Add SMP " Catalin Marinas
2011-01-24 17:55 ` [PATCH v4 15/19] ARM: LPAE: use phys_addr_t instead of unsigned long for physical addresses Catalin Marinas
2011-02-12 10:28 ` Russell King - ARM Linux
2011-02-15 11:52 ` Will Deacon
2011-02-15 12:35 ` Russell King - ARM Linux
2011-02-15 12:39 ` Catalin Marinas
2011-02-15 13:37 ` Will Deacon
2011-02-15 14:23 ` Russell King - ARM Linux
2011-02-15 15:26 ` Will Deacon
2011-02-15 15:48 ` Russell King - ARM Linux
2011-02-19 18:26 ` Russell King - ARM Linux
2011-02-21 14:36 ` Will Deacon
2011-02-21 14:58 ` Russell King - ARM Linux
2011-02-21 15:01 ` Will Deacon
2011-01-24 17:55 ` [PATCH v4 16/19] ARM: LPAE: Use generic dma_addr_t type definition Catalin Marinas
2011-02-12 10:34 ` Russell King - ARM Linux
2011-02-14 13:01 ` Catalin Marinas
2011-02-15 14:27 ` Russell King - ARM Linux
2011-02-15 15:24 ` Catalin Marinas
2011-01-24 17:55 ` [PATCH v4 17/19] ARM: LPAE: mark memory banks with start > ULONG_MAX as highmem Catalin Marinas
2011-02-12 10:36 ` Russell King - ARM Linux
2011-01-24 17:56 ` [PATCH v4 18/19] ARM: LPAE: add support for ATAG_MEM64 Catalin Marinas
2011-01-24 17:56 ` [PATCH v4 19/19] ARM: LPAE: Add the Kconfig entries Catalin Marinas
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=201101251514.43808.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=sboyd@codeaurora.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