1. 18 3月, 2011 21 次提交
  2. 17 3月, 2011 10 次提交
  3. 16 3月, 2011 3 次提交
  4. 15 3月, 2011 6 次提交
    • M
      x86: stop_machine_text_poke() should issue sync_core() · 0e00f7ae
      Mathieu Desnoyers 提交于
      Intel Archiecture Software Developer's Manual section 7.1.3 specifies that a
      core serializing instruction such as "cpuid" should be executed on _each_ core
      before the new instruction is made visible.
      
      Failure to do so can lead to unspecified behavior (Intel XMC erratas include
      General Protection Fault in the list), so we should avoid this at all cost.
      
      This problem can affect modified code executed by interrupt handlers after
      interrupt are re-enabled at the end of stop_machine, because no core serializing
      instruction is executed between the code modification and the moment interrupts
      are reenabled.
      
      Because stop_machine_text_poke performs the text modification from the first CPU
      decrementing stop_machine_first, modified code executed in thread context is
      also affected by this problem. To explain why, we have to split the CPUs in two
      categories: the CPU that initiates the text modification (calls text_poke_smp)
      and all the others. The scheduler, executed on all other CPUs after
      stop_machine, issues an "iret" core serializing instruction, and therefore
      handles core serialization for all these CPUs. However, the text modification
      initiator can continue its execution on the same thread and access the modified
      text without any scheduler call. Given that the CPU that initiates the code
      modification is not guaranteed to be the one actually performing the code
      modification, it falls into the XMC errata.
      
      Q: Isn't this executed from an IPI handler, which will return with IRET (a
         serializing instruction) anyway?
      A: No, now stop_machine uses per-cpu workqueue, so that handler will be
         executed from worker threads. There is no iret anymore.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      LKML-Reference: <20110303160137.GB1590@Krystal>
      Reviewed-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: <stable@kernel.org>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      0e00f7ae
    • G
      m68knommu: external interrupt support to ColdFire intc-simr controller · 47e0c7e1
      Greg Ungerer 提交于
      The EDGE Port module of some ColdFire parts using the intc-simr interrupt
      controller provides support for 7 external interrupts. These interrupts
      go off-chip (that is they are not for internal peripherals). They need
      some special handling and have some extra setup registers. Add code to
      support them.
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      47e0c7e1
    • G
      m68knommu: external interrupt support to ColdFire intc-2 controller · 57b48143
      Greg Ungerer 提交于
      The EDGE Port module of some ColdFire parts using the intc-2 interrupt
      controller provides support for 7 external interrupts. These interrupts
      go off-chip (that is they are not for internal peripherals). They need
      some special handling and have some extra setup registers. Add code to
      support them.
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      57b48143
    • G
      m68knommu: remove ColdFire CLOCK_DIV config option · ce3de78a
      Greg Ungerer 提交于
      The reality is that you do not need the abiltity to configure the
      clock divider for ColdFire CPUs. It is a fixed ratio on any given
      ColdFire family member. It is not the same for all ColdFire parts,
      but it is always the same in a model range. So hard define the divider
      for each supported ColdFire CPU type and remove the Kconfig option.
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      ce3de78a
    • G
      m68knommu: fix gpio warnings for ColdFire 5407 targets · 442ca465
      Greg Ungerer 提交于
      Fix these compiler warnings:
      
      arch/m68knommu/platform/5407/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
      arch/m68knommu/platform/5407/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
      arch/m68knommu/platform/5407/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      442ca465
    • G
      m68knommu: fix gpio warnings for ColdFire 532x targets · 5d44b096
      Greg Ungerer 提交于
      Fix these compiler warnings:
      
      arch/m68knommu/platform/532x/gpio.c:35:3: warning: initialisation makes pointer from integer without a cast
      arch/m68knommu/platform/532x/gpio.c:36:3: warning: initialisation makes pointer from integer without a cast
      arch/m68knommu/platform/532x/gpio.c:37:3: warning: initialisation makes pointer from integer without a cast
      arch/m68knommu/platform/532x/gpio.c:51:3: warning: initialisation makes pointer from integer without a cast
      arch/m68knommu/platform/532x/gpio.c:52:3: warning: initialisation makes pointer from integer without a cast
      arch/m68knommu/platform/532x/gpio.c:53:3: warning: initialisation makes pointer from integer without a cast
      arch/m68knommu/platform/532x/gpio.c:54:3: warning: initialisation makes pointer from integer without a cast
      ...
      Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
      5d44b096