When ioatdma was loaded we we were unable to transmit traffic.  We weren't
using the correct registers in ixgbe_update_tx_dca for 82599 systems.
Likewise in ixgbe_configure_tx() we weren't disabling the arbiter before
modifying MTQC.
Signed-off-by: NDon Skidmore <donald.c.skidmore@intel.com>
Acked-by: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When DCB is enabled, the ixgbe_check_tx_hang() should check the corresponding
TC's TXOFF in TFCS based on the TC that the tx ring belongs to. Adds a
function to map from the tx_ring hw reg_idx to the correspodning TC and read
TFCS accordingly.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Acked-by: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The 32k gso_max_size when DCB is enabled is for 82598 only, not for 82599.
Signed-off-by: NYi Zou <yi.zou@intel.com>
Acked-by: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

No-one seems to know where the PowerBook 500 series store their ethernet
MAC addresses. So, rather than crash, use a MAC address from the SONIC
CAM. Failing that, generate a random one.
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Stanse found that one error path in cas_open omits to unlock pm_mutex.
Fix that.
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

CPC-USB is using a ARM7 core with little endian byte order. The "id" field
in can_msg needs byte order conversion from/to CPU byte order.
Signed-off-by: NSebastian Haas <haas@ems-wuensche.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Sending config commands to be2 hardware before netdev_register is
completed, is sometimes causing the async link notification to arrive
even before the driver is ready to handle it. The commands for vlan
config and flow control settings can infact wait till be_open.
This patch takes care of that.
Signed-off-by: NAjit Khaparde <ajitk@serverengines.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If be2 goes into suspend after a user changes the flow control settings,
we are not programming them back after resume. This patch takes care of it.
We now get the flow control settings before going to suspend mode and
then apply them during resume.
Signed-off-by: NAjit Khaparde <ajitk@serverengines.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit v2.6.28-rc1~717^2~109^2~2 was slightly incomplete; not all
instances of par->match->family were changed to par->family.

References: http://bugzilla.netfilter.org/show_bug.cgi?id=610Signed-off-by: NJan Engelhardt <jengelh@medozas.de>
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This prevents the rt2x00 driver from queueing ieee80211 work after the  
USB card has been removed, preventing a kernel panic.
Signed-off-by: NSean Cross <sean@chumby.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reverts commit e6c5fc53.

Based on this regression report:

Date: Thu, 05 Nov 2009 15:59:16 +0100
From: Holger Schurig <holgerschurig@gmail.com>
To: linux-wireless@vger.kernel.org
Subject: BUG: oops when "rmmod ipw2200"

This happened on wireless-testing v2.6.32-rc6-41575-g5e68bfb. I
modprobed ipw2200, put it into monitor mode, used tshark a while to
monitor, then I stopped tshark, "ifconfig eth2 down" and finally
"rmmod ipw2200", and voila:

[  917.189620] ------------[ cut here ]------------
[  917.189717] kernel BUG at net/wireless/core.c:543!
[  917.189805] invalid opcode: 0000 [#1] PREEMPT SMP
[  917.190002] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:02:0d.0/firmware/0000:02:0d.0/loading
[  917.190136] Modules linked in: lib80211_crypt_wep ipw2200(-) libipw lib80211 ath5k mac80211 ath cfg80211 psmouse uhci_hcd
[  917.190680]
[  917.190759] Pid: 1763, comm: rmmod Not tainted (2.6.32-rc6-wl #26) Amilo M1425
[  917.190886] EIP: 0060:[<f8accf34>] EFLAGS: 00010202 CPU: 0
[  917.190992] EIP is at wiphy_unregister+0xd3/0x175 [cfg80211]
[  917.191083] EAX: f601d4c4 EBX: 00000000 ECX: 00000000 EDX: f79e8600
[  917.191176] ESI: f601d400 EDI: f95b4350 EBP: f6009eb4 ESP: f6009e8c
[  917.191269]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[  917.191360] Process rmmod (pid: 1763, ti=f6008000 task=f79e8130 task.ti=f6008000)
[  917.191486] Stack:
[  917.191562]  f601d5a0 f601d484 f6460e98 f6009ea0 c01407ee f6009eb8 00000246 f64604c0
[  917.191916] <0> f6460e5c f95b4350 f6009ec0 f94fd030 f6460e98 f6009edc f95a9d4f f787bc00
[  917.192100] <0> f787bc58 f787bc00 f95b4350 f95b4350 f6009ee8 c0207fca f787bc58 f6009ef8
[  917.192100] Call Trace:
[  917.192100]  [<c01407ee>] ? trace_hardirqs_on+0xb/0xd
[  917.192100]  [<f94fd030>] ? unregister_ieee80211+0xe/0x27 [libipw]
[  917.192100]  [<f95a9d4f>] ? ipw_pci_remove+0x59/0x227 [ipw2200]
[  917.192100]  [<c0207fca>] ? pci_device_remove+0x19/0x39
[  917.192100]  [<c02b93a4>] ? __device_release_driver+0x59/0x9d
[  917.192100]  [<c02b944f>] ? driver_detach+0x67/0x85
[  917.192100]  [<c02b88d6>] ? bus_remove_driver+0x69/0x85
[  917.192100]  [<c02b9878>] ? driver_unregister+0x4d/0x54
[  917.192100]  [<c02081c3>] ? pci_unregister_driver+0x28/0x71
[  917.192100]  [<f95a9cf4>] ? ipw_exit+0x1c/0x1e [ipw2200]
[  917.192100]  [<c0148e2b>] ? sys_delete_module+0x192/0x1ef
[  917.192100]  [<c0162cdb>] ? remove_vma+0x52/0x58
[  917.192100]  [<c01028bb>] ? sysenter_exit+0xf/0x18
[  917.192100]  [<c0102888>] ? sysenter_do_call+0x12/0x36
[  917.192100] Code: 74 07 e8 81 bc 8c c7 eb c8 8d 55 e0 89 f8 e8 d6 6d 66 c7 8b 45 dc 31 d2 e8 81 cc 8c c7 8d 86 c4 00 00 00 39 86 c4 00 00 00 74 04 <0f> 0b eb fe 8b 45 dc 8d 5e 0c e8 5a cc 8c c7 8b 86 94 03 00 00
[  917.192100] EIP: [<f8accf34>] wiphy_unregister+0xd3/0x175 [cfg80211] SS:ESP 0068:f6009e8c
[  917.203718] ---[ end trace bcaaf449945a5100 ]---
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

While working on device refcount stuff, I found a device refcount leak
through DECNET.
This nasty bug can be used to hold refcounts on any !DECNET netdevice.
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Vitezslav Samel discovered that since 2.6.30.4+ active FTP can not work
over NAT. The "cause" of the problem was a fix of unacknowledged data
detection with NAT (commit a3a9f79e).
However, actually, that fix uncovered a long standing bug in TCP conntrack:
when NAT was enabled, we simply updated the max of the right edge of
the segments we have seen (td_end), by the offset NAT produced with
changing IP/port in the data. However, we did not update the other parameter
(td_maxend) which is affected by the NAT offset. Thus that could drift
away from the correct value and thus resulted breaking active FTP.

The patch below fixes the issue by *not* updating the conntrack parameters
from NAT, but instead taking into account the NAT offsets in conntrack in a
consistent way. (Updating from NAT would be more harder and expensive because
it'd need to re-calculate parameters we already calculated in conntrack.)
Signed-off-by: NJozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NSathya Perla <sathyap@serverengines.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

While hunting dev_put() for net-next-2.6, I found a device refcount
leak in ROSE, ioctl(SIOCADDRT) error path.

Fix is to not touch device refcount, as we hold RTNL
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The bridge code assumes ethernet addressing, so be more strict in
the what is allowed. This showed up when GRE had a bug and was not
using correct address format.

Add some more comments for increased clarity.
Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit

	3d1285be (move virtnet_remove to .devexit.text)

introduced the first reference to __devexit in struct virtio_driver
virtio_net which upset modpost ("Section mismatch in reference from the
variable virtio_net to the function .devexit.text:virtnet_remove()").

Fix this by renaming virtio_net to virtio_net_driver.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reported-by: NMichael S. Tsirkin <mst@redhat.com>
Blame-taken-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

As reported by Rick Farina (sidhayn@gmail.com), removing the RTL8187
USB stick, or unloading the driver rtl8187 using rmmod will cause a
kernel oops.  There are at least two forms of the failure, (1) BUG:
Scheduling while atomic, and (2) a fatal kernel page fault. This
problem is reported in Bugzilla #14539.

This problem does not occur for kernel 2.6.31, but does for 2.6.32-rc2,
thus it is technically a regression; however, bisection did not locate
any faulty patch. The fix was found by comparing the faulty code in
rtl8187 with p54usb.  My interpretation is that the handling of work
queues in mac80211 changed enough to the LEDs to be unregistered
before tasks on the work queues are cancelled. Previously, these
actions could be done in either order.

(Herton Ronaldo Krzesinski <herton@mandriva.com.br> reports that the
code is the same in 2.6.31, so this may be a candidate for 2.6.31.x.
-- JWL)
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Reported-by: NRick Farina <sidhayn@gmail.com>
Tested-by: NRick Farina <sidhayn@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add a reference to the the git tree where most
of the forward going network development occurs.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Check whether index is within bounds before testing the element.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Cc: Karsten Keil <isdn@linux-pingi.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The negation makes it a bool before the comparison and hence it
will never be 0x40.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Cc: Karsten Keil <isdn@linux-pingi.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When diva_strace_read_uint returns an error, return even from
process_idi_event, because l2_state is uninitialized.
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Cc: Karsten Keil <isdn@linux-pingi.de>
Acked-by: NArmin Schindler <armin@melware.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use offsetof instead of explicit implementation.

* fixes bug with omitted & like:
  len = (byte)(((T30_INFO *) 0)->station_id + 20)

* avoids compiler warnings with wrong sizes (pointer-to-char cast):
  len = (byte)(&(((T30_INFO *) 0)->universal_6));

* cleans up the code
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Cc: Karsten Keil <isdn@linux-pingi.de>
Acked-by: NArmin Schindler <armin@melware.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The current code probably returns -EINVAL a lot.  Otherwise it would oops.

Compile tested only.  Found by smatch (http://repo.or.cz/w/smatch.git).
Signed-off-by: NDan Carpenter <error27@gmail.com>
Cc: Karsten Keil <isdn@linux-pingi.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add omittted unlocks to 2 functions.
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Cc: Karsten Keil <Karsten-Keil@t-online.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

emac_irq is declared as:

static irqreturn_t emac_irq(int irq, void *dev_id)
{
       struct net_device *ndev = (struct net_device *)dev_id;
       struct emac_priv *priv = netdev_priv(ndev);
    ... 

	Clearly emac_irq() needs "struct net_device *" as "void *dev_id", so correct this.
Signed-off-by: NTonyliu <Bo.Liu@windriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NTorgny Johansson <torgny.johansson@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

For some strange reason the netif_running() check
ended up after the actual type change instead of
before, potentially causing all kinds of problems
if the interface is up while changing the type;
one of the problems manifests itself as a warning:

WARNING: at net/mac80211/iface.c:651 ieee80211_teardown_sdata+0xda/0x1a0 [mac80211]()
Hardware name: Aspire one
Pid: 2596, comm: wpa_supplicant Tainted: G        W  2.6.31-10-generic #32-Ubuntu
Call Trace:
 [] warn_slowpath_common+0x6d/0xa0
 [] warn_slowpath_null+0x15/0x20
 [] ieee80211_teardown_sdata+0xda/0x1a0 [mac80211]
 [] ieee80211_if_change_type+0x4a/0xc0 [mac80211]
 [] ieee80211_change_iface+0x61/0xa0 [mac80211]
 [] cfg80211_wext_siwmode+0xc7/0x120 [cfg80211]
 [] ioctl_standard_call+0x58/0xf0

(http://www.kerneloops.org/searchweek.php?search=ieee80211_teardown_sdata)

Cc: Arjan van de Ven <arjan@infradead.org>
Cc: stable@kernel.org
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

commit 211a4d12abf86fe0df4cd68fc6327cbb58f56f81
  Author: Johannes Berg <johannes@sipsolutions.net>
  Date:   Tue Oct 20 15:08:53 2009 +0900

      cfg80211: sme: deauthenticate on assoc failure

introduced a potential NULL pointer dereference that
some people have been hitting for some reason -- the
params.bssid pointer is not guaranteed to be non-NULL
for what seems to be a race between various ways of
reaching the same thing.

While I'm trying to analyse the problem more let's
first fix the crash. I think the real fix may be to
avoid doing _anything_ if it ended up being NULL, but
right now I'm not sure yet.

I think
http://bugzilla.kernel.org/show_bug.cgi?id=14342
might also be this issue.
Reported-by: NParag Warudkar <parag.lkml@gmail.com>
Tested-by: NParag Warudkar <parag.lkml@gmail.com>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On a 64-bit kernel, skb->tail is an offset, not a pointer. The libertas
usb driver passes it to usb_fill_bulk_urb() anyway, causing interesting
crashes. Fix that by using skb->data instead.

This highlights a problem with usb_fill_bulk_urb(). It doesn't notice
when dma_map_single() fails and return the error to its caller as it
should. In fact it _can't_ currently return the error, since it returns
void.

So this problem was showing up only at unmap time, after we'd already
suffered memory corruption by doing DMA to a bogus address.
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
Cc: stable@kernel.org
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When HT debugging is enabled and we receive a DelBA
frame we print out the reason code in the wrong byte
order. Fix that so we don't get weird values printed.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The addba timer function acquires the sta spinlock,
but at the same time we try to del_timer_sync() it
under the spinlock which can produce deadlocks.

To fix this, always del_timer_sync() the timer in
ieee80211_process_addba_resp() and add it again
after checking the conditions, if necessary.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The patch e43419f9:

	ath9k: downgrade assert in rc.c for invalid rate

downgraded an ASSERT to a WARN_ON() but also misplaced a
semicolon at the end of the second check. What this did
was force the rate control code to always return the rate
even if we should have warned about it. Since this should
not have happened anymore anyway this fix isn't critical
as the proper rate would have been returned anyway.

Cc: stable@kernel.org
Reported-by: NJiri Slaby <jirislaby@gmail.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

b43 allocates a bouncebuffer, if the supplied TX skb is in an invalid
memory range for DMA.
However, this is broken in that it fails to copy over some metadata to the
new skb.

This patch fixes three problems:
* Failure to adjust the ieee80211_tx_info pointer to the new buffer.
  This results in a kmemcheck warning.
* Failure to copy the skb cb, which contains ieee80211_tx_info, to the new skb.
  This results in breakage of various TX-status postprocessing (Rate control).
* Failure to transfer the queue mapping.
  This results in the wrong queue being stopped on saturation and can result in queue overflow.
Signed-off-by: NMichael Buesch <mb@bu3sch.de>
Tested-by: NChristian Casteyde <casteyde.christian@free.fr>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The IBSS code leaks a BSS struct after telling
cfg80211 about a given BSS by passing a frame.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

stolen from windows inf file(07/17/2009, 1.03.05.0000)
Ovislink 0x1b75, 0x7318
MSI 0x0db0, 0x4600
WideTell 0x7167, 0x3840
Signed-off-by: NXose Vazquez Perez <xose.vazquez@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For non-monitor interfaces, the syntax for alloc_ieee80211/free_80211
is wrong. Because alloc_ieee80211 only creates (wiphy_new) a wiphy, but
free_80211() does wiphy_unregister() also. This is only correct when
the later wiphy_register() is called successfully, which apparently
is not the case for your fw doesn't exist one.
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Nathan Neulinger noticed that gretap devices get their MAC address
from the local IP address, which results in invalid MAC addresses
half of the time.

This is because gretap is still using the tunnel netdev ops rather
than the correct tap netdev ops struct.

This patch also fixes changelink to not clobber the MAC address
for the gretap case.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Acked-by: NStephen Hemminger <shemminger@vyatta.com>
Tested-by: NNathan Neulinger <nneul@mst.edu>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>