Skip to content

L
linux

Linux-御风守护者 / linux
与 Fork 源项目一致

从无法访问的项目Fork

通知 1
Star 0
Fork 0
L
linux

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 23 1月, 2007 34 次提交
  3. 22 1月, 2007 6 次提交
    • P
      [POWERPC] Update defconfigs · e89debcd
      由 Paul Mackerras 提交于 
      Mostly took the defaults, except tried to get the netfilter options
more or less as they were before.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e89debcd
    • R
      [POWERPC] atomic_dec_if_positive sign extension fix · 434f98c4
      由 Robert Jennings 提交于 
      On 64-bit machines, if an atomic counter is explicitly set to a
negative value, the atomic_dec_if_positive function will decrement and
store the next smallest value in the atomic counter, contrary to its
intended operation.

The comparison to determine if the decrement will make the result
negative was done by the "addic." instruction, which operates on a
64-bit value, namely the zero-extended word loaded from the atomic
variable.  This patch uses an explicit word compare (cmpwi) and
changes the addic. to an addi (also changing "=&r" to "=&b" so that r0
isn't used, and addi doesn't become li).

This also fixes a bug for both 32-bit and 64-bit in that previously
0x80000000 was considered positive, since the result after
decrementing is positive.  Now it is considered negative.

Also, I clarify the return value in the comments just to make it clear
that the value returned is always the decremented value, even if that
value is not stored back to the atomic counter.
Signed-off-by: NRobert Jennings <rcj@linux.vnet.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      434f98c4
    • L
      [POWERPC] Fix OF node refcnt underflow in 836x and 832x platform code · 06cd9396
      由 Li Yang 提交于 
      Incorrect use of of_find_node_by_name() causes of_node_put()
on a node which has already been put.  It causes the refcount of
the node to underflow, which triggers the WARN_ON in kref_get
for 836x and 832x.  This fixes it.
Signed-off-by: NLi Yang <leoli@freescale.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      06cd9396
    • G
      [POWERPC] Make it blatantly clear; mpc5200 device tree is not yet stable · 121361f7
      由 Grant Likely 提交于 
      Documentation-only change.  The 5200 device tree layout has not yet
stablized, so nobody should depend on the layout of the tree.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Acked-by: NSylvain Munaut <tnt@246tNt.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      121361f7
    • L
      [POWERPC] Fix broken DMA on non-LPAR pSeries · 77319254
      由 Linas Vepstas 提交于 
      It appears that the iommu table address is never stored, and thus
never found, on non-lpar systems. Thus, for example, during boot:

<7>[   93.067916] PCI: Scanning bus 0001:41
<7>[   93.068542] PCI: Found 0001:41:01.0 [8086/100f] 000200 00
<7>[   93.068550] PCI: Calling quirk c0000000007822e0 for 0001:41:01.0
<7>[   93.069815] PCI: Fixups for bus 0001:41
<4>[   93.070167] iommu: Device 0001:41:01.0 has no iommu table
<7>[   93.070251] PCI: Bus scan for 0001:41 returning with max=41

No iommu table? How can that be? Well, circa line 471 of
arch/powerpc/platforms/pseries/iommu.c we see the code:

   while (dn && PCI_DN(dn) && PCI_DN(dn)->iommu_table == NULL)
      dn = dn->parent;

and a few lines later is the surprising print statement about
the missing table.  Seems that this loop ran unto the end, never
once finding a non-null PCI_DN(dn)->iommu_table.

The problem can be found a few lines earlier: it sems that the
value of PCI_DN(dn)->iommu_table is never ever set. Thus, the
patch sets it.

The patch was tested on a Power4 system running in full system
partition mode, which is where I saw the problem. It works; I've
not done any wider testing. Had a brief discussion on this on irc.
Signed-off-by: NLinas Vepstas <linas@austin.ibm.com>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      77319254
    • B
      [POWERPC] Fix cell's mmio nvram to properly parse device tree · 6984ee79
      由 Benjamin Herrenschmidt 提交于 
      The mmio nvram driver (used by cell only atm) isn't properly parsing
the device-tree, meaning that nvram isn't found correctly on the new
Cell blades.  It works ok for old blades where the nvram is at the
root of the device tree but fails on Malta and CAB when it's hanging
off axon.  This fixes it by using the proper OF parsing functions.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      6984ee79