USRobotics Wireless Adapter (Model 5423) works well with current
zd1211rw driver also (i have tested 2.6.18, 2.6.20 and 2.6.21-rc7).

It just needs its ID added to the list of devices.
Signed-off-by: NS.Çağlar Onur <caglar@pardus.org.tr>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NMarcel van Nies <morcles@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NMarcel van Nies <morcles@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The MAC address assignment at module loading is simply forgotten.
The bug at module unloading is caused by an incorrect call.

The bug at module unloading does not only happen for sunqe,
sunlance and sunhme (sbus) suffer from it too.

I've tested this on my SS20.
Signed-off-by: NMarcel van Nies <morcles@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This reverts commit 60cba200.  It's been
linked to lockups of the e1000 hardware, see for example

	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603

but it's likely that the commit itself is not really introducing the
bug, but just allowing an unrelated problem to rear its ugly head (ie
one current working theory is that the code exposes us to a hardware
race condition by decreasing the amount of time we spend in each NAPI
poll cycle).

We'll revert it until root cause is known.  Intel has a repeatable
reproduction on two different machines and bus traces of the hardware
doing something bad.
Acked-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Greg KH <gregkh@suse.de>
Cc: Dave Jones <davej@redhat.com>
Cc: Auke Kok <auke-jan.h.kok@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

From: Paul Mackerras <paulus@samba.org>

This fixes:

Subject: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6

process_input_packet() treats the case where the first byte is 0xff
(PPP_ALLSTATIONS) but the second byte is 0x03 (PPP_UI) as indicating a
packet with a PPP protocol number of 0xff.  Arguably that's wrong
since PPP protocol 0xff is reserved, and the RFC does envision the
possibility of receiving frames where the control field has values
other than 0x03.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

The Yukon FE (100mbit only) chips do not support large packets.
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

The Yukon EC Ultra chips have transmit settings for store and
forward and PCI buffering. By setting these appropriately, normal
performance goes from 750Mbytes/sec to 940Mbytes/sec (non-jumbo).

It is also possible to do Jumbo mode, but it means turning off
TSO and checksum offload so the performance gets worse. There isn't
enough buffering for checksum offload to work.
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Need to make sure and disable ASF on all chip types. Otherwise, there may be
random reboots.
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

There should never be descriptor error unless hardware or driver is buggy.
But if an error occurs, print useful information, clear irq, and recover.
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

This device is having all sorts of problems that lead to data corruption
and system instability.  It gets receive status and data out of order,
it generates descriptor and TSO errors, etc.

Until the problems are resolved, it should not be used by anyone
who cares about there system.
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Gianfar needs crc32 to be selected to compile.
Signed-off-by: NDave Jiang <djiang@mvista.com>

--
 drivers/net/Kconfig |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
--
Signed-off-by: NJeff Garzik <jeff@garzik.org>

The basic structure of "normal" UDP/IP/Ethernet
frames (that actually work):
 - It starts with the Ethernet header (dest MAC, src MAC, etc.)
 - The next part is occupied by the IP header (version info, length of
packet, id=0, fragment offset=0, checksum, from / to address, etc.)
 - Then comes the UDP header (src / dest port, length, checksum)
 - Actual payload
 - Ethernet checksum

Now what's different for IP fragment:
 - The IP header has id set to some value (same for all fragments),
offset is set appropriately (i.e. 0 for first fragment, following
according to size of other fragments), size is the length of the frame.
 - UDP header is unchanged. I.e. length is according to full UDP
datagram, not just the part within the actual frame! But this is only
true within the first frame: all following frames don't have a valid
UDP-header at all.

The spidernet silicon seems to be quite intelligent: It's able to
compute (IP / UDP / Ethernet) checksums on the fly and tests if frames
are conforming to RFC -- at least conforming to RFC on complete frames.

But IP fragments are different as explained above:
I.e. for IP fragments containing part of a UDP datagram it sees
incompatible length in the headers for IP and UDP in the first frame
and, thus, skips this frame. But the content *is* correct for IP
fragments. For all following frames it finds (most probably) no valid
UDP header at all. But this *is* also correct for IP fragments.

The Linux IP-stack seems to be clever in this point. It expects the
spidernet to calculate the checksum (since the module claims to be able
to do so) and marks the skb's for "normal" frames accordingly
(ip_summed set to CHECKSUM_HW).
But for the IP fragments it does not expect the driver to be capable to
handle the frames appropriately. Thus all checksums are allready
computed. This is also flaged within the skb (ip_summed set to
CHECKSUM_NONE).

Unfortunately the spidernet driver ignores that hints. It tries to send
the IP fragments of UDP datagrams as normal UDP/IP frames. Since they
have different structure the silicon detects them the be not
"well-formed" and skips them.

The following one-liner against 2.6.21-rc2 changes this behavior. If the
IP-stack claims to have done the checksumming, the driver should not
try to checksum (and analyze) the frame but send it as is.
Signed-off-by: NNorbert Eicker <n.eicker@fz-juelich.de>
Signed-off-by: NLinas Vepstas <linas@austin.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Remove assumption that PHY interrupts use GPIOs 3 and 5.
Deal with PHY interrupts connected to any GPIO pins.
Signed-off-by: NDivy Le Ray <divy@chelsio.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Reuse the incoming skb when a clientless abort req is recieved.

The release of RDMA connections HW resources might be deferred in
low memory situations.
Ensure that no further activity is passed up to the RDMA driver
for these connections.
Signed-off-by: NDivy Le Ray <divy@chelsio.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Update the myri10ge driver version number to 1.3.0-1.233.
Signed-off-by: NBrice Goglin <brice@myri.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Add the Intel 5000 southbridge (aka Intel 6310/6311/6321ESB) PCIe ports
and the Intel E30x0 chipsets to the whitelist of aligned PCIe completion.
Signed-off-by: NBrice Goglin <brice@myri.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Simpler way of dealing with the firmware 4KB boundary crossing
restriction for rx buffers.  This fixes a variety of memory
corruption issues when using an "uncommon" MTU with a 16KB
page size.
Signed-off-by: NBrice Goglin <brice@myri.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Remove specific CPL handler.
Add missing CPL handler.
Add missing register setting when the interface is brought up.
Signed-off-by: NDivy Le Ray <divy@chelsio.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

The MAC watchdog was failing if the peer interface was brought down.
Signed-off-by: NDivy Le Ray <divy@chelsio.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Fix a deadlock when the interface s configured down and
the watchdog tack is sleeping on rtnl_lock.
Signed-off-by: NDivy Le Ray <divy@chelsio.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Need to rework wake on lan code to setup properly and get activated
on shutdown (and suspend), not when ethtool is run.

This does not need to go to stable queue because wake on lan
was not even included in 2.6.20 (or earlier versions).
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

The workaround Yukon EC-U wasn't comparing with correct
version and wasn't doing correct setup. Without it, 88e8056
throws all sorts of errors.
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Some of these chips are disabled until clock is enabled.
This fixes:
     http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=404107Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Driver needs to turn off carrier when down.
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Driver needs to turn off carrier when down, otherwise it can
confuse bonding and bridging and looks like carrier is on immediately
when it is brought back up.
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

The specifications for loopback_gain calculation and for G PHY
initialization have been updated. This patch implements them and
fixes a machine check error that occurs for PPC architecture with a
phy->rev of 1.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

In 802.11b/g mode, bcm43xx actively scans channels 1-14 no matter what
locale has been set, either in the sprom or by the locale option. This
behaviorviolates regulatory rules everywhere in the world except
Japan. This patch changes the default range to the correct value if the
locale has been set, and to channels 1-13 if no locale has been set.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Due to conflicting/confusing defines in the vendor driver, we were
reading E2P_PHY_REG from the wrong location.

CR157 patching was slightly incorrect in that the vendor driver only
patches in an 8-bit value, whereas we were patching 24 bits.

Additionally, CR157 patching was happening on both zd1211 and zd1211b,
but this should only happen on zd1211.
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NUlrich Kunitz <kune@deine-taler.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

zd1211rw currently detects AL2230S-based devices as AL2230, and hence
programs the RF incorrectly. Transmit silently fails on this
misconfiguration.

After this patch, AL2230S devices are rejected with an error message, to
avoid any confusion with an apparent driver bug.
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The spin_lock calls made in dev->open and dev->close must disable
BH since open/close are made in process context.  Conversely, the
call in dev->hard_start_xmit does not need to disable BH since it
is already executing with BH disabled.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The driver will crash when the chip has been initialized by EFI before
tg3_init_one().  In this case, the driver will call tg3_chip_reset()
before allocating consistent memory.

The bug is fixed by checking for tp->hw_status before accessing it
during tg3_chip_reset().
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The PM hooks are no-op if the r8169 interface is down (i.e. !IFF_UP).
However, as the chipset is enabled, the device will not work after a
suspend/resume cycle. The patch always issue the required PCI suspend
sequence and removes the module unload/reload workaround.
Signed-off-by: NArnaud Patard <apatard@mandriva.com>
Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

The irq handler schedules a NAPI poll request unconditionally as soon as
the status register is not clean. It has been there - and wrong - for
ages but a recent timing change made it apparently easier to trigger.
Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
Cc: Jay Cliburn <jacliburn@bellsouth.net>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

If you set the IFF_ALLMULTI flag on a b44 device, or if you join more than
B44_MCAST_TABLE_SIZE multicast groups, the device will stop receiving unicast
messages.  This is because the __b44_set_mac_addr call sets the zeroth CAM
entry to the MAC address of the device, and then the loop at line 1722
proceeds to overwrite it unless the value of i is set by the __b44_load_mcast
call.  However, when IFF_ALLMULTI is set, that call is bypassed, leaving i set
to zero.

Fixed by starting the loop at 1 to make it skip the CAM entry for the MAC
address.
Signed-off-by: NBill Helfinstine <bhelf@flitterfly.whirpon.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Introduce FW micro version.
Bump up FW version to 3.3.0
Signed-off-by: NDivy Le Ray <divy@chelsio.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Run the watchdog task when the link is up.
Flush the XGMAC Tx FIFO when the link drops.

Also remove a statistics update that should have gone
in the previous modification of xgmac.c.
Signed-off-by: NDivy Le Ray <divy@chelsio.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Differentiate NIC only adapters from RNICs.
Initialize offload capabilities for RNICs only.
Signed-off-by: NDivy Le Ray <divy@chelsio.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Ensure that the TCAM active region size is at least 16.
Signed-off-by: NDivy Le Ray <divy@chelsio.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>