Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 21 10月, 2008 1 次提交
  3. 14 10月, 2008 8 次提交
  5. 03 10月, 2008 1 次提交
  7. 30 9月, 2008 1 次提交
    • D
      powerpc: Fix PCI in Holly device tree · ad611045
      由 David Gibson 提交于 
      The PCI bridge on the Holly board is incorrectly represented in the
device tree.  The current device tree node for the PCI bridge sits
under the tsi-bridge node.  That's not obviously wrong, but the PCI
bridge translates some PCI spaces into CPU address ranges which were
not translated by the "ranges" property in tsi-bridge node.

We used to get away with this problem because the PCI bridge discovery
code was also buggy, assuming incorrectly that PCI host bridge nodes
were always directly under the root bus and treating the translated
addresses as raw CPU addresses, rather than parent bus addresses.
This has since been fixed, thus breaking Holly.

This could be fixed by adding extra translations to the tsi-bridge
node, but this patch instead moves the Holly PCI bridge out of the
tsi-bridge node to the root bus.  This makes the tsi-bridge node
represent only the built-in IO devices in the bridge, with a
more-or-less contiguous address range.  This is the same convention
used on Freescale SoC chips, where the "soc" node represents only the
IMMR region, and the PCI and other bus bridges are separate nodes
under the root bus.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Acked-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ad611045
  9. 24 9月, 2008 1 次提交
  11. 18 9月, 2008 1 次提交
  13. 17 9月, 2008 1 次提交
  15. 16 9月, 2008 4 次提交
  17. 09 9月, 2008 1 次提交
  19. 28 8月, 2008 2 次提交
  21. 21 8月, 2008 2 次提交
  23. 06 8月, 2008 1 次提交
  25. 05 8月, 2008 2 次提交
  27. 30 7月, 2008 1 次提交
  29. 17 7月, 2008 3 次提交
  31. 14 7月, 2008 6 次提交
  33. 13 7月, 2008 2 次提交
  35. 10 7月, 2008 1 次提交
  37. 09 7月, 2008 1 次提交
    • G
      ibm_newemac: Parameterize EMAC Multicast Match Handling · 05781ccd
      由 Grant Erickson 提交于 
      Various instances of the EMAC core have varying: 1) number of address
match slots, 2) width of the registers for handling address match slots,
3) number of registers for handling address match slots and 4) base
offset for those registers.

As the driver stands today, it assumes that all EMACs have 4 IAHT and
GAHT 32-bit registers, starting at offset 0x30 from the register base,
with only 16-bits of each used for a total of 64 match slots.

The 405EX(r) and 460EX now use the EMAC4SYNC core rather than the EMAC4
core. This core has 8 IAHT and GAHT registers, starting at offset 0x80
from the register base, with ALL 32-bits of each used for a total of
256 match slots.

This adds a new compatible device tree entry "emac4sync" and a new,
related feature flag "EMAC_FTR_EMAC4SYNC" along with a series of macros
and inlines which supply the appropriate parameterized value based on
the presence or absence of the EMAC4SYNC feature.

The code has further been reworked where appropriate to use those macros
and inlines.

In addition, the register size passed to ioremap is now taken from the
device tree:

	c4 for EMAC4SYNC cores
	74 for EMAC4 cores
	70 for EMAC cores

rather than sizeof (emac_regs).

Finally, the device trees have been updated with the appropriate compatible
entries and resource sizes.

This has been tested on an AMCC Haleakala board such that: 1) inbound
ICMP requests to 'haleakala.local' via MDNS from both Mac OS X 10.4.11
and Ubuntu 8.04 systems as well as 2) outbound ICMP requests from
'haleakala.local' to those same systems in the '.local' domain via MDNS
now work.
Signed-off-by: NGrant Erickson <gerickson@nuovations.com>
Acked-by: NJeff Garzik <jgarzik@pobox.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      05781ccd