aboutsummaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2009-05-19sfc: Remove lro module parameterBen Hutchings
GRO/LRO can be controlled through ethtool so this is unnecessary. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-19myri10ge: update version to 1.5.0-1.415Brice Goglin
Update myri10ge driver version to 1.5.0-1.415. Signed-off-by: Brice Goglin <brice@myri.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-19myri10ge: allow LRO to be enabled via ethtoolBrice Goglin
Allow myri10ge LRO to be enabled/disabled via ethtool (and by the stack for packet forwarding). Signed-off-by: Brice Goglin <brice@myri.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-19ixgbe: Cleanup feature setup code to make the code more readableJesse Brandeburg
This is purely a cleanup patch. This collapses some of the code required when we configure our Tx and Rx feature sets, and makes the code more readable and maintainable. Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-19ixgbe: Change Direct Attach Twinax cable detection for SFP+ NICsPeter P Waskiewicz Jr
The SFF specification for Direct Attach cable detection has now been ratified. Previously, DA cable detect was looking at the Twinaxial bit in byte 9 of the SFP+ EEPROM. The spec now defines active and passive DA cables in byte 8 of the SFP+ EEPROM. This patch changes the cable detection for both 82598 and 82599 SFP+ adapters to conform to the new spec. Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-19ixgbe: Add semaphore access for PHY initialization for 82599Peter P Waskiewicz Jr
The SFP+ NIC (device id 0x10fb) needs a semaphore to serialize PHY access, so our PHY init code must honor that same semaphore. Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-19r8169: allow true forced mode settingfrançois romieu
Due to mostly historic reasons, including a lack of reliability of the link handling (especially with the older 8169), the current r8169 driver emulates forced mode setting by limiting the advertised modes. With this change the driver allows real 10/100 forced mode settings on the 8169 and 8101/8102. Original idea by Vincent Steenhoute. The RTL_GIGA_MAC_VER_03 tweak was extracted from Realtek's r8169 v6.010.00 driver. Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Tested-by: Jean Delvare <jdelvare@suse.de> Cc: Edward Hsu <edward_hsu@realtek.com.tw> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-19r8169: remove useless struct memberfrançois romieu
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Edward Hsu <edward_hsu@realtek.com.tw> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-19ppp: unset IFF_XMIT_DST_RELEASE in ppp_setup()Eric Dumazet
Jarek pointed pppoe can call back dev_queue_xmit(), and might need skb->dst, so its safer to unset IFF_XMIT_DST_RELEASE on ppp devices. Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-18net: release dst entry in dev_hard_start_xmit()Eric Dumazet
One point of contention in high network loads is the dst_release() performed when a transmited skb is freed. This is because NIC tx completion calls dev_kree_skb() long after original call to dev_queue_xmit(skb). CPU cache is cold and the atomic op in dst_release() stalls. On SMP, this is quite visible if one CPU is 100% handling softirqs for a network device, since dst_clone() is done by other cpus, involving cache line ping pongs. It seems right place to release dst is in dev_hard_start_xmit(), for most devices but ones that are virtual, and some exceptions. David Miller suggested to define a new device flag, set in alloc_netdev_mq() (so that most devices set it at init time), and carefuly unset in devices which dont want a NULL skb->dst in their ndo_start_xmit(). List of devices that must clear this flag is : - loopback device, because it calls netif_rx() and quoting Patrick : "ip_route_input() doesn't accept loopback addresses, so loopback packets already need to have a dst_entry attached." - appletalk/ipddp.c : needs skb->dst in its xmit function - And all devices that call again dev_queue_xmit() from their xmit function (as some classifiers need skb->dst) : bonding, vlan, macvlan, eql, ifb, hdlc_fr Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-18net: FIX bonding sysfs rtnl_lock deadlockEric W. Biederman
Sysfs files for a network device can not unconditionally take the rtnl_lock as the bonding sysfs files do. If someone accesses those sysfs files while the network device is being unregistered with the rtnl_lock held we will deadlock. So use trylock and restart_syscall to avoid this problem. Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-18netxen: fix msi irq setupDhananjay Phadke
The pdev->irq was not saved in netxen_adapter, causing request_irq() with invalid irq number. This was broken in commit be339aee634d5cb98a8df8d6febe04002ec497f3 ("netxen: fix irq tear down and msix leak."). Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-18Merge branch 'master' of ↵David S. Miller
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 Conflicts: drivers/scsi/fcoe/fcoe.c
2009-05-18The patch adds support for the PCI cards: PCIcan and PCIcanx (1, 2 or 4 ↵Wolfgang Grandegger
channel) from Kvaser (http://www.kvaser.com). Signed-off-by: Per Dalen <per.dalen@cnw.se> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-18can: SJA1000 driver for EMS PCI cardsWolfgang Grandegger
The patch adds support for the one or two channel CPC-PCI and CPC-PCIe cards from EMS Dr. Thomas Wuensche (http://www.ems-wuensche.de). Signed-off-by: Sebastian Haas <haas@ems-wuensche.com> Signed-off-by: Markus Plessing <plessing@ems-wuensche.com> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-18can: SJA1000 generic platform bus driverWolfgang Grandegger
This driver adds support for the SJA1000 chips connected to the "platform bus", which can be found on various embedded systems. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-18can: Driver for the SJA1000 CAN controllerWolfgang Grandegger
This patch adds the generic Socket-CAN driver for the Philips SJA1000 full CAN controller. Signed-off-by: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-18can: CAN Network device driver and Netlink interfaceWolfgang Grandegger
The CAN network device driver interface provides a generic interface to setup, configure and monitor CAN network devices. It exports a set of common data structures and functions, which all real CAN network device drivers should use. Please have a look to the SJA1000 or MSCAN driver to understand how to use them. The name of the module is can-dev.ko. Furthermore, it adds a Netlink interface allowing to configure the CAN device using the program "ip" from the iproute2 utility suite. For further information please check "Documentation/networking/can.txt" Signed-off-by: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-18be2net: add two new pci device ids to pci device tableAjit Khaparde
Signed-off-by: Ajit Khaparde <ajitk@serverengines.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-18net: Add TI DaVinci EMAC driverAnant Gole
Add support for TI DaVinci EMAC driver. TI DaVinci Ethernet Media Access Controller module is based upon TI CPPI 3.0 DMA engine and supports 10/100 Mbps on all and Gigabit modes on some TI devices. It supports MII/RMII and has up to 8Kbytes of internal descriptor memory. This driver has been working on several TI devices including DM644x, DM646x and DA830 platforms. The specs of this device are available at: http://www.ti.com/litv/pdf/sprue24a Signed-off-by: Anant Gole <anantgole@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Chaithrika U S <chaithrika@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-18ixgbe: Increase the driver version numberPeter P Waskiewicz Jr
Marching along, let's bump the version number to indicate things actually have happened to the driver. Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-18ixgbe: Add generic XAUI support to 82599Peter P Waskiewicz Jr
This patch adds the generic XAUI device support for 82599 controllers. Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-18ixgbe: set max desc to prevent total RSC packet size of 64KAlexander Duyck
The performance of hardware RSC is greatly reduced if the total for max rsc descriptors multiplied by the buffer size is greater than 65535. To prevent this we need to adjust the max rsc descriptors appropriately. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-18Merge branch 'master' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6
2009-05-17Neterion: *FIFO1_DMA_ERR set twice, should 2nd be *FIFO2_DMA_ERR?roel kluin
FIFO1_DMA_ERR is set twice, the second should be FIFO2_DMA_ERR. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Acked-by: Ram Vepa <ram.vepa@neterion.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17mv643xx_eth: fix PPC DMA breakageGabriel Paubert
After 2.6.29, PPC no more admits passing NULL to the dev parameter of the DMA API. The result is a BUG followed by solid lock-up when the mv643xx_eth driver brings an interface up. The following patch makes the driver work on my Pegasos again; it is mostly a search and replace of NULL by mp->dev->dev.parent in dma allocation/freeing/mapping/unmapping functions. Signed-off-by: Gabriel Paubert <paubert@iram.es> Acked-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17bonding: fix link down handling in 802.3ad modeStephen Hemminger
One of the purposes of bonding is to allow for redundant links, and failover correctly if the cable is pulled. If all the members of a bonded device have no carrier present, the bonded device itself needs to report no carrier present to user space so management tools (like routing daemons) can respond. Bonding in 802.3ad mode does not work correctly for this because it incorrectly chooses a link that is down as a possible aggregator. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17Merge branch 'linux-2.6.30.y' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax
2009-05-17NET: Meth: Fix unsafe mix of irq and non-irq spinlocks.Ralf Baechle
Mixing of normal and irq spinlocks results in the following lockdep messages on bootup on IP32: [...] Sending DHCP requests . ====================================================== [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ] 2.6.30-rc5-00164-g41baeef #30 ------------------------------------------------------ swapper/1 [HC0[0]:SC0[1]:HE0:SE0] is trying to acquire: (&priv->meth_lock){+.+...}, at: [<ffffffff8026388c>] meth_tx+0x48/0x43c and this task is already holding: (_xmit_ETHER#2){+.-...}, at: [<ffffffff802d3a00>] __qdisc_run+0x118/0x30c which would create a new lock dependency: (_xmit_ETHER#2){+.-...} -> (&priv->meth_lock){+.+...} but this new dependency connects a SOFTIRQ-irq-safe lock: (_xmit_ETHER#2){+.-...} ... which became SOFTIRQ-irq-safe at: [<ffffffff80061458>] __lock_acquire+0x784/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff802d2b88>] dev_watchdog+0x70/0x398 [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248 [<ffffffff8003da5c>] __do_softirq+0xec/0x208 [<ffffffff8003dbd8>] do_softirq+0x60/0xe4 [<ffffffff8003dda0>] irq_exit+0x54/0x9c [<ffffffff80004420>] ret_from_irq+0x0/0x4 [<ffffffff80004720>] r4k_wait+0x20/0x40 [<ffffffff80015418>] cpu_idle+0x30/0x60 [<ffffffff804cd934>] start_kernel+0x3ec/0x404 to a SOFTIRQ-irq-unsafe lock: (&priv->meth_lock){+.+...} ... which became SOFTIRQ-irq-unsafe at: ... [<ffffffff800614f8>] __lock_acquire+0x824/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff80263f20>] meth_reset+0x118/0x2d8 [<ffffffff8026424c>] meth_open+0x28/0x140 [<ffffffff802c1ae8>] dev_open+0xe0/0x18c [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4 [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28 [<ffffffff80012e68>] do_one_initcall+0x58/0x170 [<ffffffff804cd190>] kernel_init+0x98/0x104 [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18 other info that might help us debug this: 2 locks held by swapper/1: #0: (rcu_read_lock){.+.+..}, at: [<ffffffff802c0954>] dev_queue_xmit+0x1e0/0x4b0 #1: (_xmit_ETHER#2){+.-...}, at: [<ffffffff802d3a00>] __qdisc_run+0x118/0x30c the SOFTIRQ-irq-safe lock's dependencies: -> (_xmit_ETHER#2){+.-...} ops: 0 { HARDIRQ-ON-W at: [<ffffffff800614d0>] __lock_acquire+0x7fc/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff802d2b88>] dev_watchdog+0x70/0x398 [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248 [<ffffffff8003da5c>] __do_softirq+0xec/0x208 [<ffffffff8003dbd8>] do_softirq+0x60/0xe4 [<ffffffff8003dda0>] irq_exit+0x54/0x9c [<ffffffff80004420>] ret_from_irq+0x0/0x4 [<ffffffff80004720>] r4k_wait+0x20/0x40 [<ffffffff80015418>] cpu_idle+0x30/0x60 [<ffffffff804cd934>] start_kernel+0x3ec/0x404 IN-SOFTIRQ-W at: [<ffffffff80061458>] __lock_acquire+0x784/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff802d2b88>] dev_watchdog+0x70/0x398 [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248 [<ffffffff8003da5c>] __do_softirq+0xec/0x208 [<ffffffff8003dbd8>] do_softirq+0x60/0xe4 [<ffffffff8003dda0>] irq_exit+0x54/0x9c [<ffffffff80004420>] ret_from_irq+0x0/0x4 [<ffffffff80004720>] r4k_wait+0x20/0x40 [<ffffffff80015418>] cpu_idle+0x30/0x60 [<ffffffff804cd934>] start_kernel+0x3ec/0x404 INITIAL USE at: [<ffffffff80061570>] __lock_acquire+0x89c/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff802d2b88>] dev_watchdog+0x70/0x398 [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248 [<ffffffff8003da5c>] __do_softirq+0xec/0x208 [<ffffffff8003dbd8>] do_softirq+0x60/0xe4 [<ffffffff8003dda0>] irq_exit+0x54/0x9c [<ffffffff80004420>] ret_from_irq+0x0/0x4 [<ffffffff80004720>] r4k_wait+0x20/0x40 [<ffffffff80015418>] cpu_idle+0x30/0x60 [<ffffffff804cd934>] start_kernel+0x3ec/0x404 } ... key at: [<ffffffff80cf93f0>] netdev_xmit_lock_key+0x8/0x1c8 the SOFTIRQ-irq-unsafe lock's dependencies: -> (&priv->meth_lock){+.+...} ops: 0 { HARDIRQ-ON-W at: [<ffffffff800614d0>] __lock_acquire+0x7fc/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff80263f20>] meth_reset+0x118/0x2d8 [<ffffffff8026424c>] meth_open+0x28/0x140 [<ffffffff802c1ae8>] dev_open+0xe0/0x18c [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4 [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28 [<ffffffff80012e68>] do_one_initcall+0x58/0x170 [<ffffffff804cd190>] kernel_init+0x98/0x104 [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18 SOFTIRQ-ON-W at: [<ffffffff800614f8>] __lock_acquire+0x824/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff80263f20>] meth_reset+0x118/0x2d8 [<ffffffff8026424c>] meth_open+0x28/0x140 [<ffffffff802c1ae8>] dev_open+0xe0/0x18c [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4 [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28 [<ffffffff80012e68>] do_one_initcall+0x58/0x170 [<ffffffff804cd190>] kernel_init+0x98/0x104 [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18 INITIAL USE at: [<ffffffff80061570>] __lock_acquire+0x89c/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff80263f20>] meth_reset+0x118/0x2d8 [<ffffffff8026424c>] meth_open+0x28/0x140 [<ffffffff802c1ae8>] dev_open+0xe0/0x18c [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4 [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28 [<ffffffff80012e68>] do_one_initcall+0x58/0x170 [<ffffffff804cd190>] kernel_init+0x98/0x104 [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18 } ... key at: [<ffffffff80cf6ce8>] __key.32424+0x0/0x8 stack backtrace: Call Trace: [<ffffffff8000ed0c>] dump_stack+0x8/0x34 [<ffffffff80060b74>] check_usage+0x470/0x4a0 [<ffffffff80060c34>] check_irq_usage+0x90/0x130 [<ffffffff80061f78>] __lock_acquire+0x12a4/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff80012a0c>] _spin_lock_irqsave+0x60/0x84 [<ffffffff8026388c>] meth_tx+0x48/0x43c [<ffffffff802d3a38>] __qdisc_run+0x150/0x30c [<ffffffff802c0aa8>] dev_queue_xmit+0x334/0x4b0 [<ffffffff804e7e6c>] ip_auto_config+0x8d0/0xf28 [<ffffffff80012e68>] do_one_initcall+0x58/0x170 [<ffffffff804cd190>] kernel_init+0x98/0x104 [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18 ..... timed out! IP-Config: Retrying forever (NFS root)... Sending DHCP requests ., OK [...] Fixed by converting all locks to irq locks. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Tested-by: Andrew Randrianasulu <randrik_a@yahoo.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17ixgbe: Don't reset the hardware when switching between LFC and PFCPeter P Waskiewicz Jr
When running in DCB mode, switching between link flow control and priority flow control shouldn't need to reset the hardware. This removes that reset. This also extends the set_all() dcbnl callback to return a value indicating that the HW config changed, however a reset was not required. Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17ixgbe: When in DCB mode with PFC enabled, show LFC is disabledPeter P Waskiewicz Jr
Ethtool should report that link flow control is disabled when in priority flow control mode. Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17ixgbe: Allow link flow control in DCB mode for 82599 adaptersPeter P Waskiewicz Jr
82599 supports using either link flow control or priority flow control when in DCB mode. The dcbnl interface already supports sending down configurations through rtnetlink that can enable LFC when DCB is enabled, so the driver should take advantage of this. 82598 does not support using LFC when DCB is enabled, so explicitly disable it when we're in DCB mode. This means we always run in PFC mode when DCB is enabled. Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17ixgbe: Set Priority Flow Control low water threshhold for DCBPeter P Waskiewicz Jr
This sets the low water threshhold for priority flow control for 82598 and 82599 controllers in DCB mode. Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17ixgbe: Enable jumbo frame for FCoE feature in 82599Yi Zou
Enable jumbo frame when FCoE feature is enabled in 82599. Use 3K as the receive queue buffer size for receive queues used by FCoE to address for max Fiber Channel frame size as 2148 bytes (with max 2112 bytes of payload). Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17ixgbe: Enable FCoE redirection table feature in 82599Yi Zou
Enable using FCoE redirection table feature in 82599. The FCoE redirection table has maximum of eight entries, corresponding to maximum of eight receive queues to be used for distributing incoming FCoE packets. This patch sets up the FCoE redirection table when multiple receive queues are available for FCoE. Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17ixgbe: Add RING_F_FCOE for FCoE feature in 82599Yi Zou
Add ring feature for FCoE to make use of the FCoE redirection table in 82599. The FCoE redirection table is a receive side scaling feature for Fiber Channel over Ethernet feature in 82599, enabling distributing FCoE packets to different receive queues based on the exchange id. Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17ixgbe: Add SAN MAC address to the RAR, return the address to DCBWaskiewicz Jr, Peter P
After acquiring the SAN MAC address from the EEPROM, we need to program it into one of the RARs. Also, DCB will use this MAC address to run DCBX commands, so it doesn't have to play musical MAC addresses when things like bonding enter the picture. So we need to return the MAC address through the netlink interface to userspace. This also moves the init_rx_addrs() call out of start_hw() and into reset_hw(). We shouldn't try to read any of the RAR information before initializing our internal accounting of the RAR table, which was what was happening. Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17ixgbe: Add FCoE Storage MAC Address supportPJ Waskiewicz
This patch implements the Storage Address entrypoint from the net device. It will read the SAN MAC addresses from the EEPROM of the 82599 hardware, and make them available to the FCoE stack through the net device. Also, add/del the SAN MAC address to the netdev dev_addr_list via the kernel api dev_addr_add()/dev_addr_del() when there is a valid SAN MAC supported by the HW. Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17skfddi: convert PRINTK() to pr_debug()Alexander Beregalov
Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17mac89x0: remove PRINTK()Alexander Beregalov
There are no users of it. Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17de620: convert PRINTK() to pr_debug() and cleanupAlexander Beregalov
Also remove DE620_DEBUG and de620_debug. Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17de600: convert PRINTK() to pr_debug()Alexander Beregalov
Also remove de600_debug as it is not needed. Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17de620: fix forgotten semicolonAlexander Beregalov
It seems it always was here. Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17drivers/net: Convert #ifdef DEBUG printk(KERN_DEBUG to pr_debug(Joe Perches
Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17sfc: Use generic XENPAK register definitionsBen Hutchings
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17smsc95xx: strip ethernet fcs (crc) on receive pathPeter Korsgaard
The smsc95xx driver was forwarding the trailing fcs on received frames up the stack leading to confusion in tcpdump. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> Tested-by: Steve Glendinning <steve.glendinning@smsc.com> Acked-by: Steve Glendinning <steve.glendinning@smsc.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17dm9601: trivial comment fixesPeter Korsgaard
The comments describing the rx/tx headers used a combination of zero- and 1-based indexing, leading to confusion. Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17net: tx scalability works : trans_startEric Dumazet
struct net_device trans_start field is a hot spot on SMP and high performance devices, particularly multi queues ones, because every transmitter dirties it. Is main use is tx watchdog and bonding alive checks. But as most devices dont use NETIF_F_LLTX, we have to lock a netdev_queue before calling their ndo_start_xmit(). So it makes sense to move trans_start from net_device to netdev_queue. Its update will occur on a already present (and in exclusive state) cache line, for free. We can do this transition smoothly. An old driver continue to update dev->trans_start, while an updated one updates txq->trans_start. Further patches could also put tx_bytes/tx_packets counters in netdev_queue to avoid dirtying dev->stats (vlan device comes to mind) Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17mlx4_en: Fix not deleted napi structuresYevgeny Petrilin
Napi structures are being created each time we open a port, but when the port is closed the napi structure is only disabled but not removed. This bug caused hang while removing the driver. Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-05-17bnx2: bnx2_tx_int() optimizationsEric Dumazet
When using bnx2 in a high transmit load, bnx2_tx_int() cost is pretty high. There are two reasons. One is an expensive call to bnx2_get_hw_tx_cons(bnapi) for each freed skb One is cpu stalls when accessing skb_is_gso(skb) / skb_shinfo(skb)->nr_frags because of two cache line misses. (One to get skb->end/head to compute skb_shinfo(skb), one to get is_gso/nr_frags) This patch : 1) avoids calling bnx2_get_hw_tx_cons(bnapi) too many times. 2) makes bnx2_start_xmit() cache is_gso & nr_frags into sw_tx_bd descriptor. This uses a litle bit more ram (256 longs per device on x86), but helps a lot. 3) uses a prefetch(&skb->end) to speedup dev_kfree_skb(), bringing cache line that will be needed in skb_release_data() result is 5 % bandwidth increase in benchmarks, involving UDP or TCP receive & transmits, when a cpu is dedicated to ksoftirqd for bnx2. bnx2_tx_int going from 3.33 % cpu to 0.5 % cpu in oprofile Note : skb_dma_unmap() still very expensive but this is for another patch, not related to bnx2 (2.9 % of cpu, while it does nothing on x86_32) Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-19 22:28:19 +0000