* [PATCH 2/3] compat-wireless: make compat-2.6.37.c build
From: Hauke Mehrtens @ 2010-08-17 18:31 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, Hauke Mehrtens
In-Reply-To: <1282069869-22300-1-git-send-email-hauke@hauke-m.de>
This is needed to set CONFIG_COMPAT_KERNEL_37
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
config.mk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/config.mk b/config.mk
index 777ebd3..edfeca2 100644
--- a/config.mk
+++ b/config.mk
@@ -20,7 +20,7 @@ endif
# as I suspect all users of this package want 802.11e (WME) and
# 802.11n (HT) support.
ifneq ($(wildcard $(KLIB_BUILD)/Makefile),)
-COMPAT_LATEST_VERSION = 35
+COMPAT_LATEST_VERSION = 37
KERNEL_SUBLEVEL := $(shell $(MAKE) -C $(KLIB_BUILD) kernelversion | sed -n 's/^2\.6\.\([0-9]\+\).*/\1/p')
COMPAT_VERSIONS := $(shell I=$(COMPAT_LATEST_VERSION); while [ "$$I" -gt $(KERNEL_SUBLEVEL) ]; do echo $$I; I=$$(($$I - 1)); done)
$(foreach ver,$(COMPAT_VERSIONS),$(eval CONFIG_COMPAT_KERNEL_$(ver)=y))
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/3] compat-wireless: deactivate namespace
From: Hauke Mehrtens @ 2010-08-17 18:31 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, Hauke Mehrtens
In-Reply-To: <1282069869-22300-1-git-send-email-hauke@hauke-m.de>
Namespace support was introduced with kernel 2.6.35 in struct class.
Deactivate it for older kernel.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
patches/32-remove-ns-type.patch | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
create mode 100644 patches/32-remove-ns-type.patch
diff --git a/patches/32-remove-ns-type.patch b/patches/32-remove-ns-type.patch
new file mode 100644
index 0000000..b35c927
--- /dev/null
+++ b/patches/32-remove-ns-type.patch
@@ -0,0 +1,28 @@
+--- a/net/wireless/sysfs.c
++++ b/net/wireless/sysfs.c
+@@ -110,12 +110,14 @@ static int wiphy_resume(struct device *d
+ return ret;
+ }
+
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35))
+ static const void *wiphy_namespace(struct device *d)
+ {
+ struct wiphy *wiphy = container_of(d, struct wiphy, dev);
+
+ return wiphy_net(wiphy);
+ }
++#endif
+
+ struct class ieee80211_class = {
+ .name = "ieee80211",
+@@ -127,8 +129,10 @@ struct class ieee80211_class = {
+ #endif
+ .suspend = wiphy_suspend,
+ .resume = wiphy_resume,
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35))
+ .ns_type = &net_ns_type_operations,
+ .namespace = wiphy_namespace,
++#endif
+ };
+
+ int wiphy_sysfs_init(void)
--
1.7.0.4
^ permalink raw reply related
* [PATCH 0/3] compat-wireless: miscellaneous fixes
From: Hauke Mehrtens @ 2010-08-17 18:31 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, Hauke Mehrtens
This was build tested in combination with the patches to compat.
Hauke Mehrtens (3):
compat-wireless: deactivate namespace
compat-wireless: make compat-2.6.37.c build
compat-wireless: fix hidp_output_raw_report
config.mk | 2 +-
patches/16-bluetooth.patch | 37 +++++++++++++++++++++++--------------
patches/32-remove-ns-type.patch | 28 ++++++++++++++++++++++++++++
3 files changed, 52 insertions(+), 15 deletions(-)
create mode 100644 patches/32-remove-ns-type.patch
^ permalink raw reply
* Re: [mac80211] minstrel_ht rate population
From: Felix Fietkau @ 2010-08-17 18:22 UTC (permalink / raw)
To: Michael Griepentrog; +Cc: linux-wireless
In-Reply-To: <AANLkTi=axa4jxYCodm4mhedtnauPzr5AJvD5Z2GssWdc@mail.gmail.com>
On 2010-08-17 7:37 PM, Michael Griepentrog wrote:
> Hi,
>
> I'm looking at minstrel_ht_get_rate() from the latest git, and I
> noticed that the rates are getting set into info->status.rates. Is
> this correct? My impression was that array gets populated by the
> driver after a successful transmission. ath9k's rate control algorithm
> uses the expected tx_info->control.rates. Minstrel_ht appears to still
> work, am I missing something?
That's technically a bug (I'll send a fix for this soon), but it doesn't
matter in practice, as info->control.rates always points to the same
location as info->status.rates.
- Felix
^ permalink raw reply
* [mac80211] minstrel_ht rate population
From: Michael Griepentrog @ 2010-08-17 17:37 UTC (permalink / raw)
To: linux-wireless
Hi,
I'm looking at minstrel_ht_get_rate() from the latest git, and I
noticed that the rates are getting set into info->status.rates. Is
this correct? My impression was that array gets populated by the
driver after a successful transmission. ath9k's rate control algorithm
uses the expected tx_info->control.rates. Minstrel_ht appears to still
work, am I missing something?
Thanks,
Michael Griepentrog
^ permalink raw reply
* Re: [RFT] BCM4312 users with DMA errors, please test!
From: Arthur Moreira @ 2010-08-17 15:49 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: b43-dev, linux-wireless
In-Reply-To: <AANLkTimYs3fcSTKYwa60P0_OtumBoHJidYFZuLhXeimZ@mail.gmail.com>
all right
but i try to test with pacience, but i am newer in module compilation and paths
if you create a topic only for the device 4353 is better.
and obvios, ever... sorry for the bad english, but a talk from brazil.
if you can, try to post the step by step for the path aplication..
for the diff file and the path file... i know to aply the path for the
path comand (path <# file)
but i dont know the essencial.
if you send me modules for test. tks.
and the steps
Arthur Moreira
2010/8/16 Gábor Stefanik <netrolller.3d@gmail.com>:
> 2010/8/16 Arthur Moreira <arthur.moreira@gmail.com>:
>> Ok, tks Gábor
>>
>> i will wait, i need much of this card working in monitor mode for
>> tests and demonstration and my organization. i work with security in
>> my city. and i dont want to plug another card, like usb ou pciexpreess
>> card than a original embedded.
>>
>> if you need a help to tests and beta version of driver or modules
>> call me
>>
>>
>> Arthur Moreira
>
> Well, I post any testing requests on the list, so you will probably
> see them here.
>
> Also, please use the Reply to All button when replying to a list!
>
>>
>> 2010/8/16 Gábor Stefanik <netrolller.3d@gmail.com>:
>>> 2010/8/16 Arthur Moreira <arthur.moreira@gmail.com>:
>>>> Hi,
>>>> I have a BCM4353 card, with the hybrid module wl work fine to find
>>>> and conect to networks.
>>>> But, a want to put the card in monitor mode.
>>>>
>>>> (my card is a 802.11bgN mini card, in a dell vostro)
>>>>
>>>> this path will help me? and.. how to aply the path? the comand path $#
>>>> < file ???
>>>> tks
>>>>
>>>>
>>>> Arthur Moreira
>>>>
>>>
>>> No, this patch is only for BCM4312 devices, not the BCM43224 that you
>>> have (there is no such thing as a "BCM4353" AFAIK - PCI device IDs
>>> don't map directly to chip IDs!). Your card is an N-PHY, probably
>>> revision 4 or 5 (you can see the revision by adding 14e4:4353 to the
>>> list of PCI IDs in ssb, then looking for the "FOUND UNSUPPORTED PHY"
>>> line in dmesg). We are working on N-PHYs, revisions <=2 will likely be
>>> usable soon; rev.3 and newer will take longer, however. (It is
>>> possible that this patch will also be needed for N-PHYs if they show
>>> similar DMA errors to the 4312, but it is certainly not enough to get
>>> N-PHYs to work.)
>>>
>>>>
>>>>
>>>>
>>>> 2010/8/16 Gábor Stefanik <netrolller.3d@gmail.com>:
>>>>> Hello Everyone!
>>>>>
>>>>> If you are experiencing DMA errors on a BCM4312, please test the
>>>>> attached patch. It implements the PCI-E SERDES workaround, which the
>>>>> hybrid driver is applying during early init to LP-PHY cards, and which
>>>>> is a good candidate for the cause of the DMA error.
>>>>> Note that this is not a final patch & it may cause collateral damage
>>>>> for non-4312 cards; if it helps the 4312 problem, I will submit a
>>>>> cleaned-up version.
>>>>>
>>>>> Thanks,
>>>>> Gábor
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
>>>
>>
>
>
>
> --
> Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
>
^ permalink raw reply
* Re: STA mode bandwidth issues
From: Johannes Berg @ 2010-08-17 14:48 UTC (permalink / raw)
To: ramakanth varala; +Cc: linux-wireless
In-Reply-To: <AANLkTikQ+mYbt1gEx7DkV8Jt=Mqe+ojLrUmPCfKKg4Fj@mail.gmail.com>
On Tue, 2010-08-17 at 20:10 +0530, ramakanth varala wrote:
> ifconfig ath0 down
> wlanconfig ath0 destroy
> wlanconfig ath0 create wlandev wifi0 wlanmode sta
> You'r views would be highly appreciated.
My view is that you shouldn't be using madwifi.
However, if you insist, you should ask any questions related to it on
the appropriate madwifi list, not here.
johannes
^ permalink raw reply
* STA mode bandwidth issues
From: ramakanth varala @ 2010-08-17 14:40 UTC (permalink / raw)
To: linux-wireless
Hello all,
I have the following setup.
HostPC <-eth-> STA <-Wifi-> AP <-eth-> WAN …. ServerPC
Our Target Board topology have three interfaces eth0 , br0 and ath0 .
eth0 physical interface through this HostPC is connected and eth0 is
in bridge of br0, ath0 is wireless interface ( acting as a wan
interface for the target board when it is in client mode, this is
outside of bridge)
HostPC will be getting the IP from DHCP running in the STA. After all
the client mode successfull setup following is the ips .
HostPC :192.168.1.2
br0:192.168.1.1
ath0 :192.168.3.2
AP : br0 interface ip is 192.168.3.1 , in AP br0 contain ath0 in it.
Iam configuring the sta mode by using following commands
ifconfig ath0 down
wlanconfig ath0 destroy
wlanconfig ath0 create wlandev wifi0 wlanmode sta
iwconfig ath0 key <wep key>
iwconfig ap <AP mac>
iwconfig ath0 rate auto
ifconfig ath0 up
my target board in running with mips linux of kernel version 2.6.20
and driver by atheros .
Here my concern is iam experiencing very very low bandwidth .
There are no inferences as such. If i take ftp for testing between
hostpc and server
after nearly 1mb of download from Hostpc ftp service is getting time out.
We sniffed the packets and observed that the type/subtype is set QoS Data.
Does this also contributes to the bandwidth issue
You'r views would be highly appreciated.
regards
^ permalink raw reply
* Re: [RFT] BCM4312 users with DMA errors, please test!
From: Chris Vine @ 2010-08-17 12:23 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, b43-dev
In-Reply-To: <4C69DF79.2020900@lwfinger.net>
On Mon, 16 Aug 2010 20:01:45 -0500
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> My wl came from hybrid-portsrc-x86_32-v5.60.48.36.tar.gz. My kernel is
> 2.6.36-rc1 from mainline.
>
> Very strange that a patch to ssb, which is a module that cannot even
> load due to being blacklisted, can cause this kind of problem. Are
> you warm or cold rebooting?
I am using the same version of wl.
On booting up my netbook this morning, I found that I get a wholesome
set of bugs reported by dmesg, even without wl available to the
kernel and with the ssb patch reverted. I think the ssb patch is an
innocent bystander which just happened first to reveal a bug in the
2.6.35.2 kernel. A lot seems to depend on the starting state of the
hardware - a cold boot in a stock 2.6.35.2 kernel will trigger it
(what I got this morning). A warm boot on a 2.6.35.2 kernel with the ssb
patch will also trigger it (what I got yesterday).
The fact that something tries to load a blacklisted wl module would
seem to show there is something fairly fundamentally amiss, possibly
with the ACPI code. In any event, the conclusion I have reached is that
the 2.6.35.2 kernel is hopelessly broken on my netbook hardware. I do
not now think there is any file system corruption: it just gave that
appearance because of the saving of the state of the machine between
warm boots.
Reverting to 2.6.35.1 solves this. Probably 2.6.36-rc1 would be OK as
well. I might later today try the ssb patch on the 2.6.35.1 kernel,
but it doesn't look as if it solves the DMA errors. However,
yesterday's tests clearly aren't conclusive about anything.
Chris
^ permalink raw reply
* [PATCH] mac80211-hwsim: allow configuring IBSS
From: Johannes Berg @ 2010-08-17 10:08 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
It will not look standard-compliant in a sniffer
because because it doesn't
* sync TSF
* adjust the TSF in beacons
* send beacons at TBTT
* cancel beacons when another phy sends
However, it does allow testing the configuration
and parts of the mac80211 code for IBSS and as
such is still useful.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/wireless/mac80211_hwsim.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- wireless-testing.orig/drivers/net/wireless/mac80211_hwsim.c 2010-08-17 11:53:00.000000000 +0200
+++ wireless-testing/drivers/net/wireless/mac80211_hwsim.c 2010-08-17 12:06:20.000000000 +0200
@@ -9,7 +9,8 @@
/*
* TODO:
- * - IBSS mode simulation (Beacon transmission with competition for "air time")
+ * - Add TSF sync and fix IBSS beacon transmission by adding
+ * competition for "air time" at TBTT
* - RX filtering based on filter configuration (data->rx_filter)
*/
@@ -620,7 +621,8 @@ static void mac80211_hwsim_beacon_tx(voi
hwsim_check_magic(vif);
if (vif->type != NL80211_IFTYPE_AP &&
- vif->type != NL80211_IFTYPE_MESH_POINT)
+ vif->type != NL80211_IFTYPE_MESH_POINT &&
+ vif->type != NL80211_IFTYPE_ADHOC)
return;
skb = ieee80211_beacon_get(hw, vif);
@@ -1295,6 +1297,7 @@ static int __init init_mac80211_hwsim(vo
hw->wiphy->interface_modes =
BIT(NL80211_IFTYPE_STATION) |
BIT(NL80211_IFTYPE_AP) |
+ BIT(NL80211_IFTYPE_ADHOC) |
BIT(NL80211_IFTYPE_MESH_POINT);
hw->flags = IEEE80211_HW_MFP_CAPABLE |
^ permalink raw reply
* [PATCH] wireless: move documentation books
From: Johannes Berg @ 2010-08-17 10:04 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
This moves mac80211 documentation into a new
802.11 bookset and also adds a cfg80211 book
to the set. All of this is rather incomplete,
but it's easier to work with big code moving
as a separate patch.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
Documentation/DocBook/80211.tmpl | 371 ++++++++++++++++++++++++++++++++++++
Documentation/DocBook/Makefile | 2
Documentation/DocBook/mac80211.tmpl | 337 --------------------------------
3 files changed, 372 insertions(+), 338 deletions(-)
--- wireless-testing.orig/Documentation/DocBook/mac80211.tmpl 2010-06-15 11:20:57.000000000 +0200
+++ /dev/null 1970-01-01 00:00:00.000000000 +0000
@@ -1,337 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
- "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
-
-<book id="mac80211-developers-guide">
- <bookinfo>
- <title>The mac80211 subsystem for kernel developers</title>
-
- <authorgroup>
- <author>
- <firstname>Johannes</firstname>
- <surname>Berg</surname>
- <affiliation>
- <address><email>johannes@sipsolutions.net</email></address>
- </affiliation>
- </author>
- </authorgroup>
-
- <copyright>
- <year>2007-2009</year>
- <holder>Johannes Berg</holder>
- </copyright>
-
- <legalnotice>
- <para>
- This documentation is free software; you can redistribute
- it and/or modify it under the terms of the GNU General Public
- License version 2 as published by the Free Software Foundation.
- </para>
-
- <para>
- This documentation is distributed in the hope that it will be
- useful, but WITHOUT ANY WARRANTY; without even the implied
- warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
- See the GNU General Public License for more details.
- </para>
-
- <para>
- You should have received a copy of the GNU General Public
- License along with this documentation; if not, write to the Free
- Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- MA 02111-1307 USA
- </para>
-
- <para>
- For more details see the file COPYING in the source
- distribution of Linux.
- </para>
- </legalnotice>
-
- <abstract>
-!Pinclude/net/mac80211.h Introduction
-!Pinclude/net/mac80211.h Warning
- </abstract>
- </bookinfo>
-
- <toc></toc>
-
-<!--
-Generally, this document shall be ordered by increasing complexity.
-It is important to note that readers should be able to read only
-the first few sections to get a working driver and only advanced
-usage should require reading the full document.
--->
-
- <part>
- <title>The basic mac80211 driver interface</title>
- <partintro>
- <para>
- You should read and understand the information contained
- within this part of the book while implementing a driver.
- In some chapters, advanced usage is noted, that may be
- skipped at first.
- </para>
- <para>
- This part of the book only covers station and monitor mode
- functionality, additional information required to implement
- the other modes is covered in the second part of the book.
- </para>
- </partintro>
-
- <chapter id="basics">
- <title>Basic hardware handling</title>
- <para>TBD</para>
- <para>
- This chapter shall contain information on getting a hw
- struct allocated and registered with mac80211.
- </para>
- <para>
- Since it is required to allocate rates/modes before registering
- a hw struct, this chapter shall also contain information on setting
- up the rate/mode structs.
- </para>
- <para>
- Additionally, some discussion about the callbacks and
- the general programming model should be in here, including
- the definition of ieee80211_ops which will be referred to
- a lot.
- </para>
- <para>
- Finally, a discussion of hardware capabilities should be done
- with references to other parts of the book.
- </para>
-<!-- intentionally multiple !F lines to get proper order -->
-!Finclude/net/mac80211.h ieee80211_hw
-!Finclude/net/mac80211.h ieee80211_hw_flags
-!Finclude/net/mac80211.h SET_IEEE80211_DEV
-!Finclude/net/mac80211.h SET_IEEE80211_PERM_ADDR
-!Finclude/net/mac80211.h ieee80211_ops
-!Finclude/net/mac80211.h ieee80211_alloc_hw
-!Finclude/net/mac80211.h ieee80211_register_hw
-!Finclude/net/mac80211.h ieee80211_get_tx_led_name
-!Finclude/net/mac80211.h ieee80211_get_rx_led_name
-!Finclude/net/mac80211.h ieee80211_get_assoc_led_name
-!Finclude/net/mac80211.h ieee80211_get_radio_led_name
-!Finclude/net/mac80211.h ieee80211_unregister_hw
-!Finclude/net/mac80211.h ieee80211_free_hw
- </chapter>
-
- <chapter id="phy-handling">
- <title>PHY configuration</title>
- <para>TBD</para>
- <para>
- This chapter should describe PHY handling including
- start/stop callbacks and the various structures used.
- </para>
-!Finclude/net/mac80211.h ieee80211_conf
-!Finclude/net/mac80211.h ieee80211_conf_flags
- </chapter>
-
- <chapter id="iface-handling">
- <title>Virtual interfaces</title>
- <para>TBD</para>
- <para>
- This chapter should describe virtual interface basics
- that are relevant to the driver (VLANs, MGMT etc are not.)
- It should explain the use of the add_iface/remove_iface
- callbacks as well as the interface configuration callbacks.
- </para>
- <para>Things related to AP mode should be discussed there.</para>
- <para>
- Things related to supporting multiple interfaces should be
- in the appropriate chapter, a BIG FAT note should be here about
- this though and the recommendation to allow only a single
- interface in STA mode at first!
- </para>
-!Finclude/net/mac80211.h ieee80211_vif
- </chapter>
-
- <chapter id="rx-tx">
- <title>Receive and transmit processing</title>
- <sect1>
- <title>what should be here</title>
- <para>TBD</para>
- <para>
- This should describe the receive and transmit
- paths in mac80211/the drivers as well as
- transmit status handling.
- </para>
- </sect1>
- <sect1>
- <title>Frame format</title>
-!Pinclude/net/mac80211.h Frame format
- </sect1>
- <sect1>
- <title>Packet alignment</title>
-!Pnet/mac80211/rx.c Packet alignment
- </sect1>
- <sect1>
- <title>Calling into mac80211 from interrupts</title>
-!Pinclude/net/mac80211.h Calling mac80211 from interrupts
- </sect1>
- <sect1>
- <title>functions/definitions</title>
-!Finclude/net/mac80211.h ieee80211_rx_status
-!Finclude/net/mac80211.h mac80211_rx_flags
-!Finclude/net/mac80211.h ieee80211_tx_info
-!Finclude/net/mac80211.h ieee80211_rx
-!Finclude/net/mac80211.h ieee80211_rx_irqsafe
-!Finclude/net/mac80211.h ieee80211_tx_status
-!Finclude/net/mac80211.h ieee80211_tx_status_irqsafe
-!Finclude/net/mac80211.h ieee80211_rts_get
-!Finclude/net/mac80211.h ieee80211_rts_duration
-!Finclude/net/mac80211.h ieee80211_ctstoself_get
-!Finclude/net/mac80211.h ieee80211_ctstoself_duration
-!Finclude/net/mac80211.h ieee80211_generic_frame_duration
-!Finclude/net/mac80211.h ieee80211_wake_queue
-!Finclude/net/mac80211.h ieee80211_stop_queue
-!Finclude/net/mac80211.h ieee80211_wake_queues
-!Finclude/net/mac80211.h ieee80211_stop_queues
- </sect1>
- </chapter>
-
- <chapter id="filters">
- <title>Frame filtering</title>
-!Pinclude/net/mac80211.h Frame filtering
-!Finclude/net/mac80211.h ieee80211_filter_flags
- </chapter>
- </part>
-
- <part id="advanced">
- <title>Advanced driver interface</title>
- <partintro>
- <para>
- Information contained within this part of the book is
- of interest only for advanced interaction of mac80211
- with drivers to exploit more hardware capabilities and
- improve performance.
- </para>
- </partintro>
-
- <chapter id="hardware-crypto-offload">
- <title>Hardware crypto acceleration</title>
-!Pinclude/net/mac80211.h Hardware crypto acceleration
-<!-- intentionally multiple !F lines to get proper order -->
-!Finclude/net/mac80211.h set_key_cmd
-!Finclude/net/mac80211.h ieee80211_key_conf
-!Finclude/net/mac80211.h ieee80211_key_alg
-!Finclude/net/mac80211.h ieee80211_key_flags
- </chapter>
-
- <chapter id="powersave">
- <title>Powersave support</title>
-!Pinclude/net/mac80211.h Powersave support
- </chapter>
-
- <chapter id="beacon-filter">
- <title>Beacon filter support</title>
-!Pinclude/net/mac80211.h Beacon filter support
-!Finclude/net/mac80211.h ieee80211_beacon_loss
- </chapter>
-
- <chapter id="qos">
- <title>Multiple queues and QoS support</title>
- <para>TBD</para>
-!Finclude/net/mac80211.h ieee80211_tx_queue_params
- </chapter>
-
- <chapter id="AP">
- <title>Access point mode support</title>
- <para>TBD</para>
- <para>Some parts of the if_conf should be discussed here instead</para>
- <para>
- Insert notes about VLAN interfaces with hw crypto here or
- in the hw crypto chapter.
- </para>
-!Finclude/net/mac80211.h ieee80211_get_buffered_bc
-!Finclude/net/mac80211.h ieee80211_beacon_get
- </chapter>
-
- <chapter id="multi-iface">
- <title>Supporting multiple virtual interfaces</title>
- <para>TBD</para>
- <para>
- Note: WDS with identical MAC address should almost always be OK
- </para>
- <para>
- Insert notes about having multiple virtual interfaces with
- different MAC addresses here, note which configurations are
- supported by mac80211, add notes about supporting hw crypto
- with it.
- </para>
- </chapter>
-
- <chapter id="hardware-scan-offload">
- <title>Hardware scan offload</title>
- <para>TBD</para>
-!Finclude/net/mac80211.h ieee80211_scan_completed
- </chapter>
- </part>
-
- <part id="rate-control">
- <title>Rate control interface</title>
- <partintro>
- <para>TBD</para>
- <para>
- This part of the book describes the rate control algorithm
- interface and how it relates to mac80211 and drivers.
- </para>
- </partintro>
- <chapter id="dummy">
- <title>dummy chapter</title>
- <para>TBD</para>
- </chapter>
- </part>
-
- <part id="internal">
- <title>Internals</title>
- <partintro>
- <para>TBD</para>
- <para>
- This part of the book describes mac80211 internals.
- </para>
- </partintro>
-
- <chapter id="key-handling">
- <title>Key handling</title>
- <sect1>
- <title>Key handling basics</title>
-!Pnet/mac80211/key.c Key handling basics
- </sect1>
- <sect1>
- <title>MORE TBD</title>
- <para>TBD</para>
- </sect1>
- </chapter>
-
- <chapter id="rx-processing">
- <title>Receive processing</title>
- <para>TBD</para>
- </chapter>
-
- <chapter id="tx-processing">
- <title>Transmit processing</title>
- <para>TBD</para>
- </chapter>
-
- <chapter id="sta-info">
- <title>Station info handling</title>
- <sect1>
- <title>Programming information</title>
-!Fnet/mac80211/sta_info.h sta_info
-!Fnet/mac80211/sta_info.h ieee80211_sta_info_flags
- </sect1>
- <sect1>
- <title>STA information lifetime rules</title>
-!Pnet/mac80211/sta_info.c STA information lifetime rules
- </sect1>
- </chapter>
-
- <chapter id="synchronisation">
- <title>Synchronisation</title>
- <para>TBD</para>
- <para>Locking, lots of RCU</para>
- </chapter>
- </part>
-</book>
--- wireless-testing.orig/Documentation/DocBook/Makefile 2010-06-15 11:20:57.000000000 +0200
+++ wireless-testing/Documentation/DocBook/Makefile 2010-06-15 11:21:01.000000000 +0200
@@ -12,7 +12,7 @@ DOCBOOKS := z8530book.xml mcabook.xml de
kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
- mac80211.xml debugobjects.xml sh.xml regulator.xml \
+ 80211.xml debugobjects.xml sh.xml regulator.xml \
alsa-driver-api.xml writing-an-alsa-driver.xml \
tracepoint.xml media.xml drm.xml
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ wireless-testing/Documentation/DocBook/80211.tmpl 2010-06-15 11:21:01.000000000 +0200
@@ -0,0 +1,371 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE set PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
+ "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
+<set>
+ <setinfo>
+ <title>The 802.11 subsystems – for kernel developers</title>
+ <subtitle>
+ Explaining wireless 802.11 networking in the Linux kernel
+ </subtitle>
+
+ <copyright>
+ <year>2007-2009</year>
+ <holder>Johannes Berg</holder>
+ </copyright>
+
+ <authorgroup>
+ <author>
+ <firstname>Johannes</firstname>
+ <surname>Berg</surname>
+ <affiliation>
+ <address><email>johannes@sipsolutions.net</email></address>
+ </affiliation>
+ </author>
+ </authorgroup>
+
+ <legalnotice>
+ <para>
+ This documentation is free software; you can redistribute
+ it and/or modify it under the terms of the GNU General Public
+ License version 2 as published by the Free Software Foundation.
+ </para>
+ <para>
+ This documentation is distributed in the hope that it will be
+ useful, but WITHOUT ANY WARRANTY; without even the implied
+ warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ See the GNU General Public License for more details.
+ </para>
+ <para>
+ You should have received a copy of the GNU General Public
+ License along with this documentation; if not, write to the Free
+ Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ MA 02111-1307 USA
+ </para>
+ <para>
+ For more details see the file COPYING in the source
+ distribution of Linux.
+ </para>
+ </legalnotice>
+
+ <abstract>
+ <para>
+ These books attempt to give a description of the
+ various subsystems that play a role in 802.11 wireless
+ networking in Linux. Since these books are for kernel
+ developers they attempts to document the structures
+ and functions used in the kernel as well as giving a
+ higher-level overview.
+ </para>
+ <para>
+ The reader is expected to be familiar with the 802.11
+ standard as published by the IEEE in 802.11-2007 (or
+ possibly later versions). References to this standard
+ will be given as "802.11-2007 8.1.5".
+ </para>
+ </abstract>
+ </setinfo>
+ <book id="cfg80211-developers-guide">
+ <bookinfo>
+ <title>The cfg80211 subsystem</title>
+
+ <abstract>
+ <para>
+MISSING
+ </para>
+ </abstract>
+ </bookinfo>
+ <part><chapter>
+!Finclude/net/cfg80211.h ieee80211_band
+ </chapter></part>
+ </book>
+ <book id="mac80211-developers-guide">
+ <bookinfo>
+ <title>The mac80211 subsystem</title>
+ <abstract>
+!Pinclude/net/mac80211.h Introduction
+!Pinclude/net/mac80211.h Warning
+ </abstract>
+ </bookinfo>
+
+ <toc></toc>
+
+ <!--
+ Generally, this document shall be ordered by increasing complexity.
+ It is important to note that readers should be able to read only
+ the first few sections to get a working driver and only advanced
+ usage should require reading the full document.
+ -->
+
+ <part>
+ <title>The basic mac80211 driver interface</title>
+ <partintro>
+ <para>
+ You should read and understand the information contained
+ within this part of the book while implementing a driver.
+ In some chapters, advanced usage is noted, that may be
+ skipped at first.
+ </para>
+ <para>
+ This part of the book only covers station and monitor mode
+ functionality, additional information required to implement
+ the other modes is covered in the second part of the book.
+ </para>
+ </partintro>
+
+ <chapter id="basics">
+ <title>Basic hardware handling</title>
+ <para>TBD</para>
+ <para>
+ This chapter shall contain information on getting a hw
+ struct allocated and registered with mac80211.
+ </para>
+ <para>
+ Since it is required to allocate rates/modes before registering
+ a hw struct, this chapter shall also contain information on setting
+ up the rate/mode structs.
+ </para>
+ <para>
+ Additionally, some discussion about the callbacks and
+ the general programming model should be in here, including
+ the definition of ieee80211_ops which will be referred to
+ a lot.
+ </para>
+ <para>
+ Finally, a discussion of hardware capabilities should be done
+ with references to other parts of the book.
+ </para>
+ <!-- intentionally multiple !F lines to get proper order -->
+!Finclude/net/mac80211.h ieee80211_hw
+!Finclude/net/mac80211.h ieee80211_hw_flags
+!Finclude/net/mac80211.h SET_IEEE80211_DEV
+!Finclude/net/mac80211.h SET_IEEE80211_PERM_ADDR
+!Finclude/net/mac80211.h ieee80211_ops
+!Finclude/net/mac80211.h ieee80211_alloc_hw
+!Finclude/net/mac80211.h ieee80211_register_hw
+!Finclude/net/mac80211.h ieee80211_get_tx_led_name
+!Finclude/net/mac80211.h ieee80211_get_rx_led_name
+!Finclude/net/mac80211.h ieee80211_get_assoc_led_name
+!Finclude/net/mac80211.h ieee80211_get_radio_led_name
+!Finclude/net/mac80211.h ieee80211_unregister_hw
+!Finclude/net/mac80211.h ieee80211_free_hw
+ </chapter>
+
+ <chapter id="phy-handling">
+ <title>PHY configuration</title>
+ <para>TBD</para>
+ <para>
+ This chapter should describe PHY handling including
+ start/stop callbacks and the various structures used.
+ </para>
+!Finclude/net/mac80211.h ieee80211_conf
+!Finclude/net/mac80211.h ieee80211_conf_flags
+ </chapter>
+
+ <chapter id="iface-handling">
+ <title>Virtual interfaces</title>
+ <para>TBD</para>
+ <para>
+ This chapter should describe virtual interface basics
+ that are relevant to the driver (VLANs, MGMT etc are not.)
+ It should explain the use of the add_iface/remove_iface
+ callbacks as well as the interface configuration callbacks.
+ </para>
+ <para>Things related to AP mode should be discussed there.</para>
+ <para>
+ Things related to supporting multiple interfaces should be
+ in the appropriate chapter, a BIG FAT note should be here about
+ this though and the recommendation to allow only a single
+ interface in STA mode at first!
+ </para>
+!Finclude/net/mac80211.h ieee80211_vif
+ </chapter>
+
+ <chapter id="rx-tx">
+ <title>Receive and transmit processing</title>
+ <sect1>
+ <title>what should be here</title>
+ <para>TBD</para>
+ <para>
+ This should describe the receive and transmit
+ paths in mac80211/the drivers as well as
+ transmit status handling.
+ </para>
+ </sect1>
+ <sect1>
+ <title>Frame format</title>
+!Pinclude/net/mac80211.h Frame format
+ </sect1>
+ <sect1>
+ <title>Packet alignment</title>
+!Pnet/mac80211/rx.c Packet alignment
+ </sect1>
+ <sect1>
+ <title>Calling into mac80211 from interrupts</title>
+!Pinclude/net/mac80211.h Calling mac80211 from interrupts
+ </sect1>
+ <sect1>
+ <title>functions/definitions</title>
+!Finclude/net/mac80211.h ieee80211_rx_status
+!Finclude/net/mac80211.h mac80211_rx_flags
+!Finclude/net/mac80211.h ieee80211_tx_info
+!Finclude/net/mac80211.h ieee80211_rx
+!Finclude/net/mac80211.h ieee80211_rx_irqsafe
+!Finclude/net/mac80211.h ieee80211_tx_status
+!Finclude/net/mac80211.h ieee80211_tx_status_irqsafe
+!Finclude/net/mac80211.h ieee80211_rts_get
+!Finclude/net/mac80211.h ieee80211_rts_duration
+!Finclude/net/mac80211.h ieee80211_ctstoself_get
+!Finclude/net/mac80211.h ieee80211_ctstoself_duration
+!Finclude/net/mac80211.h ieee80211_generic_frame_duration
+!Finclude/net/mac80211.h ieee80211_wake_queue
+!Finclude/net/mac80211.h ieee80211_stop_queue
+!Finclude/net/mac80211.h ieee80211_wake_queues
+!Finclude/net/mac80211.h ieee80211_stop_queues
+ </sect1>
+ </chapter>
+
+ <chapter id="filters">
+ <title>Frame filtering</title>
+!Pinclude/net/mac80211.h Frame filtering
+!Finclude/net/mac80211.h ieee80211_filter_flags
+ </chapter>
+ </part>
+
+ <part id="advanced">
+ <title>Advanced driver interface</title>
+ <partintro>
+ <para>
+ Information contained within this part of the book is
+ of interest only for advanced interaction of mac80211
+ with drivers to exploit more hardware capabilities and
+ improve performance.
+ </para>
+ </partintro>
+
+ <chapter id="hardware-crypto-offload">
+ <title>Hardware crypto acceleration</title>
+!Pinclude/net/mac80211.h Hardware crypto acceleration
+ <!-- intentionally multiple !F lines to get proper order -->
+!Finclude/net/mac80211.h set_key_cmd
+!Finclude/net/mac80211.h ieee80211_key_conf
+!Finclude/net/mac80211.h ieee80211_key_alg
+!Finclude/net/mac80211.h ieee80211_key_flags
+ </chapter>
+
+ <chapter id="powersave">
+ <title>Powersave support</title>
+!Pinclude/net/mac80211.h Powersave support
+ </chapter>
+
+ <chapter id="beacon-filter">
+ <title>Beacon filter support</title>
+!Pinclude/net/mac80211.h Beacon filter support
+!Finclude/net/mac80211.h ieee80211_beacon_loss
+ </chapter>
+
+ <chapter id="qos">
+ <title>Multiple queues and QoS support</title>
+ <para>TBD</para>
+!Finclude/net/mac80211.h ieee80211_tx_queue_params
+ </chapter>
+
+ <chapter id="AP">
+ <title>Access point mode support</title>
+ <para>TBD</para>
+ <para>Some parts of the if_conf should be discussed here instead</para>
+ <para>
+ Insert notes about VLAN interfaces with hw crypto here or
+ in the hw crypto chapter.
+ </para>
+!Finclude/net/mac80211.h ieee80211_get_buffered_bc
+!Finclude/net/mac80211.h ieee80211_beacon_get
+ </chapter>
+
+ <chapter id="multi-iface">
+ <title>Supporting multiple virtual interfaces</title>
+ <para>TBD</para>
+ <para>
+ Note: WDS with identical MAC address should almost always be OK
+ </para>
+ <para>
+ Insert notes about having multiple virtual interfaces with
+ different MAC addresses here, note which configurations are
+ supported by mac80211, add notes about supporting hw crypto
+ with it.
+ </para>
+ </chapter>
+
+ <chapter id="hardware-scan-offload">
+ <title>Hardware scan offload</title>
+ <para>TBD</para>
+!Finclude/net/mac80211.h ieee80211_scan_completed
+ </chapter>
+ </part>
+
+ <part id="rate-control">
+ <title>Rate control interface</title>
+ <partintro>
+ <para>TBD</para>
+ <para>
+ This part of the book describes the rate control algorithm
+ interface and how it relates to mac80211 and drivers.
+ </para>
+ </partintro>
+ <chapter id="dummy">
+ <title>dummy chapter</title>
+ <para>TBD</para>
+ </chapter>
+ </part>
+
+ <part id="internal">
+ <title>Internals</title>
+ <partintro>
+ <para>TBD</para>
+ <para>
+ This part of the book describes mac80211 internals.
+ </para>
+ </partintro>
+
+ <chapter id="key-handling">
+ <title>Key handling</title>
+ <sect1>
+ <title>Key handling basics</title>
+!Pnet/mac80211/key.c Key handling basics
+ </sect1>
+ <sect1>
+ <title>MORE TBD</title>
+ <para>TBD</para>
+ </sect1>
+ </chapter>
+
+ <chapter id="rx-processing">
+ <title>Receive processing</title>
+ <para>TBD</para>
+ </chapter>
+
+ <chapter id="tx-processing">
+ <title>Transmit processing</title>
+ <para>TBD</para>
+ </chapter>
+
+ <chapter id="sta-info">
+ <title>Station info handling</title>
+ <sect1>
+ <title>Programming information</title>
+!Fnet/mac80211/sta_info.h sta_info
+!Fnet/mac80211/sta_info.h ieee80211_sta_info_flags
+ </sect1>
+ <sect1>
+ <title>STA information lifetime rules</title>
+!Pnet/mac80211/sta_info.c STA information lifetime rules
+ </sect1>
+ </chapter>
+
+ <chapter id="synchronisation">
+ <title>Synchronisation</title>
+ <para>TBD</para>
+ <para>Locking, lots of RCU</para>
+ </chapter>
+ </part>
+ </book>
+</set>
^ permalink raw reply
* [PATCH] iwlwifi: fix 3945 filter flags
From: Johannes Berg @ 2010-08-17 9:24 UTC (permalink / raw)
To: Alex Romosan; +Cc: Guy, Wey-Yi, linux-wireless@vger.kernel.org
In-Reply-To: <877hjqpl2e.fsf@sycorax.lbl.gov>
From: Johannes Berg <johannes.berg@intel.com>
Applying the filter flags directly as done since
commit 3474ad635db371b0d8d0ee40086f15d223d5b6a4
Author: Johannes Berg <johannes.berg@intel.com>
Date: Thu Apr 29 04:43:05 2010 -0700
iwlwifi: apply filter flags directly
broke 3945 under some unknown circumstances, as
reported by Alex.
Since I want to keep the direct application of
filter flags on iwlagn, duplicate the code into
both 3945 and agn and remove committing the
RXON that broke things from the 3945 version.
Cc: stable@kernel.org [2.6.35]
Reported-by: Alex Romosan <romosan@sycorax.lbl.gov>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-agn.c | 45 ++++++++++++++++++++++++
drivers/net/wireless/iwlwifi/iwl-core.c | 45 ------------------------
drivers/net/wireless/iwlwifi/iwl-core.h | 3 -
drivers/net/wireless/iwlwifi/iwl3945-base.c | 51 +++++++++++++++++++++++++++-
4 files changed, 94 insertions(+), 50 deletions(-)
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-agn.c 2010-08-17 11:08:50.000000000 +0200
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-agn.c 2010-08-17 11:10:50.000000000 +0200
@@ -3669,6 +3669,49 @@ out_exit:
IWL_DEBUG_MAC80211(priv, "leave\n");
}
+static void iwlagn_configure_filter(struct ieee80211_hw *hw,
+ unsigned int changed_flags,
+ unsigned int *total_flags,
+ u64 multicast)
+{
+ struct iwl_priv *priv = hw->priv;
+ __le32 filter_or = 0, filter_nand = 0;
+
+#define CHK(test, flag) do { \
+ if (*total_flags & (test)) \
+ filter_or |= (flag); \
+ else \
+ filter_nand |= (flag); \
+ } while (0)
+
+ IWL_DEBUG_MAC80211(priv, "Enter: changed: 0x%x, total: 0x%x\n",
+ changed_flags, *total_flags);
+
+ CHK(FIF_OTHER_BSS | FIF_PROMISC_IN_BSS, RXON_FILTER_PROMISC_MSK);
+ CHK(FIF_CONTROL, RXON_FILTER_CTL2HOST_MSK);
+ CHK(FIF_BCN_PRBRESP_PROMISC, RXON_FILTER_BCON_AWARE_MSK);
+
+#undef CHK
+
+ mutex_lock(&priv->mutex);
+
+ priv->staging_rxon.filter_flags &= ~filter_nand;
+ priv->staging_rxon.filter_flags |= filter_or;
+
+ iwlcore_commit_rxon(priv);
+
+ mutex_unlock(&priv->mutex);
+
+ /*
+ * Receiving all multicast frames is always enabled by the
+ * default flags setup in iwl_connection_init_rx_config()
+ * since we currently do not support programming multicast
+ * filters into the device.
+ */
+ *total_flags &= FIF_OTHER_BSS | FIF_ALLMULTI | FIF_PROMISC_IN_BSS |
+ FIF_BCN_PRBRESP_PROMISC | FIF_CONTROL;
+}
+
static void iwl_mac_flush(struct ieee80211_hw *hw, bool drop)
{
struct iwl_priv *priv = hw->priv;
@@ -3869,7 +3912,7 @@ static struct ieee80211_ops iwl_hw_ops =
.add_interface = iwl_mac_add_interface,
.remove_interface = iwl_mac_remove_interface,
.config = iwl_mac_config,
- .configure_filter = iwl_configure_filter,
+ .configure_filter = iwlagn_configure_filter,
.set_key = iwl_mac_set_key,
.update_tkip_key = iwl_mac_update_tkip_key,
.conf_tx = iwl_mac_conf_tx,
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-core.c 2010-08-17 11:08:18.000000000 +0200
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-core.c 2010-08-17 11:10:49.000000000 +0200
@@ -1328,51 +1328,6 @@ out:
EXPORT_SYMBOL(iwl_apm_init);
-
-void iwl_configure_filter(struct ieee80211_hw *hw,
- unsigned int changed_flags,
- unsigned int *total_flags,
- u64 multicast)
-{
- struct iwl_priv *priv = hw->priv;
- __le32 filter_or = 0, filter_nand = 0;
-
-#define CHK(test, flag) do { \
- if (*total_flags & (test)) \
- filter_or |= (flag); \
- else \
- filter_nand |= (flag); \
- } while (0)
-
- IWL_DEBUG_MAC80211(priv, "Enter: changed: 0x%x, total: 0x%x\n",
- changed_flags, *total_flags);
-
- CHK(FIF_OTHER_BSS | FIF_PROMISC_IN_BSS, RXON_FILTER_PROMISC_MSK);
- CHK(FIF_CONTROL, RXON_FILTER_CTL2HOST_MSK);
- CHK(FIF_BCN_PRBRESP_PROMISC, RXON_FILTER_BCON_AWARE_MSK);
-
-#undef CHK
-
- mutex_lock(&priv->mutex);
-
- priv->staging_rxon.filter_flags &= ~filter_nand;
- priv->staging_rxon.filter_flags |= filter_or;
-
- iwlcore_commit_rxon(priv);
-
- mutex_unlock(&priv->mutex);
-
- /*
- * Receiving all multicast frames is always enabled by the
- * default flags setup in iwl_connection_init_rx_config()
- * since we currently do not support programming multicast
- * filters into the device.
- */
- *total_flags &= FIF_OTHER_BSS | FIF_ALLMULTI | FIF_PROMISC_IN_BSS |
- FIF_BCN_PRBRESP_PROMISC | FIF_CONTROL;
-}
-EXPORT_SYMBOL(iwl_configure_filter);
-
int iwl_set_hw_params(struct iwl_priv *priv)
{
priv->hw_params.max_rxq_size = RX_QUEUE_SIZE;
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-core.h 2010-08-17 11:08:50.000000000 +0200
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-core.h 2010-08-17 11:08:57.000000000 +0200
@@ -372,9 +372,6 @@ int iwl_set_decrypted_flag(struct iwl_pr
u32 decrypt_res,
struct ieee80211_rx_status *stats);
void iwl_irq_handle_error(struct iwl_priv *priv);
-void iwl_configure_filter(struct ieee80211_hw *hw,
- unsigned int changed_flags,
- unsigned int *total_flags, u64 multicast);
int iwl_set_hw_params(struct iwl_priv *priv);
void iwl_post_associate(struct iwl_priv *priv, struct ieee80211_vif *vif);
void iwl_bss_info_changed(struct ieee80211_hw *hw,
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl3945-base.c 2010-08-17 11:08:50.000000000 +0200
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl3945-base.c 2010-08-17 11:11:30.000000000 +0200
@@ -3396,6 +3396,55 @@ static int iwl3945_mac_sta_add(struct ie
return 0;
}
+
+static void iwl3945_configure_filter(struct ieee80211_hw *hw,
+ unsigned int changed_flags,
+ unsigned int *total_flags,
+ u64 multicast)
+{
+ struct iwl_priv *priv = hw->priv;
+ __le32 filter_or = 0, filter_nand = 0;
+
+#define CHK(test, flag) do { \
+ if (*total_flags & (test)) \
+ filter_or |= (flag); \
+ else \
+ filter_nand |= (flag); \
+ } while (0)
+
+ IWL_DEBUG_MAC80211(priv, "Enter: changed: 0x%x, total: 0x%x\n",
+ changed_flags, *total_flags);
+
+ CHK(FIF_OTHER_BSS | FIF_PROMISC_IN_BSS, RXON_FILTER_PROMISC_MSK);
+ CHK(FIF_CONTROL, RXON_FILTER_CTL2HOST_MSK);
+ CHK(FIF_BCN_PRBRESP_PROMISC, RXON_FILTER_BCON_AWARE_MSK);
+
+#undef CHK
+
+ mutex_lock(&priv->mutex);
+
+ priv->staging_rxon.filter_flags &= ~filter_nand;
+ priv->staging_rxon.filter_flags |= filter_or;
+
+ /*
+ * Committing directly here breaks for some reason,
+ * but we'll eventually commit the filter flags
+ * change anyway.
+ */
+
+ mutex_unlock(&priv->mutex);
+
+ /*
+ * Receiving all multicast frames is always enabled by the
+ * default flags setup in iwl_connection_init_rx_config()
+ * since we currently do not support programming multicast
+ * filters into the device.
+ */
+ *total_flags &= FIF_OTHER_BSS | FIF_ALLMULTI | FIF_PROMISC_IN_BSS |
+ FIF_BCN_PRBRESP_PROMISC | FIF_CONTROL;
+}
+
+
/*****************************************************************************
*
* sysfs attributes
@@ -3801,7 +3850,7 @@ static struct ieee80211_ops iwl3945_hw_o
.add_interface = iwl_mac_add_interface,
.remove_interface = iwl_mac_remove_interface,
.config = iwl_mac_config,
- .configure_filter = iwl_configure_filter,
+ .configure_filter = iwl3945_configure_filter,
.set_key = iwl3945_mac_set_key,
.conf_tx = iwl_mac_conf_tx,
.reset_tsf = iwl_mac_reset_tsf,
^ permalink raw reply
* Re: nl80211 scanning from userspace
From: Johannes Berg @ 2010-08-17 8:51 UTC (permalink / raw)
To: Christopher Piggott; +Cc: linux-wireless
In-Reply-To: <AANLkTin90i08fbYeyrc17a7=smhshxR69=ushqUSkA0Z@mail.gmail.com>
On Mon, 2010-08-16 at 19:16 -0400, Christopher Piggott wrote:
> Forgive me if this is an obtuse question but why would one use
> nl_socket_add_membership, if all that isn't necessary to get back the
> scan results?
Well, you want to know when the scan finished, and for that you need to
be in the right group to receive the event when it finishes.
johannes
^ permalink raw reply
* Re: iwl3945 not associating on 2.6.35
From: Marcus Better @ 2010-08-17 7:10 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20100816145221.GB2656@tuxdriver.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
John W. Linville wrote:
> I'm not aware of this issue. Please open a bug at bugzilla.kernel.org.
https://bugzilla.kernel.org/show_bug.cgi?id=16610
Cheers,
Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkxqNcwACgkQXjXn6TzcAQknwQCgk+c05IofA8KG6J+OP9nGD4m1
E6MAoLQSThgPu0+8io9HUuBNISNIs5zX
=+wgZ
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 4/4] b43: N-PHY: Implement RX core state setting for rev.2 and earlier PHYs
From: Gábor Stefanik @ 2010-08-17 6:37 UTC (permalink / raw)
To: Michael Büsch
Cc: John Linville, linux-wireless, b43-dev, Larry Finger,
Rafał Miłecki
In-Reply-To: <4C69A3E4.1080807@bu3sch.de>
On Mon, Aug 16, 2010 at 10:47 PM, Michael Büsch <mb@bu3sch.de> wrote:
> On 08/16/2010 10:39 PM, Gábor Stefanik wrote:
>>
>> +static void b43_nphy_set_rx_core_state(struct b43_wldev *dev, u8 mask)
>> +{
>> + struct b43_phy *phy =&dev->phy;
>> + struct b43_phy_n *nphy = phy->n;
>> + u16 buf[16];
>
>> + if (maskbits& 0x3 != 0x3) {
>
> Does this even compile? I don't see maskbits being defined.
Typo, should be just "mask" (without "bits").
>
> --
> Greetings Michael.
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH 10/16] drivers/net/wireless/wl12xx: Use available error codes
From: Luciano Coelho @ 2010-08-17 5:42 UTC (permalink / raw)
To: ext Julia Lawall
Cc: John W. Linville, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <Pine.LNX.4.64.1008161827140.19313@ask.diku.dk>
On Mon, 2010-08-16 at 18:27 +0200, ext Julia Lawall wrote:
> From: Julia Lawall <julia@diku.dk>
>
> Error codes are stored in ret, but the return value is always 0. Return
> ret instead.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @r@
> local idexpression x;
> constant C;
> @@
>
> if (...) { ...
> x = -C
> ... when != x
> (
> return <+...x...+>;
> |
> return NULL;
> |
> return;
> |
> * return ...;
> )
> }
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
>
> ---
This was indeed a bug. Thanks!
Acked-by: Luciano Coelho <luciano.coelho@nokia.com>
--
Cheers,
Luca.
^ permalink raw reply
* Re: linux-next: manual merge of the wireless tree with Linus' tree
From: Stephen Rothwell @ 2010-08-17 3:07 UTC (permalink / raw)
To: Rusty Russell
Cc: John W. Linville, linux-wireless, linux-next, linux-kernel,
Dan Williams, libertas-dev, netdev, Takashi Iwai
In-Reply-To: <201008171229.46175.rusty@rustcorp.com.au>
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]
Hi Rusty,
On Tue, 17 Aug 2010 12:29:44 +0930 Rusty Russell <rusty@rustcorp.com.au> wrote:
>
> You can drop the commit as you have done. But it leaves three problematic
> writable charp parameters in the libertas/ directory which now need lifetime
> management.
>
> ie. kparam_block_sysfs_write()/unblock around them, and probably they need
> to be copied.
I figured that there was something needed, but I could not figure out where.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the wireless tree with Linus' tree
From: Rusty Russell @ 2010-08-17 2:59 UTC (permalink / raw)
To: Stephen Rothwell
Cc: John W. Linville, linux-wireless, linux-next, linux-kernel,
Dan Williams, libertas-dev, netdev, Takashi Iwai
In-Reply-To: <20100817115203.e8a76e44.sfr@canb.auug.org.au>
On Tue, 17 Aug 2010 11:22:03 am Stephen Rothwell wrote:
> Hi John,
>
> Today's linux-next merge of the wireless tree got a conflict in
> drivers/net/wireless/libertas/if_sdio.c between commit
> 886275ce41a9751117367fb387ed171049eb6148 ("param: lock if_sdio's
> lbs_helper_name and lbs_fw_name against sysfs changes") from Linus' tree
> and commit 3d32a58b87cd251b50842f93b87d5458061c0cfc ("libertas: [sdio]
> use common firmware request helper and new firmware locations") from the
> wireless tree.
>
> OK, I can't quite figure out what is going on here. The latter commit
> removes that code that was modified by the former, so I effectively
> reverted the former commit (by using this file from the wireless tree)
> since the "helper" and "firmware" fields of struct if_sdio_card don't
> seem to be used anywhere anymore. Can they be removed as well?
I'm looking at the wireless tree now.
You can drop the commit as you have done. But it leaves three problematic
writable charp parameters in the libertas/ directory which now need lifetime
management.
ie. kparam_block_sysfs_write()/unblock around them, and probably they need
to be copied.
Cheers,
Rusty.
^ permalink raw reply
* linux-next: manual merge of the wireless tree with Linus' tree
From: Stephen Rothwell @ 2010-08-17 1:52 UTC (permalink / raw)
To: John W. Linville, linux-wireless
Cc: linux-next, linux-kernel, Dan Williams, Rusty Russell,
libertas-dev, netdev, Takashi Iwai
[-- Attachment #1: Type: text/plain, Size: 893 bytes --]
Hi John,
Today's linux-next merge of the wireless tree got a conflict in
drivers/net/wireless/libertas/if_sdio.c between commit
886275ce41a9751117367fb387ed171049eb6148 ("param: lock if_sdio's
lbs_helper_name and lbs_fw_name against sysfs changes") from Linus' tree
and commit 3d32a58b87cd251b50842f93b87d5458061c0cfc ("libertas: [sdio]
use common firmware request helper and new firmware locations") from the
wireless tree.
OK, I can't quite figure out what is going on here. The latter commit
removes that code that was modified by the former, so I effectively
reverted the former commit (by using this file from the wireless tree)
since the "helper" and "firmware" fields of struct if_sdio_card don't
seem to be used anywhere anymore. Can they be removed as well?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [RFT] BCM4312 users with DMA errors, please test!
From: Larry Finger @ 2010-08-17 1:01 UTC (permalink / raw)
To: Chris Vine; +Cc: linux-wireless, b43-dev
In-Reply-To: <20100817011455.4919cfbb@boulder.homenet>
On 08/16/2010 07:14 PM, Chris Vine wrote:
>>
>> I have reproduced it twice. It is definitely the patch, in the sense
>> that it happens with the patch included (on two separate tests that I
>> have conducted) and never without.
>>
>> I do not doubt that you do not experience this effect. However, you
>> don't experience the DMA bug either.
>
> Out of interest, which version of the wl module do you have installed,
> as I wonder if that makes a difference? (As I said in my e-mail on
> this, this problem only occurs if the wl module is available to the
> kernel.)
My wl came from hybrid-portsrc-x86_32-v5.60.48.36.tar.gz. My kernel is
2.6.36-rc1 from mainline.
Very strange that a patch to ssb, which is a module that cannot even load due to
being blacklisted, can cause this kind of problem. Are you warm or cold rebooting?
Larry
^ permalink raw reply
* Compat-wireless for 2.6.36-rc1 release
From: Luis R. Rodriguez @ 2010-08-17 0:19 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth; +Cc: linux-kernel
Linus released 2.6.36-rc1 over the weekend. We've been following the
next kernel's development cycle through the master branch of both
compat-wireless.git and compat.git. I just created the branch for each
of those git trees for the 2.6.36.y release and put up the first
tarball for testing purposes:
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.36/compat-wireless-2.6.36-rc1-1.tar.bz2
Note that the extra -1 here accounts for the fact that we can have bug
fixes within compat-wireless.git and/or comat.git during one extra
version of the kernel or even during one rc release.You can find the
ChangeLog of what went in to this kernel by reading this:
http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.36/ChangeLog-2.6.36-rc1-wireless
Please report any issues, remember this is a stable kernel so if there
is a bug it should be reported ASAP.
compat-wireless code metrics
494638 - Total upstream lines of code being pulled
1699 - backport code changes
1460 - backport code additions
239 - backport code deletions
5979 - backport from compat module
7678 - total backport code
1.5522 - % of code consists of backport work
Base tree: linux-2.6-allstable.git
Base tree version: v2.6.36-rc1
compat-wireless release: compat-wireless-v2.6.36-rc1
If you have a bug fix for compat-wireless.git which also applies down
to the linux-2.6.36.y branch or a patch for compat.git that applies to
its respective linux-2.6.36.y branch please indicate it on the patch
you send. You can do so by marking the patch with this on the commit
log:
Applies-to: linux-2.6.35.y
for example if the fix was also required for the 2.6.35.y branch. You
can specify branch ranges as well.
Applies-to: linux-2.6.32.y-linux-2.6.35.y
I'll send out a full ChangeLog of the compat-wireless.git and
compat.git contributions for this release once we bake the final
2.6.36 release along with Linus.
This goes compile and load tested with ath9k using a 3x3 AR9003 card on 2.6.32.
Luis
^ permalink raw reply
* Re: [RFT] BCM4312 users with DMA errors, please test!
From: Chris Vine @ 2010-08-17 0:10 UTC (permalink / raw)
To: Larry Finger; +Cc: Gábor Stefanik, linux-wireless, b43-dev
In-Reply-To: <20100817010923.589d8063@boulder.homenet>
On Tue, 17 Aug 2010 01:09:23 +0100
Chris Vine <chris@cvine.freeserve.co.uk> wrote:
> On Mon, 16 Aug 2010 18:53:41 -0500
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
> > I tried to duplicate your boot problems without anything unexpected
> > happening.
> >
> > I don't know what happened, but I doubt that this ssb patch was
> > responsible.
>
> I have reproduced it twice. It is definitely the patch, in the sense
> that it happens with the patch included (on two separate tests that I
> have conducted) and never without.
>
> I do not doubt that you do not experience this effect. However, you
> don't experience the DMA bug either.
I probably also ought to say that this is with a stock 2.6.35.2
kernel. You may be using wireless testing, although I doubt that makes
a difference.
Chris
^ permalink raw reply
* Re: [RFT] BCM4312 users with DMA errors, please test!
From: Chris Vine @ 2010-08-17 0:09 UTC (permalink / raw)
To: Larry Finger; +Cc: Gábor Stefanik, linux-wireless, b43-dev
In-Reply-To: <4C69CF85.2020809@lwfinger.net>
On Mon, 16 Aug 2010 18:53:41 -0500
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> I tried to duplicate your boot problems without anything unexpected
> happening.
>
> I don't know what happened, but I doubt that this ssb patch was
> responsible.
I have reproduced it twice. It is definitely the patch, in the sense
that it happens with the patch included (on two separate tests that I
have conducted) and never without.
I do not doubt that you do not experience this effect. However, you
don't experience the DMA bug either.
Chris
^ permalink raw reply
* Re: [RFT] BCM4312 users with DMA errors, please test!
From: Chris Vine @ 2010-08-17 0:14 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, b43-dev
In-Reply-To: <20100817010923.589d8063@boulder.homenet>
On Tue, 17 Aug 2010 01:09:23 +0100
Chris Vine <chris@cvine.freeserve.co.uk> wrote:
> On Mon, 16 Aug 2010 18:53:41 -0500
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
> > I tried to duplicate your boot problems without anything unexpected
> > happening.
> >
> > I don't know what happened, but I doubt that this ssb patch was
> > responsible.
>
> I have reproduced it twice. It is definitely the patch, in the sense
> that it happens with the patch included (on two separate tests that I
> have conducted) and never without.
>
> I do not doubt that you do not experience this effect. However, you
> don't experience the DMA bug either.
Out of interest, which version of the wl module do you have installed,
as I wonder if that makes a difference? (As I said in my e-mail on
this, this problem only occurs if the wl module is available to the
kernel.)
Chris
^ permalink raw reply
* Re: [RFT] BCM4312 users with DMA errors, please test!
From: Larry Finger @ 2010-08-16 23:53 UTC (permalink / raw)
To: Chris Vine; +Cc: Gábor Stefanik, linux-wireless, b43-dev
In-Reply-To: <20100816233544.40f0e1d4@boulder.homenet>
On 08/16/2010 05:35 PM, Chris Vine wrote:
> On Mon, 16 Aug 2010 20:41:54 +0100
> Chris Vine <chris@cvine.freeserve.co.uk> wrote:
>
>> On Mon, 16 Aug 2010 19:59:36 +0200
>> Gábor Stefanik <netrolller.3d@gmail.com> wrote:
>>> Hello Everyone!
>>>
>>> If you are experiencing DMA errors on a BCM4312, please test the
>>> attached patch. It implements the PCI-E SERDES workaround, which the
>>> hybrid driver is applying during early init to LP-PHY cards, and
>>> which is a good candidate for the cause of the DMA error.
>>> Note that this is not a final patch & it may cause collateral damage
>>> for non-4312 cards; if it helps the 4312 problem, I will submit a
>>> cleaned-up version.
>>
>> This applies to 2.6.35.2, but does not compile:
>>
>> drivers/ssb/driver_pcicore.c: In function 'ssb_pcie_mdio_set_block':
>> drivers/ssb/driver_pcicore.c:457: error: 'i' undeclared (first use in
>> this function) drivers/ssb/driver_pcicore.c:457: error: (Each
>> undeclared identifier is reported only once
>> drivers/ssb/driver_pcicore.c:457: error: for each function it appears
>> in.) drivers/ssb/driver_pcicore.c: In function 'ssb_pcie_mdio_read':
>> drivers/ssb/driver_pcicore.c:503: error: expected ';' before
>> 'pcicore_write32'
>>
>> With the obvious fixes (providing a variable 'i' of int type as the
>> count variable and terminating the line which had no terminating
>> semi-colon), it compiled OK and the first time I booted up, booted up
>> OK but didn't fix the DMA error. Subsequent attempts to boot up gave
>> me a slew of errors on boot up so I am not sure what is going on
>> there.
>>
>> You might want to check that the obvious fixes to the patch are
>> complete.
>
> I have more or less tracked down what is happening.
>
> The first thing to report is that this does not fix the DMA error.
>
> The second thing is that with the patch applied, and with _all_
> wireless/ssb modules blacklisted (ssb, b43, wl), if the wl module is
> present the kernel bizarrely still tries to load it on boot up and
> shortly thereafter hangs with a number of errors reported, which differ
> on different boots (there is no particular pattern to them). That in
> turn causes some file system corruption which affects further boots
> even if the wl module is removed. The corruption is not that serious
> and appears only to affect the kernel image and/or the wl module.
> Reinstalling both solved the problem, so far. ef2fsck -f only reported
> that the time stamps were wrong, but inodes and directory structures
> were reported as OK.
>
> But caveat testor so far as the corruption is concerned. I might have
> been lucky.
I tried to duplicate your boot problems without anything unexpected happening.
I don't know what happened, but I doubt that this ssb patch was responsible.
Larry
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox