1. 03 Jul, 2008 11 commits
  2. 02 Jul, 2008 8 commits
  3. 01 Jul, 2008 7 commits
    • Tim Yamin's avatar
      powerpc/mpc5200: Fix lite5200b suspend/resume · 18d76ac9
      Tim Yamin authored
      Suspend/resume ("echo mem > /sys/power/state") does not work with
      vanilla kernels -- the system does not suspend correctly and just
      hangs. This patch fixes this so suspend/resume works:
      
      1) of_iomap does not map the whole 0xC000 of the MPC5200 immr so
      saving registers does not work.
      2) PCI registers need to be saved and restored.
      Signed-off-by: default avatarTim Yamin <plasm@roo.me.uk>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      18d76ac9
    • John Linn's avatar
      powerpc/legacy_serial: Bail if reg-offset/shift properties are present · 1e6d1f26
      John Linn authored
      The legacy serial driver does not work with an 8250 type UART that is
      described in the device tree with the reg-offset and reg-shift
      properties.  This change makes legacy_serial ignore these devices.
      Signed-off-by: default avatarJohn Linn <john.linn@xilinx.com>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      1e6d1f26
    • Wolfram Sang's avatar
      i2c: Fix bad hint about irqs in i2c.h · 8e29da9e
      Wolfram Sang authored
      i2c.h mentions -1 as a not-issued irq. This false hint was taken by
      of_i2c and caused crashes. Don't give any advice as 'no irq' is not
      consistent across all architectures yet and it is not needed internally
      by the i2c-core.
      Signed-off-by: default avatarWolfram Sang <w.sang@pengutronix.de>
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      8e29da9e
    • Ben Dooks's avatar
      i2c: Documentation: fix device matching description · 2260e63a
      Ben Dooks authored
      The matching process described for new style clients in
      Documentation/i2c/writing-clients is classed as out-of-date
      as it requires the presence of an .id_table entry in the
      driver's i2c_driver entry.
      Signed-off-by: default avatarBen Dooks <ben-linux@fluff.org>
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      2260e63a
    • John Linn's avatar
      powerpc/bootwrapper: update for initrd with simpleImage · 5d1a0411
      John Linn authored
      This change to the makefile corrects the build of a simpleImage with initrd.
      Signed-off-by: default avatarJohn Linn <john.linn@xilinx>
      Signed-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      5d1a0411
    • Gautham R Shenoy's avatar
      rcu: fix hotplug vs rcu race · 8558f8f8
      Gautham R Shenoy authored
      Dhaval Giani reported this warning during cpu hotplug stress-tests:
      
      | On running kernel compiles in parallel with cpu hotplug:
      |
      | WARNING: at arch/x86/kernel/smp.c:118
      | native_smp_send_reschedule+0x21/0x36()
      | Modules linked in:
      | Pid: 27483, comm: cc1 Not tainted 2.6.26-rc7 #1
      | [...]
      |  [<c0110355>] native_smp_send_reschedule+0x21/0x36
      |  [<c014fe8f>] force_quiescent_state+0x47/0x57
      |  [<c014fef0>] call_rcu+0x51/0x6d
      |  [<c01713b3>] __fput+0x130/0x158
      |  [<c0171231>] fput+0x17/0x19
      |  [<c016fd99>] filp_close+0x4d/0x57
      |  [<c016fdff>] sys_close+0x5c/0x97
      
      IMHO the warning is a spurious one.
      
      cpu_online_map is updated by the _cpu_down() using stop_machine_run().
      Since force_quiescent_state is invoked from irqs disabled section,
      stop_machine_run() won't be executing while a cpu is executing
      force_quiescent_state(). Hence the cpu_online_map is stable while we're
      in the irq disabled section.
      
      However, a cpu might have been offlined _just_ before we disabled irqs
      while entering force_quiescent_state(). And rcu subsystem might not yet
      have handled the CPU_DEAD notification, leading to the offlined cpu's
      bit being set in the rcp->cpumask.
      
      Hence cpumask = (rcp->cpumask & cpu_online_map) to prevent sending
      smp_reschedule() to an offlined CPU.
      
      Here's the timeline:
      
      CPU_A						 CPU_B
      --------------------------------------------------------------
      cpu_down():					.
      .					   	.
      .						.
      stop_machine(): /* disables preemption,		.
      		 * and irqs */			.
      .						.
      .						.
      take_cpu_down();				.
      .						.
      .						.
      .						.
      cpu_disable(); /*this removes cpu 		.
      		*from cpu_online_map 		.
      		*/				.
      .						.
      .						.
      restart_machine(); /* enables irqs */		.
      ------WINDOW DURING WHICH rcp->cpumask is stale ---------------
      .						call_rcu();
      .						/* disables irqs here */
      .						.force_quiescent_state();
      .CPU_DEAD:					.for_each_cpu(rcp->cpumask)
      .						.   smp_send_reschedule();
      .						.
      .						.   WARN_ON() for offlined CPU!
      .
      .
      .
      rcu_cpu_notify:
      .
      -------- WINDOW ENDS ------------------------------------------
      rcu_offline_cpu() /* Which calls cpu_quiet()
      		   * which removes
      		   * cpu from rcp->cpumask.
      		   */
      
      If a new batch was started just before calling stop_machine_run(), the
      "tobe-offlined" cpu is still present in rcp-cpumask.
      
      During a cpu-offline, from take_cpu_down(), we queue an rt-prio idle
      task as the next task to be picked by the scheduler. We also call
      cpu_disable() which will disable any further interrupts and remove the
      cpu's bit from the cpu_online_map.
      
      Once the stop_machine_run() successfully calls take_cpu_down(), it calls
      schedule(). That's the last time a schedule is called on the offlined
      cpu, and hence the last time when rdp->passed_quiesc will be set to 1
      through rcu_qsctr_inc().
      
      But the cpu_quiet() will be on this cpu will be called only when the
      next RCU_SOFTIRQ occurs on this CPU. So at this time, the offlined CPU
      is still set in rcp->cpumask.
      
      Now coming back to the idle_task which truely offlines the CPU, it does
      check for a pending RCU and raises the softirq, since it will find
      rdp->passed_quiesc to be 0 in this case. However, since the cpu is
      offline I am not sure if the softirq will trigger on the CPU.
      
      Even if it doesn't the rcu_offline_cpu() will find that rcp->completed
      is not the same as rcp->cur, which means that our cpu could be holding
      up the grace period progression. Hence we call cpu_quiet() and move
      ahead.
      
      But because of the window explained in the timeline, we could still have
      a call_rcu() before the RCU subsystem executes it's CPU_DEAD
      notification, and we send smp_send_reschedule() to offlined cpu while
      trying to force the quiescent states. The appended patch adds comments
      and prevents checking for offlined cpu everytime.
      
      cpu_online_map is updated by the _cpu_down() using stop_machine_run().
      Since force_quiescent_state is invoked from irqs disabled section,
      stop_machine_run() won't be executing while a cpu is executing
      force_quiescent_state(). Hence the cpu_online_map is stable while we're
      in the irq disabled section.
      Reported-by: default avatarDhaval Giani <dhaval@linux.vnet.ibm.com>
      Signed-off-by: default avatarGautham R Shenoy <ego@in.ibm.com>
      Acked-by: default avatarDhaval Giani <dhaval@linux.vnet.ibm.com>
      Cc: Dipankar Sarma <dipankar@in.ibm.com>
      Cc: laijs@cn.fujitsu.com
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Rusty Russel <rusty@rustcorp.com.au>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      8558f8f8
    • Thomas Gleixner's avatar
      x86: fix NODES_SHIFT Kconfig range · efac4189
      Thomas Gleixner authored
      commit 43238382
             x86: change size of node ids from u8 to s16
      
      set the range for NODES_SHIFT to 1..15.
      
      The possible range is 1..9
      
      Fixes Bugzilla #10726
      Reported-by: default avatarDave Jones <davej@codemonkey.org.uk>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      efac4189
  4. 30 Jun, 2008 14 commits