- 04 Dec, 2009 15 commits
-
-
Samuel Ortiz authored
This update follows the firmware engineers recommendations. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Reinette Chatre authored
The driver version number is a remnant from when there was an out-of-tree iwlwifi driver. Now that the driver forms part of kernel source we do not need a separate driver version. Instead, we now use the kernel version as driver version. We maintain the previous tags used to indicate which components the driver has been compiled with. 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>
-
Wey-Yi Guy authored
error_event_table_ptr is only set upon receipt of REPLY_ALIVE. Until then both event log and error log will fail. Add information to indicate which uCode encounter the failure case. 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 authored
In the process of improving uCode event logging capability, the new implementation was introduced without removing the existing implementation. The event log will be dumped to dmesg twice. Remove the old implementation to only log the event once upon sys assert or request by user. 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 authored
My gcc appears to be able to see past the function boundary and notices that the variable 'behaviour' could be used uninitialised: drivers/net/wireless/b43/leds.c: In function ‘b43_leds_register’: drivers/net/wireless/b43/leds.c:339: warning: ‘behaviour’ may be used uninitialized in this function drivers/net/wireless/b43/leds.c: In function ‘b43_leds_init’: drivers/net/wireless/b43/leds.c:262: warning: ‘behaviour’ may be used uninitialized in this function because b43_led_get_sprominfo() didn't initialise it in all cases. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Zhu Yi authored
Add PCI .shutdown method so that we can disable the device during shutdown or reboot. Without this, the reboot doesn't work well on some platforms. This fixes http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2124Tested-by: pablo <pablolm2005@gmail.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Kalle Valo authored
The regulatory messages in syslog look weird: kernel: cfg80211: Regulatory domain: US kernel: ^I(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) kernel: ^I(2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm) kernel: ^I(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm) kernel: ^I(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm) kernel: ^I(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm) kernel: ^I(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm) kernel: ^I(5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm) Indent them with four spaces instead of the tab character to get prettier output. Signed-off-by: Kalle Valo <kalle.valo@nokia.com> Acked: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Zhu Yi authored
When handling IWM_CMD_PMKID_FLUSH command, the bssid and pmkid in pmksa are all NULL. Check it before memcpy. Signed-off-by: Zhu Yi <yi.zhu@intel.com> Acked-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jouni Malinen authored
An earlier optimization on removing unnecessary traffic on cooked monitor interfaces ("mac80211: reduce the amount of unnecessary traffic on cooked monitor interfaces ") ended up removing quite a bit more than just unnecessary traffic. It was not supposed to remove TX status reporting for injected frames, but ended up doing it by checking the injected flag in skb->cb only after that field had been cleared with memset.. Fix this by taking a local copy of the injected flag before skb->cb is cleared. This broke user space applications that depend on getting TX status notifications for injected data frames. For example, STA inactivity poll from hostapd did not work and ended up kicking out stations even if they were still present. Signed-off-by: Jouni Malinen <j@w1.fi> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Gabor Juhos authored
Currently, the 2GHz band is enabled unconditionally, even if the device does not support it. Changes-licensed-under: ISC Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Michael Buesch authored
On BigEndian gcc complains: drivers/net/wireless/airo.c: In function ‘sniffing_mode’: drivers/net/wireless/airo.c:4809: warning: integer overflow in expression Fix this by doing the bitwise AND on the host-endian value. Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Gertjan van Wingerde authored
While reviewing the l2pad function to align both the header and the payload on a DMA-capable boundary a bug was discovered where the payload would not be properly aligned. The header_align value was used where the payload_align value should have been used. Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Jean Tourrilhes authored
I've just noticed that some events are no longer propagated for some wireless drivers. Basically, SET request with a extra payload for driver without commit handler. The fix is pretty simple, see attached. Actually, a few lines below this line, you will see that the event generation for simple SET (iwpoint-less ?) is done properly, and this other event generation does not need fixing. Signed-off-by: Jean Tourrilhes <jt@hpl.hp.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Larry Finger authored
For PPC architecture with PHY Revision < 3, a read of the register B43_MMIO_HWENABLED_LO will cause a CPU fault unless b43legacy_status() returns a value of 2 (B43legacy_STAT_STARTED); however, one finds that the driver is unable to associate after resuming from hibernation unless this routine returns 1. To satisfy both conditions, the routine is rewritten to return TRUE whenever b43legacy_status() returns a value < 2. This patch fixes the second problem listed in the postings for Red Hat Bugzilla #538523. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Larry Finger authored
The routine b43_is_hw_radio_enabled() has long been a problem. For PPC architecture with PHY Revision < 3, a read of the register B43_MMIO_HWENABLED_LO will cause a CPU fault unless b43_status() returns a value of 2 (B43_STAT_STARTED) (BUG 14181). Fixing that results in Bug 14538 in which the driver is unable to reassociate after resuming from hibernation because b43_status() returns 0. The correct fix would be to determine why the status is 0; however, I have not yet found why that happens. The correct value is found for my device, which has PHY revision >= 3. Returning TRUE when the PHY revision < 3 and b43_status() returns 0 fixes the regression for 2.6.32. This patch fixes the problem in Red Hat Bugzilla #538523. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Tested-by: Christian Casteyde <casteyde.christian@free.fr> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 28 Nov, 2009 25 commits
-
-
Samuel Ortiz authored
We need to implement the PMKSA API for proper WPA2 pre-auth and fast re-association. Our fullmac device generates all (re-)assoc IEs, and thus it needs the right PMKIDs. With this implementation we now get them from wpa_supplicant. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Samuel Ortiz authored
With the addition of the *_pmksa cfg80211 ops, we can now add the corresponding wireless extensions compatibility handler. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Samuel Ortiz authored
This is an interface to set, delete and flush PMKIDs through nl80211. Main users would be fullmac devices which firmwares are capable of generating the RSN IEs for the re-association requests, e.g. iwmc3200wifi. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
In my setups, ath9k's debugfs files are most of the time much more useful than the messages generated by enabling CONFIG_ATH_DEBUG along with the right debug flags. Since CONFIG_ATH_DEBUG comes with a noticeable overhead on embedded systems, this patch makes it possible to use the debugfs files without that option. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Enable logging of more configuration data when tracing is enabled. Except for the channel frequency this is only useful with the binary trace format, but that can be recorded and replayed with trace-cmd and I will be working on a plugin that reports all the information. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
As indicated by the comment, the aMPDU RX reorder code should logically be after ieee80211_rx_h_check(). The previous patch moved the code there, and this patch now hooks it up in that place by introducing a list of skbs that are then processed by the remaining handlers. The list may be empty if the function is buffering the skb to release it later. The only change needed to the RX data is that the crypto handler needs to clear the key that may be set from a previous loop iteration, and that not everything can be in the rx flags now. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This code should be part of RX handlers, so move it to the place where it belongs without changing it. A follow-up patch will do the changes to hook it up. The sole purpose of this code move is to make the other patch readable, it doesn't change the code at all except that it now requires a different static function declaration (which will go away too). Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
The RX flags should soon be used only for flags that cannot change within an a-MPDU, so move the cooked monitor flag into the RX status flags. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Alban Browaeys authored
This patch moves the works cleanup, scan and events to a cfg80211 dedicated workqueue. Platform driver like eeepc-laptop ought to use works to rfkill (as new rfkill does lock in rfkill_unregister and the platform driver is called from rfkill_switch_all which also lock the same mutex). This raise a new issue in itself that the work scheduled by the platform driver to the global worqueue calls wiphy_unregister which flush_work scan and event works (which thus flush works on the global workqueue inside a work on the global workqueue) and also put on hold the wdev_cleanup_work (which prevents the dev_put on netdev thus indefinite Usage count error on wifi device). Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Alban Browaeys <prahal@yahoo.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Holger Schurig authored
Signed-off-by: Holger Schurig <holgerschurig@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Holger Schurig authored
Signed-off-by: Holger Schurig <holgerschurig@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Holger Schurig authored
This moves mesh initialization, start/stop and rx/tx handling from into mesh.c. Signed-off-by: Holger Schurig <holgerschurig@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Holger Schurig authored
Signed-off-by: Holger Schurig <holgerschurig@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Holger Schurig authored
mesh.c will be the file where we concentrate all mesh-related code. This allows us to either add a KConfig entry for mesh and makes matters easier for the cfg80211 transition. Signed-off-by: Holger Schurig <holgerschurig@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Alexey Dobriyan authored
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Alexey Dobriyan authored
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Vivek Natarajan authored
Update the beacon queue parameters with best effort queue parameters for IBSS mode. This reduces the number of beacons generated by ath9k and ensures a fair beacon distribution when there are multiple IBSS stations. Also CWmin is quadrupled to achieve the expected percentage of distribution. Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
Atheros single stream AR9285 and AR9271 have half the PCU TX FIFO buffer size of that of dual stream devices. Dual stream devices have a max PCU TX FIFO size of 8 KB while single stream devices have 4 KB. Single stream devices have an issue though and require hardware only to use half of the amount of its capable PCU TX FIFO size, 2 KB and this requires a change in software. Technically a change would not have been required (except for frame burst considerations of 128 bytes) if these devices would have been able to use the full 4 KB of the PCU TX FIFO size but our systems engineers recommend 2 KB to be used only. We enforce this through software by reducing the max frame triggger level to 2 KB. Fixing the max frame trigger level should then have a few benefits: * The PER will now be adjusted as designed for underruns when the max trigger level is reached. This should help alleviate the bus as the rate control algorithm chooses a slower rate which should ensure frames are transmitted properly under high system bus load. * The poll we use on our TX queues should now trigger and work as designed for single stream devices. The hardware passes data from each TX queue on the PCU TX FIFO queue respecting each queue's priority. The new trigger level ensures this seeding of the PCU TX FIFO queue occurs as designed which could mean avoiding false resets and actually reseting hw correctly when a TX queue is indeed stuck. * Some undocumented / unsupported behaviour could have been triggered when the max trigger level level was being set to 4 KB on single stream devices. Its not clear what this issue was to me yet. Cc: Kyungwan Nam <kyungwan.nam@atheros.com> Cc: Bennyam Malavazi <bennyam.malavazi@atheros.com> Cc: Stephen Chen <stephen.chen@atheros.com> Cc: Shan Palanisamy <shan.palanisamy@atheros.com> Cc: Paul Shaw <paul.shaw@atheros.com> Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Benoit Papillault authored
Software padding is done on the TX path and software unpadding is done on the RX path. This patch corrects the position where the padding occurs. A specific function computes the pad position and this function is used in the TX and RX path. This patch has been tested by generating every possible 802.11 frames with every possible frame_control field and a varying length. This patch is useful for analyzing non standard 802.11 frames going over the air Signed-off-by: Benoit Papillault <benoit.papillault@free.fr> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
When mac80211 was telling us to go into Powersave we listened and immediately turned RX off. This meant hardware would not see the ACKs from the AP we're associated with and hardware we'd end up retransmiting the null data frame in a loop helplessly. Fix this by keeping track of the transmitted nullfunc frames and only when we are sure the AP has sent back an ACK do we go ahead and shut RX off. Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: Vivek Natarajan <Vivek.Natarajan@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Samuel Ortiz authored
The tx concatenation option works fine now, we no longer need the debugging option of disabling concatenation. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Samuel Ortiz authored
We add the stopped queue count and display to the tx queue debugfs entry. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Samuel Ortiz authored
To support 802.11n Tx aggregation support with iwmc3200 wifi, we have to handle the UMAC_CMD_OPCODE_STOP_RESUME_STA_TX notification from the UMAC. Before sending an AddBA, the UMAC synchronizes with the host in order to know what is the last Tx frame it's supposed to receive before it will be able to start the actual aggregation session. We thus have to keep track of the last sequence number that is scheduled for transmission on a particular RAxTID, send an answer to the UMAC with this sequence number. The UMAC then does the BA negociation and once it's done with it sends a new UMAC_CMD_OPCODE_STOP_RESUME_STA_TX notification to let us know that we can resume the Tx flow on the specified RAxTID. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Reviewed-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Zhu Yi authored
Set the wireless mode with regard to both the driver's configuration and the device's EEPROM result. Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Samuel Ortiz authored
The iwmc3200wifi eeprom contains information about the available PHYs on the chip. We should update our wireless_mode setting and profile according to it. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-