1. 22 Oct, 2004 4 commits
    • Benjamin Herrenschmidt's avatar
      [PATCH] ppc64: Update G5 thermal control driver · e206f393
      Benjamin Herrenschmidt authored
      This patch updates the G5 thermal control driver, the main change
      is support for the new "PowerMac7,3" type desktops including the
      dual 2.5Ghz with liquid cooling.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e206f393
    • Benjamin Herrenschmidt's avatar
      [PATCH] ppc64: Fix typo in zImage boot wrapper · bcfb0dd9
      Benjamin Herrenschmidt authored
      This patch fixes a typo in the zImage boot wrapper (incorrect printf).
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarMatthew Dharm <mdharm@momenco.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      bcfb0dd9
    • Benjamin Herrenschmidt's avatar
      [PATCH] ppc64: Fix boot on some non-LPAR pSeries · 7923a9d6
      Benjamin Herrenschmidt authored
      This patch fixes a problem when allocating the TCE tables (iommu) during
      early boot on some non-LPAR machines with a lot of memory.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      7923a9d6
    • Paul Mackerras's avatar
      [PATCH] PPC64 remove __ioremap_explicit() error message · 577e92ea
      Paul Mackerras authored
      This patch, from John Rose, is the counterpart of one recently
      forwarded by Greg KH.  It has the same description, but isn't the same
      patch - this is the arch/ppc64 part of the change.
      
      As an unfortunate side effect of runtime addition/removal of PCI Host Bridges,
      the RPA DLPAR driver can no longer depend on the success of ioremap_explicit()
      (and therefore remap_page_range()) for the case of DLPAR adding an I/O Slot.  
      
      Without addressing this, an attempt to add the first child slot of a newly
      added PHB will fail when __ioremap_explicit() determines the mappings for that
      range to already exist.
      
      For a little context, __ioremap_explicit() creates mappings for the range of a
      newly added slot.  Here's why these calls will be expected to fail in some
      cases.  Keep in mind that at boot-time, the PPC64 kernel calls ioremap() for
      the entire range spanned by each PHB.  Consider the following scenarios of
      DLPAR-adding an I/O slot.
      
      1) Just after boot, one removes an I/O slot.  At this point the range
         associated with the parent PHB is fragmented, and the child range for the
         slot in question is iounmap()'ed.  One then re-adds the slot, at which point
         remap_page_range()/ioremap_explicit() restores the mappings that were
         previously removed.
      
      2) One adds a new PHB, at which point the ppc64-specific addition ioremaps the
         entire PHB range.  One then performs a DLPAR-add of a child slot of that
         PHB.  At this point, mappings already exist for the range of the slot to
         be added.  So remap_page_range()/ioremap_explicit() will fail at this point.
      
      The problem is, there's not a good way to distinguish between cases 1 and 2
      from the perspective of the DLPAR driver.  Because of that, I believe the
      correct solution to be:
      
      - Removal of relevant error prints from iounmap_explicit(), which is only used
        for DLPAR.
      - Removal of error code checks from the RPA driver
      
      Here's the first of these.
      Signed-off-by: default avatarJohn Rose <johnrose@austin.ibm.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      577e92ea
  2. 21 Oct, 2004 10 commits
  3. 22 Oct, 2004 2 commits
  4. 21 Oct, 2004 24 commits