rt2x00: move experimental on kconfig only to rt2800usb
These drivers have been around for a while, if there are issues
they should be reported. rt2800usb is still a bit flaky though.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
cancel_delayed_work_sync() and cancel_work_sync() are already being
used therefore already waiting for all pending work by the driver
to have been completed, no need to flush the mac80211 workqueue.
Cc: Christian Lamparter <chunkeey@web.de> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
This should fix suspend as mac80211 expects all work queued
to the mac80211 workqueue to be canceled at driver stop().
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Acked-by: Kalle Valo <kalle.valo@iki.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ar76c50x-usb: cancel promisc work during mac80211 stop
We weren't ever cancelling this.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Acked-by: Kalle Valo <kalle.valo@iki.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
We should be cancelling our work at the stop callback since
we are borrowing the mac80211 workqueue for our work. As it
stands mac80211 expects this for suspend purposes.
The ath9k specific virtual wiphy stuff need only be
cancelled only when the we have no secondary virtual wiphys.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k: re-order cancelling of work on mac80211 workqueue
ath9k uses the mac80211 workqueue for 4 different types of work:
* Led blink work
* TX hang monitoring work
* internal wiphy schedular work
* channel change work done for internal wiphy schedular
Since the internal wiphy schedular can end up kicking off some
channel channel change work we should first cancel the wiphy
schedular work and then the channel change work.
The TX hang work can be cancelled second since we're going down
anyway.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Mon, 27 Jul 2009 18:28:40 +0000 (20:28 +0200)]
mac80211: disable software retry for now
Pavel Roskin reported a problem that seems to be due to
software retry of already transmitted frames. It turns
out that we've never done that correctly, but due to
some recent changes it now crashes in the TX code. I've
added a comment in the patch that explains the problem
better and also points to possible solutions -- which
I can't implement right now.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Eric Dumazet [Thu, 30 Jul 2009 03:15:07 +0000 (03:15 +0000)]
neigh: Convert garbage collection from softirq to workqueue
Current neigh_periodic_timer() function is fired by timer IRQ, and
scans one hash bucket each round (very litle work in fact)
As we are supposed to scan whole hash table in 15 seconds, this means
neigh_periodic_timer() can be fired very often. (depending on the number
of concurrent hash entries we stored in this table)
Converting this to a workqueue permits scanning whole table, minimizing
icache pollution, and firing this work every 15 seconds, independantly
of hash table size.
This 15 seconds delay is not a hard number, as work is a deferrable one.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Hannes Eder [Sun, 2 Aug 2009 11:05:41 +0000 (11:05 +0000)]
IPVS: use pr_err and friends instead of IP_VS_ERR and friends
Since pr_err and friends are used instead of printk there is no point
in keeping IP_VS_ERR and friends. Furthermore make use of '__func__'
instead of hard coded function names.
Signed-off-by: Hannes Eder <heder@google.com> Acked-by: Simon Horman <horms@verge.net.au> Signed-off-by: David S. Miller <davem@davemloft.net>
The eeprom read & write commands currently check the E2P_CMD_LOADED_ bit is
set before allowing any operations. This prevents any reading or writing
unless a correctly programmed EEPROM is installed.
This patch removes the check, so it is possible to program blank EEPROMS
via ethtool.
Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This renames away a variable clash:
* ipv6_table[] is declared as a static global table;
* ipv6_sysctl_net_init() uses ipv6_table to refer/destroy dynamic memory;
* ipv6_sysctl_net_exit() also uses ipv6_table for the same purpose;
* both the two last functions call kfree() on ipv6_table.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
Dean Nelson [Fri, 31 Jul 2009 09:14:03 +0000 (09:14 +0000)]
vxge: return PCI_ERS_RESULT_DISCONNECT on permanent failure
PCI drivers that implement the struct pci_error_handlers' error_detected
callback should return PCI_ERS_RESULT_DISCONNECT if the state passed in is
pci_channel_io_perm_failure. This patch fixes the issue for vxge.
Signed-off-by: Dean Nelson <dnelson@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Dean Nelson [Fri, 31 Jul 2009 09:13:56 +0000 (09:13 +0000)]
s2io: return PCI_ERS_RESULT_DISCONNECT on permanent failure
PCI drivers that implement the struct pci_error_handlers' error_detected
callback should return PCI_ERS_RESULT_DISCONNECT if the state passed in is
pci_channel_io_perm_failure. This patch fixes the issue for s2io.
Signed-off-by: Dean Nelson <dnelson@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Dean Nelson [Fri, 31 Jul 2009 09:13:48 +0000 (09:13 +0000)]
qlge: return PCI_ERS_RESULT_DISCONNECT on permanent failure
PCI drivers that implement the struct pci_error_handlers' error_detected
callback should return PCI_ERS_RESULT_DISCONNECT if the state passed in is
pci_channel_io_perm_failure. This patch fixes the issue for qlge.
Signed-off-by: Dean Nelson <dnelson@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Dean Nelson [Fri, 31 Jul 2009 09:13:40 +0000 (09:13 +0000)]
ixgb: return PCI_ERS_RESULT_DISCONNECT on permanent failure
PCI drivers that implement the struct pci_error_handlers' error_detected
callback should return PCI_ERS_RESULT_DISCONNECT if the state passed in is
pci_channel_io_perm_failure. This patch fixes the issue for ixgb.
Signed-off-by: Dean Nelson <dnelson@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Dean Nelson [Fri, 31 Jul 2009 09:13:33 +0000 (09:13 +0000)]
igbvf: return PCI_ERS_RESULT_DISCONNECT on permanent failure
PCI drivers that implement the struct pci_error_handlers' error_detected
callback should return PCI_ERS_RESULT_DISCONNECT if the state passed in is
pci_channel_io_perm_failure. This patch fixes the issue for igbvf.
Signed-off-by: Dean Nelson <dnelson@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Dean Nelson [Fri, 31 Jul 2009 09:13:25 +0000 (09:13 +0000)]
bnx2x: return PCI_ERS_RESULT_DISCONNECT on permanent failure
PCI drivers that implement the struct pci_error_handlers' error_detected
callback should return PCI_ERS_RESULT_DISCONNECT if the state passed in is
pci_channel_io_perm_failure. This patch fixes the issue for bnx2x.
Signed-off-by: Dean Nelson <dnelson@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Dean Nelson [Fri, 31 Jul 2009 09:13:18 +0000 (09:13 +0000)]
bnx2: return PCI_ERS_RESULT_DISCONNECT on permanent failure
PCI drivers that implement the struct pci_error_handlers' error_detected
callback should return PCI_ERS_RESULT_DISCONNECT if the state passed in is
pci_channel_io_perm_failure. This patch fixes the issue for bnx2.
Signed-off-by: Dean Nelson <dnelson@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Dean Nelson [Fri, 31 Jul 2009 09:13:10 +0000 (09:13 +0000)]
atl1e: return PCI_ERS_RESULT_DISCONNECT on permanent failure
PCI drivers that implement the struct pci_error_handlers' error_detected
callback should return PCI_ERS_RESULT_DISCONNECT if the state passed in is
pci_channel_io_perm_failure. This patch fixes the issue for atl1e.
Signed-off-by: Dean Nelson <dnelson@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Dean Nelson [Fri, 31 Jul 2009 09:13:02 +0000 (09:13 +0000)]
atl1c: return PCI_ERS_RESULT_DISCONNECT on permanent failure
PCI drivers that implement the struct pci_error_handlers' error_detected
callback should return PCI_ERS_RESULT_DISCONNECT if the state passed in is
pci_channel_io_perm_failure. This patch fixes the issue for atl1c.
Signed-off-by: Dean Nelson <dnelson@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
be_mbox_db_ring() has been changed to be_mbox_notify() (to be consistent with
be_mcc_notify()) and struct be_mcc_cq_entry changed to be_mcc_compl
to be consistent with rx/tx_compl.
Signed-off-by: Sathya Perla <sathyap@serverengines.com> Signed-off-by: David S. Miller <davem@davemloft.net>
be2net: get rid of be_ctrl_info struct/abstraction
Currently only the be_ctrl_info struct ptr (instead of adapter) is
passed to all the routines in be_cmds.c. Instead pass be_adapter
ptr to allow access to all its fields. Merge the contents of struct be_ctrl_info
into be_adapter. The resulting code is simpler.
Signed-off-by: Sathya Perla <sathyap@serverengines.com> Signed-off-by: David S. Miller <davem@davemloft.net>
ixgbe: Fix RSC completion delay causing Rx interrupts to stop
When a user disables interrupt throttling with ethtool on 82599 devices,
the interrupt timer may not be re-enabled if hardware RSC is running. The
RSC completions in hardware don't complete before the next ITR event tries
to fire, so the ITR timer never gets re-armed. This patch increases the
amount of time between interrupts when throttling is disabled (rx-usecs =
0) when the hardware RSC deature is enabled.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
ixgbe: Fix usage of second flags bitmap when using LRO/RSC
A second set of feature flag bits was added, and the hardware RSC engine
flags were moved there. However, the code itself didn't make the move
completely to use the new bitmap.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Acked-by: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
ixgbe: Fix netpoll to be properly multiqueue aware
Our ndo_poll_controller callback is broken for anything but non-multiqueue
setups. This fixes that issue.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Neil Horman [Fri, 31 Jul 2009 01:52:15 +0000 (18:52 -0700)]
xfrm: select sane defaults for xfrm[4|6] gc_thresh
Choose saner defaults for xfrm[4|6] gc_thresh values on init
Currently, the xfrm[4|6] code has hard-coded initial gc_thresh values
(set to 1024). Given that the ipv4 and ipv6 routing caches are sized
dynamically at boot time, the static selections can be non-sensical.
This patch dynamically selects an appropriate gc threshold based on
the corresponding main routing table size, using the assumption that
we should in the worst case be able to handle as many connections as
the routing table can.
For ipv4, the maximum route cache size is 16 * the number of hash
buckets in the route cache. Given that xfrm4 starts garbage
collection at the gc_thresh and prevents new allocations at 2 *
gc_thresh, we set gc_thresh to half the maximum route cache size.
For ipv6, its a bit trickier. there is no maximum route cache size,
but the ipv6 dst_ops gc_thresh is statically set to 1024. It seems
sane to select a simmilar gc_thresh for the xfrm6 code that is half
the number of hash buckets in the v6 route cache times 16 (like the v4
code does).
Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Tue, 28 Jul 2009 23:43:08 +0000 (23:43 +0000)]
pppoe: fix /proc/net/pppoe
If a socket is hashed in last slot of pppoe hash table (PPPOE_HASH_SIZE-1)
we report it many times (up to filling seq buffer)
(Only the last socket of last slot)
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
vlan: allow creating vlan when real device is not up
There is no reason for the arbitrary restriction that device must be
up to create a vlan. This patch was added to Vyatta kernel to resolve startup
ordering issues where vlan's are created but real device was disabled.
Note: the vlan already correctly inherits the operstate from real device; so
if vlan is created and real device is marked down, the vlan is marked
down.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Use the %pI4 format string instead of %d.%d.%d.%d and NIPQUAD.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
In some cases with 57711E, depending on the functions unload sequence, other
functions MAC address could have been used to wake the system as well. Make sure
to block all but the current function if WoL is required by changing the mode
to single function WoL.
Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
bnx2x: Receive traffic that maches management filtering rules
Due to lack of configuration, if the BMC configures the chip to pass all
broadcast/multicast traffic to it, the host will not receive it. On top of
fixing it, also make sure that in promiscuous mode, the host will receive the
management traffic as well.
Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
x = \(kmalloc\|kcalloc\|kzalloc\)(...);
... when != x == NULL
when != x != NULL
when != (x || ...)
(
kfree(x)
|
f(...,C,...,x,...)
|
*f(...,x,...)
|
*x->f
)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk> Acked-by: Paul Moore <paul.moore@hp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Wrap dest IP hashing code with #ifdef CONFIG_INET,
this feature makes no sense without INET, but other
driver can still work.
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Wey-Yi Guy [Mon, 27 Jul 2009 20:50:15 +0000 (13:50 -0700)]
iwlwifi: debugFs to enable/disable HT40 support
Add debugfs file to enable/disable HT40(40MHz) channel support.
By default, 40MHz is supported if AP can support the function.
By echo "1" to "disable_ht40" file, iwlwifi driver will disable the
40MHz support and only allow 20MHz channel.
Because the information exchange happen during association time,
so enable/disable ht40 channel only can be performed when it is not
associated with AP.
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>
Johannes Berg [Mon, 27 Jul 2009 10:01:53 +0000 (12:01 +0200)]
cfg80211: self-contained wext handling where possible
Finally! This is what you've all been waiting for!
This patch makes cfg80211 take care of wext emulation
_completely_ by itself, drivers that don't need things
cfg80211 doesn't do yet don't even need to be aware of
wireless extensions.
This means we can also clean up mac80211's and iwm's
Kconfig and make it possible to build them w/o wext
now!
RIP wext.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Mon, 27 Jul 2009 10:01:50 +0000 (12:01 +0200)]
cfg80211: combine iwfreq implementations
Until now we implemented iwfreq for managed mode, we
needed to keep the implementations separate, but now
that we have all versions implemented we can combine
them and export just one handler.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Mon, 27 Jul 2009 08:33:31 +0000 (10:33 +0200)]
mac80211: verify info->control.vif is not NULL
When enqueuing packets on the internal packet queue, we
need to ensure that we have a valid vif pointer since
that is required since the net namespace work. Add some
assertions to verify this, but also don't crash is for
some reason we don't end up with a vif pointer -- warn
and drop the packet in all these cases.
Since this code touches a number of hotpaths, it is
intended to be temporary, or maybe configurable in the
future, at least the bit that is in the path that gets
hit for every packet, ieee80211_tx_pending().
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Mon, 27 Jul 2009 08:22:28 +0000 (10:22 +0200)]
cfg80211: fix disassoc while not associated
When trying to disassociate while not associated,
the kernel would crash rather than refusing the
operation, fix this;
Reported-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Helmut Schaa [Sat, 25 Jul 2009 15:25:51 +0000 (17:25 +0200)]
mac80211: fix an oops in ieee80211_scan_state_set_channel
Fix an oops in ieee80211_scan_state_set_channel which was triggered
if the last scanned channel was skipped (for example due to regulatory
restrictions) by returning to the decision state after each skipped
channel.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Sat, 25 Jul 2009 14:54:36 +0000 (16:54 +0200)]
nl80211: add missing parameter clearing
Jouni and Maxim reported an oops when using wpa_supplicant -Dnl80211,
which seems to be due to random data being contained in the crypto
settings for the assoc() command. This seems to be due to the missing
memset here, so add it -- it's certainly missing but I'm not 100%
certain that it will fix the problem.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
There is a small window where the mac80211 changes the IEEE80211_CONF_PS
flag, and then informs the driver about the change. We have a race
condition if we are checking the flag in the same time. Avoid it by
introducing a local variable, and using that instead of checking the
IEEE80211_CONF_PS flag directly.
This fix the problem reported by Luis:
http://article.gmane.org/gmane.linux.kernel.wireless.general/34363
Changes-licensed-under: ISC Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix this build error when CONFIG_AR9170_LEDS is not set
drivers/net/wireless/ath/ar9170/main.c:1296: error: 'struct ar9170' has
no member named 'led_work'
Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Sat, 25 Jul 2009 09:58:36 +0000 (11:58 +0200)]
mac80211: fix receiving deauth
Marcel reported a warning, which quite obviously comes
from an oversight in the code handling deauth frames,
and which resulted in multiple follow-up warnings due
to this missing handling. This patch adds the missing
deauth handling (telling cfg80211 about it) and also
removes the follow-up warnings since they could happen
due to races even if nothing is wrong. I've explained
the races in the comments.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Reported-by: Marcel Holtmann <marcel@holtmann.org> Tested-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Sat, 25 Jul 2009 08:54:13 +0000 (10:54 +0200)]
cfg80211: fix circular lock dependency (1)
Luis reported this lockdep complaint, that he had also
reported earlier but when trying to analyse I had been
locking at the wrong code, and never saw the problem:
(slightly abridged)
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.31-rc4-wl #6
-------------------------------------------------------
wpa_supplicant/3799 is trying to acquire lock:
(cfg80211_mutex){+.+.+.}, at: [<ffffffffa009246a>] cfg80211_get_dev_from_ifindex+0x1a/0x90 [cfg80211]
but task is already holding lock:
(rtnl_mutex){+.+.+.}, at: [<ffffffff81400ff2>] rtnl_lock+0x12/0x20
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
When looking at the correct code, the problem is quite
obvious. I'm not entirely sure which code paths lead
here, so until I can analyse it better let's just use
RCU to avoid the problem.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
iwlagn: fix sparse warning when compiling without debug
C [M] drivers/net/wireless/iwlwifi/iwl-core.o
drivers/net/wireless/iwlwifi/iwl-core.c:1341: warning:
‘iwl_dump_nic_error_log’ defined but not used
Reported-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
iwlagn: fix null pointer access during ucode load on 1000
Commit "iwlwifi: Handle new firmware file with ucode build number
in header" introduced new ucode header parsing routines, but
neglected to initialize these routines for 1000. The system thus goes
into infinite loop trying to load ucode, failing every time with a null
pointer exception as it tries to parse the header.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Tue, 28 Jul 2009 16:10:17 +0000 (18:10 +0200)]
mac80211: fix suspend
Jan reported that his b43-based laptop hangs during suspend.
The problem turned out to be mac80211 asking the driver to
stop the hardware before removing interfaces, and interface
removal caused b43 to touch the hardware (while down, which
causes the hang).
This patch fixes mac80211 to do reorder these operations to
have them in the correct order -- first remove interfaces
and then stop the hardware. Some more code is necessary to
be able to do so in a race-free manner, in particular it is
necessary to not process frames received during quiescing.
Reported-by: Jan Scholz <scholz@fias.uni-frankfurt.de> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
reads bss->rates[j] before checking bounds of index, and should use
ARRAY_SIZE to determine the size of the array.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Acked-by: Holger Schurig <hs4233@mail.mn-solutions.de> Acked-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Even though reverse path filter was changed from simple boolean to
trinary control, the loose mode only works if both all and device are
configured because of this logic error.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Pavel Machek [Fri, 24 Jul 2009 18:13:10 +0000 (11:13 -0700)]
iwlwifi: fix LED config option
IWLWIFI_LEDS option should certainly have help comment, and should
default to y.
Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Fri, 24 Jul 2009 18:13:06 +0000 (11:13 -0700)]
iwlwifi: remove command callback return value
No existing callbacks use anything other than the return
value 1, which means that the caller should free the
reply skb, so it seems safer in terms of not introducing
memory leaks to simply remove the return value and let
the caller always free the skb.
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>
Johannes Berg [Fri, 24 Jul 2009 18:13:05 +0000 (11:13 -0700)]
iwlwifi: fix up command sending
The current command sending in iwlwifi is a bit of a mess:
1) there is a struct, iwl_cmd, that contains both driver
and device data in a single packed structure -- this
is very confusing
2) the on-stack data and the command metadata share a
structure by embedding the latter in the former, which
is also rather confusing because it leads to weird
unions and similarly odd constructs
3) each txq always has enough space for 256 commands,
even if only 32 end up being used
This patch fixes these things:
1) rename iwl_cmd to iwl_device_cmd and keep track of
command metadata and device command separately, in
two arrays in each tx queue
2) remove the 'meta' member from iwl_host_cmd and only
put in the required members
3) allocate the cmd/meta arrays separately instead of
embedding them into the txq structure
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>
Wey-Yi Guy [Fri, 24 Jul 2009 18:13:04 +0000 (11:13 -0700)]
iwlwifi: Thermal Throttling debugfs function
Add debugfs function to display current thermal throttling status for
both Legacy and Advance Thermal Throttling Management
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>
Wey-Yi Guy [Fri, 24 Jul 2009 18:13:03 +0000 (11:13 -0700)]
iwlwifi: Thermal Throttling Management - part 2
Part 2 of Thermal Throttling Management -
Thermal Throttling feature is used to put NIC into low power state when
driver detect the Radio temperature reach pre-defined threshold
Two Thermal Throttling Management Methods; this patch introduce the
Advance Thermal Throttling:
TI-0: system power index, no tx/rx restriction, HT enabled
TI-1: power index 5, 1 spatial stream Tx, multiple spatial stream Rx, HT
enabled
TI-2: power index 5: 1 spatial stream Tx, 1 spatial stream Rx, HT
disabled
TI-CT-KILL: power index 5, no Tx, no Rx, HT disabled
For advance Thermal Throttling, CT_KILL_ENTER threshold and CT_KILL_EXIT
threshold are different; uCode will not stay awake until reach
CT_KILL_EXIT threshold.
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>
Wey-Yi Guy [Fri, 24 Jul 2009 18:13:02 +0000 (11:13 -0700)]
iwlwifi: Thermal Throttling Management - Part 1
Part 1 of Thermal Throttling Management -
Thermal Throttling feature is used to put NIC into low power state when
driver detect the Radio temperature reach pre-defined threshold
Two Thermal Throttling Management Methods; this patch introduce the
Legacy Thermal Management:
IWL_TI_0: normal temperature, system power state
IWL_TI_1: high temperature detect, low power state
IWL_TI_2: higher temperature detected, lower power state
IWL_TI_CT_KILL: critical temperature detected, lowest power state
Once get into CT_KILL state, uCode go into sleep, driver will stop all
the active queues, then move to IWL_TI_CT_KILL state; also set up 5
seconds timer to toggle CSR flag, uCode wake up upon CSR flag change,
then measure the temperature.
If temperature is above CT_KILL exit threshold, uCode go backto sleep;
if temperature is below CT_KILL exit threshold, uCode send Card State
Notification response with appropriate CT_KILL status flag, and uCode
remain awake, Driver receive Card State Notification Response and update
the card temperature to the CT_KILL exit threshold.
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>
Wey-Yi Guy [Fri, 24 Jul 2009 18:13:01 +0000 (11:13 -0700)]
iwlwifi: critical temperature enter/exit condition
If advance thermal throttling is used the driver need to pass both
"enter" and "exit" temperature to uCode.
Using different critical temperature threshold for legacy and advance
thermal throttling management based on the type of thermal throttling
method is used except 1000.
For 1000, it use advance thermal throttling critical temperature
threshold, but with legacy thermal management implementation until ucode
has the necessary implementations in place.
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>
Wey-Yi Guy [Fri, 24 Jul 2009 18:13:00 +0000 (11:13 -0700)]
iwlwifi: revert to active table when rate is not valid
When performing rate scaling, if detected that the new rate
index is invalid, clear the search_better_tbl flag
so it will not be stuck in the loop.
Since the search table is already set up in uCode,
we need to empty out the the search table;
revert back to the "active" rate and throughput info.
Also pass the "active" table setup to uCode to make
sure the rate scale is functioning correctly.
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>
The skb->cb virtual interface data wasn't being reset for
reuse so ath9k pooped out when trying to dereference the
private rate control info from the skb.
Reported-by: Davide Pesavento <davidepesa@gmail.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Fri, 24 Jul 2009 11:23:09 +0000 (13:23 +0200)]
mac80211: fix PS-poll response, race
When a station queries us for a PS-poll response, we wrongly
queue the frame on the virtual interface's queue rather than
the pending queue.
Additionally, fix a race condition where we could potentially
send multiple frames to the sleeping station due to using a
station flag rather than a packet flag. When converting to a
packet flag, we can also convert p54 and remove the filter
clearing we added for it.
(Also remove a now dead function)
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Reported-by: Bob Copeland <me@bobcopeland.com> Tested-by: Bob Copeland <me@bobcopeland.com> Cc: Christian Lamparter <chunkeey@web.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: fix MLME issuing of probe requests while scanning
We were issuing probe requests to the associated AP on the wrong
band by having our beacon timer loss trigger while we are scanning.
When we would scan the timer could hit and force us to send a
probe request to the AP but with a chance we'd be on the wrong band.
This leads to finding no usable bitrate but we should not get so
far on the xmit path. We should not be trying to send these probe
request frames so prevent ieee80211_mgd_probe_ap() from sending
these.
As it turns out all callers of ieee80211_mgd_probe_ap() need this
check so we just move the scan check there. This means we can remove
the recenlty added check during ieee80211_sta_monitor_work().
Additionally we now fix a race condition added by the patch
"mac80211: do not monitor the connection while scanning" which
had the same check in ieee80211_sta_conn_mon_timer(). The race
happens because the timer routine *does* a valid check for
scanning but after it queues work into the mac80211 workqueue
the work callback can kick off with scanning enabled and cause
the same issue we were trying to avoid.
The more appropriate solution would be to disable the respective
timers during scan and re-enable them after scan but requires more
complex code and testing.
Cc: Christian Lamparter <chunkeey@web.de> Cc: Larry Finger <Larry.Finger@lwfinger.net> Reported-by: Fabio Rossi <rossi.f@inwind.it> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Johannes Berg [Thu, 23 Jul 2009 14:50:16 +0000 (16:50 +0200)]
mac80211: fix mlme timeouts
When a new MLME work is created, its timeout is initialised
to 0. This is wrong, it could then be thought of as having
an actual timeout in the future (time_is_after_jiffies() can
return true). Instead, it should be initialised to jiffies
so that it will run right away as soon as the mlme work is
executed.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Reported-by: Luciano Roth Coelho <luciano.coelho@nokia.com> Reported-by: Alban Browaeys <prahal@yahoo.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Helmut Schaa [Thu, 23 Jul 2009 10:14:29 +0000 (12:14 +0200)]
cfg80211: increase scan result expire time
Using background scanning in mac80211 the time a scan needs to
finish can exceed 10 seconds. Hence, increase the scan results
expire time to 15 seconds which should be sufficient.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Helmut Schaa [Thu, 23 Jul 2009 10:14:20 +0000 (12:14 +0200)]
mac80211: rename scan_state to next_scan_state
Rename scan_state to next_scan_state to better reflect
what it is used for.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Helmut Schaa [Thu, 23 Jul 2009 11:18:01 +0000 (13:18 +0200)]
mac80211: implement basic background scanning
Introduce a new scan flag "SCAN_OFF_CHANNEL" which basically tells us
that we are currently on a different channel for scanning and cannot
RX/TX. "SCAN_SW_SCANNING" tells us that we are currently running a
software scan but we might as well be on the operating channel to RX/TX.
While "SCAN_SW_SCANNING" is set during the whole scan "SCAN_OFF_CHANNEL"
is set when leaving the operating channel and unset when coming back.
Introduce two new scan states "SCAN_LEAVE_OPER_CHANNEL" and
"SCAN_ENTER_OPER_CHANNEL" which basically implement the functionality we
need to leave the operating channel (send a nullfunc to the AP and stop
the queues) and enter it again (send a nullfunc to the AP and start the
queues again).
Enhance the scan state "SCAN_DECISION" to switch back to the operating
channel after each scanned channel. In the future it sould be simple
to enhance the decision state to scan as much channels in a row as the
qos latency allows us.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Helmut Schaa [Thu, 23 Jul 2009 10:14:04 +0000 (12:14 +0200)]
mac80211: Replace {sw, hw}_scanning variables with a bitfield
Use a bitfield to store the current scan mode instead of two boolean
variables {sw,hw}_scanning. This patch does not introduce functional
changes but allows us to enhance the scan flags later (for example
for background scanning).
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>