public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: robherring2@gmail•com (Rob Herring)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
Date: Thu, 11 Oct 2012 08:31:47 -0500	[thread overview]
Message-ID: <5076CA43.9070503@gmail.com> (raw)
In-Reply-To: <20121011130955.GP4625@n2100.arm.linux.org.uk>

On 10/11/2012 08:09 AM, Russell King - ARM Linux wrote:
> On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
>> The contents of this were already reviewed on this thread, so I sent this
>> to the patch system and this was Russell's reply:
> 
> So that's why I couldn't find it - the mailing list thread has a different
> subject line to the patch.  Don't do that.  Given the amount of list
> traffic we have today, that's as good as not having been posted at all.
> 
>>> NAK for two reasons.
>>>
>>> 1. It hasn't been on the list (I can't find a match for "clear SCTLR.A"
>>> in my mailbox)
>>>
>>> 2. The behaviour of unaligned accesses vary depending on CPU.  Some
>>> fix-up the access, others load the word and then rotate it.  If we have
>>> decompressors which perform unaligned accesses, we need to fix this
>>> properly to avoid the CPU specific behaviour, rather than tweaking
>>> control bits to hide the problem.
>>
>> I'm simply matching the behavior of the kernel itself. The A bit is cleared
>> for v7 kernels and compilers only generate unaligned accesses for v7.
>> Without this the initial state of the A bit is undefined as a bootloader
>> could have cleared it already. We should document the required state or set
>> it to what we want.
> 
> Irrespective of this, (2) still stands.  Unaligned accesses in the
> decompressor without a fixup (which will be very hard to provide)
> will return different data depending on the CPU as I mention in point
> 2.

This only affects v7 cores. It should not vary for v7 cores as unaligned
access is a required feature. So how is it going to vary on v7 CPUs?
We've got bigger problems if there are v7 cores that don't handle
unaligned accesses.

Rob

> So, using unaligned accesses in the decompressor may not give expected
> results in all cases, so they're best avoided.
>
> And if they're avoided, then we don't care about the setting of the A
> bit.
> 

  reply	other threads:[~2012-10-11 13:31 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-05  1:23 [PATCH v2 0/5] Use more asm-generic headers Rob Herring
2012-08-05  1:23 ` [PATCH v2 1/5] ARM: use generic version of identical asm headers Rob Herring
2012-08-05  1:23 ` [PATCH v2 2/5] ARM: add strstr declaration for decompressors Rob Herring
2012-08-05  1:23 ` [PATCH v2 3/5] ARM: use generic unaligned.h Rob Herring
2012-10-08 16:43   ` Shawn Guo
2012-10-08 20:34     ` Rob Herring
2012-10-08 23:28       ` Shawn Guo
2012-10-09  2:27         ` Rob Herring
2012-10-09  2:45           ` Shawn Guo
2012-10-09  4:01           ` Nicolas Pitre
2012-10-10 13:29             ` Rob Herring
2012-10-10 13:57               ` Nicolas Pitre
2012-10-11 12:43                 ` [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores Rob Herring
2012-10-11 13:09                   ` Russell King - ARM Linux
2012-10-11 13:31                     ` Rob Herring [this message]
2012-10-11 13:41                       ` Russell King - ARM Linux
2012-10-11 15:44                         ` Nicolas Pitre
2012-10-23 20:32                           ` Gregory CLEMENT
2012-10-25 12:07                             ` Russell King - ARM Linux
2012-10-11 13:59                       ` Russell King - ARM Linux
2012-10-11 15:58                         ` Nicolas Pitre
2012-10-25  9:34                   ` Johannes Stezenbach
2012-10-25 12:41                     ` Rob Herring
2012-10-25 13:30                       ` Arnd Bergmann
2012-10-25 14:16                       ` Johannes Stezenbach
2012-10-25 14:25                         ` Rob Herring
2012-10-25 15:02                           ` Nicolas Pitre
2012-10-25 15:08                           ` Johannes Stezenbach
2012-11-05 10:48                             ` Dave Martin
2012-11-05 11:13                               ` Russell King - ARM Linux
2012-11-05 13:02                                 ` Dave Martin
2012-11-05 13:43                                   ` Johannes Stezenbach
2012-11-05 15:39                                   ` Russell King - ARM Linux
2012-11-05 16:13                                     ` Nicolas Pitre
2012-11-05 17:26                                       ` Dave Martin
2012-11-05 17:44                                         ` Rob Herring
2012-11-05 20:02                                           ` Nicolas Pitre
2012-11-05 17:46                                         ` Nicolas Pitre
2012-11-05 13:48                                 ` Rob Herring
2012-11-05 22:02                                   ` Michael Hope
2013-02-20 14:56                                     ` Johannes Stezenbach
2013-02-20 15:07                                       ` Johannes Stezenbach
2012-08-05  1:23 ` [PATCH v2 4/5] ARM: use generic termios.h Rob Herring
2012-08-05  1:24 ` [PATCH v2 5/5] ARM: convert asm/irqflags.h to use asm-generic/irqflags.h Rob Herring
2012-08-05  9:34 ` [PATCH v2 0/5] Use more asm-generic headers Thomas Petazzoni
2012-08-06 14:35 ` 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=5076CA43.9070503@gmail.com \
    --to=robherring2@gmail$(echo .)com \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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