All of lore.kernel.org
 help / color / mirror / Atom feed
From: slash.tmp@free.fr (Mason)
To: linux-arm-kernel@lists.infradead.org
Subject: read_cpuid_id() in arch/arm/kernel/setup.c
Date: Mon, 16 Mar 2015 23:17:23 +0100	[thread overview]
Message-ID: <55075673.5010600@free.fr> (raw)
In-Reply-To: <alpine.DEB.2.02.1503161641000.29420@utopia.booyaka.com>

Hello Paul,

On 16/03/2015 17:54, Paul Walmsley wrote:

> On Mon, 16 Mar 2015, Mason wrote:
> 
>> On 15/03/2015 18:40, Mason wrote:
>>
>>> On 13/03/2015 17:45, Russell King - ARM Linux wrote:
>>>
>>>> Yes, this one I like - and it probably fixes a potential latent bug
>>>> where the compiler was free to re-order that mrc outside of the if()
>>>> statement.
>>>>
>>>> Please wrap it up as a normal submission, thanks.
>>>
>>> Proposed patch at the end of this message.
>>>
>>> I'm now puzzling over why it's required to have "memory"
>>> in read_cpuid_ext's clobber list, and not in read_cpuid's?
> 
> Reviewed-by: Paul Walmsley <paul@pwsan.com>
> 
> Looks reasonable to me.  I'd suggest updating the patch message to 
> describe your change, and why it's needed.  Consider something like:
> 
> ---
> 
> Convert the open-coded MMFR0 register read in __get_cpu_architecture() to 
> use the read_cpuid_ext() macro.  This shortens the function and ensures 
> that a memory clobber is used on the coprocessor read instruction.  The 
> memory clobber works around a bug in gcc 4.5.  gcc 4.5 can reorder 
> coprocessor read instructions with respect to other code, disregarding 
> potential side-effects of the coprocessor read.

To be honest, the reason I wrote the patch in the first place
was merely to fix the code duplication! ;-)

I wasn't aware of the latent-bug issue until Russel mentioned
it. So I didn't want to put too much emphasis on that part,
since it didn't come from me, and it is well-documented in
your own commit, which I referenced.

Do you know why it was necessary to fix read_cpuid_ext and
not read_cpuid? I would think that the same problem affects
both macros.

> Once you've got something that you're happy with, and have reposted it to 
> the public lists, I believe the next step will be for you to post it to 
> rmk's patch tracker at:
> 
> http://www.arm.linux.org.uk/developer/patches/

Oh, I didn't know about that part. It's not mentioned in
https://www.kernel.org/doc/Documentation/SubmittingPatches

Thanks for the review, and for mentioning the tracker.

Ah yes, now I see this:
http://www.arm.linux.org.uk/mailinglists/faq.php#p1

Will post an (hopefully) improved commit message ASAP.

Regards.

  reply	other threads:[~2015-03-16 22:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-13 16:03 read_cpuid_id() in arch/arm/kernel/setup.c Mason
2015-03-13 16:19 ` Russell King - ARM Linux
2015-03-13 16:39   ` Mason
2015-03-13 16:45     ` Russell King - ARM Linux
2015-03-13 17:06       ` Mason
2015-03-15 17:40       ` Mason
2015-03-16  8:44         ` Mason
2015-03-16 16:54           ` Paul Walmsley
2015-03-16 22:17             ` Mason [this message]
2015-03-16 23:30               ` Mason
2015-03-13 16:56 ` Mark Rutland
2015-03-13 17:02   ` Russell King - ARM Linux
2015-03-13 18:26     ` Mark Rutland

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=55075673.5010600@free.fr \
    --to=slash.tmp@free.fr \
    --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.