linux-toradex.git/drivers/net/ibm_emac, branch master

ibm_emac: Remove the ibm_emac driver

2008-06-18T03:59:01+00:00

The arch/ppc sub-tree has been removed in the powerpc git tree.  The old
ibm_emac driver is no longer used by anything as a result of this.  This
removes it, leaving the ibm_newemac driver as the proper driver to use for
PowerPC boards with the EMAC hardware.

Signed-off-by: Josh Boyer 
Signed-off-by: Jeff Garzik

Add dcr_host_t.base in dcr_read()/dcr_write()

2007-10-15T18:29:49+00:00

Now that all users of dcr_read()/dcr_write() add the dcr_host_t.base, we
can save them the trouble and do it in dcr_read()/dcr_write().

As some background to why we just went through all this jiggery-pokery,
benh sayeth:

 Initially the goal of the dcr_read/dcr_write routines was to operate like
 mfdcr/mtdcr which take absolute DCR numbers. The reason is that on 4xx
 hardware, indirect DCR access is a pain (goes through a table of
 instructions) and it's useful to have the compiler resolve an absolute DCR
 inline.

 We decided that wasn't worth the API bastardisation since most places
 where absolute DCR values are used are low level 4xx-only code which may
 as well continue using mfdcr/mtdcr, while the new API is designed for
 device "instances" that can exist on 4xx and Axon type platforms and may
 be located at variable DCR offsets.

Signed-off-by: Michael Ellerman 
Signed-off-by: Jeff Garzik

Use dcr_host_t.base in ibm_emac_mal

2007-10-15T18:29:49+00:00

This requires us to do a sort-of fake dcr_map(), so that base is set
properly. This will be fixed/removed when the device-tree-aware emac driver
is merged.

Signed-off-by: Michael Ellerman 
Signed-off-by: Jeff Garzik

ibm_emac: Convert to use napi_struct independent of struct net_device

2007-10-10T23:55:31+00:00

Commit da3dedd9 ("[NET]: Make NAPI polling independent of struct
net_device objects.") changed the interface to NAPI polling.  Fix up
the ibm_emac driver so that it works with this new interface.  This is
actually a nice cleanup because ibm_emac is one of the drivers that
wants to have multiple NAPI structures for a single net_device.

Tested with the internal MAC of a PowerPC 440SPe SoC with an AMCC
'Yucca' evaluation board.

Signed-off-by: Roland Dreier 
Signed-off-by: Jeff Garzik

Device tree aware EMAC driver

2007-10-10T23:51:52+00:00

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 
Signed-off-by: Jeff Garzik

[netdrvr] Stop using legacy hooks ->self_test_count, ->get_stats_count

2007-10-10T23:51:45+00:00

These have been superceded by the new ->get_sset_count() hook.

Signed-off-by: Jeff Garzik 
Signed-off-by: David S. Miller

[NET]: Introduce and use print_mac() and DECLARE_MAC_BUF()

2007-10-10T23:51:42+00:00

This is nicer than the MAC_FMT stuff.

Signed-off-by: Joe Perches 
Signed-off-by: David S. Miller

[ETHTOOL] Provide default behaviors for a few ethtool sub-ioctls

2007-10-10T23:51:17+00:00

For the operations
	get-tx-csum
	get-sg
	get-tso
	get-ufo
the default ethtool_op_xxx behavior is fine for all drivers, so we
permit op==NULL to imply the default behavior.

This provides a more uniform behavior across all drivers, eliminating
ethtool(8) "ioctl not supported" errors on older drivers that had
not been updated for the latest sub-ioctls.

The ethtool_op_xxx() functions are left exported, in case anyone
wishes to call them directly from a driver-private implementation --
a not-uncommon case.  Should an ethtool_op_xxx() helper remain unused
for a while, except by net/core/ethtool.c, we can un-export it at a
later date.

[ Resolved conflicts with set/get value ethtool patch... -DaveM ]

Signed-off-by: Jeff Garzik 
Signed-off-by: David S. Miller

drivers/net/: all drivers/net/ cleanup with ARRAY_SIZE

2007-10-10T23:51:15+00:00

Signed-off-by: Denis Cheng 
Signed-off-by: Jeff Garzik

[NET]: Nuke SET_MODULE_OWNER macro.

2007-10-10T23:51:13+00:00

It's been a useless no-op for long enough in 2.6 so I figured it's time to
remove it.  The number of people that could object because they're
maintaining unified 2.4 and 2.6 drivers is probably rather small.

[ Handled drivers added by netdev tree and some missed IRDA cases... -DaveM ]

Signed-off-by: Ralf Baechle 
Signed-off-by: Jeff Garzik 
Signed-off-by: David S. Miller