Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 15 7月, 2013 1 次提交
    • P
      arm: delete __cpuinit/__CPUINIT usage from all ARM users · 8bd26e3a
      由 Paul Gortmaker 提交于 
      The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications.  For example, the fix in
commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.

After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out.  Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.

Note that some harmless section mismatch warnings may result, since
notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
and are flagged as __cpuinit  -- so if we remove the __cpuinit from
the arch specific callers, we will also get section mismatch warnings.
As an intermediate step, we intend to turn the linux/init.h cpuinit
related content into no-ops as early as possible, since that will get
rid of these warnings.  In any case, they are temporary and harmless.

This removes all the ARM uses of the __cpuinit macros from C code,
and all __CPUINIT from assembly code.  It also had two ".previous"
section statements that were paired off against __CPUINIT
(aka .section ".cpuinit.text") that also get removed here.

[1] https://lkml.org/lkml/2013/5/20/589

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      8bd26e3a
  3. 19 6月, 2013 3 次提交
  5. 09 4月, 2013 1 次提交
  7. 27 3月, 2013 1 次提交
  9. 13 1月, 2013 1 次提交
    • R
      irqchip: Move ARM gic.h to include/linux/irqchip/arm-gic.h · 520f7bd7
      由 Rob Herring 提交于 
      Now that we have GIC moved to drivers/irqchip and all GIC DT init for
platforms using irqchip_init, move gic.h and update the remaining
includes.
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Anton Vorontsov <avorontsov@mvista.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: David Brown <davidb@codeaurora.org>
Cc: Daniel Walker <dwalker@fifo99.com>
Cc: Bryan Huntsman <bryanh@codeaurora.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Viresh Kumar <viresh.linux@gmail.com>
Cc: Shiraz Hashim <shiraz.hashim@st.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Samuel Ortiz <sameo@linux.intel.com>
      520f7bd7
  11. 11 1月, 2013 1 次提交
  13. 19 12月, 2012 1 次提交
  15. 28 11月, 2012 1 次提交
  17. 14 9月, 2012 2 次提交
  19. 11 8月, 2012 1 次提交
  21. 14 3月, 2012 1 次提交
  23. 23 1月, 2012 1 次提交
  25. 16 1月, 2012 1 次提交
  27. 16 11月, 2011 1 次提交
    • M
      ARM: gic: allow GIC to support non-banked setups · db0d4db2
      由 Marc Zyngier 提交于 
      The GIC support code is heavily using the fact that hardware
implementations are exposing banked registers. Unfortunately, it
looks like at least one GIC implementation (EXYNOS) offers both
the distributor and the CPU interfaces at different addresses,
depending on the CPU.

This problem is solved by allowing the distributor and CPU interface
addresses to be per-cpu variables for the platforms that require it.
The EXYNOS code is updated not to mess with the GIC internals while
handling interrupts, and struct gic_chip_data is back to being private.
The DT binding for the gic is updated to allow an optional "cpu-offset"
value, which is used to compute the various base addresses.

Finally, a new config option (GIC_NON_BANKED) is used to control this
feature, so the overhead is only present on kernels compiled with
support for EXYNOS.

Tested on Origen (EXYNOS4) and Panda (OMAP4).

Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Thomas Abraham <thomas.abraham@linaro.org>
Acked-by: NRob Herring <rob.herring@calxeda.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      db0d4db2
  29. 06 11月, 2011 2 次提交
  31. 21 10月, 2011 1 次提交
  33. 17 10月, 2011 1 次提交
  35. 04 10月, 2011 1 次提交
  37. 15 9月, 2011 1 次提交
  39. 24 8月, 2011 1 次提交
  41. 20 7月, 2011 2 次提交
  43. 07 7月, 2011 1 次提交
    • S
      ARM: 6993/1: platsmp: Allow secondary cpu hotplug with maxcpus=1 · 7fa22bd5
      由 Stephen Boyd 提交于 
      If an ARM system has multiple cpus in the same socket and the
kernel is booted with maxcpus=1, secondary cpus are possible but
not present due to how platform_smp_prepare_cpus() is called.
Since most typical ARM processors don't actually support physical
hotplug, initialize the present map to be equal to the possible
map in generic ARM SMP code. Also, always call
platform_smp_prepare_cpus() as long as max_cpus is non-zero (0
means no SMP) to allow platform code to do any SMP setup.

After applying this patch it's possible to boot an ARM system
with maxcpus=1 on the command line and then hotplug in secondary
cpus via sysfs. This is more in line with how x86 does things.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: David Brown <davidb@codeaurora.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Cc: Linus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7fa22bd5
  45. 23 5月, 2011 1 次提交
  47. 22 2月, 2011 1 次提交
  49. 20 12月, 2010 4 次提交
    • R
      ARM: Fix subtle race in CPU pen_release hotplug code · 3705ff6d
      由 Russell King 提交于 
      There is a subtle race in the CPU hotplug code, where a CPU which has
been offlined can online itself before being requested, which results
in things going astray on the next online/offline cycle.

What happens in the normal online/offline/online cycle is:

	CPU0			CPU3
	requests boot of CPU3
	pen_release = 3
	flush cache line
				checks pen_release, reads 3
				starts boot
				pen_release = -1
	... requests CPU3 offline ...
				... dies ...
				checks pen_release, reads -1
	requests boot of CPU3
	pen_release = 3
	flush cache line
				checks pen_release, reads 3
				starts boot
				pen_release = -1

However, as the write of -1 of pen_release is not fully flushed back to
memory, and the checking of pen_release is done with caches disabled,
this allows CPU3 the opportunity to read the old value of pen_release:

	CPU0			CPU3
	requests boot of CPU3
	pen_release = 3
	flush cache line
				checks pen_release, reads 3
				starts boot
				pen_release = -1
	... requests CPU3 offline ...
				... dies ...
				checks pen_release, reads 3
				starts boot
				pen_release = -1
	requests boot of CPU3
	pen_release = 3
	flush cache line

Fix this by grouping the write of pen_release along with its cache line
flushing code to ensure that any update to pen_release is always pushed
out to physical memory.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      3705ff6d
    • R
      ARM: SMP: consolidate trace_hardirqs_off() into common SMP code · 2c0136db
      由 Russell King 提交于 
      All platforms call trace_hardirqs_off() in their secondary startup code,
so move this into the core SMP code - it doesn't need to be in the
per-platform code.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2c0136db
    • R
      ARM: SMP: consolidate the common parts of smp_prepare_cpus() · 05c74a6c
      由 Russell King 提交于 
      There is a certain amount of smp_prepare_cpus() which doesn't belong
in the platform support code - that is, code which is invariant to the
SMP implementation.  Move this code into arch/arm/kernel/smp.c, and
add a platform_ prefix to the original function.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      05c74a6c
    • R
      ARM: SMP: Clean up ncores sanity checks · 8975b6c0
      由 Russell King 提交于 
      scu_get_core_count() never returns zero cores, so we don't need to
check and correct if ncores is zero.

Tegra was missing the check against NR_CPUS, leading to a potential
bitfield overflow if this becomes the case.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      8975b6c0
  51. 15 12月, 2010 1 次提交
  53. 03 12月, 2010 1 次提交
  55. 27 8月, 2010 1 次提交
  57. 05 8月, 2010 1 次提交
  59. 02 5月, 2010 1 次提交
  61. 05 11月, 2009 1 次提交
  63. 24 7月, 2009 1 次提交