Driver for the Atmel MACB on-chip ethernet module.

Tested on AVR32/AT32AP7000/ATSTK1000. I've heard rumours that it works
with AT91SAM9260 as well, and it may be possible to share some code with
the at91_ether driver for AT91RM9200.

Hardware documentation can be found in the AT32AP7000 data sheet,
which can be downloaded from

http://www.atmel.com/dyn/products/datasheets.asp?family_id=682

Changes since previous version:
  * Probe for PHY ID instead of depending on it being provided through
    platform_data.
  * Grab initial ethernet address from the MACB registers instead
    of depending on platform_data.
  * Set MII/RMII mode correctly.

These changes are mostly about making the driver more compatible with
the at91 infrastructure.

Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>

Add tsi108/9 on chip Ethernet controller driver support.

The driver code collects the feedback of previous posting form the mailing
list and gives the update.

MPC7448HPC2 platform in arch/powerpc uses tsi108 bridge.

The following is a brief description of the Ethernet controller:

The Tsi108/9 Ethernet Controller connects Switch Fabric to two independent
Gigabit Ethernet ports,E0 and E1.  It uses a single Management interface to
manage the two physical connection devices (PHYs).  Each Ethernet port has
its own statistics monitor that tracks and reports key interface
statistics.  Each port supports a 256-entry hash table for address
filtering.  In addition, each port is bridged to the Switch Fabric through
a 2-Kbyte transmit FIFO and a 4-Kbyte Receive FIFO.

Each Ethernet port also has a pair of internal Ethernet DMA channels to
support the transmit and receive data flows.  The Ethernet DMA channels use
descriptors set up in memory, the memory map of the device, and access via
the Switch Fabric.  The Ethernet Controller’s DMA arbiter handles
arbitration for the Switch Fabric.  The Controller also has a register bus
interface for register accesses and status monitor control.

The PMD (Physical Media Device) interface operates in MII, GMII, or TBI
modes.  The MII mode is used for connecting with 10 or 100 Mbit/s PMDs.
The GMII and TBI modes are used to connect with Gigabit PMDs.  Internal
data flows to and from the Ethernet Controller through the Switch Fabric.
Each

Ethernet port uses its transmit and receive DMA channels to manage data
flows through buffer descriptors that are predefined by the system (the
descriptors can exist anywhere in the system memory map).  These
descriptors are data structures that point to buffers filled with data
ready to transmit over Ethernet, or they point to empty buffers ready to
receive data from Ethernet.

Signed-off-by: Alexandre Bounine <Alexandre.Bounine@tundra.com>
Signed-off-by: Roy Zang	<tie-fei.zang@freescale.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>

Signed-off-by: Amit S. Kale <amitkale@netxen.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>

The rest of 8390 conversions; ifdef cascade in 8390.h is gone now.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>

more 8390 conversions - mac8390, zorro8390 and hydra got the same treatment
as arm etherh; one more case in 8390.h ifdef cascade is gone.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>

etherh and a handful of other odd drivers use different macros when building
8390.c.  Since we generate a single 8390.o and then link with it, in any
config with both oddball and normal 8390-based driver we will end up with
breakage in at least one of them.  Solution: take most of 8390.c into
lib8390.c and have 8390.c, etherh.c and the rest of oddballs #include it.
Helper macros are taken from 8390.h to whoever includes lib8390.c.  That
way odd drivers get separate instances of compiled 8390 stuff and stop
stepping on each other's toes.  8390.h gets cleaned up - we don't have
the cascade of ifdefs in there and are left with the stuff that can be
used by any 8390-based driver.  Current problems are exactly because of
that cascade - we attempt to choose the set of helpers by looking at config
and that, of course, doesn't work well when we have several sets needed
by various drivers in our config.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>

Code for the EV96100 evaluation board hasn't compiled since at least
November 15, 2003, so it is being deleted as of 2.6.18 due to lack of
a user base.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>

Hi Jeff,

I fixed the __iomem issue and tested the driver with sparse. Looks good so far.
Thanks for your effort.

Jan-Bernd Themann

Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>

 drivers/net/Kconfig             |    9
 drivers/net/Makefile            |    1
 drivers/net/ehea/Makefile       |    6
 drivers/net/ehea/ehea.h         |  447 ++++++
 drivers/net/ehea/ehea_ethtool.c |  294 ++++
 drivers/net/ehea/ehea_hcall.h   |   51
 drivers/net/ehea/ehea_hw.h      |  287 ++++
 drivers/net/ehea/ehea_main.c    | 2654 ++++++++++++++++++++++++++++++++++++++++
 drivers/net/ehea/ehea_phyp.c    |  705 ++++++++++
 drivers/net/ehea/ehea_phyp.h    |  455 ++++++
 drivers/net/ehea/ehea_qmr.c     |  582 ++++++++
 drivers/net/ehea/ehea_qmr.h     |  358 +++++
 12 files changed, 5849 insertions(+)
Signed-off-by: Jeff Garzik <jeff@garzik.org>

QE(QUICC Engine) is a new generation communication coprocessor, which can
be found on some of the latest Freescale PowerQUICC CPUs(e.g.  MPC8360).
The UCC(Unified Communications Controller) module of QE can work as gigabit
Ethernet device.  This patch provides driver for the device.

Signed-off-by: Shlomi Gridish <gridish@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>