Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 02 6月, 2015 1 次提交
  3. 08 5月, 2015 1 次提交
  5. 18 4月, 2015 1 次提交
  7. 02 4月, 2015 1 次提交
    • F
      ARM: 8276/1: Make CPU_DCACHE_DISABLE depend on !SMP · e1e2f6e4
      由 Florian Fainelli 提交于 
      Enabling CPU_DCACHE_DISABLE on a SMP capable system will prevent the
kernel from booting because of the following ldrex instruction in
arch_spin_lock:

(gdb) x/10i $pc
=> 0xc053cfa8 <_raw_spin_lock+4>:       ldrex   r3, [r0]
   0xc053cfac <_raw_spin_lock+8>:       add     r2, r3, #65536  ; 0x10000

which is taken by the very first printk call:

    at /home/fainelli/work/linux/arch/arm/include/asm/spinlock.h:65
    fmt=0xc0637650 " 01 66Booting Linux on physical CPU 0x%xn", args=<incomplete type>)
    at kernel/printk/printk.c:1525
    fmt=0xc05370f4 <printk+52> " 24320215342 04340235344 20320215342 36377/341 17") at kernel/printk/printk.c:1688

ldrex requires exclusive monitor(s) (local or global) which are no longer
working when the Data cache is disabled in CP15 and will just hang the CPU
there.
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      e1e2f6e4
  9. 28 3月, 2015 1 次提交
  11. 18 2月, 2015 1 次提交
  13. 29 1月, 2015 1 次提交
  15. 14 11月, 2014 1 次提交
    • N
      ARM: 8198/1: make kuser helpers depend on MMU · 08b964ff
      由 Nathan Lynch 提交于 
      The kuser helpers page is not set up on non-MMU systems, so it does
not make sense to allow CONFIG_KUSER_HELPERS to be enabled when
CONFIG_MMU=n.  Allowing it to be set on !MMU results in an oops in
set_tls (used in execve and the arm_syscall trap handler):

Unhandled exception: IPSR = 00000005 LR = fffffff1
CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-rc1-00041-ga30465a #216
task: 8b838000 ti: 8b82a000 task.ti: 8b82a000
PC is at flush_thread+0x32/0x40
LR is at flush_thread+0x21/0x40
pc : [<8f00157a>]    lr : [<8f001569>]    psr: 4100000b
sp : 8b82be20  ip : 00000000  fp : 8b83c000
r10: 00000001  r9 : 88018c84  r8 : 8bb85000
r7 : 8b838000  r6 : 00000000  r5 : 8bb77400  r4 : 8b82a000
r3 : ffff0ff0  r2 : 8b82a000  r1 : 00000000  r0 : 88020354
xPSR: 4100000b
CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-rc1-00041-ga30465a #216
[<8f002bc1>] (unwind_backtrace) from [<8f002033>] (show_stack+0xb/0xc)
[<8f002033>] (show_stack) from [<8f00265b>] (__invalid_entry+0x4b/0x4c)

As best I can tell this issue existed for the set_tls ARM syscall
before commit fbfb872f "ARM: 8148/1: flush TLS and thumbee
register state during exec" consolidated the TLS manipulation code
into the set_tls helper function, but now that we're using it to flush
register state during execve, !MMU users encounter the oops at the
first exec.

Prevent CONFIG_MMU=n configurations from enabling
CONFIG_KUSER_HELPERS.

Fixes: fbfb872f (ARM: 8148/1: flush TLS and thumbee register state during exec)
Signed-off-by: NNathan Lynch <nathan_lynch@mentor.com>
Reported-by: NStefan Agner <stefan@agner.ch>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      08b964ff
  17. 12 11月, 2014 1 次提交
    • L
      ARM: fix multiplatform allmodcompile · dc680b98
      由 Linus Walleij 提交于 
      Commit 68f3b875
"ARM: integrator: make the Integrator multiplatform"
broke allmodconfig like this:

>> arch/arm/include/asm/cmpxchg.h:114:2: error: #error
"SMP is not supported on this platform"
(etc)

This is due to the fact that as we turned on multiplatform
for the Integrator, this enabled a lot of non-applicable
CPU's to be selected for its multiplatform images, due to
a lot of "depends on ARCH_INTEGRATOR" restrictions in
arch/arm/mm/Kconfig for the different ARM CPU types.

Fix this by restricting the CPU selections to respective
multiplatform config, which now becomes a subset of the
possible Integrator configurations, or alternatively the
non-multiplatform config plus ARCH_INTEGRATOR, i.e.:

if (!ARCH_MULTIPLATFORM || ARCH_MULTI_Vx) &&
   (ARCH_INTEGRATOR || ARCH_FOO ...)

Since the Integrator has been converted to multiplatform,
this will often take the short form:

if (ARCH_MULTI_Vx && ARCH_INTEGRATOR)

If no other non-multiplatform platforms are elegible.
Reported-by: NBuild bot for Mark Brown <broonie@kernel.org>
Reported-by: NKbuild test robot <fengguang.wu@intel.com>
Suggested-by: NRussell King <linux@arm.linux.org.uk>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      dc680b98
  19. 17 10月, 2014 2 次提交
  21. 18 7月, 2014 2 次提交
  23. 14 7月, 2014 1 次提交
  25. 19 6月, 2014 1 次提交
    • R
      ARM: l2c: fix dependencies on PL310 errata symbols · a641f3a6
      由 Russell King 提交于 
      A number of configurations spit out warnings similar to:

warning: (SOC_IMX6 && SOC_VF610 && ARCH_OMAP4) selects PL310_ERRATA_588369 which has unmet direct dependencies (CACHE_L2X0)
warning: (SOC_IMX6 && SOC_VF610 && ARCH_OMAP4) selects PL310_ERRATA_727915 which has unmet direct dependencies (CACHE_L2X0)

Clean up the dependencies here:
* PL310 symbols should only be selected when CACHE_L2X0 is enabled.
* Since the cache-l2x0 code detects PL310 presence at runtime, and we will
  eventually get rid of CACHE_PL310, surround these errata options with an
  if CACHE_L2X0 conditional rather than repeating the dependency against
  each.
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a641f3a6
  27. 30 5月, 2014 1 次提交
  29. 23 4月, 2014 1 次提交
  31. 22 3月, 2014 1 次提交
    • A
      ARM: rpc: autoselect CPU_SA110 · fa04e209
      由 Arnd Bergmann 提交于 
      ARCH_RPC no longer supports other CPUs aside from StrongARM110,
so we can make the option implicitly selected by the platform
and no longer give the option of building a kernel without CPU
support.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
      fa04e209
  33. 23 2月, 2014 1 次提交
  35. 10 2月, 2014 1 次提交
    • W
      ARM: 7954/1: mm: remove remaining domain support from ARMv6 · b6ccb980
      由 Will Deacon 提交于 
      CPU_32v6 currently selects CPU_USE_DOMAINS if CPU_V6 and MMU. This is
because ARM 1136 r0pX CPUs lack the v6k extensions, and therefore do
not have hardware thread registers. The lack of these registers requires
the kernel to update the vectors page at each context switch in order to
write a new TLS pointer. This write must be done via the userspace
mapping, since aliasing caches can lead to expensive flushing when using
kmap. Finally, this requires the vectors page to be mapped r/w for
kernel and r/o for user, which has implications for things like put_user
which must trigger CoW appropriately when targetting user pages.

The upshot of all this is that a v6/v7 kernel makes use of domains to
segregate kernel and user memory accesses. This has the nasty
side-effect of making device mappings executable, which has been
observed to cause subtle bugs on recent cores (e.g. Cortex-A15
performing a speculative instruction fetch from the GIC and acking an
interrupt in the process).

This patch solves this problem by removing the remaining domain support
from ARMv6. A new memory type is added specifically for the vectors page
which allows that page (and only that page) to be mapped as user r/o,
kernel r/w. All other user r/o pages are mapped also as kernel r/o.
Patch co-developed with Russell King.

Cc: <stable@vger.kernel.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      b6ccb980
  37. 20 10月, 2013 1 次提交
    • B
      ARM: fix ARCH_IXP4xx usage of ARCH_SUPPORTS_BIG_ENDIAN · d10d2d48
      由 Ben Dooks 提交于 
      The Kconfig for arch/arm/mach-ixp4xx has a local definition
of ARCH_SUPPORTS_BIG_ENDIAN which could be used elsewhere.
This means that if IXP4xx is selected and this symbol is
selected eleswhere then an warning is produced.

Clean the following error up by making the symbol be
selected by the main ARCH_IXP4XX definition and have a
common definition in arch/arm/mm/Kconfig

warning: (ARCH_xxx) selects ARCH_SUPPORTS_BIG_ENDIAN which has unmet direct dependencies (ARCH_IXP4XX)
warning: (ARCH_xxx) selects ARCH_SUPPORTS_BIG_ENDIAN which has unmet direct dependencies (ARCH_IXP4XX)
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
      d10d2d48
  39. 20 8月, 2013 1 次提交
  41. 01 8月, 2013 1 次提交
  43. 08 6月, 2013 1 次提交
    • J
      ARM: select CPU_CPU15_MMU/MPU appropriately · 66567618
      由 Jonathan Austin 提交于 
      Currently CPU_V7 selects CPU_CP15_MMU, however in the case of a V7 CPU
implementing the PMSA, such as the Cortex-R7, the CP15_MMU operations are
not available. Selecting CPU_CP15_MPU is appropriate in this case.

This patch makes CPU_CP15_MMU dependent on the use of the MMU, selecting
CPU_CP15_MPU for v7 processors when !MMU is chosen.
Signed-off-by: NJonathan Austin <jonathan.austin@arm.com>
      66567618
  45. 18 4月, 2013 1 次提交
  47. 26 3月, 2013 1 次提交
  49. 01 2月, 2013 1 次提交
  51. 11 1月, 2013 1 次提交
    • W
      ARM: virt: hide CONFIG_ARM_VIRT_EXT from user · 651134b0
      由 Will Deacon 提交于 
      ARM_VIRT_EXT is a property of CPU_V7, but does not adversely affect
other CPUs that can be built into the same kernel image (i.e. ARMv6+).

This patch defaults ARM_VIRT_EXT to y if CPU_V7, allowing hypervisors
such as KVM to make better use of the option and being able to rely
on hyp-mode boot support.
Signed-off-by: NWill Deacon <will.deacon@arm.com>
      651134b0
  53. 21 11月, 2012 1 次提交
  55. 14 10月, 2012 1 次提交
    • R
      ARM: config: sort select statements alphanumerically · b1b3f49c
      由 Russell King 提交于 
      As suggested by Andrew Morton:

  This is a pet peeve of mine.  Any time there's a long list of items
  (header file inclusions, kconfig entries, array initalisers, etc) and
  someone wants to add a new item, they *always* go and stick it at the
  end of the list.

  Guys, don't do this.  Either put the new item into a randomly-chosen
  position or, probably better, alphanumerically sort the list.

lets sort all our select statements alphanumerically.  This commit was
created by the following perl:

while (<>) {
	while (/\\\s*$/) {
		$_ .= <>;
	}
	undef %selects if /^\s*config\s+/;
	if (/^\s+select\s+(\w+).*/) {
		if (defined($selects{$1})) {
			if ($selects{$1} eq $_) {
				print STDERR "Warning: removing duplicated $1 entry\n";
			} else {
				print STDERR "Error: $1 differently selected\n".
					"\tOld: $selects{$1}\n".
					"\tNew: $_\n";
				exit 1;
			}
		}
		$selects{$1} = $_;
		next;
	}
	if (%selects and (/^\s*$/ or /^\s+help/ or /^\s+---help---/ or
			  /^endif/ or /^endchoice/)) {
		foreach $k (sort (keys %selects)) {
			print "$selects{$k}";
		}
		undef %selects;
	}
	print;
}
if (%selects) {
	foreach $k (sort (keys %selects)) {
		print "$selects{$k}";
	}
}

It found two duplicates:

Warning: removing duplicated S5P_SETUP_MIPIPHY entry
Warning: removing duplicated HARDIRQS_SW_RESEND entry

and they are identical duplicates, hence the shrinkage in the diffstat
of two lines.

We have four testers reporting success of this change (Tony, Stephen,
Linus and Sekhar.)
Acked-by: NJason Cooper <jason@lakedaemon.net>
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      b1b3f49c
  57. 19 9月, 2012 1 次提交
  59. 05 5月, 2012 1 次提交
  61. 13 4月, 2012 1 次提交
  63. 15 2月, 2012 1 次提交
  65. 23 1月, 2012 1 次提交
    • W
      ARM: 7291/1: cache: assume 64-byte L1 cachelines for ARMv7 CPUs · a092f2b1
      由 Will Deacon 提交于 
      To ensure correct alignment of cacheline-aligned data, the maximum
cacheline size needs to be known at compile time.

Since Cortex-A8 and Cortex-A15 have 64-byte cachelines (and it is likely
that there will be future ARMv7 implementations with the same line size)
then it makes sense to assume that CPU_V7 implies a 64-byte L1 cacheline
size. For CPUs with smaller caches, this will result in some harmless
padding but will help with single zImage work and avoid hitting subtle
bugs with misaligned data structures.
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a092f2b1
  67. 19 12月, 2011 1 次提交
  69. 08 12月, 2011 1 次提交
  71. 31 10月, 2011 3 次提交