1. 05 Nov, 2008 7 commits
  2. 31 Oct, 2008 5 commits
  3. 30 Oct, 2008 15 commits
    • Carl Love's avatar
      powerpc/cell/OProfile: Fix on-stack array size in activate spu profiling function · 210434d7
      Carl Love authored
      The size of the pm_signal_local array should be equal to the
      number of SPUs being configured in the array.  Currently, the
      array is of size 4 (NR_PHYS_CTRS) but being indexed by a for
      loop from 0 to 7 (NUM_SPUS_PER_NODE).  This could potentially
      cause an oops or random memory corruption since the pm_signal_local
      array is on the stack.  This fixes it.
      Signed-off-by: default avatarCarl Love <carll@us.ibm.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
    • Kumar Gala's avatar
      powerpc/mpic: Fix regression caused by change of default IRQ affinity · 3c10c9c4
      Kumar Gala authored
      The Freescale implementation of MPIC only allows a single CPU destination
      for non-IPI interrupts.  We add a flag to the mpic_init to distinquish
      these variants of MPIC.  We pull in the irq_choose_cpu from sparc64 to
      select a single CPU as the destination of the interrupt.
      This is to deal with the fact that the default smp affinity was
      changed by commit 18404756
      Expose default irq affinity mask (take 3)") to be all CPUs.
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
    • Mark Nelson's avatar
      powerpc: Update remaining dma_mapping_ops to use map/unmap_page · f9226d57
      Mark Nelson authored
      After the merge of the 32 and 64bit DMA code, dma_direct_ops lost
      their map/unmap_single() functions but gained map/unmap_page().  This
      caused a problem for Cell because Cell's dma_iommu_fixed_ops called
      the dma_direct_ops if the fixed linear mapping was to be used or the
      iommu ops if the dynamic window was to be used.  So in order to fix
      this problem we need to update the 64bit DMA code to use
      First, we update the generic IOMMU code so that iommu_map_single()
      becomes iommu_map_page() and iommu_unmap_single() becomes
      iommu_unmap_page().  Then we propagate these changes up through all
      the callers of these two functions and in the process update all the
      dma_mapping_ops so that they have map/unmap_page rahter than
      map/unmap_single.  We can do this because on 64bit there is no HIGHMEM
      memory so map/unmap_page ends up performing exactly the same function
      as map/unmap_single, just taking different arguments.
      This has no affect on drivers because the dma_map_single_attrs() just
      ends up calling the map_page() function of the appropriate
      dma_mapping_ops and similarly the dma_unmap_single_attrs() calls
      This fixes an oops on Cell blades, which oops on boot without this
      because they call dma_direct_ops.map_single, which is NULL.
      Signed-off-by: default avatarMark Nelson <markn@au1.ibm.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
    • Benjamin Herrenschmidt's avatar
      powerpc/pci: Fix unmapping of IO space on 64-bit · b30115ea
      Benjamin Herrenschmidt authored
      A typo/thinko made us pass the wrong argument to __flush_hash_table_range
      when unplugging bridges, thus not flushing all the translations for
      the IO space on unplug.  The third parameter to __flush_hash_table_range
      is `end', not `size'.
      This causes the hypervisor to refuse unplugging slots.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
    • Nathan Fontenot's avatar
      powerpc/pci: Properly allocate bus resources for hotplug PHBs · e90a1318
      Nathan Fontenot authored
      Resources for PHB's that are dynamically added to a system are not
      properly allocated in the resource tree.
      Not having these resources allocated causes an oops when removing
      the PHB when we try to release them.
      The diff appears a bit messy, this is mainly due to moving everything
      one tab to the left in the pcibios_allocate_bus_resources routine.
      The functionality change in this routine is only that the
      list_for_each_entry() loop is pulled out and moved to the necessary
      calling routine.
      Signed-off-by: default avatarNathan Fontenot <nfont@austin.ibm.com>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
    • Jeremy Kerr's avatar
      OF-device: Don't overwrite numa_node in device registration · 6098e2ee
      Jeremy Kerr authored
      Currently, the numa_node of OF-devices will be overwritten during
      device_register, which simply sets the node to -1.  On cell machines,
      this means that devices can't find their IOMMU, which is referenced
      through the device's numa node.
      Set the numa node for OF devices with no parent, and use the
      lower-level device_initialize and device_add functions, so that the
      node is preserved.
      We can remove the call to set_dev_node in of_device_alloc, as it
      will be overwritten during register.
      Signed-off-by: default avatarJeremy Kerr <jk@ozlabs.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
    • Michael Neuling's avatar
      powerpc: Fix swapcontext system for VSX + old ucontext size · 16c29d18
      Michael Neuling authored
      Since VSX support was added, we now have two sizes of ucontext_t;
      the older, smaller size without the extra VSX state, and the new
      larger size with the extra VSX state.  A program using the
      sys_swapcontext system call and supplying smaller ucontext_t
      structures will currently get an EINVAL error if the task has
      used VSX (e.g. because of calling library code that uses VSX) and
      the old_ctx argument is non-NULL (i.e. the program is asking for
      its current context to be saved).  Thus the program will start
      getting EINVAL errors on calls that previously worked.
      This commit changes this behaviour so that we don't send an EINVAL in
      this case.  It will now return the smaller context but the VSX MSR bit
      will always be cleared to indicate that the ucontext_t doesn't include
      the extra VSX state, even if the task has executed VSX instructions.
      Both 32 and 64 bit cases are updated.
      [paulus@samba.org - also fix some access_ok() and get_user() calls]
      Thanks to Ben Herrenschmidt for noticing this problem.
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
    • Michael Neuling's avatar
      powerpc: Fix compiler warning for the relocatable kernel · b160544c
      Michael Neuling authored
      Fixes this warning:
       arch/powerpc/kernel/setup_64.c:447:5: warning: "kernstart_addr" is not defined
      which arises because PHYSICAL_START is no longer a constant when
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
    • Paul Mackerras's avatar
      powerpc: Work around ld bug in older binutils · 2a4b9c5a
      Paul Mackerras authored
      Commit 549e8152
       ("powerpc: Make the
      64-bit kernel as a position-independent executable") added lines to
      vmlinux.lds.S to add the extra sections needed to implement a
      relocatable kernel.  However, those lines seem to trigger a bug in
      older versions of GNU ld (such as 2.16.1) when building a
      non-relocatable kernel.  Since ld 2.16.1 is still a popular choice for
      cross-toolchains, this adds an #ifdef to vmlinux.lds.S so the added
      lines are only included when building a relocatable kernel.
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
    • Milton Miller's avatar
      powerpc/ppc64/kdump: Better flag for running relocatable · 8b8b0cc1
      Milton Miller authored
      The __kdump_flag ABI is overly constraining for future development.
      As of 2.6.27, the kernel entry point has 4 constraints:  Offset 0 is
      the starting point for the master (boot) cpu (entered with r3 pointing
      to the device tree structure), offset 0x60 is code for the slave cpus
      (entered with r3 set to their device tree physical id), offset 0x20 is
      used by the iseries hypervisor, and secondary cpus must be well behaved
      when the first 256 bytes are copied to address 0.
      Placing the __kdump_flag at 0x18 is bad because:
      - It was taking the last 8 bytes before the iseries hypervisor data.
      - It was 8 bytes for a boolean flag
      - It had no way of identifying that the flag was present
      - It does leave any room for the master to add any additional code
        before branching, which hurts debug.
      - It will be unnecessarily hard for 32 bit code to be common (8 bytes)
      Now that we have eliminated the use of __kdump_flag in favor of
      the standard is_kdump_kernel(), this flag only controls run without
      relocating the kernel to PHYSICAL_START (0), so rename it __run_at_load.
      Move the flag to 0x5c, 1 word before the secondary cpu entry point at
      0x60.  Initialize it with "run0" to say it will run at 0 unless it is
      set to 1.  It only exists if we are relocatable.
      Signed-off-by: default avatarMilton Miller <miltonm@bga.com>
      Signed-off-by: default avatarMichael Neuling <mikey@neuling.org>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
    • Milton Miller's avatar
      powerpc: Use is_kdump_kernel() · 62a8bd6c
      Milton Miller authored
      linux/crash_dump.h defines is_kdump_kernel() to be used by code that
      needs to know if the previous kernel crashed instead of a (clean) boot
      or reboot.
      This updates the just added powerpc code to use it.  This is needed
      for the next commit, which will remove __kdump_flag.
      Signed-off-by: default avatarMilton Miller <miltonm@bga.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
    • Milton Miller's avatar
      powerpc: Kexec exit should not use magic numbers · 1767c8f3
      Milton Miller authored
      Commit 54622f10
       ("powerpc: Support for
      relocatable kdump kernel") added a magic flag value in a register to
      tell purgatory that it should be a panic kernel.  This part is wrong
      and is reverted by this commit.
      The kernel gets a list of memory blocks and a entry point from user space.
      Its job is to copy the blocks into place and then branch to the designated
      entry point (after turning "off" the mmu).
      The user space tool inserts a trampoline, called purgatory, that runs
      before the user supplied code.   Its job is to establish the entry
      environment for the new kernel or other application based on the contents
      of memory.  The purgatory code is compiled and embedded in the tool,
      where it is later patched using the elf symbol table using elf symbols.
      Since the tool knows it is creating a purgatory that will run after a
      kernel crash, it should just patch purgatory (or the kernel directly)
      if something needs to happen.
      Signed-off-by: default avatarMilton Miller <miltonm@bga.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
    • Trent Piepho's avatar
      gianfar: Fix race in TBI/SerDes configuration · c132419e
      Trent Piepho authored
      The init_phy() function attaches to the PHY, then configures the
      SerDes<->TBI link (in SGMII mode).  The TBI is on the MDIO bus with the PHY
      (sort of) and is accessed via the gianfar's MDIO registers, using the
      functions gfar_local_mdio_read/write(), which don't do any locking.
      The previously attached PHY will start a work-queue on a timer, and
      probably an irq handler as well, which will talk to the PHY and thus use
      the MDIO bus.  This uses phy_read/write(), which have locking, but not
      against the gfar_local_mdio versions.
      The result is that PHY code will try to use the MDIO bus at the same time
      as the SerDes setup code, corrupting the transfers.
      Setting up the SerDes before attaching to the PHY will insure that there is
      no race between the SerDes code and *our* PHY, but doesn't fix everything.
      Typically the PHYs for all gianfar devices are on the same MDIO bus, which
      is associated with the first gianfar device.  This means that the first
      gianfar's SerDes code could corrupt the MDIO transfers for a different
      gianfar's PHY.
      The lock used by phy_read/write() is contained in the mii_bus structure,
      which is pointed to by the PHY.  This is difficult to access from the
      gianfar drivers, as there is no link between a gianfar device and the
      mii_bus which shares the same MDIO registers.  As far as the device layer
      and drivers are concerned they are two unrelated devices (which happen to
      share registers).
      Generally all gianfar devices' PHYs will be on the bus associated with the
      first gianfar.  But this might not be the case, so simply locking the
      gianfar's PHY's mii bus might not lock the mii bus that the SerDes setup
      code is going to use.
      We solve this by having the code that creates the gianfar platform device
      look in the device tree for an mdio device that shares the gianfar's
      registers.  If one is found the ID of its platform device is saved in the
      gianfar's platform data.
      A new function in the gianfar mii code, gfar_get_miibus(), can use the bus
      ID to search through the platform devices for a gianfar_mdio device with
      the right ID.  The platform device's driver data is the mii_bus structure,
      which the SerDes setup code can use to lock the current bus.
      Signed-off-by: default avatarTrent Piepho <tpiepho@freescale.com>
      CC: Andy Fleming <afleming@freescale.com>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
    • Josh Boyer's avatar
      powerpc/44x: Update 44x defconfigs · 8531b7a8
      Josh Boyer authored
      Update the PowerPC 44x defconfigs for 2.6.28
      Signed-off-by: default avatarJosh Boyer <jwboyer@linux.vnet.ibm.com>
    • Josh Boyer's avatar
      powerpc/40x: Update 40x defconfigs · c4cd9ec4
      Josh Boyer authored
      Update the PowerPC 40x defconfigs for 2.6.28
      Signed-off-by: default avatarJosh Boyer <jwboyer@linux.vnet.ibm.com>
  4. 28 Oct, 2008 4 commits
  5. 23 Oct, 2008 4 commits
  6. 22 Oct, 2008 1 commit
  7. 21 Oct, 2008 4 commits