Skip to content

L
linux
Switch branch/tag
  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
  3. 21 Oct, 2004 10 commits
  5. 22 Oct, 2004 2 commits
  7. 21 Oct, 2004 24 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7