1. 09 9月, 2013 1 次提交
    • H
      s390/irq: reduce size of external interrupt handler hash array · 9e75c627
      Heiko Carstens 提交于
      Change the hash algorithm a bit so it produces only values in the
      range of 0..31.
      This allows to reduce the size of the external interrupt handler hash
      array even further while making sure that each of the known interrupt
      sources keeps its unique hash with the slightly modified algorithm:
      
      0x1004 --> 12
      0x1201 --> 10
      0x1202 --> 11
      0x1406 --> 16
      0x1407 --> 17
      0x2401 --> 19
      0x2603 --> 22
      0x4000 --> 0
      
      This also means that the entire array now fits into exactly one cache
      line; so add a proper align statement as well.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      9e75c627
  2. 07 9月, 2013 4 次提交
  3. 04 9月, 2013 4 次提交
  4. 30 8月, 2013 2 次提交
  5. 28 8月, 2013 2 次提交
  6. 22 8月, 2013 5 次提交
  7. 14 8月, 2013 1 次提交
    • F
      vtime: Describe overriden functions in dedicated arch headers · a5725ac2
      Frederic Weisbecker 提交于
      If the arch overrides some generic vtime APIs, let it describe
      these on a dedicated and standalone header. This way it becomes
      convenient to include it in vtime generic headers without irrelevant
      stuff in such a low level header.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Li Zhong <zhong@linux.vnet.ibm.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Kevin Hilman <khilman@linaro.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      a5725ac2
  8. 26 7月, 2013 2 次提交
  9. 18 7月, 2013 1 次提交
  10. 16 7月, 2013 1 次提交
  11. 15 7月, 2013 1 次提交
    • P
      s390: delete __cpuinit usage from all s390 files · e2741f17
      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)
      are flagged as __cpuinit  -- so if we remove the __cpuinit from
      arch specific callers, we will also get section mismatch warnings.
      As an intermediate step, we intend to turn the linux/init.h cpuinit
      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 arch/s390 uses of the __cpuinit macros from
      all C files.  Currently s390 does not have any __CPUINIT used in
      assembly files.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: linux390@de.ibm.com
      Cc: linux-s390@vger.kernel.org
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      e2741f17
  12. 04 7月, 2013 1 次提交
    • Z
      s390: remove setting for saved_max_pfn · 8bdc237a
      Zhang Yanfei 提交于
      The only user of saved_max_pfn in s390 is read_oldmem interface but we
      have removed that interface, so saved_max_pfn is now unneeded in s390, and
      we needn't set it anymore.
      Signed-off-by: NZhang Yanfei <zhangyanfei@cn.fujitsu.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Matt Fleming <matt.fleming@intel.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8bdc237a
  13. 27 6月, 2013 2 次提交
  14. 24 6月, 2013 1 次提交
  15. 19 6月, 2013 1 次提交
  16. 17 6月, 2013 1 次提交
  17. 10 6月, 2013 1 次提交
  18. 05 6月, 2013 2 次提交
  19. 27 5月, 2013 1 次提交
    • H
      s390/smp: lost IPIs on cpu hotplug · 9acf73b7
      Heiko Carstens 提交于
      IPIs might be lost when a cpu gets brought offline:
      
      When stop_machine executes its state machine there is a race window
      for the state STOPMACHINE_DISABLE_IRQ where the to be brought offline
      cpu might already have irqs disabled but a different cpu still may
      have irqs enabled.
      If the enabled cpu receives an interrupt and as a result sends an IPI
      to the to be offlined cpu in its bottom halve context, the IPI won't
      be noticed before the cpu is offline.
      
      In fact the race window is much larger since there is no guarantee
      when an IPI will be received.
      
      To fix this check for enqueued but not yet received IPIs in the
      cpu_disable() path and call the respective handlers before the cpu
      is marked offline.
      Reported-by: NJuergen Doelle <juergen.doelle@de.ibm.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      9acf73b7
  20. 21 5月, 2013 3 次提交
  21. 17 5月, 2013 1 次提交
    • M
      s390/smp: fix cpu re-scan vs. cpu state · a4eeea4e
      Martin Schwidefsky 提交于
      The cpu-info array starts with a list of cpus in configured state,
      followed by the cpus in standby state. The comparison to decide which
      state a cpu has is incorrect, this causes configured cpus appear as
      standby cpus. The correct comparison is the index of the new cpu in
      the cpu-info array vs. the number of configured cpus.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      a4eeea4e
  22. 15 5月, 2013 1 次提交
    • H
      s390/ftrace: fix mcount adjustment · aca91209
      Heiko Carstens 提交于
      Tony Jones reported that the ftrace self tests on s390 do not work:
      
      <6>Testing dynamic ftrace ops #1: (0 0 0 0 0) FAILED!
      <6>Testing tracer irqsoff:
      <3>failed to start irqsoff tracer
      <4>.. no entries found ..FAILED!
      <6>Testing tracer wakeup:
      <3>failed to start wakeup tracer
      <4>.. no entries found ..FAILED!
      <6>Testing tracer function_graph:
      <4>Failed to init function_graph tracer, init returned -19
      <4>FAILED!
      
      This happens because we forgot to adjust the instruction pointer that gets
      passed to the ftrace trace function by MCOUNT_INSN_SIZE.
      
      In addition change MCOUNT_INSN_SIZE to the correct value on 31 bit.
      It only worked so far because the to be patched instruction was identical.
      Reported-by: NTony Jones <tonyj@suse.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      aca91209
  23. 10 5月, 2013 1 次提交