From: u.kleine-koenig@pengutronix.de (Uwe Kleine-König)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: ks8695: fix __initdata annotation
Date: Tue, 9 Feb 2016 12:36:24 +0100 [thread overview]
Message-ID: <20160209113624.GU13664@pengutronix.de> (raw)
In-Reply-To: <18237653.x9qPaNvtCU@wuerfel>
Hello Arnd,
On Tue, Feb 09, 2016 at 12:14:15PM +0100, Arnd Bergmann wrote:
> On Tuesday 09 February 2016 10:00:30 Uwe Kleine-K?nig wrote:
> > > diff --git a/arch/arm/mach-ks8695/board-og.c b/arch/arm/mach-ks8695/board-og.c
> > > index 1f4f2f4f25bb..fa1a7c2ca2bb 100644
> > > --- a/arch/arm/mach-ks8695/board-og.c
> > > +++ b/arch/arm/mach-ks8695/board-og.c
> > > @@ -80,7 +80,7 @@ static void __init og_pci_bus_reset(void)
> > > #define S8250_VIRT 0xf4000000
> > > #define S8250_SIZE 0x00100000
> > >
> > > -static struct __initdata map_desc og_io_desc[] = {
> > > +static struct map_desc __initdata og_io_desc[] = {
> >
> > I would have expected that
> >
> > +static struct map_desc og_io_desc[] __initdata = {
> >
> > is the correct variant?
> >
>
> I think those two mean the exact same thing, and we have tons of examples
> for either one in the kernel, unlike the one I removed. I have
> verified that the resulting object files are identical.
>
> Can you point me to some documentation that clarifies which one to use,
> and why?
Having the attribute list after the declarator isn't recommended as
explicit as I remember having read it somewhere in the gcc docs.
info gcc "Attribute Syntax"
has:
An attribute specifier list may appear immediately before a declarator
(other than the first) in a comma-separated list of declarators in a
declaration of more than one identifier using a single list of
specifiers and qualifiers. Such attribute specifiers apply only to the
identifier before whose declarator they appear. For example, in
__attribute__((noreturn)) void d0 (void),
__attribute__((format(printf, 1, 2))) d1 (const char *, ...),
d2 (void)
the 'noreturn' attribute applies to all the functions declared; the
'format' attribute only applies to 'd1'.
(Funny enough, in the example the attribute specifier list doesn't
appear *immediately* before the declarator d0.)
This might be interpreted as "usually the attribute specifier list appears
after the declarator". Other than that I cannot find an explict
recommended placement in the docs. The examples in
info gcc "Variable Attributes"
always have the attribute list after the declarator.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
WARNING: multiple messages have this Message-ID (diff)
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Ungerer <gerg@uclinux.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARM: ks8695: fix __initdata annotation
Date: Tue, 9 Feb 2016 12:36:24 +0100 [thread overview]
Message-ID: <20160209113624.GU13664@pengutronix.de> (raw)
In-Reply-To: <18237653.x9qPaNvtCU@wuerfel>
Hello Arnd,
On Tue, Feb 09, 2016 at 12:14:15PM +0100, Arnd Bergmann wrote:
> On Tuesday 09 February 2016 10:00:30 Uwe Kleine-König wrote:
> > > diff --git a/arch/arm/mach-ks8695/board-og.c b/arch/arm/mach-ks8695/board-og.c
> > > index 1f4f2f4f25bb..fa1a7c2ca2bb 100644
> > > --- a/arch/arm/mach-ks8695/board-og.c
> > > +++ b/arch/arm/mach-ks8695/board-og.c
> > > @@ -80,7 +80,7 @@ static void __init og_pci_bus_reset(void)
> > > #define S8250_VIRT 0xf4000000
> > > #define S8250_SIZE 0x00100000
> > >
> > > -static struct __initdata map_desc og_io_desc[] = {
> > > +static struct map_desc __initdata og_io_desc[] = {
> >
> > I would have expected that
> >
> > +static struct map_desc og_io_desc[] __initdata = {
> >
> > is the correct variant?
> >
>
> I think those two mean the exact same thing, and we have tons of examples
> for either one in the kernel, unlike the one I removed. I have
> verified that the resulting object files are identical.
>
> Can you point me to some documentation that clarifies which one to use,
> and why?
Having the attribute list after the declarator isn't recommended as
explicit as I remember having read it somewhere in the gcc docs.
info gcc "Attribute Syntax"
has:
An attribute specifier list may appear immediately before a declarator
(other than the first) in a comma-separated list of declarators in a
declaration of more than one identifier using a single list of
specifiers and qualifiers. Such attribute specifiers apply only to the
identifier before whose declarator they appear. For example, in
__attribute__((noreturn)) void d0 (void),
__attribute__((format(printf, 1, 2))) d1 (const char *, ...),
d2 (void)
the 'noreturn' attribute applies to all the functions declared; the
'format' attribute only applies to 'd1'.
(Funny enough, in the example the attribute specifier list doesn't
appear *immediately* before the declarator d0.)
This might be interpreted as "usually the attribute specifier list appears
after the declarator". Other than that I cannot find an explict
recommended placement in the docs. The examples in
info gcc "Variable Attributes"
always have the attribute list after the declarator.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
next prev parent reply other threads:[~2016-02-09 11:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-08 14:24 [PATCH] ARM: ks8695: fix __initdata annotation Arnd Bergmann
2016-02-08 14:24 ` Arnd Bergmann
2016-02-08 23:36 ` Greg Ungerer
2016-02-08 23:36 ` Greg Ungerer
2016-02-26 16:25 ` Arnd Bergmann
2016-02-26 16:25 ` Arnd Bergmann
2016-02-09 9:00 ` Uwe Kleine-König
2016-02-09 9:00 ` Uwe Kleine-König
2016-02-09 11:14 ` Arnd Bergmann
2016-02-09 11:14 ` Arnd Bergmann
2016-02-09 11:36 ` Uwe Kleine-König [this message]
2016-02-09 11:36 ` Uwe Kleine-König
2016-02-09 15:10 ` Arnd Bergmann
2016-02-09 15:10 ` Arnd Bergmann
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=20160209113624.GU13664@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.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 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.