The calibration period is now invoked by triggering a software
interrupt from within the ISR by ath5k_hw_calibration_poll()
instead of via a timer.
However, the calibration interval isn't initialized before
interrupts are enabled, so we can have a situation where an
interrupt occurs before the interval is assigned, so the
interval is actually negative. As a result, the ISR will
arm a software interrupt to schedule the tasklet, and then
rearm it when the SWI is processed, and so on, leading to a
softlockup at modprobe time.
Move the initialization order around so the calibration interval
is set before interrupts are active. Another possible fix
is to schedule the tasklet directly from the poll routine,
but I think there are additional plans for the SWI.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There is no reason to signal a carrier off when doing a 802.11 scan.
Cc: Holger Schurig <holgerschurig@gmail.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
I noticed yesterday, because Jeff had noticed
a speed regression, cf. bug
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2138
that the SM PS settings for peers were wrong.
Instead of overwriting the SM PS settings with
the local bits, we need to keep the remote bits.
The bug was part of the original HT code from
over two years ago, but unfortunately nobody
noticed that it makes no sense -- we shouldn't
be overwriting the peer's setting with our own
but rather keep it intact when masking the peer
capabilities with our own.
While fixing that, I noticed that the masking of
capabilities is completely useless for most of
the bits, so also fix those other bits.
Finally, I also noticed that PSMP_SUPPORT no
longer exists in the final 802.11n version, so
also remove that.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
`queue' was unsigned so the test did not work.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Reviewed-by: Pavel Roskin <proski@gnu.org>
Acked-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The libertas driver copies the SSID buffer back to the wireless core and
appends a trailing NULL character for termination. This is
a) unnecessary because the buffer is allocated with kzalloc and is hence
already NULLed when this function is called, and
b) for priv->curbssparams.ssid_len == 32, it writes back one byte too
much which causes memory corruptions.
Fix this by removing the extra write.
Signed-off-by: Daniel Mack <daniel@caiaq.de>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Cc: Maithili Hinge <maithili@marvell.com>
Cc: Kiran Divekar <dkiran@marvell.com>
Cc: Michael Hirsch <m.hirsch@raumfeld.com>
Cc: netdev@vger.kernel.org
Cc: libertas-dev@lists.infradead.org
Cc: linux-wireless@lists.infradead.org
Cc: stable@kernel.org
Acked-by: Holger Schurig <holgerschurig@gmail.com>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
drivers/net/wireless/iwlwifi/iwl-tx.c: In function `iwl_hw_txq_ctx_free':
drivers/net/wireless/iwlwifi/iwl-tx.c:410: warning: suggest explicit braces to avoid ambiguous `else'
Cc: Zhu Yi <yi.zhu@intel.com>
Cc: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The MIB counters are disabled when doing a chip reset.
Since ANI depends on the MIB registers for its operation, relying
on the contents of said registers during HW reset results in sub-optimal
performance.
Cc: stable@kernel.org
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When TX DMA termination has failed, the HW has to be reset
completely. Doing a fast channel change in this case is insufficient.
Also, change the debug level of a couple of messages to FATAL.
Cc: stable@kernel.org
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The internal, driver-specific maintenance of sequence
numbers is applicable only for HT frames.
Also, remove comments that are not relevant anymore.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix typo. The index should be multiplied by the entry size, not 'and'-ed.
Found via code-inspection.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some devices have 40MHz operation disabled entirely. Ensure that driver do
not enable 40MHz operation if a channel does not allow this.
This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2135
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
CC: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Recent powersaving work resulted in power management ops being called
during EEPROM initialization. The lock used by these functions is not
initialized at this time. Ensure lock is initialized before it is used.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
we see from http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2125
that power saving does not work well on 3945. Since then power saving has
also been connected with association problems where an AP deathenticates a
3945 after it is unable to transmit data to it - this happens when 3945
enters power savings mode.
Disable power save support until issues are resolved.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
CC: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
I've also for a long time had a problem with the
temperature calculation code, which I had fixed
by byte-swapping the values, and now it turns out
that was the correct fix after all.
Also, any use of iwl_eeprom_query_addr() that is
for more than a u8 must be cast to little endian,
and some structs as well.
Fix all this. Again, no real impact on platforms
that already are little endian.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: stable@kernel.org
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The construct "le16_to_cpu((__force __le16)(r >> 16))" has
always bothered me when looking through the iwlwifi code,
it shouldn't be necessary to __force anything, and before
this code, "r" was obtained with an ioread32, which swaps
each of the two u16 values in it properly when swapping the
entire u32 value. I've had arguments about this code with
people before, but always conceded they were right because
removing it only made things not work at all on big endian
platforms.
However, analysing a failure of the OTP reading code, I now
finally figured out what is going on, and why my intuition
about that code being wrong was right all along.
It turns out that the 'priv->eeprom' u8 array really wants
to have the data in it in little endian. So the force code
above and all really converts *to* little endian, not from
it. Cf., for instance, the function iwl_eeprom_query16() --
it reads two u8 values and combines them into a u16, in a
little-endian way. And considering it more, it makes sense
to have the eeprom array as on the device, after all not
all values really are 16-bit values, the MAC address for
instance is not.
Now, what this really means is that all the annotations are
completely wrong. The eeprom reading code should fill the
priv->eeprom array as a __le16 array, with __le16 values.
This also means that iwl_read_otp_word() should really have
a __le16 pointer as the data argument, since it should be
filling that in a format suitable for priv->eeprom.
Propagating these changes throughout, iwl_find_otp_image()
is found to be, now obviously visible, defective -- it uses
the data returned by iwl_read_otp_word() directly as if it
was CPU endianness. Fixing that, which is this hunk of the
patch:
- next_link_addr = link_value * sizeof(u16);
+ next_link_addr = le16_to_cpu(link_value) * sizeof(u16);
is the only real change of this patch. Everything else is
just fixing the sparse annotations.
Also, the bug only shows up on big endian platforms with a
1000 series card. 5000 and previous series do not use OTP,
and 6000 series has shadow RAM support which means we don't
ever use the defective code on any cards but 1000.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: stable@kernel.org
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We've had many reports of rt61pci failures with powersaving enabled.
Therefore, as a stop-gap measure, disable powersaving of the rt61pci
until we have found a proper solution.
Also disable powersaving on rt2800pci as it most probably will show
the same problem.
Cc: stable@kernel.org
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
sizeof(iv16) and sizeof(iv32) are the sizes of pointers. Change them to
the size of the copied data.
Furthermore, iveiv_entry is a local structure that has just been
initialized and is not visible outside this function. Thus, there would
seem to be no point to copy data into it. The order of the arguments is
thus changed to copy the data into the parameters, which are provided as
pointers, suggesting in this case that they should be used to return values.
A simplified version of the semantic patch that finds the first problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression *x;
expression f;
type T;
@@
*f(...,(T)x,...)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
First, we copy/paste the padding stuff from ath9k_tx to ath_tx_cabq since it
needs to same kind of padding, but for internally generated beacons.
Next, software padding done on TX needs to be removed before calling
ieee80211_tx_status. The code was already there in ath_tx_complete but it
was wrong. Fix it by using ath9k_cmn_padpos. This later code has been
tested by sending packets to a monitor interface and reading packets from the
same interface.
Signed-off-by: Benoit PAPILLAULT <benoit.papillault@free.fr>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When trigger event log dumping from debugfs, the entire event log
should be dumped and the size should match the number of events being
dump.
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>
Recent commits "iwlwifi: remove power-wasting calls to apm_ops.init()" and
"iwlagn: power up device before initializing EEPROM" had the goal of
reducing device power consumption from the time the module is loaded until
the interface is brought up and the device's power saving mechanisms kick
in. The idea is that once the module is loaded there is no need for the
device to consume power until the interface is brought up.
With the current solution the device is only powered up during EEPROM read,
and then so also only if the EEPROM type is OTP. We have found that on
certain platforms even non-OTP devices require power to be up during EEPROM
read. On these platforms the driver never loads and the system log contains
the following:
iwlagn 0000:03:00.0: MAC is in deep sleep!. CSR_GP_CNTRL = 0x080403D8
We thus now power up all devices during EEPROM read.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In iwlwifi, priv->alloc_rxb_page is used to keep track of the Rx
pages allocated by the driver. This cleans up the page free routines
by introducing __iwl_free_pages/iwl_free_pages so that the accounting
is more accurate and less error prone. This also fixes two instances where
the counter was not updated.
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2800lib incorrectly detected whether RT2800USB was enabled because
it didn't account for a modularized RT2800USB driver.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As shown in Kernel Bugzilla #14761, doing a controller restart after a
fatal DMA error does not accomplish anything other than consume the CPU
on an affected system. Accordingly, substitute a meaningful message for
the restart.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> [2.6.32]
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Michael Buesch reports that his rtl8187 gives warnings on suspend
("queueing ieee80211 work while going to suspend" warnings), as rtl8187
can call ieee80211_queue_delayed_work after mac80211 is suspended.
This change enhances rtl8187 led code so we can avoid queuing work after
mac80211 is suspended: now we register a radio led and make additional
checks to ensure led is off/on properly as mac80211 wants.
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Without this we have no gaurantee of the integrity of the
EEPROM and are likely to encounter a lot of bogus bug reports
due to actual issues on the EEPROM. With the EEPROM checksum
check in place we can easily rule those issues out.
If you run patch during a revert *you* have a card with a busted
EEPROM and only older kernel will support that concoction. This
patch is a trade off between not accepitng bogus EEPROMs and
avoiding bogus bug reports allowing developers to focus instead
on real concrete issues.
If stable keeps bogus bug reports because of a possibly busted EEPROM
feel free to apply this there too.
Tested on an AR5414
Cc: stable@kernel.org
Cc: jirislaby@gmail.com
Cc: akpm@linux-foundation.org
Cc: rjw@sisk.pl
Cc: me@bobcopeland.com
Cc: david.quan@atheros.com
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Adds support for the WiFi activity LED on the Dell Vostro A860 laptop.
Signed-off-by: Shahar Or <shahar@shahar-or.co.il>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
A KERN_DEBUG didn't get removed when transitioning from printk to
pr_debug
Signed-off-by: David Kilroy <kilroyd@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There are different bits used to convey the setting of the rfkill
switch to the driver. The current driver only supports one of these
possibilities. These changes were derived from the latest version
of the vendor driver.
This patch fixes the regression noted in kernel Bugzilla #14743.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-and-tested-by: Antti Kaijanmäki <antti@kaijanmaki.net>
Tested-by: Hin-Tak Leung <hintak.leung@gmail.com>
Cc: Stable <stable@kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes a bug in ath9k's tx status check, which
caused mac80211 to consider regularly transmitted unicast frames
as un-acked.
When checking the ts_status field for errors, it needs to be masked
with ATH9K_TXERR_FILT, because this field also contains other fields
like ATH9K_TX_ACKED.
Without this patch, AP mode is pretty much unusable, as hostapd
checks the ACK status for the frames that it injects.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The FINALIZE_JOIN firmware command only looks at the first couple of
fields in the beacon, and therefore it's not necessary to complain if
the beacon is longer than 128 bytes.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When disassociating, mac80211 zeroes vif->bss_info.bssid before
calling our ->bss_info_changed(), but we need the BSSID to remove the
hardware station database entry for our AP, so we can't clear our
local copy of the BSSID until after we've done that.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Don't forget to call pci_disable_device() if pci_request_regions()
fails during probe.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The time between loading the helper image and starting to upload the
main firmware image should be at least 5 ms or so. We were doing an
msleep(1) before, and 1 ms appears to not be enough in almost all
cases, but building with HZ=100 has always masked this so far. Bumping
the msleep argument to 5 fixes firmware loading e.g. when HZ=1000.
Some firmware images need more than 200ms to initialize. Bump the
ready code timeout to 500ms to accommodate for this.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Before issuing any firmware commands, we wait for the transmit rings
to drain, to prevent control versus data path synchronization issues.
In some cases, this can end up taking longer than the current hardcoded
limit of 5 seconds, for example if the transmit rings are filled with
packets for a host that has dropped off the air and we end up
retransmitting every pending packet at the lowest rate a couple of
times.
This patch changes mwl8k_tx_wait_empty() to only bail out on timeout
expiry if there was no change in the number of packets pending in the
transmit rings during the waiting period. If at least one transmit
ring entry was reclaimed while we were waiting, we are apparently still
making progress, and we'll allow waiting for another timeout period.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Some firmware commands can under some circumstances take more than 2
seconds to complete. This patch bumps the timeout up to 10 seconds,
and prints a message whenever a command takes more than 2 seconds.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On 8366, bit 6 in the rx descriptor rate field indicates whether the
packet was received on a 20MHz or 40MHz channel, and is not part of
the MCS index. Handle this properly, which then prevents hitting the
WARN_ON and being dropped in ieee80211_rx().
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When inserting a DMA header into a packet for transmission,
mwl8k_add_dma_header() would blindly zero the addr4 field, which
is not a good idea if the packet being transmitted is actually a
4-address packet.
Also, if the transmitted packet was a 4-address with QoS packet,
the memmove() to do the needed header reshuffling would inadvertently
overwrite the first two bytes of the packet payload with the QoS field.
This fixes both of these issues.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Packets exchanged between the mwl8k driver and the firmware always
have a 4-address header without QoS field. For QoS packets, the QoS
field is passed to/from the firmware via the tx/rx descriptors.
We were handling this correctly on transmit, but not on receive -- if
a QoS packet was received, we would leave garbage in the QoS field in
the packet passed up to the stack, which is Bad(tm).
Also, if the packet received on the air was a 4-address without QoS
packet, we would forget to skb_pull the 2-byte DMA length prefix off.
This patch adds an argument to the ->rxd_process() receive descriptor
operation to retrieve the QoS field from the receive descriptor, and
extends mwl8k_remove_dma_header() to insert this field back into the
packet if the packet received is a QoS packet. It also fixes
mwl8k_remove_dma_header() to strip off the length prefix in all cases.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There exist 12 802.11b/g rates, but mwl8k supports two additional
(non-standard) rates, and includes those rates in rate bitmasks and
in its internal rate table that hardware rate indices index.
Commit "mwl8k: report rate and other information for received frames"
added one of the nonstandard rates to the mwl8k_rates table to make
the OFDM rates in the table line up with the rate indices that are
reported in the receive descriptor (so that we can just simply copy
the receive descriptor rate index into ieee80211_rx_status::rate_idx)
and bumped MWL8K_IEEE_LEGACY_DATA_RATES from 12 to 13, but this
screwed up the UPDATE_STADB command struct layout, as it also uses
that define, for its legacy_rates array.
To avoid having to convert rate indices and legacy rate bitmaps (e.g.
ieee80211_bss_conf::basic_rates) between the 12-rate mac80211 format
and the 14-rate mwl8k format, we'll report all 14 rates in our wiphy's
band, but filter out the nonstandard ones e.g. in the case of the
UPDATE_STADB command which only accepts 12 rates.
In the commands that accept 14 rates (SET_AID, SET_RATE), replace the
use of the MWL8K_RATE_INDEX_MAX_ARRAY define in the command struct by
the constant 14, to make it clearer that these commands accept 14 rates.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The MCS bitmaps in the SET_RATE command structure were of the wrong
size, due to use of the wrong define for the array length. Just
hardcode the lengths as 16, and do the same for the MCS bitmaps in
other command structures.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The bssid can be zero when null data template is set in wl1251_op_config().
It's enough, and especially safe, to set it once after association.
Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
bssid needs to be copied first in wl1251_op_bss_info_changed(), otherwise
templates will have incorrect bssid and power save will not work
correctly.
Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There was a warning from wl1251_op_bss_info_changed():
wl1251: WARNING Set ctsprotect failed 0
It was printed always, it's completely false and can be removed.
Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
CC [M] drivers/net/wireless/iwlwifi/iwl-tx.o
drivers/net/wireless/iwlwifi/iwl-tx.c: In function ‘iwl_tx_agg_stop’:
drivers/net/wireless/iwlwifi/iwl-tx.c:1356: warning: passing argument 1 of ‘ieee80211_stop_tx_ba_cb_irqsafe’ from incompatible pointer type
include/net/mac80211.h:2128: note: expected ‘struct ieee80211_vif *’ but argument is of type ‘struct ieee80211_hw *’
Signed-off-by: John W. Linville <linville@tuxdriver.com>
