1. 31 Aug, 2007 2 commits
    • Linus Torvalds's avatar
      Merge master.kernel.org:/home/rmk/linux-2.6-arm · feabb06b
      Linus Torvalds authored
      * master.kernel.org:/home/rmk/linux-2.6-arm:
        [ARM] 4561/1: i.MX/MX1 GPIO parenthes omission and input setup fix
        [ARM] 4557/1: Fix PXA irq gpio initialization
        [ARM] 4551/1: s3c24xx: fix wrong virtual address offsets
        [ARM] 4552/1: i.MX/MX1 GPIO output setup fix
        [ARM] 4553/1: ARM at91: define FIQ_START
        [ARM] 4554/1: replace consistent_sync() with flush_ioremap_region()
        ARM: OMAP: Enable serial idling and wakeup features
        ARM: OMAP2: Force APLLs always active
        ARM: OMAP: H3 workqueue fixes
        ARM: OMAP: OSK led fixes
        ARM: OMAP: fix OMAP1 dmtimer build warning
        ARM: OMAP: Fix 32k timer unsupported one-shot mode
      feabb06b
    • Hugh Dickins's avatar
      fix maxcpus=1 oops in show_stat() · 62e6f1e8
      Hugh Dickins authored
      Alexey Dobriyan reports that maxcpus=1 is still broken in 2.6.23-rc4:
      if CONFIG_HOTPLUG_CPU is not set, x86_64 bootup oopses in show_stat() -
      for_each_possible_cpu accesses a per-cpu area which was never set up.
      
      Alexey identified commit 61ec7567
      (ACPI: boot correctly with "nosmp" or "maxcpus=0") as the origin;
      but it's not really to blame, just exposes a bug in 2.6.23-rc1's commit
      8b3b2955 (Especially when !CONFIG_HOTPLUG_CPU,
      avoid needlessy allocating resources for CPUs that can never become available).
      
      rc1's test for max_cpus < 2 in start_kernel() wasn't working because
      max_cpus was still NR_CPUS at that point: until rc4 moved the maxcpus
      parsing earlier.  Now it sets cpu_possible_map to 1 before allocating
      all possible per-cpu areas; then smp_init() expands cpu_possible_map
      to cpu_present_map (0xf in my case) later on.
      
      rc1's commit has good intentions, but expects cpu_present_map to be
      limited by maxcpus, which is only the case on i386.  cpus_and(possible,
      possible,present) might be good, but needs an audit of cpu_present_map
      uses - there may well be assumptions that any cpu present is possible.
      
      So stay safe for now and just revert those #ifndef CONFIG_HOTPLUG_CPU
      optimizations in rc1's commit.
      Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
      Cc: Alexey Dobriyan <adobriyan@sw.ru>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jan Beulich <jbeulich@novell.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      62e6f1e8
  2. 30 Aug, 2007 8 commits
  3. 29 Aug, 2007 3 commits
    • Christian Krafft's avatar
      [POWERPC] spu_manage: fix spu_unit_number for celleb device tree · aac2e684
      Christian Krafft authored
      This fixes a regression introduced with 2.6.23-rc4 after on some
      confusion about the device tree interfaces.
      
      IBM QS21 device trees provide "physical-id", so we changed the code to
      run on that and remain compatible with all IBM machines.
      
      However, the Toshiba Celleb device tree provides the "unit-id" property,
      which was in the Linux code, but never used in this way on IBM hardware.
      
      Legacy device tree used the reg property for the physical id of an spe.
      This patch fixes find_spu_unit_number to look for the spu id in that order.
      The length is checked to avoid misinterpretation in case the attributes
      unit-id or reg do not contain the id.
      Signed-off-by: default avatarChristian Krafft <krafft@de.ibm.com>
      Signed-off-by: default avatarArnd Bergmann <arnd.bergmann@de.ibm.com>
      Cc: Jeremy Kerr <jk@ozlabs.org>
      aac2e684
    • Kumar Gala's avatar
      [POWERPC] Update defconfigs · 5cc44e08
      Kumar Gala authored
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      5cc44e08
    • Kumar Gala's avatar
      [POWERPC] Flush registers to proper task context · 0ee6c15e
      Kumar Gala authored
      When we flush register state for FP, Altivec, or SPE in flush_*_to_thread
      we need to respect the task_struct that the caller has passed to us.
      
      Most cases we are called with current, however sometimes (ptrace) we may
      be passed a different task_struct.
      
      This showed up when using gdbserver debugging a simple program that used
      floating point. When gdb tried to show the FP regs they all showed up as
      0, because the child's FP registers were never properly flushed to memory.
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      0ee6c15e
  4. 28 Aug, 2007 2 commits
  5. 27 Aug, 2007 25 commits