summaryrefslogtreecommitdiff
path: root/drivers/net/ibm_newemac/Kconfig
AgeCommit message (Collapse)AuthorFilesLines
2008-10-15Merge commit 'origin'Benjamin Herrenschmidt1-1/+1
Manual fixup of conflicts on: arch/powerpc/include/asm/dcr-regs.h drivers/net/ibm_newemac/core.h
2008-09-30ibm_newemac: Introduce mal_has_featureJosh Boyer1-0/+8
There are some PowerPC SoCs that do odd things with the MAL handling. In order to accommodate them, we need to introduce a feature mechanism that is similar to the existing emac_has_feature function. This adds a feature variable to the mal_instance structure, and adds a mal_has_feature function. Two features are defined and are guarded by Kconfig options that are selected by the affected platforms. MAL_FTR_CLEAR_ICINSTAT is used for platforms that need to clear the interrupt bits in the ICINTSTAT SDR for txeob/rxeob. This is common on MAL implementations that have interrupt coalescing. MAL_FTR_COMMON_ERR_INT is used for platforms that have SERR, TXDE, and RXDE OR'd into a single interrupt bit. Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
2008-09-30ibm_newemac: Allow the "no flow control" EMAC feature to workJosh Boyer1-0/+4
Some PowerPC 40x chips have errata that force us not to use the integrated flow control. We have the feature defined, but it currently can't be used because it is never added to EMAC_FTRS_POSSIBLE. This adds a Kconfig option for affected platforms to select and puts the feature in the EMAC_FTRS_POSSIBLE list. This is set for PowerPC 405EZ platforms as well. Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
2008-09-24netdev: drop CONFIG_PPC_MERGE from KconfigKumar Gala1-1/+1
Now that arch/ppc is dead CONFIG_PPC_MERGE is always defined for all powerpc platforms so we don't need to depend on it. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Josh Boyer <jwboyer@linux.vnet.ibm.com> Cc: David Gibson <david@gibson.dropbear.id.au> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2008-06-17ibm_newemac: select CRC32 in KconfigJosh Boyer1-0/+1
The ibm_newemac driver requires ether_crc to be defined. Apparently it is possible to generate a .config without CONFIG_CRC32 set which causes the following link errors if IBM_NEW_EMAC is selected: LD .tmp_vmlinux1 drivers/built-in.o: In function `emac_hash_mc': core.c:(.text+0x2f524): undefined reference to `crc32_le' core.c:(.text+0x2f528): undefined reference to `bitrev32' make: *** [.tmp_vmlinux1] Error 1 This patch has IBM_NEW_EMAC select CRC32 so we don't hit this error. Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2007-10-10Device tree aware EMAC driverDavid Gibson1-0/+63
Based on BenH's earlier work, this is a new version of the EMAC driver for the built-in ethernet found on PowerPC 4xx embedded CPUs. The same ASIC is also found in the Axon bridge chip. This new version is designed to work in the arch/powerpc tree, using the device tree to probe the device, rather than the old and ugly arch/ppc OCP layer. This driver is designed to sit alongside the old driver (that lies in drivers/net/ibm_emac and this one in drivers/net/ibm_newemac). The old driver is left in place to support arch/ppc until arch/ppc itself reaches its final demise (not too long now, with luck). This driver still has a number of things that could do with cleaning up, but I think they can be fixed up after merging. Specifically: - Should be adjusted to properly use the dma mapping API. Axon needs this. - Probe logic needs reworking, in conjuction with the general probing code for of_platform devices. The dependencies here between EMAC, MAL, ZMII etc. make this complicated. At present, it usually works, because we initialize and register the sub-drivers before the EMAC driver itself, and (being in driver code) runs after the devices themselves have been instantiated from the device tree. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Jeff Garzik <jeff@garzik.org>