On machine were no IO ports are assigned the call
to pci_enable_device() will fail, even if need_ioport
is false, we need to use pci_enable_device_mem() here.
Signed-off-by: Karsten Keil <kkeil@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
A nasty bug was found where an MTU change (or anything else that caused a
reset) could race with the interrupt code. The interrupt code was entered
by a shared interrupt during the MTU change.
This change prevents the interrupt code from running while the driver is in
the middle of its reset path.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When the napi api was changed to separate its 1:1 binding to the net_device
struct, the netif_rx_[prep|schedule|complete] api failed to remove the now
vestigual net_device structure parameter. This patch cleans up that api by
properly removing it..
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit bea3348eef
"[NET]: Make NAPI polling independent of struct net_device objects."
made NAPI polling to be independent of net_device.
So e1000_adapter->polling_netdev is no longer used.
Kill it.
Signed-off-by: Wang Chen <wangchen@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The system log messages created on a link status change need to follow a
specific format to work with tools some customers use. This also makes
the messages consistant with other Intel driver link messages.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
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 to new network device ops interface.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since dev->power.should_wakeup bit is used by the PCI core to
decide whether the device should wake up the system from sleep
states, set/unset this bit whenever WOL is enabled/disabled using
e1000_set_wol(). Accordingly, use device_can_wakeup() for checking
if wake-up is supported by the device.
Signed-off-by: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We have some reasons to kill netdev->priv:
1. netdev->priv is equal to netdev_priv().
2. netdev_priv() wraps the calculation of netdev->priv's offset, obviously
netdev_priv() is more flexible than netdev->priv.
But we cann't kill netdev->priv, because so many drivers reference to it
directly.
This patch is a safe convert for netdev->priv to netdev_priv(netdev).
Since all of the netdev->priv is only for read.
But it is too big to be sent in one mail.
I split it to 4 parts and make every part smaller than 100,000 bytes,
which is max size allowed by vger.
Signed-off-by: Wang Chen <wangchen@cn.fujitsu.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>
Use the newly introduced pci_ioremap_bar() function in drivers/net.
pci_ioremap_bar() just takes a pci device and a bar number, with the goal
of making it really hard to get wrong, while also having a central place
to stick sanity checks.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
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 changes e1000 to set vlan_features so TSO and CSUM
offload can be used by VLAN devices, similar as with the other
Intel drivers.
Signed-off-by: Patrick McHardy <kaber@trash.net>
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>
When offloading transmit checksums only, the driver was not
correctly configuring the hardware to handle the case of a zero
checksum. For UDP the correct behavior is to leave it alone, but
for tcp the checksum must be changed from 0x0000 to 0xFFFF. The
hardware takes care of this case but only if it is told the
packet is tcp.
same patch as e1000e
Signed-off-by: Dave Graham <david.graham@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>
Since the e1000/e1000e split, no hardware supported by e1000
supports packet split, just remove the Kconfig option and associated
code from the driver.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
This patch makes e1000 driver ioport-free.
This corrects behavior in probe function so as not to request ioport
resources as long as they are not really needed. This is based on the
ioport-free patch of e1000 driver from Auke Kok and Tomohiro Kusumi.
Signed-off-by: Tomohiro Kusumi <kusumi.tomohiro@jp.fujitsu.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
Signed-off-by: Jeff Kirsher<jeffrey.t.kirsher@intel.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
The email linux-nics@intel.com is no longer available, remove all
references.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Use struct e1000_hw *hw = adapter->hw; where necessary
Change macros E1000_READ_REG and E1000_WRITE_REG to er32 and ew32
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
With the recent changes to tx mutiqueue, e1000 was not calling
netif_start_queue() before calling netif_wake_queue().
This causes an oops during loading of the driver.
(Based on commit d55b53fff0
("igb/ixgbe/e1000e: resolve tx multiqueue bug").)
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently VLAN filtering is enabled when the first VLAN is added.
Obviously before that there's no point in receiving any VLAN packets.
Now that we disable VLAN filtering in promiscous mode, we can keep
the VLAN filters enabled the remaining time.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
As discussed in this thread:
http://www.mail-archive.com/netdev@vger.kernel.org/msg53976.html
promiscous mode means to disable *all* filters. Currently only unicast
and multicast filtering is disabled. This patch changes all Intel
drivers to also disable VLAN filtering.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The vlan_hwaccel_{rx,receive_skb} functions expect the full TCI field
for priority mappings, don't truncate the upper 4 bits.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Acked-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The call to e1000_clean_tx_irq in e1000_netpoll can race with the call
to e1000_clean_tx_irq in e1000_clean. With a small bit of tweaking to
to netpoll_send_skb to simulate a system that was under extreme stress,
I was able to reproduce these concurrent calls. This can result in
multiple frees to the skbs on the tx ring buffer.
Dropping this call from e1000_netpoll should be fine since we can rely
on the calls in e1000_clean to do what is needed since napi will poll
the hardware just after calling poll_controller.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
We do not want to prolong the situation much longer that e1000
and e1000e support these devices at the same time. As a result,
take out the bandage that was added for the interim period
and remove all the PCI Express device IDs from e1000.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Conglomerate from 4 separate patches from Joe.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
irq_sem was just a hack to prevent interrupts from being enabled
unexpectedly in deep call paths. Simply finding those call paths and
fixing them by hand results in a driver that behaves as we expect and
doesn't need the atomic at all.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
On Thu, 2008-03-06 at 10:07 -0800, Kok, Auke wrote:
> send me a patch for e1000 and for ixgb and I'll happily apply those :)
boolean_t to bool
TRUE to true
FALSE to false
comment typo ahread to ahead
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
We're already starting to see reports from users still
using e1000 where they should be using e1000e now that this is
actually possible. Just to prevent some of this thrash, add
a big warning on load on these devices that people should
switch to e1000e.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
The e1000 driver stores the content of the PCI resources into
unsigned long's before ioremapping. This breaks on 32 bits
platforms that support 64 bits MMIO resources such as ppc 44x.
This fixes it by removing those temporary variables and passing
directly the result of pci_resource_start/len to ioremap.
The side effect is that I removed the assignments to the netdev
fields mem_start, mem_end and base_addr, which are totally useless
for PCI devices.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
--
drivers/net/e1000/e1000_main.c | 18 +++++-------------
1 file changed, 5 insertions(+), 13 deletions(-)
Signed-off-by: Jeff Garzik <jeff@garzik.org>
This patch makes the needlessly global e1000_dump_eeprom() static.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Both the old e1000 driver and the new e1000e driver can drive some
PCI-Express e1000 cards, and we should avoid ambiguity about which
driver will pick up the support for those cards when both drivers are
enabled.
This solves the problem by having the old driver support those cards if
the new driver isn't configured, but otherwise ceding support for PCI
Express versions of the e1000 chipset to the newer driver. Thus
allowing both legacy configurations where only the old driver is active
(and handles all chips it knows about) and the new configuration with
the new driver handling the more modern PCIE variants.
Acked-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The new e1000e driver is apparently not yet suitable for general use, so
mark it experimental, and re-instate all the PCI-Express device IDs in
the old and stable e1000 driver so that people (namely me) can continue
to use a driver that actually works.
Auke & co have been appraised of the situation.
Cc: Auke Kok <auke-jan.h.kok@intel.com>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
To help supporting users with a bad eeprom checksum, dump the
eeprom info when such a situation is encountered by a user.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Add support for configuring secondary unicast addresses. Unicast
addresses take precendece over multicast addresses when filling
the exact address filters to avoid going to promiscous mode.
When more unicast addresses are present than filter slots,
unicast filtering is disabled and all slots can be used for
multicast addresses.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
formerly e1000/e1000e only updated traffic counters once every
2 seconds with the register values of bytes/packets. With newer
code however in the interrupt and polling code we can real-time
fill in these values in the netstats struct for users to see.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
e1000e will from now on support the PCI-Express adapters that
previously were supported by e1000. This support means better
performance and easier debugging from now on for both the old
PCI-X/PCI hardware and PCI-Express adapters.
This patch also moves 3 recently merged device IDs over to e1000e
that are identical to quad-port versions of already existing
dual port versions. With this last bit every former e1000 pci-e
device should work now with e1000e.
Here is a brief list of which gigabit driver to use with which
adapter:
e1000:
82540 -> 82547
e1000e:
82571 -> 82573
ich8, ich9 (82562 or 82566)
es2lan (80003eslan)
igb: (not yet merged, only available from e1000.sf.net)
82575
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Several of the Intel ethernet drivers keep an atomic counter used to
manage when to actually hit the hardware with a disable or an enable.
The way the net_rx_work() breakout logic works during a pending
napi_disable() is that it simply unschedules the poll even if it
still has work.
This can potentially leave interrupts disabled, but that is OK
because all of the drivers are about to disable interrupts
anyways in all such code paths that do a napi_disable().
Unfortunately, this trips up the semaphore used here in the Intel
drivers. If you hit this case, when you try to bring the interface
back up it won't enable interrupts. A reload of the driver module
fixes it of course.
So what we do is make sure all the sequences now go:
napi_disable();
atomic_set(&adapter->irq_sem, 0);
*_irq_disable();
which makes sure the counter is always in the correct state.
Reported by Robert Olsson.
Signed-off-by: David S. Miller <davem@davemloft.net>
This fixes a regression added by changeset
53e52c729c ("[NET]: Make ->poll()
breakout consistent in Intel ethernet drivers.")
As pointed out by Jesse Brandeburg, for three of the drivers edited
above there is breakout logic in the *_clean_tx_irq() code to prevent
running TX reclaim forever. If this occurs, we have to elide NAPI
poll completion or else those TX events will never be serviced.
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
This makes the ->poll() routines of the E100, E1000, E1000E, IXGB, and
IXGBE drivers complete ->poll() consistently.
Now they will all break out when the amount of RX work done is less
than 'budget'.
At a later time, we may want put back code to include the TX work as
well (as at least one other NAPI driver does, but by in large NAPI
drivers do not do this). But if so, it should be done consistently
across the board to all of these drivers.
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Auke Kok <auke-jan.h.kok@intel.com>
Drivers do this to try to break out of the ->poll()'ing loop
when the device is being brought administratively down.
Now that we have a napi_disable() "pending" state we are going
to solve that problem generically.
Signed-off-by: David S. Miller <davem@davemloft.net>
Don't exit polling when we have not yet used our budget, this causes
the NAPI system to end up with a messed up poll list.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
mii-tool can cause the driver to call msleep during nway reset,
bugzilla.kernel.org bug 8430. Fix by simply calling reinit_locked
outside of the spinlock, which is safe from ethtool, so it should be
safe from here.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix sparse warnings and problems from e1000 driver.
Added a sparse fix for the module param array index
-- Auke
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
![](/avatar/43508f7a1ec957af441e34aa327a4088?size=56 "\\"Rafael J. Wysocki\"){kind=small}
