Add some read's to avoid any PCI posting issues when controlling
irq's.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Reset more parts of the receive path when device is take offline.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

This unblocks the chip if it is stuck in pause cycle during
shutdown.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Stopping all activity through ChipCmd and blindly acking the irqs
is neither nice nor completely needed: the transition to low-power
mode does enough work and it apparently keeps the device in a sane
state.

Patch suggested by a fix for http://bugzilla.kernel.org/show_bug.cgi?id=9512

The rtl_shutdown path is kept unchanged so far.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Tested-by: Anders Eriksson <aeriksson@fastmail.fm>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
Signed-off-by: David S. Miller <davem@davemloft.net>

When sis190 driver is trying to get default phy, if it doesn't find home
or lan phy, it falls back to the first phy in the phy list but list_entry()
points to a bogus entry. list_first_entry() should be used instead.
Signed-off-by: Arnaud Patard <apatard@mandriva.com>
Acked-off-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

-- derived from reverted commit 047584ce
-- reworked by Grant Likely to play nice with commit:
   "net: Rework ucc_geth driver to use of_mdio infrastructure"
   (0b9da337)
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: David S. Miller <davem@davemloft.net>

This reverts commit 047584ce.

This patch meshes badly with "net: Rework ucc_geth driver to use
of_mdio infrastructure" (0b9da337).
Since most of the patch needs to be reworked, it is clearer to revert
the patch and then apply the corrected version
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: David S. Miller <davem@davemloft.net>

The skb mac_header field is sometimes NULL (or ~0u) as a sentinel
value. The places where skb is expanded add an offset which would
change this flag into an invalid pointer (or offset).
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Looking at the crash in log_martians(), one suspect is that the check for
mac header being set is not correct.  The value of mac_header defaults to
0 on allocation, therefore skb_mac_header_was_set will always be true on
platforms using NET_SKBUFF_USES_OFFSET.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

commit 2b85a34e
(net: No more expensive sock_hold()/sock_put() on each tx)
changed initial sk_wmem_alloc value.

Some protocols check sk_wmem_alloc value to determine if a timer
must delay socket deallocation. We must take care of the sk_wmem_alloc
value being one instead of zero when no write allocations are pending.

Reported by Ingo Molnar, and full diagnostic from David Miller.

This patch introduces three helpers to get read/write allocations
and a followup patch will use these helpers to report correct
write allocations to user.
Reported-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Fix kernel-doc parameter name in phy_device.c.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Fix up remaining drivers returning a magic or an errno value from their
ndo_start_xmit() functions that were missed in the first pass:

- isdn_net: missed conversion
- bpqether: missed conversion: skb is freed, so return NETDEV_TX_OK
- hp100: intention appears to be to resubmit skb once resources are
  available, but due to no queue handling it is dropped for now.
- lapbether: skb is freed, so return NETDEV_TX_OK
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

- Enabled SRIOV support in the driver.
- Call __vxge_hw_verify_pci_e_info() for the PF only. This function
  verifies the negotiated link width and current link speed in the
  Link Status Register (offset 12h) which are reserved fields for VFs
  as per the SRIOV specification, section 3.5.8.
- Implemented David Miller's comment to remove the #ifdef CONFIG_PCI_IOV as
  these intefaces have NOP versions declared when the defintion is not set.
Signed-off-by: Sivakumar Subramani <sivakumar.subramani@neterion.com>
Signed-off-by: Rastapur Santosh <santosh.rastapur@neterion.com>
Signed-off-by: Ramkrishna Vepa <ram.vepa@neterion.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Fix kernel-doc warnings (missing + extra entries) in skbuff.h.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Noticed by Stephen Rothwell.
Signed-off-by: David S. Miller <davem@davemloft.net>

If socket destuction gets delayed to a timer, we try to
lock_sock() from that timer which won't work.

Use bh_lock_sock() in that case.
Signed-off-by: David S. Miller <davem@davemloft.net>
Tested-by: Ingo Molnar <mingo@elte.hu>

The code to compute VPD size didn't handle some systems that use
chip without VPD. Also some of the newer chips use some additional
registers to store the actual size, and wasn't worth putting the
additional complexity in, so just remove the code.

No big loss since the code to set the VPD size was only a
convenience so that utilities would not read the extra space past
the end of the available VPD.

Move the first PCI config read earlier to detect bad hardware
where it returns all ones and refuse loading driver before furthur
damage.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Tested-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

When changing to a new BSSID or SSID, the code in
ieee80211_set_disassoc() needs to have the old data
still valid to be able to disconnect and clean up
properly. Currently, however, the old data is thrown
away before ieee80211_set_disassoc() is ever called,
so fix that by calling the function _before_ the old
data is overwritten.

This is (one of) the issue(s) causing mac80211 to hold
cfg80211's BSS structs forever, and them thus being
returned in scan results after they're long gone.

http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2015Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

If we are in PS mode, we have to process the received frame if
the SC_OP_WAIT_FOR_CAB bit is set.

Changes-licensed-under: ISC
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

We have to remain awake if the SC_OP_WAIT_FOR_CAB flag is set.

Changes-licensed-under: ISC
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The ath9k_ps_{wakeup,restore} calls must be in balance.

Changes-licensed-under: ISC
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

A polarity error snuck into the rfkill rewrite's dell-laptop
conversion, fix it.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Tested-by: Oliver Hartkopp <oliver@hartkopp.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Now that the dust has settled a bit, improve the docs on rfkill
and include more information about /dev/rfkill.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

If we do not disconnect when a channel switch is requested,
we end up eventually detection beacon loss from the AP and
then disconnecting, without ever really telling the AP, so
we might just as well disconnect right away.

Additionally, this fixes a problem with iwlwifi where the
driver will clear some internal state on channel changes
like this and then get confused when we actually go clear
that state from mac80211.

It may look like this patch drops the no-IBSS check, but
that is already handled by cfg80211 in the wext handler it
provides for IBSS (cfg80211_ibss_wext_siwfreq).
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

I suspect that some driver bugs can cause queues to be
stopped while they shouldn't be, but it's hard to find
out whether that is the case or not without having any
visible information about the queues. This adds a file
to debugfs that allows us to see the queues' statuses.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This ports the ath9k rfkill code to the new API offered by
cfg80211 and thus removes a lot of useless stuff.

("With this series a kernel panic, which is a regression, during module
unload disappears." -- Vasanthakumar Thiagarajan <vasanth@atheros.com>

Other patches in the series:

  ath9k: Add helper to get ath9k specific current channel
  ath9k: Make sure we have current channel in ah_curchan before rf
    disable/enable

-- JWL)
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Luis Rodriguez <mcgrof@gmail.com>
Tested-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

This patch is from Nick Kossifidis but he forgot to send it.  It ensures
that the beacon queue gets started in mesh mode as well, otherwise ath5k
will not beacon in mesh point mode.

At this time, we still need to issue a scan before mesh beaconing will
work but that appears to be a separate problem.
Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Patch fixes the following bugs at
http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2005
http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2007

If we suspend with an association and then resumed,
we need to synchronize the active rxon with staging rxon,
else we will get an error when iwl_alive_start try to commit
rxon and staging is set to channel 0. Before going to suspend
staging and active rxon are in sync. After resuming from the
suspend, iwl_mac_start is called and it clears the staging
rxon. Patch fixes the bug by not clearing the staging rxon
in iwl_mac_start.

Patch also adds similar fix to 3945.
Signed-off-by: Abhijeet Kolekar <abhijeet.kolekar@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

for both mixed and pure 40MHz, need to check for valid channel location.
if the specified channel not allow the channel location requested
(ABOVE, BELOW), then reject the Fat channel access

This fixes http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1988

("iwlwifi: checking for 40MHz mode" and "iwlwifi: check control channel
for pure 40MHz" combine with this to address the above bug. -- JWL)
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

for pure 40MHz mode, set the control channel location if provided, but not
like Mixed mode; if information is not provided, still allow 40MHz
operation.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

when checking for 40MHz, compare ht_protection to
IEEE80211_HT_OP_MODE_PROTECTION_20MHZ. ht_protection is not a bit-mask
field
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

My earlier patch,
	"mac80211: unify config_interface and bss_info_changed"
introduced a bug in iwlwifi where it will do some things
incorrectly now when reassociating.

Revamp iwl_bss_info_changed to fix that issue and make it
easier to read. Also, while at it, add comments about things
that it should do but currently doesn't.

Finally, also improve the locking in the function.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

|BUG: spinlock recursion on CPU#0, lbs_spi_thread/1030
| lock: dee9a1bc, .magic: dead4ead, .owner: lbs_spi_thread/1030, .owner_cpu: 0
|Call Trace:
|[deec3eb0] [c0007220] show_stack+0x4c/0x15c (unreliable)
|[deec3ef0] [c0187720] spin_bug+0x9c/0xb0
|[deec3f10] [c0187890] _raw_spin_lock+0x54/0x148
|[deec3f40] [c02d260c] _spin_lock_irqsave+0x2c/0x44
|[deec3f60] [e8671800] lbs_queue_event+0x7c/0x130 [libertas]
|[deec3f80] [e8725f04] lbs_spi_thread+0x538/0x58c [libertas_spi]
|[deec3fe0] [c004f270] kthread+0x4c/0x88
|[deec3ff0] [c000f33c] kernel_thread+0x4c/0x68

if_spi_e2h() is grabbing ->driver_lock just while calling
lbs_queue_event() which is grabbing the same lock.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

The card firmware does not set the Command Download Ready interrupt bit
when IEEE PS mode is enabled, preventing the driver from sending
commands (such as the command to exit IEEE PS mode) since there is no
indication that the card is ready to accept commands.

This patch works around the problem by using the the TX Download Ready
bit in place of the Command Download Ready Bit while in IEEE PS mode.
TX Download Ready is set in IEEE PS mode.
Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

It looks like some programs (e.g., NM) are setting an empty SSID with
SIOCSIWESSID in some cases. This seems to trigger mac80211 to try to
associate with an invalid configuration (wildcard SSID) which will
result in failing associations (or odd issues, potentially including
kernel panic with some drivers) if the AP were to actually accept this
anyway).

Only start association process if the SSID is actually set. This
speeds up connection with NM in number of cases and avoids sending out
broken association request frames.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

When the hard state changes, we shouldn't set the soft
state to blocked as well -- we have no such indication
from the device in that case so leave it untouched.

Fixes http://bugzilla.kernel.org/show_bug.cgi?id=13458.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Reported-by: Reinette Chatre <reinette.chatre@intel.com>
Tested-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Conflicts:
	Documentation/feature-removal-schedule.txt
	drivers/scsi/fcoe/fcoe.c
	net/core/drop_monitor.c
	net/core/net-traces.c