Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NJeff 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 d55b53ff
("igb/ixgbe/e1000e: resolve tx multiqueue bug").)
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Acked-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid 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: NPatrick McHardy <kaber@trash.net>
Acked-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: NDavid 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: NPatrick McHardy <kaber@trash.net>
Acked-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: NDavid 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: NPatrick McHardy <kaber@trash.net>
Acked-by: NJeff Garzik <jgarzik@redhat.com>
Signed-off-by: NDavid 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: NAndy Gospodarek <andy@greyhouse.net>
Signed-off-by: NJeff 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: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Conglomerate from 4 separate patches from Joe.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff 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: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff 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: NJoe Perches <joe@perches.com>
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff 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: NAuke Kok <auke-jan.h.kok@intel.com>
Acked-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NJeff 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: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
--

 drivers/net/e1000/e1000_main.c |   18 +++++-------------
 1 file changed, 5 insertions(+), 13 deletions(-)
Signed-off-by: NJeff Garzik <jeff@garzik.org>

This patch makes the needlessly global e1000_dump_eeprom() static.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
Signed-off-by: NDavid 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: NJeff Garzik <jeff@garzik.org>
Signed-off-by: NLinus 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: NLinus 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: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NJeff 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: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NDavid 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: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NDavid 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: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff 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: NDavid S. Miller <davem@davemloft.net>

This fixes a regression added by changeset
53e52c72 ("[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: NDavid S. Miller <davem@davemloft.net>
Acked-by: NJesse 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: NDavid S. Miller <davem@davemloft.net>
Acked-by: NAuke 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: NDavid 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: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff 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: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NDavid 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: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Signed-off-by: NMasatake YAMATO <jet@gyve.org>
Signed-off-by: NAdrian Bunk <bunk@kernel.org>

Some simple optimizations in e1000_xmit_frame.
Signed-off-by: NKrishna Kumar <krkumar2@in.ibm.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

These driver changes incorporate the proposed PCI-X / PCI-Express read byte
count interface.  Reading and setting those valuse doesn't take place
"manually", instead wrapping functions are called to allow quirks for some
PCI bridges.

Signed-off by: Peter Oruba <peter.oruba@amd.com>
Based on work by Stephen Hemminger <shemminger@linux-foundation.org>
Acked-by: NAuke Kok <auke-jan.h.kok@intel.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

This is nicer than the MAC_FMT stuff.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NRalf Baechle <ralf@linux-mips.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Several devices have multiple independant RX queues per net
device, and some have a single interrupt doorbell for several
queues.

In either case, it's easier to support layouts like that if the
structure representing the poll is independant from the net
device itself.

The signature of the ->poll() call back goes from:

	int foo_poll(struct net_device *dev, int *budget)

to

	int foo_poll(struct napi_struct *napi, int budget)

The caller is returned the number of RX packets processed (or
the number of "NAPI credits" consumed if you want to get
abstract).  The callee no longer messes around bumping
dev->quota, *budget, etc. because that is all handled in the
caller upon return.

The napi_struct is to be embedded in the device driver private data
structures.

Furthermore, it is the driver's responsibility to disable all NAPI
instances in it's ->stop() device close handler.  Since the
napi_struct is privatized into the driver's private data structures,
only the driver knows how to get at all of the napi_struct instances
it may have per-device.

With lots of help and suggestions from Rusty Russell, Roland Dreier,
Michael Chan, Jeff Garzik, and Jamal Hadi Salim.

Bug fixes from Thomas Graf, Roland Dreier, Peter Zijlstra,
Joseph Fannin, Scott Wood, Hans J. Koch, and Michael Chan.

[ Ported to current tree and all drivers converted.  Integrated
  Stephen's follow-on kerneldoc additions, and restored poll_list
  handling to the old style to fix mutual exclusion issues.  -DaveM ]
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This blade-specific board form factor is identical to the 82571EB
board.
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

This patch adds support for 2 new board variants:
- A Quad port fiber 82571 board
- A blade version of the 82571 quad copper board
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Instead of all drivers reading pci config space to get the revision
ID, they can now use the pci_device->revision member.

This exposes some issues where drivers where reading a word or a dword
for the revision number, and adding useless error-handling around the
read. Some drivers even just read it for no purpose of all.

In devices where the revision ID is being copied over and used in what
appears to be the equivalent of hotpath, I have left the copy code
and the cached copy as not to influence the driver's performance.

Compile tested with make all{yes,mod}config on x86_64 and i386.
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Acked-by: NDave Jones <davej@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

To assure the symmetry of poll enable/disable in up/down, we should
initialize the netdevice to be poll_disabled at load time. Doing
this after register_netdevice leaves us open to another race, so
lets move all the netif_* calls above register_netdevice so the
stack starts out how we expect it to be.
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Doug Chapman <doug.chapman@hp.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

This restores the previously removed netif_poll_enable call in e1000_open.
It's needed on all but the first call to e1000_open for a NIC as
e1000_close always calls netif_poll_disable.

netif_poll_enable can only be called safely if no polls have been
scheduled.  This should be the case as long as we don't enter our IRQ
handler.

In order to guarantee this we explicitly disable IRQs as early as possible
when we're probing the NIC.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Cc: "Kok, Auke" <auke-jan.h.kok@intel.com>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Herbert Xu wrote:
"netif_poll_enable can only be called if you've previously called
netif_poll_disable.  Otherwise a poll might already be in action
and you may get a crash like this."

Removing the call to netif_poll_enable in e1000_open should fix this issue,
the only other call to netif_poll_enable is in e1000_up() which is only
reached after a device reset or resume.

Bugzilla: http://bugzilla.kernel.org/show_bug.cgi?id=8455
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240339

Tested by Doug Chapman <doug.chapman@hp.com>
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJeff Garzik <jeff@garzik.org>