1. 11 4月, 2015 36 次提交
  2. 10 4月, 2015 4 次提交
    • M
      powerpc: Drop return value of smp_ops->probe() · a7f4ee1f
      Michael Ellerman 提交于
      smp_ops->probe() is currently supposed to return the number of cpus in
      the system.
      
      The last actual usage of the value was removed in May 2007 in e147ec8f
      "[POWERPC] Simplify smp_space_timers". We still passed the value around
      until June 2010 when even that was finally removed in c1aa687d
      "powerpc: Clean up obsolete code relating to decrementer and timebase".
      
      So drop that requirement, probe() now returns void, and update all
      implementations.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      a7f4ee1f
    • M
      powerpc/cell: Fix cell iommu after it_page_shift changes · 7261b956
      Michael Ellerman 提交于
      The patch to add it_page_shift incorrectly changed the increment of
      uaddr to use it_page_shift, rather then (1 << it_page_shift).
      
      This broke booting on at least some Cell blades, as the iommu was
      basically non-functional.
      
      Fixes: 3a553170 ("powerpc/iommu: Add it_page_shift field to determine iommu page size")
      Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      7261b956
    • M
      powerpc/cell: Fix crash in iic_setup_cpu() after per_cpu changes · b0dd00ad
      Michael Ellerman 提交于
      The conversion from __get_cpu_var() to this_cpu_ptr() in iic_setup_cpu()
      is wrong. It causes an oops at boot.
      
      We need the per-cpu address of struct cpu_iic, not cpu_iic.regs->prio.
      
      Sparse noticed this, because we pass a non-iomem pointer to out_be64(),
      but we obviously don't check the sparse results often enough.
      
      Fixes: 69111bac ("powerpc: Replace __get_cpu_var uses")
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      b0dd00ad
    • M
      powerpc: Reword the "returning from prom_init" message · 7e862d7e
      Michael Ellerman 提交于
      We get way too many bug reports that say "the kernel is hung in
      prom_init", which stems from the fact that the last piece of output
      people see is "returning from prom_init".
      
      The kernel is almost never hung in prom_init(), it's just that it's
      crashed somewhere after prom_init() but prior to the console coming up.
      
      The existing message should give a clue to that, ie. "returning from"
      indicates that prom_init() has finished, but it doesn't seem to work.
      Let's try something different.
      
      This prints:
      
        Quiescing Open Firmware ...
        Booting Linux via __start() ...
      
      Which hopefully makes it clear that prom_init() is not the problem, and
      although __start() probably isn't either, it's at least the right place
      to begin looking.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Wistfully-Acked-by: NJeremy Kerr <jk@ozlabs.org>
      7e862d7e