Commit Graph

3 Commits

Author SHA1 Message Date
Jiri Slaby
edee39321b NET: ksz884x, fix lock imbalance
Stanse found that one error path (when alloc_skb fails) in netdev_tx
omits to unlock hw_priv->hwlock. Fix that.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Tristram Ha <Tristram.Ha@micrel.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-03-16 14:15:41 -07:00
Jiri Pirko
f9dcbcc9e3 net: convert multiple drivers to use netdev_for_each_mc_addr, part5 V2
removed some needless checks and also corrected bug in lp486e (dmi was passed
instead of dmi->dmi_addr)

Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-02-26 02:07:30 -08:00
Tristram Ha
8ca86fd83e net: Micrel KSZ8841/2 PCI Ethernet driver
This is a new network driver for Micrel KSZ8841/KSZ8842 PCI Ethernet chips.  The same driver can run both chips at the same time.  It supports IPv4 TCP hardware checksumming and so can use scatter/gather transmission.

The KSZ8842 switch has 2 ports.  Some users like to take direct control of those ports.  So KSZ8842 has a multiple devices mode in which the driver creates another network device so that users can specify which port to send packets.  This mode is enabled by passing the "multi_dev=1" parameter to the driver during loading.

The KSZ884X can receive huge frames with size up to 1916 bytes.  To use this feature change the network device MTU from 1500 to 1898.

The KSZ884X driver has 3 packet receive processing functions for the normal mode, multiple devices mode, and huge frame mode.  Those functions are identical except for more checking for the new features.  In normal programming point of view the huge frame version is the one to use because it covers all the cases, but this is done for performance consideration because the target clients for the KSZ884X chips are embedded systems, which unlike desktop PC may not have powerful CPU.

Signed-off-by: Tristram Ha <Tristram.Ha@micrel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-02-12 12:15:21 -08:00