be2net: Bug fix to send config commands to hardware after netdev_register

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: Ajit Khaparde <ajitk@serverengines.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

be2net: fix to set proper flow control on resume

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: Ajit Khaparde <ajitk@serverengines.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'master' of git://git./linux/kernel/git/linville/wireless-2.6

netfilter: xt_connlimit: fix regression caused by zero family value

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=610
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

rt2x00: Don't queue ieee80211 work after USB removal

This prevents the rt2x00 driver from queueing ieee80211 work after the  
USB card has been removed, preventing a kernel panic.

Signed-off-by: Sean Cross <sean@chumby.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Revert "ipw2200: fix oops on missing firmware"

This reverts commit e6c5fc53d0f44a772398402ee8a1879818e42b4e.

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: John W. Linville <linville@tuxdriver.com>

decnet: netdevice refcount leak

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: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

netfilter: nf_nat: fix NAT issue in 2.6.30.4+

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 a3a9f79e361e864f0e9d75ebe2a0cb43d17c4272).
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: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

be2net: Fix CQE_STATUS_EXTD_SHIFT define

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

rose: device refcount leak

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: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

bridge: prevent bridging wrong device

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: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

virtio_net: rename driver struct to please modpost

Commit

3d1285b (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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reported-by: Michael S. Tsirkin <mst@redhat.com>
Blame-taken-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

rtl8187: Fix kernel oops when device is removed when LEDS enabled

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: Larry Finger <Larry.Finger@lwfinger.net>
Reported-by: Rick Farina <sidhayn@gmail.com>
Tested-by: Rick Farina <sidhayn@gmail.com>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>

MAINTAINERS: Add git net-next-2.6

Add a reference to the the git tree where most
of the forward going network development occurs.

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

isdn: hfc_usb: Fix read buffer overflow

Check whether index is within bounds before testing the element.

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Cc: Karsten Keil <isdn@linux-pingi.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

isdn: hisax: Fix test in waitforxfw

The negation makes it a bool before the comparison and hence it
will never be 0x40.

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Cc: Karsten Keil <isdn@linux-pingi.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

isdn: eicon: Return on error

When diva_strace_read_uint returns an error, return even from
process_idi_event, because l2_state is uninitialized.

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Karsten Keil <isdn@linux-pingi.de>
Acked-by: Armin Schindler <armin@melware.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

isdn: eicon: Use offsetof

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: Jiri Slaby <jirislaby@gmail.com>
Cc: Karsten Keil <isdn@linux-pingi.de>
Acked-by: Armin Schindler <armin@melware.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

misdn: Fix reversed 'if' in st_own_ctrl

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: Dan Carpenter <error27@gmail.com>
Cc: Karsten Keil <isdn@linux-pingi.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

isdn: hisax: Fix lock imbalance.

Add omittted unlocks to 2 functions.

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Karsten Keil <Karsten-Keil@t-online.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

DaVinci EMAC: correct param for ISR

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: Tonyliu <Bo.Liu@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

cdc_ether: additional Ericsson MBM PID's to the whitelist

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

Merge branch 'master' of git://git./linux/kernel/git/linville/wireless-2.6

mac80211: check interface is down before type change

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: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

cfg80211: fix NULL ptr deref

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: Parag Warudkar <parag.lkml@gmail.com>
Tested-by: Parag Warudkar <parag.lkml@gmail.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

libertas if_usb: Fix crash on 64-bit machines

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: David Woodhouse <David.Woodhouse@intel.com>
Cc: stable@kernel.org
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: fix reason code output endianness

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: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: fix addba timer

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: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ath9k: fix misplaced semicolon on rate control

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: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

b43: Fix DMA TX bounce buffer copying

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: Michael Buesch <mb@bu3sch.de>
Tested-by: Christian Casteyde <casteyde.christian@free.fr>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: fix BSS leak

The IBSS code leaks a BSS struct after telling
cfg80211 about a given BSS by passing a frame.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rt73usb.c : more ids

stolen from windows inf file(07/17/2009, 1.03.05.0000)
Ovislink 0x1b75, 0x7318
MSI 0x0db0, 0x4600
WideTell 0x7167, 0x3840

Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ipw2200: fix oops on missing firmware

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: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

gre: Fix dev_addr clobbering for gretap

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: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Tested-by: Nathan Neulinger <nneul@mst.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>

sky2: set carrier off in probe

Before bringing up a sky2 interface up ethtool reports
"Link detected: yes". Do as ixgbe does and netif_carrier_off() on
probe().

Signed-off-by: Brandon Philips <bphilips@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: fix sk_forward_alloc corruption

On UDP sockets, we must call skb_free_datagram() with socket locked,
or risk sk_forward_alloc corruption. This requirement is not respected
in SUNRPC.

Add a convenient helper, skb_free_datagram_locked() and use it in SUNRPC

Reported-by: Francis Moreau <francis.moro@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

pcnet_cs: add cis of PreMax PE-200 ethernet pcmcia card

pcnet_cs,serial_cs:

add cis of PreMax ethernet pcmcia card,
and some Sierra Wireless serial card(AC555, AC7xx, AC8xx).

use PROD_ID for AC7xx, because MANF_ID of AC7xx and AC8xx are the same.

Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>

r8169: Fix card drop incoming VLAN tagged MTU byte large jumbo frames

r8169 card drop incoming VLAN tagged MTU byte large jumbo frames

It looks to compare current and maximal packet sizes hardware use
'<' operator, not '<='.

Bug introduced by commit fdd7b4c3302c93f6833e338903ea77245eb510b4
("r8169: fix crash when large packets are received")

Signed-off-by: Raimonds Cicans <ray@apollo.lv>
Signed-off-by: David S. Miller <davem@davemloft.net>

ibmtr: possible Read buffer overflow?

Prevent read outside array bounds.

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: Fix RPF to work with policy routing

Policy routing is not looked up by mark on reverse path filtering.
This fixes it.

Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: fix kmemcheck annotations

struct sk_buff kmemcheck annotations enlarged this structure by 8/16 bytes

Fix this by moving 'protocol' inside flags1 bitfield,
and queue_mapping inside flags2 bitfield.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

e1000e: rework disable K1 at 1000Mbps for 82577/82578

This patch reworks a previous workaround (commit 7d3cabbcc) for an issue
in hardware where noise on the interconnect between the MAC and PHY could
be generated by a lower power mode (K1) at 1000Mbps resulting in bad
packets.  Disable K1 while at 1000 Mbps but keep it enabled for 10/100Mbps
and when the cable is disconnected.  The original version of this
workaround was found to be incomplete.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

e1000e: config PHY via software after resets

On PCH-based (82577/82578) and some ICH8-based parts (82566) there is an
issue with the hardware automatically configuring the PHY with contents
from the EEPROM after the PHY is reset, so do the configuration by the
driver instead.  This was already similarly done for some 82566 parts in
e1000_phy_hw_reset_ich8lan() but needs to be done after other resets,
so move the PHY configuration code to its own function and call after
all PHY resets.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

e100: e100_phy_init() isolates selected PHY, causes 10 second boot delay

A change in how PHYs are electrically isolated caused all PHYs to be
isolated followed by reverting that isolation for the selected PHY.
Unfortunately, isolating the selected PHY for even a short period of
time can result in DHCP negotiation taking more than 10 seconds on certain
embedded configurations delaying boot time as reported by Bernhard Kaindl.
This patch reverts the change to how PHYs are isolated yet still works
around the issue for 82552 needing the selected PHY's BMCR register to
be written after the unused PHYs are isolated.  This code is moved below
the setting of nic->phy ID in order to do the 82552-specific workaround.

Cc: Bernhard Kaindl <bernhard.kaindl@gmx.net>
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: Fix 'Re: PACKET_TX_RING: packet size is too long'

Currently PACKET_TX_RING forces certain amount of every frame to remain
unused. This probably originates from an early version of the
PACKET_TX_RING patch that in fact used the extra space when the (since
removed) CONFIG_PACKET_MMAP_ZERO_COPY option was enabled. The current
code does not make any use of this extra space.

This patch removes the extra space reservation and lets userspace make
use of the full frame size.

Signed-off-by: Gabor Gombas <gombasg@sztaki.hu>
Signed-off-by: David S. Miller <davem@davemloft.net>

netdev: usb: dm9601.c can drive a device not supported yet, add support for it

I found that the current version of drivers/net/usb/dm9601.c can be used to
successfully drive a low-power, low-cost network adapter with USB ID
0a46:9000, based on a DM9000E chipset. As no device with this ID is yet
present in the kernel, I have created a patch that adds support for the device
to the dm9601 driver.

Created and tested against linux-2.6.32-rc5.

Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlge: Fix firmware mailbox command timeout.

The mailbox command process would only process a maximum of 5 unrelated
firmware events while waiting for it's command completion status.
It should process an unlimited number of events while waiting for a maximum of 5 seconds.

Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

qlge: Fix EEH handling.

Clean up driver resources without touch the hardware. Add pci
save/restore state.

Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

AF_RAW: Augment raw_send_hdrinc to expand skb to fit iphdr->ihl (v2)

Augment raw_send_hdrinc to correct for incorrect ip header length values

A series of oopses was reported to me recently.  Apparently when using AF_RAW
sockets to send data to peers that were reachable via ipsec encapsulation,
people could panic or BUG halt their systems.

I've tracked the problem down to user space sending an invalid ip header over an
AF_RAW socket with IP_HDRINCL set to 1.

Basically what happens is that userspace sends down an ip frame that includes
only the header (no data), but sets the ip header ihl value to a large number,
one that is larger than the total amount of data passed to the sendmsg call.  In
raw_send_hdrincl, we allocate an skb based on the size of the data in the msghdr
that was passed in, but assume the data is all valid.  Later during ipsec
encapsulation, xfrm4_tranport_output moves the entire frame back in the skbuff
to provide headroom for the ipsec headers.  During this operation, the
skb->transport_header is repointed to a spot computed by
skb->network_header + the ip header length (ihl).  Since so little data was
passed in relative to the value of ihl provided by the raw socket, we point
transport header to an unknown location, resulting in various crashes.

This fix for this is pretty straightforward, simply validate the value of of
iph->ihl when sending over a raw socket.  If (iph->ihl*4U) > user data buffer
size, drop the frame and return -EINVAL.  I just confirmed this fixes the
reported crashes.

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'master' of git://git./linux/kernel/git/linville/wireless-2.6

bonding: fix a race condition in calls to slave MII ioctls

In mii monitor mode, bond_check_dev_link() calls the the ioctl
handler of slave devices. It stores the ndo_do_ioctl function
pointer to a static (!) ioctl variable and later uses it to call the
handler with the IOCTL macro.

If another thread executes bond_check_dev_link() at the same time
(even with a different bond, which none of the locks prevent), a
race condition occurs. If the two racing slaves have different
drivers, this may result in one driver's ioctl handler being
called with a pointer to a net_device controlled with a different
driver, resulting in unpredictable breakage.

Unless I am overlooking something, the "static" must be a
copy'n'paste error (?).

Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>

virtio-net: fix data corruption with OOM

virtio net used to unlink skbs from send queues on error,
but ever since 48925e372f04f5e35fec6269127c62b2c71ab794
we do not do this. This causes guest data corruption and crashes
with vhost since net core can requeue the skb or free it without
it being taken off the list.

This patch fixes this by queueing the skb after successful
transmit.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

sfc: Set ip_summed correctly for page buffers passed to GRO

Page buffers containing packets with an incorrect checksum or using a
protocol not handled by hardware checksum offload were previously not
passed to LRO.  The conversion to GRO changed this, but did not set
the ip_summed value accordingly.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

cnic: Fix L2CTX_STATUSB_NUM offset in context memory.

The BNX2_L2CTX_STATUSB_NUM definition needs to be changed to match
the recent firmware update:

commit 078b0735881c7969aaf21469f3577831cddd9f8c
bnx2: Update firmware to 5.0.0.j3.

Without the fix, bnx2 can crash intermittently in bnx2_rx_int() when
iSCSI is enabled.

Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

MAINTAINERS: rt2x00 list is moderated

Cc: users@rt2x00.serialmonkey.com
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

airo: Reorder tests, check bounds before element

Test whether index is within bounds before reading the element

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: fix for incorrect sequence number on hostapd injected frames

When hostapd injects a frame, e.g. an authentication or association
response, mac80211 looks for a suitable access point virtual interface
to associate the frame with based on its source address. This makes it
possible e.g. to correctly assign sequence numbers to the frames.

A small typo in the ethernet address comparison statement caused a
failure to find a suitable ap interface. Sequence numbers on such
frames where therefore left unassigned causing some clients
(especially windows-based 11b/g clients) to reject them and fail to
authenticate or associate with the access point. This patch fixes the
typo in the address comparison statement.

Signed-off-by: Björn Smedman <bjorn.smedman@venatech.se>
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>

libertas spi: fix sparse errors

This fixes the following sparse warnings:

$ make modules SUBDIRS=drivers/net/wireless/libertas C=1 CF=-D__CHECK_ENDIAN__
make: Entering directory `/usr/src/linux-wl'
  CHECK   drivers/net/wireless/libertas/if_spi.c
drivers/net/wireless/libertas/if_spi.c:137:16: warning: incorrect type in initializer (different base types)
drivers/net/wireless/libertas/if_spi.c:137:16:    expected unsigned short [unsigned] [usertype] reg_out
drivers/net/wireless/libertas/if_spi.c:137:16:    got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:191:16: warning: incorrect type in initializer (different base types)
drivers/net/wireless/libertas/if_spi.c:191:16:    expected unsigned short [unsigned] [usertype] reg_out
drivers/net/wireless/libertas/if_spi.c:191:16:    got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:256:24: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/libertas/if_spi.c:256:24:    expected restricted __le32 const [usertype] *p
drivers/net/wireless/libertas/if_spi.c:256:24:    got unsigned int *<noident>
drivers/net/wireless/libertas/if_spi.c:243:24: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/libertas/if_spi.c:243:24:    expected restricted __le16 const [usertype] *p
drivers/net/wireless/libertas/if_spi.c:243:24:    got unsigned short *<noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7:    expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7:    got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7:    expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7:    got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7:    expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7:    got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7:    expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7:    got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7:    expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7:    got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:243:24: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/libertas/if_spi.c:243:24:    expected restricted __le16 const [usertype] *p
drivers/net/wireless/libertas/if_spi.c:243:24:    got unsigned short *<noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7:    expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7:    got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7:    expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7:    got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7:    expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7:    got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7:    expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7:    got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7:    expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7:    got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7:    expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7:    got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:243:24: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/libertas/if_spi.c:243:24:    expected restricted __le16 const [usertype] *p
drivers/net/wireless/libertas/if_spi.c:243:24:    got unsigned short *<noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7:    expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7:    got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7:    expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7:    got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:243:24: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/libertas/if_spi.c:243:24:    expected restricted __le16 const [usertype] *p
drivers/net/wireless/libertas/if_spi.c:243:24:    got unsigned short *<noident>
drivers/net/wireless/libertas/if_spi.c:243:24: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/libertas/if_spi.c:243:24:    expected restricted __le16 const [usertype] *p
drivers/net/wireless/libertas/if_spi.c:243:24:    got unsigned short *<noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7:    expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7:    got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:171:7: warning: incorrect type in assignment (different base types)
drivers/net/wireless/libertas/if_spi.c:171:7:    expected unsigned short [unsigned] [usertype] buff
drivers/net/wireless/libertas/if_spi.c:171:7:    got restricted __le16 [usertype] <noident>
drivers/net/wireless/libertas/if_spi.c:243:24: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/libertas/if_spi.c:243:24:    expected restricted __le16 const [usertype] *p
drivers/net/wireless/libertas/if_spi.c:243:24:    got unsigned short *<noident>

Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: trivial: fix spelling in mesh_hwmp

Fix a typo in the description of hwmp_route_info_get(), no function
changes.

Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

cfg80211: sme: deauthenticate on assoc failure

When the in-kernel SME gets an association failure from
the AP we don't deauthenticate, and thus get into a very
confused state which will lead to warnings later on. Fix
this by actually deauthenticating when the AP indicates
an association failure.

(Brought to you by the hacking session at Kernel Summit 2009 in Tokyo,
Japan. -- JWL)

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: keep auth state when assoc fails

When association fails, we should stay authenticated,
which in mac80211 is represented by the existence of
the mlme work struct, so we cannot free that, instead
we need to just set it to idle.

(Brought to you by the hacking session at Kernel Summit 2009 in Tokyo,
Japan. -- JWL)

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: fix ibss joining

Recent commit "mac80211: fix logic error ibss merge bssid check" fixed
joining of ibss cell when static bssid is provided. In this case
ifibss->bssid is set before the cell is joined and comparing that address
to a bss should thus always succeed. Unfortunately this change broke the
other case of joining a ibss cell without providing a static bssid where
the value of ifibss->bssid is not set before the cell is joined.

Since ifibss->bssid may be set before or after joining the cell we do not
learn anything by comparing it to a known bss. Remove this check.

Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

b43: add 'struct b43_wl' missing declaration

'struct b43_wl' declaration is missing at 'leds.h'.
It should be declared to avoid getting some GCC warnings at 'b43_leds_unregister'.

Signed-off-by: Miguel Botón <mboton@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

b43: Fix Bugzilla #14181 and the bug from the previous 'fix'

"b43: Fix PPC crash in rfkill polling on unload" fixed the bug reported
in Bugzilla No. 14181; however, it introduced a new bug. Whenever the
radio switch was turned off, it was necessary to unload and reload
the driver for it to recognize the switch again.

This patch fixes both the original bug in #14181 and the bug introduced by
the previous patch. It must be stated, however, that if there is a BCM4306/3
with an rfkill switch (not yet proven), then the driver will need an
unload/reload cycle to turn the device back on.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rt2x00: Fix crypto in TX frame for rt2800usb

Signed-off-by: Benoit PAPILLAULT <benoit.papillault@free.fr>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

sh_eth: Add asm/cacheflush.h

Add include asm/cacheflush.h,  because declaration of __flush_purge_region
moved to asm/cacheflush.h.

Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

PPPoE: Fix flush/close races.

Be more careful about the state of pointers during tear-down.
The "pppoe_dev" field can only be looked at safely while holding socket locks.
This subsequently allows for the flush_lock to be killed.

We depend on the PPPOX_CONNECTED state to tell us that that those fields are
valid, so whoever clears that state (pppox_unbind_sock()) is responsible for
the dev_put() call.

We also have to ensure that we delete_item() on all sockets before they are
cleaned up.

The need for these changes has been exposed by scenarios wherein namespace
bindings of ethernet devices change while there are ongoing PPPoE sessions,
which resulted in oopses due to unusual socket connection termination paths,
exposing these issues.

Signed-off-by: Michal Ostrowski <mostrows@gmail.com>
Reviewed-by: Cyril Gorcunov <gorcunov@gmail.com>
Reported-by: Denys Fedoryschenko <denys@visp.net.lb>
Tested-by: Denys Fedoryschenko <denys@visp.net.lb>

e1000e: allow for swflag to be held over consecutive PHY accesses

PCH-based parts (82577/82578) and some ICH8-based parts (82566) need to
hold the swflag (sw/fw/hw hardware semaphore) over consecutive PHY accesses
in order to perform sw-driven PHY configuration during initialization to
workaround known hardware issues (see follow-on patch).  This patch
provides new PHY read/write functions (and function pointers) that will
allow accessing the PHY registers assuming the swflag has already been
acquired.  The actual PHY register access code has moved into helper
functions that are called with a flag indicating whether or not the swflag
has already been acquired and acquires/releases it if not.

The functions called from within the updated PHY access functions had to be
updated to assume the swflag was already acquired, and other functions that
called those functions were also updated to acquire/release the swflag.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

e1000e: separate mutex usage between NVM and PHY/CSR register for ICHx/PCH

Accesses to NVM and PHY/CSR registers on ICHx/PCH-based parts are protected
from concurrent accesses with a mutex that is acquired when the access is
initiated and released when the access has completed.  However, the two
types of accesses should not be protected by the same mutex because the
driver may have to access the NVM while already holding the mutex over
several consecutive PHY/CSR accesses which would result in livelock.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

e1000e: 82577/82578 requires a different method to configure LPLU

Unlike previous ICHx-based parts, the PCH-based parts (82577/82578) require
LPLU (Low Power Link Up, or "reverse auto-negotiation") to be configured in
the PHY rather than the MAC.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

e1000e: increase swflag acquisition timeout for ICHx/PCH

In some conditions (e.g. when AMT is enabled on the system), it is possible
to take an extended period of time to for the driver to acquire the sw/fw/hw
hardware semaphore used to protect against concurrent access of a shared
resource (e.g. PHY registers).  This could cause PHY registers to not get
configured properly resulting in link issues.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

e1000e: clear PHY wakeup bit after LCD reset on 82577/82578

Performing a dummy read of the PHY Wakeup Control (WUC) register clears the
wakeup enable bit set by an PHY reset.  If this bit remains set, link
problems may occur.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

igbvf: fix memory leak when ring size changed while interface down

This patch resolves a memory leak which occurs while changing the ring size
while the interface is down.

Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ixgbe: fix memory leak when resizing rings while interface is down

This patch resolves a memory leak that occurs when you resize the rings via
the ethtool -G option while the interface is down.

Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

igb: fix memory leak when setting ring size while interface is down

Changing ring sizes while the interface was down was causing a double
allocation of the receive and transmit rings.  This issue is amplified when
there are multiple rings enabled.  To prevent this we need to add an
additional check which will just update the ring counts when the interface
is not up and skip the allocation steps.

Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

bonding: Modify hash transmit policies to use the packet's source MAC address

Modify bonding hash transmit policies to use the psource MAC address of
the packet instead of the MAC address configured for the bonding device.

The old sitation conflicts with the documentation.

Signed-off-by: Jasper Spaans <spaans@fox-it.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

pktgen: Dont leak kernel memory

While playing with pktgen, I realized IP ID was not filled and a
random value was taken, possibly leaking 2 bytes of kernel memory.

We can use an increasing ID, this can help diagnostics anyway.

Also clear packet payload, instead of leaking kernel memory.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

DM9000: Fix revision ID for DM9000B

The DM9000B revision ID is 0x1A, not 0x1B as set in the curernt
dm9000.h header.

Fix bug reported by Paolo Zebelloni.

Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: Simtec Linux Team <linux@simtec.co.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>

r8169: fix Ethernet Hangup for RTL8110SC rev d

The 8110SC rev d chip on our board shows a regression which the 8110SB chip
did not have. When inbound traffic is overflowing the receive descriptor queue,
"holes" in the ring buffer may occur which lead to a hangup until the buffer
is filled again. The packets are than completely processed, but the ring
remains porous and no packets are processed until the next overflow. Setting
the interface down and up can fix the problem temporary from userspace.

For some reason we don't know, this behaviour is not occuring if the RxVlan
bit for hardware VLAN untagging is set. There is another "Work around for
AMD plateform" in the current code which checks the VLAN status
word in receive descriptors, but does never come to effect when hardware
VLAN support is enabled. We assume that this is a bug in the chip.

The following patch fixes the problem. Without the patch we could reproduce
the hang within minutes (given other devices also generating lots of
interrupts), without we couldn't reproduce within a few days of long term
testing.

This version contains minor style adjustments and is sent with mutt which
will hopefully not destroy the formatting again.

Signed-off-by: Bernhard Schmidt <bernhard.schmidt@saxnet.de>
Signed-off-by: Simon Wunderlich <simon.wunderlich@saxnet.de>
Acked-by: Francois Romieu <romieu@zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ifb: should not use __dev_get_by_index() without locks

At this point (ri_tasklet()), RTNL or dev_base_lock are not held,
we must use dev_get_by_index() instead of __dev_get_by_index()

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: au1000_eth: add missing capability.h

fixes the following build failure:
  CC      drivers/net/au1000_eth.o
/drivers/net/au1000_eth.c: In function 'au1000_set_settings':
/drivers/net/au1000_eth.c:623: error: implicit declaration of function 'capable'
/drivers/net/au1000_eth.c:623: error: 'CAP_NET_ADMIN' undeclared (first use in this function)
/drivers/net/au1000_eth.c:623: error: (Each undeclared identifier is reported only once
/drivers/net/au1000_eth.c:623: error: for each function it appears in.

Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

myri10ge: improve port type reporting in ethtool

Improve the reporting of myri10ge port type in ethtool,
and update for new boards.

Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: Andrew Gallatin <gallatin@myri.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: use WARN() for the WARN_ON in commit b6b39e8f3fbbb

Commit b6b39e8f3fbbb (tcp: Try to catch MSG_PEEK bug) added a printk()
to the WARN_ON() that's in tcp.c. This patch changes this combination
to WARN(); the advantage of WARN() is that the printk message shows up
inside the message, so that kerneloops.org will collect the message.

In addition, this gets rid of an extra if() statement.

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

e1000e: reset the PHY on 82577/82578 when going to Sx

The PHY on 82577/82578 parts needs a soft reset when transitioning to Sx
state in order for the PHY write which disables gigabit speed to take
effect.  Gigabit speed must be disabled in order for the PHY writes to
registers on page 800 (the wakeup control registers) to work as expected
otherwise the system might not wake via WoL.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

isdn: fix possible circular locking dependency

There's a circular locking dependency:

---> isdn_net_get_locked_lp
    --->lock &nd->queue_lock
    --->lock &nd->queue->xmit_lock
    .....................
    ---->unlock &nd->queue_lock

---> isdn_net_writebuf_skb (called with &nd->queue->xmit_lock locked)
    ---->isdn_net_inc_frame_cnt
         ---->isdn_net_device_busy
              ----> lock &nd->queue_lock

This will trigger lockdep warnings:

 =======================================================
 [ INFO: possible circular locking dependency detected ]
 2.6.32-rc4-testing #7
 -------------------------------------------------------
 ipppd/28379 is trying to acquire lock:
 (&netdev->queue_lock){......}, at: [<e62ad0fd>] isdn_net_device_busy+0x2c/0x74 [isdn]

 but task is already holding lock:
 (&netdev->local->xmit_lock){+.....}, at: [<e62aefc2>] isdn_net_write_super+0x3f/0x6e [isdn]

 which lock already depends on the new lock.
 .......

 We don't need to lock nd->queue->xmit_lock to protect single
isdn_net_lp_busy(). This can fix above lockdep warnings.

Reported-and-tested-by: Tilman Schmidt <tilman@imap.cc>
Signed-off-by: Xiaotian Feng <xtfeng@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

netxen: avoid undue board config check

Old code assumed board config version in the flash to be 1.
When this will get changed by tools, driver just refuses to
attach. This is unnecessary since driver does not have to
parse board config structure directly (maintained by firmware).

Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

netxen: fix tx timeout handling on firmware hang

Clear NX_RESETING bit in netxen_tx_timeout_task() so that
the firmware watchdog task can catch need_reset request
from tx timeout.

Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

netxen: fix i2c init

Avoid resetting subsys ID in i2c block. Also remove duplicate
check for address tranlsation error.

Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

niu: VLAN_ETH_HLEN should be used to make sure that the whole MAC header was copied to the head buffer in the Vlan packets case

Signed-off-by: Joyce Yu <joyce.yu@sun.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

KS8851: Fix ks8851_set_rx_mode() for IFF_MULTICAST

In ks8851_set_rx_mode() the case handling IFF_MULTICAST was also setting
the RXCR1_AE bit by accident. This meant that all unicast frames where
being accepted by the device. Remove RXCR1_AE from this case.

Note, RXCR1_AE was also masking a problem with setting the MAC address
properly, so needs to be applied after fixing the MAC write order.

Fixes a bug reported by Doong, Ping of Micrel. This version of the
patch avoids setting RXCR1_ME for all cases.

Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>

KS8851: Fix MAC address write order

The MAC address register was being written in the wrong order, so add
a new address macro to convert mac-address byte to register address and
a ks8851_wrreg8() function to write each byte without having to worry
about any difficult byte swapping.

Fixes a bug reported by Doong, Ping of Micrel.

Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>

KS8851: Add soft reset at probe time

Issue a full soft reset at probe time.

This was reported by Doong Ping of Micrel, but no explanation of why this
is necessary or what bug it is fixing. Add it as it does not seem to hurt
the current driver and ensures that the device is in a known state when we
start setting it up.

Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: fix section mismatch in fec.c

fec_enet_init is called by both fec_probe and fec_resume, so it
shouldn't be marked as __init.

Signed-off-by: Steven King <sfking@fdwdc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: Fix struct inet_timewait_sock bitfield annotation

commit 9e337b0f (net: annotate inet_timewait_sock bitfields)
added 4/8 bytes in struct inet_timewait_sock.

Fix this by declaring tw_ipv6_offset in the 'flags' bitfield
The 14 bits hole is named tw_pad to make it cleary apparent.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

tcp: Try to catch MSG_PEEK bug

This patch tries to print out more information when we hit the
MSG_PEEK bug in tcp_recvmsg.  It's been around since at least
2005 and it's about time that we finally fix it.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

net: Fix IP_MULTICAST_IF

ipv4/ipv6 setsockopt(IP_MULTICAST_IF) have dubious __dev_get_by_index() calls.

This function should be called only with RTNL or dev_base_lock held, or reader
could see a corrupt hash chain and eventually enter an endless loop.

Fix is to call dev_get_by_index()/dev_put().

If this happens to be performance critical, we could define a new dev_exist_by_index()
function to avoid touching dev refcount.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

bluetooth: static lock key fix

When shutdown ppp connection, lockdep waring about non-static key
will happen, it is caused by the lock is not initialized properly
at that time.

Fix with tuning the lock/skb_queue_head init order

[   94.339261] INFO: trying to register non-static key.
[   94.342509] the code is fine but needs lockdep annotation.
[   94.342509] turning off the locking correctness validator.
[   94.342509] Pid: 0, comm: swapper Not tainted 2.6.31-mm1 #2
[   94.342509] Call Trace:
[   94.342509]  [<c0248fbe>] register_lock_class+0x58/0x241
[   94.342509]  [<c024b5df>] ? __lock_acquire+0xb57/0xb73
[   94.342509]  [<c024ab34>] __lock_acquire+0xac/0xb73
[   94.342509]  [<c024b7fa>] ? lock_release_non_nested+0x17b/0x1de
[   94.342509]  [<c024b662>] lock_acquire+0x67/0x84
[   94.342509]  [<c04cd1eb>] ? skb_dequeue+0x15/0x41
[   94.342509]  [<c054a857>] _spin_lock_irqsave+0x2f/0x3f
[   94.342509]  [<c04cd1eb>] ? skb_dequeue+0x15/0x41
[   94.342509]  [<c04cd1eb>] skb_dequeue+0x15/0x41
[   94.342509]  [<c054a648>] ? _read_unlock+0x1d/0x20
[   94.342509]  [<c04cd641>] skb_queue_purge+0x14/0x1b
[   94.342509]  [<fab94fdc>] l2cap_recv_frame+0xea1/0x115a [l2cap]
[   94.342509]  [<c024b5df>] ? __lock_acquire+0xb57/0xb73
[   94.342509]  [<c0249c04>] ? mark_lock+0x1e/0x1c7
[   94.342509]  [<f8364963>] ? hci_rx_task+0xd2/0x1bc [bluetooth]
[   94.342509]  [<fab95346>] l2cap_recv_acldata+0xb1/0x1c6 [l2cap]
[   94.342509]  [<f8364997>] hci_rx_task+0x106/0x1bc [bluetooth]
[   94.342509]  [<fab95295>] ? l2cap_recv_acldata+0x0/0x1c6 [l2cap]
[   94.342509]  [<c02302c4>] tasklet_action+0x69/0xc1
[   94.342509]  [<c022fbef>] __do_softirq+0x94/0x11e
[   94.342509]  [<c022fcaf>] do_softirq+0x36/0x5a
[   94.342509]  [<c022fe14>] irq_exit+0x35/0x68
[   94.342509]  [<c0204ced>] do_IRQ+0x72/0x89
[   94.342509]  [<c02038ee>] common_interrupt+0x2e/0x34
[   94.342509]  [<c024007b>] ? pm_qos_add_requirement+0x63/0x9d
[   94.342509]  [<c038e8a5>] ? acpi_idle_enter_bm+0x209/0x238
[   94.342509]  [<c049d238>] cpuidle_idle_call+0x5c/0x94
[   94.342509]  [<c02023f8>] cpu_idle+0x4e/0x6f
[   94.342509]  [<c0534153>] rest_init+0x53/0x55
[   94.342509]  [<c0781894>] start_kernel+0x2f0/0x2f5
[   94.342509]  [<c0781091>] i386_start_kernel+0x91/0x96

Reported-by: Oliver Hartkopp <oliver@hartkopp.net>
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Tested-by: Oliver Hartkopp <oliver@hartkopp.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

bluetooth: scheduling while atomic bug fix

Due to driver core changes dev_set_drvdata will call kzalloc which should be
in might_sleep context, but hci_conn_add will be called in atomic context

Like dev_set_name move dev_set_drvdata to work queue function.

oops as following:

Oct  2 17:41:59 darkstar kernel: [  438.001341] BUG: sleeping function called from invalid context at mm/slqb.c:1546
Oct  2 17:41:59 darkstar kernel: [  438.001345] in_atomic(): 1, irqs_disabled(): 0, pid: 2133, name: sdptool
Oct  2 17:41:59 darkstar kernel: [  438.001348] 2 locks held by sdptool/2133:
Oct  2 17:41:59 darkstar kernel: [  438.001350]  #0:  (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.+.}, at: [<faa1d2f5>] lock_sock+0xa/0xc [l2cap]
Oct  2 17:41:59 darkstar kernel: [  438.001360]  #1:  (&hdev->lock){+.-.+.}, at: [<faa20e16>] l2cap_sock_connect+0x103/0x26b [l2cap]
Oct  2 17:41:59 darkstar kernel: [  438.001371] Pid: 2133, comm: sdptool Not tainted 2.6.31-mm1 #2
Oct  2 17:41:59 darkstar kernel: [  438.001373] Call Trace:
Oct  2 17:41:59 darkstar kernel: [  438.001381]  [<c022433f>] __might_sleep+0xde/0xe5
Oct  2 17:41:59 darkstar kernel: [  438.001386]  [<c0298843>] __kmalloc+0x4a/0x15a
Oct  2 17:41:59 darkstar kernel: [  438.001392]  [<c03f0065>] ? kzalloc+0xb/0xd
Oct  2 17:41:59 darkstar kernel: [  438.001396]  [<c03f0065>] kzalloc+0xb/0xd
Oct  2 17:41:59 darkstar kernel: [  438.001400]  [<c03f04ff>] device_private_init+0x15/0x3d
Oct  2 17:41:59 darkstar kernel: [  438.001405]  [<c03f24c5>] dev_set_drvdata+0x18/0x26
Oct  2 17:41:59 darkstar kernel: [  438.001414]  [<fa51fff7>] hci_conn_init_sysfs+0x40/0xd9 [bluetooth]
Oct  2 17:41:59 darkstar kernel: [  438.001422]  [<fa51cdc0>] ? hci_conn_add+0x128/0x186 [bluetooth]
Oct  2 17:41:59 darkstar kernel: [  438.001429]  [<fa51ce0f>] hci_conn_add+0x177/0x186 [bluetooth]
Oct  2 17:41:59 darkstar kernel: [  438.001437]  [<fa51cf8a>] hci_connect+0x3c/0xfb [bluetooth]
Oct  2 17:41:59 darkstar kernel: [  438.001442]  [<faa20e87>] l2cap_sock_connect+0x174/0x26b [l2cap]
Oct  2 17:41:59 darkstar kernel: [  438.001448]  [<c04c8df5>] sys_connect+0x60/0x7a
Oct  2 17:41:59 darkstar kernel: [  438.001453]  [<c024b703>] ? lock_release_non_nested+0x84/0x1de
Oct  2 17:41:59 darkstar kernel: [  438.001458]  [<c028804b>] ? might_fault+0x47/0x81
Oct  2 17:41:59 darkstar kernel: [  438.001462]  [<c028804b>] ? might_fault+0x47/0x81
Oct  2 17:41:59 darkstar kernel: [  438.001468]  [<c033361f>] ? __copy_from_user_ll+0x11/0xce
Oct  2 17:41:59 darkstar kernel: [  438.001472]  [<c04c9419>] sys_socketcall+0x82/0x17b
Oct  2 17:41:59 darkstar kernel: [  438.001477]  [<c020329d>] syscall_call+0x7/0xb

Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

tcp: fix TCP_DEFER_ACCEPT retrans calculation

Fix TCP_DEFER_ACCEPT conversion between seconds and
retransmission to match the TCP SYN-ACK retransmission periods
because the time is converted to such retransmissions. The old
algorithm selects one more retransmission in some cases. Allow
up to 255 retransmissions.

Signed-off-by: Julian Anastasov <ja@ssi.bg>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

tcp: reduce SYN-ACK retrans for TCP_DEFER_ACCEPT

Change SYN-ACK retransmitting code for the TCP_DEFER_ACCEPT
users to not retransmit SYN-ACKs during the deferring period if
ACK from client was received. The goal is to reduce traffic
during the deferring period. When the period is finished
we continue with sending SYN-ACKs (at least one) but this time
any traffic from client will change the request to established
socket allowing application to terminate it properly.
Also, do not drop acked request if sending of SYN-ACK fails.

Signed-off-by: Julian Anastasov <ja@ssi.bg>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>