From: Colin Ian King <colin.king@canonical.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Lukas Wunner <lukas@wunner.de>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/platform/intel-mid: make several arrays static, makes code smaller
Date: Fri, 25 Aug 2017 18:13:49 +0000 [thread overview]
Message-ID: <aaef84f8-e047-8d35-6702-3cc3c7a1f039@canonical.com> (raw)
In-Reply-To: <1503683627.25945.114.camel@linux.intel.com>
On 25/08/17 18:53, Andy Shevchenko wrote:
> On Fri, 2017-08-25 at 19:51 +0200, Lukas Wunner wrote:
>> On Fri, Aug 25, 2017 at 05:32:06PM +0100, Colin King wrote:
>>> --- a/arch/x86/platform/intel-mid/pwr.c
>>> +++ b/arch/x86/platform/intel-mid/pwr.c
>>> @@ -444,7 +444,7 @@ static int mid_set_initial_state(struct mid_pwr
>>> *pwr, const u32 *states)
>>> static int pnw_set_initial_state(struct mid_pwr *pwr)
>>> {
>>> /* On Penwell SRAM must stay powered on */
>>> - const u32 states[] = {
>>> + static const u32 states[] = {
>>> 0xf00fffff, /* PM_SSC(0) */
>>> 0xffffffff, /* PM_SSC(1) */
>>> 0xffffffff, /* PM_SSC(2) */
>>
>> That's a known gcc bug:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?idh725
>>
>> There are hundreds of constant compound literals that are generated
>> on the stack rather than stored in rodata, do you intend to file
>> patches for all of them? Adding static everywhere is just a
>> workaround that bloats the code. Fixing the root cause in gcc would
>> make more sense.
Hrm. constifying will specify it won't be changed; section A8.2 of "The
C programming language" 2nd edition states that this specifier "is to
announce that objects may be placed in read-only memory, and perhaps
increase opportunities for optimization". Emphasis on "may", it can do,
but it does not necessarily have to. The static storage class specifier
will ensure the object is not on the stack for sure. So I think from my
understanding of the semantics described in K&R 2nd edition:
const - data is read only, and can be put into read-only location if
compiler can (or wants) to do so
static - data will be not stashed on the stack.
So my change is to be totally clear on the intent - make it read only
and ensure it is not populated at run time on the stack.
Colin
>
> That is a good point.
>
prev parent reply other threads:[~2017-08-25 18:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-25 16:32 [PATCH] x86/platform/intel-mid: make several arrays static, makes code smaller Colin King
2017-08-25 16:53 ` Andy Shevchenko
2017-08-25 17:51 ` Lukas Wunner
2017-08-25 17:53 ` Andy Shevchenko
2017-08-25 18:13 ` Colin Ian King [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=aaef84f8-e047-8d35-6702-3cc3c7a1f039@canonical.com \
--to=colin.king@canonical.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=hpa@zytor.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@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