- 21 Jan, 2011 37 commits
-
-
Jay Sternberg authored
the sram data dumped through the debugfs interface would only work properly when dumping data on even u32 boundaries and swap bytes based on endianness on that boundary making byte arrays impossible to read. now addresses are displayed at the start of every line and the data is displayed consistently if dumping 1 byte or 20 and regardless of what is the starting address. if no lenght given, address displayed is u32 in device format Signed-off-by: Jay Sternberg <jay.e.sternberg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
2000 series device has different HW rev, add it Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
Remove refernce of g2 and use offical number for hw rev. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
Remove Gen 2 from Kconfig file since 6005/6030/6150 series of products are released. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
Add 2000 series support to Kconfig Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
Add PCI ID supports for all 2000 series devices Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
Adding 2000 series devices supports, the 2000 series devices has many different SKUs which includes 1x1 and 2x2 devices,also with and without BT combo. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
Adding EEPROM version for 2000 series devices Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
Since 6005, 6030 and 6150 series are offical released, remove the reference to gen2x and use the product number instead. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Wey-Yi Guy authored
Instead of keeping track of LED blink speed in the driver, use the new mac80211 trigger and link it up with an LED classdev that we now register. This also allows users more flexibility in how they want to have the LED blink or not. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
-
Felix Fietkau authored
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
Simplify confusing code and get rid of an unnecessary variable. Signed-off-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
When beacons are being added or removed for an interface, ieee80211_beacon_get will sometimes not return a beacon. This is normal and should not result in useless logspam. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
Remove sc->curband because the band is already stored in the current channel. Signed-off-by: Bruno Randolf <br1@einfach.org> Acked-by: Bob Copeland <me@bobcopeland.com> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
sc->curmode is set but never used. Remove it and the helper function. Also the ath5k_rate_update which is refered to in the comment does not exist (any more?) so we don't need to setup the band in that place. Signed-off-by: Bruno Randolf <br1@einfach.org> Acked-by: Bob Copeland <me@bobcopeland.com> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
They are unused in ath5k and a more detailled definition is in ath/regd_common.h. Signed-off-by: Bruno Randolf <br1@einfach.org> Acked-by: Bob Copeland <me@bobcopeland.com> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
Add the 802.11j (20MHz channel width) channels to the allowed channels. This still does not enable 802.11j in ath5k since these frequencies are out of the configured range. A later patch will deal with that. Signed-off-by: Bruno Randolf <br1@einfach.org> Acked-by: Bob Copeland <me@bobcopeland.com> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
Rename ath5k_copy_channels() to ath5k_setup_channels() - nothing is copied here. Signed-off-by: Bruno Randolf <br1@einfach.org> Acked-by: Bob Copeland <me@bobcopeland.com> Acked-by: Nick Kossifidis <mickflemm@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
Use mac80211 channel mapping function instead of own homegrown version. Signed-off-by: Bruno Randolf <br1@einfach.org> Acked-by: Bob Copeland <me@bobcopeland.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ben Greear authored
Try all xmit queues until the hardware buffers are full. Signed-off-by: Ben Greear <greearb@candelatech.com> Acked-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ben Greear authored
Add a misc file to show hardware op-mode, irq setup, number of various types of VIFs and more. Also, previous patches were using the wrong xmit queue indexes. Change to use the internal ath9k indexes instead of the mac80211 queue indexes. Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Bruno Randolf authored
Extend channel to frequency mapping for 802.11j Japan 4.9GHz band, according to IEEE802.11 section 17.3.8.3.2 and Annex J. Because there are now overlapping channel numbers in the 2GHz and 5GHz band we can't map from channel to frequency without knowing the band. This is no problem as in most contexts we know the band. In places where we don't know the band (and WEXT compatibility) we assume the 2GHz band for channels below 14. This patch does not implement all channel to frequency mappings defined in 802.11, it's just an extension for 802.11j 20MHz channels. 5MHz and 10MHz channels as well as 802.11y channels have been omitted. The following drivers have been updated to reflect the API changes: iwl-3945, iwl-agn, iwmc3200wifi, libertas, mwl8k, rt2x00, wl1251, wl12xx. The drivers have been compile-tested only. Signed-off-by: Bruno Randolf <br1@einfach.org> Signed-off-by: Brian Prodoehl <bprodoehl@gmail.com> Acked-by: Luciano Coelho <coelho@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ben Greear authored
The system can get into a state where the xmit queue is stopped, but there are no packets pending, so the queue will not be restarted. Add logic to the xmit watchdog to attempt to restart the xmit logic if this situation is detected. Example 'dmesg' output: ath: txq: f4e723e0 axq_qnum: 2, mac80211_qnum: 2 axq_link: f4e996c8 pending frames: 1 axq_acq empty: 1 stopped: 0 axq_depth: 0 Attempting to restart tx logic. Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ben Greear authored
To try to figure out why xmit logic hangs. Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ben Greear authored
The stations hold the ath_node, which holds the tid and other xmit logic structures. In order to debug stuck xmit logic, we need a way to print out the tid state for the stations. Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ben Greear authored
Show counters for pkts sent directly to hardware and those queued in software. Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ben Greear authored
If the txq->axq_q is empty, the code was breaking out of the tx_processq logic without checking to see if it should transmit other queued AMPDU frames (txq->axq_acq). This patches ensures ath_txq_schedule is called. This needs review. Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ben Greear authored
Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ben Greear authored
Should help debug strange tx lockup type issues. Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ben Greear authored
Previous code left it NULL. Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ben Greear authored
I thought this might help track down stuck queues, etc. Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Ben Greear authored
This particular error isn't about multicast. Signed-off-by: Ben Greear <greearb@candelatech.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
The notification wait support code is shared between 4965 and other AGN devices, so 4965 also has to initialize the data structures for it, otherwise it crashes. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Previously I hacked this with an msleep(300) which was fine since we never had longer PAN time slots, but now that we will have them I need to fix that. Use the new notification wait support to properly wait for the WIPAN deactivation complete signal from the ucode. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
In order to implement waiting for notifications, add a structure that captures the information, and a list of such structures that will be traversed when a command is received from the ucode. Use sparse checking to make sure calls to the prepare/wait/cancel functions are always nested correctly. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
It's not used or likely to be needed from other files, so it can be static. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
- 19 Jan, 2011 3 commits
-
-
Felix Fietkau authored
When running as a 4-addr station against an AP that has the 4-addr VLAN interface and the main 3-addr AP interface bridged together, sometimes frames originating from the station were looping back from the 3-addr AP interface, causing the bridge code to emit warnings about receiving frames with its own source address. I'm not sure why this is happening yet, but I think it's a good idea to drop all frames (except 802.1x/EAP frames) that do not match the configured addressing mode, including 4-address frames sent to a 3-address station. User test reports indicate that the problem goes away with this patch. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Currently, mac80211 always advertises that it may send up to 64 subframes in an aggregate. This is fine, since it's the max, but might as well be set to zero instead since it doesn't have any information. However, drivers might have that information, so allow them to set a variable giving it, which will then be used. The default of zero will be fine since to the peer that means we don't know and it will just use its own limit for the buffer size. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
The aggregation code currently doesn't implement the buffer size negotiation. It will always request a max buffer size (which is fine, if a little pointless, as the mac80211 code doesn't know and might just use 0 instead), but if the peer requests a smaller size it isn't possible to honour this request. In order to fix this, look at the buffer size in the addBA response frame, keep track of it and pass it to the driver in the ampdu_action callback when called with the IEEE80211_AMPDU_TX_OPERATIONAL action. That way the driver can limit the number of subframes in aggregates appropriately. Note that this doesn't fix any drivers apart from the addition of the new argument -- they all need to be updated separately to use this variable! Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-