All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dirk Behme <dirk.behme@googlemail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.
Date: Wed, 29 Dec 2010 10:40:56 +0100	[thread overview]
Message-ID: <4D1B0228.7000608@googlemail.com> (raw)
In-Reply-To: <20101222080206.A0CA3EA652A@gemini.denx.de>

On 22.12.2010 09:02, Wolfgang Denk wrote:
> Dear Alexander Holler,
>
> In message<1292711230-3234-1-git-send-email-holler@ahsoftware.de>  you wrote:
>> gcc 4.5.1 seems to ignore (at least some) volatile definitions,
>> avoid that as done in the kernel.
> ...
>> +#define writeb(v,c)			({ __iowmb(); __arch_putb(v,c); })
>> +#define writew(v,c)			({ __iowmb(); __arch_putw(v,c); })
>> +#define writel(v,c)			({ __iowmb(); __arch_putl(v,c); })
>
> http://www.codesourcery.com/archives/arm-gnu/msg03990.html  explains
> why this construct is causing errors in cases where an additional read
> from the address is unsupported.

Just for the record:

The trick is to ensure that the __arch_putx() containing the volatile 
is not the last statement in the GCC statement-expression. So, using 
something like

#define writeb(v,c)         ({ __iowmb(); __arch_putb(v,c); v;})

(note the additional 'v;') should result in correct code, too.

The patches sent by Wolfgang and Alexander using

#define writeb(v,c)	do { __iowmb(); __arch_putb(v,c); } while (0)

do the same with a slightly different syntax, so these patches are 
fine, too.

Thanks

Dirk

> Can you please try the following patch instead?
>
> -------------------------------------------------------------------------
>
>> From 4672bbddaf8ce7e17a99ba737782cc527d46e5eb Mon Sep 17 00:00:00 2001
> From: Alexander Holler<holler@ahsoftware.de>
> Date: Sat, 18 Dec 2010 23:27:10 +0100
> Subject: [PATCH] ARM: Avoid compiler optimization for readb, writeb and friends.
>
> gcc 4.5.1 seems to ignore (at least some) volatile definitions,
> avoid that as done in the kernel.
>
> Reading C99 6.7.3 8 and the comment 114) there, I think it is a bug of that
> gcc version to ignore the volatile type qualifier used e.g. in __arch_getl().
> Anyway, using a definition as in the kernel headers avoids such optimizations when
> gcc 4.5.1 is used.
>
> Maybe the headers as used in the current linux-kernel should be used,
> but to avoid large changes, I've just added a small change to the current headers.
>
> Signed-off-by: Alexander Holler<holler@ahsoftware.de>
> Signed-off-by: Wolfgang Denk<wd@denx.de>
> ---
>   arch/arm/include/asm/io.h |   32 ++++++++++++++++++++------------
>   1 files changed, 20 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
> index ff1518e..647503a 100644
> --- a/arch/arm/include/asm/io.h
> +++ b/arch/arm/include/asm/io.h
> @@ -117,21 +117,29 @@ extern inline void __raw_readsl(unsigned int addr, void *data, int longlen)
>   		*buf++ = __arch_getl(addr);
>   }
>
> -#define __raw_writeb(v,a)		__arch_putb(v,a)
> -#define __raw_writew(v,a)		__arch_putw(v,a)
> -#define __raw_writel(v,a)		__arch_putl(v,a)
> +#define __raw_writeb(v,a)	__arch_putb(v,a)
> +#define __raw_writew(v,a)	__arch_putw(v,a)
> +#define __raw_writel(v,a)	__arch_putl(v,a)
>
> -#define __raw_readb(a)			__arch_getb(a)
> -#define __raw_readw(a)			__arch_getw(a)
> -#define __raw_readl(a)			__arch_getl(a)
> +#define __raw_readb(a)		__arch_getb(a)
> +#define __raw_readw(a)		__arch_getw(a)
> +#define __raw_readl(a)		__arch_getl(a)
>
> -#define writeb(v,a)			__arch_putb(v,a)
> -#define writew(v,a)			__arch_putw(v,a)
> -#define writel(v,a)			__arch_putl(v,a)
> +/*
> + * TODO: The kernel offers some more advanced versions of barriers, it might
> + * have some advantages to use them instead of the simple one here.
> + */
> +#define dmb()		__asm__ __volatile__ ("" : : : "memory")
> +#define __iormb()	dmb()
> +#define __iowmb()	dmb()
> +
> +#define writeb(v,c)	do { __iowmb(); __arch_putb(v,c); } while (0)
> +#define writew(v,c)	do { __iowmb(); __arch_putw(v,c); } while (0)
> +#define writel(v,c)	do { __iowmb(); __arch_putl(v,c); } while (0)
>
> -#define readb(a)			__arch_getb(a)
> -#define readw(a)			__arch_getw(a)
> -#define readl(a)			__arch_getl(a)
> +#define readb(c)	({ u8  __v = __arch_getb(c); __iormb(); __v; })
> +#define readw(c)	({ u16 __v = __arch_getw(c); __iormb(); __v; })
> +#define readl(c)	({ u32 __v = __arch_getl(c); __iormb(); __v; })
>
>   /*
>    * The compiler seems to be incapable of optimising constants

  parent reply	other threads:[~2010-12-29  9:40 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-18 22:27 [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends Alexander Holler
2010-12-19  7:51 ` Dirk Behme
2010-12-19 10:22   ` Alexander Holler
2010-12-19 11:28     ` Albert ARIBAUD
2010-12-19 16:34       ` Alexander Holler
2010-12-19 18:45     ` John Rigby
2010-12-19 19:59       ` Alexander Holler
2010-12-20  0:39         ` John Rigby
2010-12-20  0:56           ` Alexander Holler
2010-12-20  4:18             ` John Rigby
2010-12-20  6:07               ` John Rigby
2010-12-20  6:49                 ` Dirk Behme
2010-12-20  7:37                   ` John Rigby
2010-12-20 16:08                     ` John Rigby
2010-12-20 16:12                       ` John Rigby
2011-01-17  4:35                       ` Alexander Holler
2010-12-20 17:12                 ` Alexander Holler
2010-12-21  0:25                   ` John Rigby
2010-12-21  0:46                     ` John Rigby
2010-12-21  7:11                       ` Dirk Behme
2010-12-21  7:21                         ` Albert ARIBAUD
2010-12-21  8:05                           ` Dirk Behme
2010-12-21  8:17                             ` Wolfgang Denk
2010-12-21  8:37                               ` Dirk Behme
2010-12-21  8:35                           ` Dirk Behme
2010-12-21  8:46                             ` John Rigby
2010-12-21 10:38                               ` Albert ARIBAUD
2010-12-21 10:53                                 ` Wolfgang Denk
2010-12-21 12:35                                   ` Alexander Holler
2010-12-21 12:51                                     ` Albert ARIBAUD
2010-12-21 13:30                                       ` Alexander Holler
2010-12-21 14:33                                         ` Albert ARIBAUD
2010-12-21 19:52                                           ` Wolfgang Denk
2010-12-21 20:04                                             ` Dirk Behme
2010-12-21 21:49                                               ` Albert ARIBAUD
2010-12-22  0:11                                               ` Alexander Holler
2010-12-22  7:02                                                 ` Albert ARIBAUD
2010-12-22  7:18                                                   ` Dirk Behme
2010-12-22  7:52                                                     ` Wolfgang Denk
2010-12-23 16:40                                                       ` Dirk Behme
2010-12-22  9:56                                                   ` Alexander Holler
2010-12-21 13:38                     ` Alexander Holler
2010-12-22  8:02 ` Wolfgang Denk
2010-12-22 11:23   ` Alexander Holler
2010-12-29  9:40   ` Dirk Behme [this message]
2010-12-29 23:10     ` Alessandro Rubini
2010-12-30 10:39       ` Dirk Behme
2011-01-09 22:03       ` Wolfgang Denk

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=4D1B0228.7000608@googlemail.com \
    --to=dirk.behme@googlemail.com \
    --cc=u-boot@lists.denx.de \
    /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.