Bring the physical link down when the interface is down by placing the PHY
in power-down state, unless WOL is enabled. This mirrors the behavior of
other drivers including e1000 and tg3.
Without the patch, ifconfig down leaves the physical link up, which confuses
datacenter users who expect the link lights both on the NIC and the switch to
go out when they bring an interface down.
Furthermore, even though the phy is powered on, autonegotiation stops working,
so a normally gigabit link might suddenly become 100 Mbit half-duplex when the
interface goes down, and become gigabit when it comes up again.
Ayaz said:
I would not include this patch until further testing is performed. NVIDIA
MCP chips use 3rd party PHY vendors. By powering down the phy, it could
have adverse affects on certain phys.
Arthur Jones said:
I just ran across this patch. Tested on a Marvell 88E1121R (GigE PHY)
and works great. This is a very important feature for me.
Signed-off-by: Ed Swierk <eswierk@arastra.com>
Tested-by: Arthur Jones <ajones@riverbed.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch moves neigh_setup and hard_start_xmit into the network device ops
structure. For bisection, fix all the previously converted drivers as well.
Bonding driver took the biggest hit on this.
Added a prefetch of the hard_start_xmit in the fast path to try and reduce
any impact this would have.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Convert this driver to network device ops. Compile tested only.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The generic packet receive code takes care of setting
netdev->last_rx when necessary, for the sake of the
bonding ARP monitor.
Drivers need not do it any more.
Some cases had to be skipped over because the drivers
were making use of the ->last_rx value themselves.
Signed-off-by: David S. Miller <davem@davemloft.net>
This eliminates the following often-generated warning from my 64 bit
Opteron SMP test stand:
eth0: too many iterations (6) in nv_nic_irq
According to the web, the problem is that the forcedeth driver has a
too-low value for max_interrupt_work. Grepping the kernel I see that
forcedeth has the second lowest value of all ethernet drivers (ie, 6).
Most are in the 20-40 range. So this patch increases this a bit, from 6
to 15 (at 15 forcedeth becomes the driver with third-lowest
max_interrupt_work value).
My test stand, which used to print out the above warnings repetitively
whenever it was under heavy net load, no longer does so.
Signed-off-by: Joe Korty <joe.korty@ccur.com>
Cc: Ayaz Abdulla <aabdulla@nvidia.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
This converts pretty much everything to print_mac. There were
a few things that had conflicts which I have just dropped for
now, no harm done.
I've built an allyesconfig with this and looked at the files
that weren't built very carefully, but it's a huge patch.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch will add the phy reset bit into the power up mask which is
used during power up. Certain BIOSes will place the phy in reset and
therefore the driver must take the phy out of reset when it loads.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
after
| commit f735a2a1a4
| Author: Tobias Diedrich <ranma+kernel@tdiedrich.de>
| Date: Sun May 18 15:02:37 2008 +0200
|
| [netdrvr] forcedeth: setup wake-on-lan before shutting down
|
| When hibernating in 'shutdown' mode, after saving the image the suspend hook
| is not called again.
| However, if the device is in promiscous mode, wake-on-lan will not work.
| This adds a shutdown hook to setup wake-on-lan before the final shutdown.
|
| Signed-off-by: Tobias Diedrich <ranma+kernel@tdiedrich.de>
| Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
my servers with nvidia ck804 and mcp55 will reverse mac address with kexec.
it turns out that we need to restore the mac addr in nv_shutdown().
[akpm@linux-foundation.org: fix typo in printk]
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: Tobias Diedrich <ranma+kernel@tdiedrich.de>
Cc: Ayaz Abdulla <aabdulla@nvidia.com>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Fix regression tracked as http://bugzilla.kernel.org/show_bug.cgi?id=11361
and caused by commit f735a2a1a4 ("[netdrvr]
forcedeth: setup wake-on-lan before shutting down") that makes network
adapters integrated into the NVidia MCP55 chipsets fail to work in kexeced
kernels. The problem appears to be that if the adapter is put into D3_hot
during ->shutdown(), it cannot be brought back into D0 after kexec (ref.
http://marc.info/?l=linux-kernel&m=121900062814967&w=4). Therefore, only
put forcedeth into D3 during ->shutdown() if the system is to be powered
off.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Tested-by: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: Ayaz Abdulla <aabdulla@nvidia.com>
Acked-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix the checksum feature advertised in device flags. The hardware support
TCP/UDP over IPv4 and TCP/UDP over IPv6 (without IPv6 extension headers).
However, the kernel feature flags do not distinguish IPv6 with/without
extension headers.
Therefore, the driver needs to use NETIF_F_IP_CSUM instead of
NETIF_F_HW_CSUM since the latter includes all IPv6 packets.
A future patch can be created to check for extension headers and perform
software checksum calculation.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Cc: Jeff Garzik <jgarzik@pobox.com>
Cc: Manfred Spraul <manfred@colorfullife.com
Cc: <stable@kernel.org> [2.6.25.x, 2.6.26.x]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
This patch adds support for limiting the number of tx pause frames to a
default of 8. Previously, hardware would send out continuous stream of
pause frames.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
This patch adds jumbo frame support for MCP79 chipsets.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
This patch adds support for new tx statistic counters in the hardware -
unicast, multicast, and broadcast
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
This patch enforces a stricter policy on rx errors. The driver needs to
verify whether there are multiple rx errors versus a single error.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
This patch adds support for the realtek 8211c phy. The driver must
perform a hardware reset of the phy due to an errata where the phy could
not detect the link.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Add netif_addr_{lock,unlock}{,_bh}() helpers.
Use them to protect operations that operate on or read
the network device unicast and multicast address lists.
Also use them in cases where the code simply wants to
block calls into the driver's ->set_rx_mode() and
->set_multicast_list() methods.
Signed-off-by: David S. Miller <davem@davemloft.net>
After enabling CONFIG_LOCKDEP and CONFIG_PROVE_LOCKING I get the
following warning when ethtool -s is first called on one of the
forcedeth ports:
=================================
[ INFO: inconsistent lock state ]
2.6.26-rc4 #28
---------------------------------
inconsistent {in-hardirq-W} -> {hardirq-on-W} usage.
ethtool/1985 [HC0[0]:SC0[1]:HE1:SE0] takes:
(&np->lock){++..}, at: [<ffffffffa000c5fd>] nv_set_settings+0xc8/0x3de [forcedeth]
{in-hardirq-W} state was registered at:
[<ffffffffffffffff>] 0xffffffffffffffff
irq event stamp: 3606
hardirqs last enabled at (3605): [<ffffffff8068106f>] _spin_unlock_irqrestore+0x3f/0x68
hardirqs last disabled at (3604): [<ffffffff80680d38>] _spin_lock_irqsave+0x13/0x46
softirqs last enabled at (3534): [<ffffffff80246ba5>] __do_softirq+0xbc/0xc5
softirqs last disabled at (3606): [<ffffffff80680b33>] _spin_lock_bh+0x11/0x41
other info that might help us debug this:
2 locks held by ethtool/1985:
#0: (rtnl_mutex){--..}, at: [<ffffffff80596072>] rtnl_lock+0x12/0x14
#1: (_xmit_ETHER){-+..}, at: [<ffffffffa000c5e8>] nv_set_settings+0xb3/0x3de [forcedeth]
stack backtrace:
Pid: 1985, comm: ethtool Not tainted 2.6.26-rc4 #28
Call Trace:
[<ffffffff8025f190>] print_usage_bug+0x162/0x173
[<ffffffff8025fa8b>] mark_lock+0x231/0x41f
[<ffffffff802607cf>] __lock_acquire+0x4e7/0xcac
[<ffffffff8025fe64>] ? trace_hardirqs_on+0xf1/0x115
[<ffffffff80272c3a>] ? disable_irq_nosync+0x6f/0x7b
[<ffffffff80261375>] lock_acquire+0x55/0x6e
[<ffffffffa000c5fd>] ? :forcedeth:nv_set_settings+0xc8/0x3de
[<ffffffff80680b15>] _spin_lock+0x2f/0x3c
[<ffffffffa000c5fd>] :forcedeth:nv_set_settings+0xc8/0x3de
[<ffffffff8058f8bb>] dev_ethtool+0x186/0xea3
[<ffffffff8067f446>] ? mutex_lock_nested+0x243/0x275
[<ffffffff8025df2b>] ? debug_mutex_free_waiter+0x46/0x4a
[<ffffffff8067f469>] ? mutex_lock_nested+0x266/0x275
[<ffffffff8058e1ce>] dev_ioctl+0x4eb/0x600
[<ffffffff8068106f>] ? _spin_unlock_irqrestore+0x3f/0x68
[<ffffffff80580f91>] sock_ioctl+0x1f5/0x202
[<ffffffff802a322e>] vfs_ioctl+0x2a/0x77
[<ffffffff802a34d6>] do_vfs_ioctl+0x25b/0x270
[<ffffffff806807b6>] ? trace_hardirqs_on_thunk+0x35/0x3a
[<ffffffff802a352d>] sys_ioctl+0x42/0x65
[<ffffffff8021fffb>] system_call_after_swapgs+0x7b/0x80
This is caused by the following snippet in nv_set_settings:
netif_carrier_off(dev);
if (netif_running(dev)) {
nv_disable_irq(dev);
netif_tx_lock_bh(dev);
spin_lock(&np->lock);
/* stop engines */
nv_stop_rxtx(dev);
spin_unlock(&np->lock);
netif_tx_unlock_bh(dev);
}
Because of nv_disable_irq this is probably not really a problem
though (I guess) and replacing the spin_lock with spin_lock_irqsave
could keep interrupts disabled for a longer period of time because
of delays in nv_stop_rx and nv_stop_tx.
Signed-off-by: Tobias Diedrich <ranma+kernel@tdiedrich.de>
Cc: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
We currently don't signal the kernel we that this device can wake
the system. Call device_init_wakeup() to correct this.
Without this device_can_wakeup and device_may_wakeup will return
incorrect values.
Together with the minimized acpi wakeup patch (6/4 ;)), which will
follow in the next mail, this really makes wake-on-lan work for me
as expected (i.e. "ethtool -s eth0 wol g" is sufficient, no
additional magic needed).
Signed-off-by: Tobias Diedrich <ranma+kernel@tdiedrich.de>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Add a workaround for lost MSI interrupts. There is a race condition in
the HW in which future interrupts could be missed. The workaround is to
toggle the MSI irq mask.
Added cleanup based on comments from Andrew Morton.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Match the suspend/resume code ordering in e100/e1000e more closely.
For example the configuration space should be saved on suspend even for
devices that are not up.
Signed-off-by: Tobias Diedrich <ranma+kernel@tdiedrich.de>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
The memory mapped device configuration space is lost during hibernate.
Save and restore it (fixes 'swapped mac' problem).
Signed-off-by: TTobias Diedrich <ranma+kernel@tdiedrich.de>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
When hibernating in 'shutdown' mode, after saving the image the suspend hook
is not called again.
However, if the device is in promiscous mode, wake-on-lan will not work.
This adds a shutdown hook to setup wake-on-lan before the final shutdown.
Signed-off-by: Tobias Diedrich <ranma+kernel@tdiedrich.de>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
nv_open() resets multicast settings, call nv_set_multicast(dev)
to restore them. (Maybe this should rather be moved into nv_open())
Signed-off-by: Tobias Diedrich <ranma+kernel@tdiedrich.de>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
This patch fixes an issue seen with the realtek 8201 phy. This phy has a
problem with crossover detection and it needs to be disabled. The
problem only arises on certain switches. Therefore, a module parameter
has been added to allow enabling crossover detection if needed. The
default will be set to disabled.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
This patch adds support for a new backoff algorithm for half duplex supported
in newer hardware. The old method is will be designated as legacy mode.
Re-seeding random values for the backoff algorithms are performed when a
transmit has failed due to a maximum retry count (1 to 15, where max is
considered the wraparound case of 0).
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
* remove changelog from source; its kept in git repository
* consolidate descriptor version tests using nv_optimized()
* consolidate NIC DMA start, stop and drain into
nv_start_txrx(), nv_stop_txrx(), nv_drain_txrx()
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
This critical patch fixes a mac address issue recently introduced. If the
device's mac address was in correct order and the flag
NVREG_TRANSMITPOLL_MAC_ADDR_REV was set, during nv_remove the flag would get
cleared. During next load, the mac address would get reversed because the
flag is missing.
As it has been indicated previously, the flag is cleared across a low power
transition. Therefore, the driver should set the mac address back into the
reversed order when clearing the flag.
Also, the driver should set back the flag after a low power transition to
protect against kexec command calling nv_probe a second time.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Cc: "Yinghai Lu" <yhlu.kernel@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
a) if you initialize something with le32_to_cpu(...), then |= it
with host-endian and feed to cpu_to_le32(), it's most definitely
*not* __le32. As sparse would've told you...
b) the whole sequence is |= cpu_to_le32(host-endian constant)
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
This timer doesn't need to run at precise times, so round it to a whole
second to decrease wakeups.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
This is a critical patch which adds a workaround for a HW bug. The patch
will limit the number of outstanding tx packets to 16. Otherwise, the HW
could send out packets with bad checksums.
The driver will still setup the tx packets into the ring, however, will
only set the Valid bit on 16 packets at a time.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
New chipsets introduced variant Rx FIFO sizes that need to be taken into
account when setting up the tx pause watermarks. This patch introduces
the new device feature flags based on a version and implements the new
watermarks.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
This patch supports a new fix in hardware regarding tx collisions. In
the cases where we are in autoneg mode and the link partner is in forced
mode, we need to setup the tx deferral register differently in order to
reduce collisions on the wire.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Various registers need to be preserved before resetting the device.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
The driver needs to ack only the phy status bits that it is currently
handling and preserve the other bits for the other handlers. For
example, when reading/writing from the phy, it should not clear the link
change interrupt bit. This will cause a missing link change interrupt.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
This patch fixes the issue where the transmitter and receiver must be
restarted when applying new changes to certain registers.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
This patch is a critical fix for MCP77 and MCP79 devices. The feature
flags were missing the define for correct mac address
(DEV_HAS_CORRECT_MACADDR).
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes the case where no multicast addresses are requested to
be added to the multicast filter. The multicast mask must be set to all
1's instead of all 0's.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes the tx pause enable watermark flags. The new values
where determined to be optimal during testing.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch updates the copyright section to include 2007 and 2008.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The driver should inform the stack when checksum has been performed by
the HW when both IP and TCP (or UDP) checksum flags are indicated by HW.
Previously, it would also inform the stack when only IP checksum flag
was indicated by HW. This can cause data corruption when IP fragments
are used. The IP Identification field can wrap around and cause data
from new fragments to fill into older fragment slots with same IP Id.
The stack would then not perform TCP/UDP checksum (after re-assembly of
all fragments) since driver falsely stated it was already calculated.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes the reset register definition from 0x3C to 0x34.
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
* misannotation: struct register_test members are actually host-endian
* bug: cpu_to_le64(n) >> 32 instead of cpu_to_le32(n >> 32) in setting
->bufhigh and similar for ->buflow (take low bits, _then_ convert to
little-endian, not the other way round).
* bug: setup_hw_rings() should not convert to little-endian at all (we
feed the result to writel(), not store in shared data structure), let
alone try to play with shifting and masking little-endian values. Introduced
when setup_hw_rings() went in, screwed both 64bit case and the old code for
32bit rings it had replaced.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
For cards that initially have the MAC address stored in reverse order,
the forcedeth driver uses a flag to signal whether the address was
already corrected, so that it is not reversed again on a subsequent
probe.
Unfortunately this flag, which is stored in a register of the card,
seems to get lost during suspend, resulting in the MAC address being
reversed again. To fix that, the MAC address needs to be written back
in reversed order before we suspend and the flag needs to be reset.
The flag is still required because at least kexec will never write
back the reversed address and thus needs to know what state the card
is in.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix a long boot delay in the forcedeth driver. During initialization, the
timeout for the handshake between mgmt unit and driver can be very long.
The patch reduces the timeout by eliminating a extra loop around the
timeout logic.
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9308
Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
Cc: Alex Howells <astinus@gentoo.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
