* Re: [PATCH] wireless: display wext SSID when connected by cfg80211
From: Johannes Berg @ 2009-08-05 5:35 UTC (permalink / raw)
To: Zhu Yi; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1249450026.4069.111.camel@debian>
[-- Attachment #1: Type: text/plain, Size: 584 bytes --]
On Wed, 2009-08-05 at 13:27 +0800, Zhu Yi wrote:
> Yeah, I'm lazy to parse the current_bss.pub->information_elements for
> SSID in the first instance. Should we implement some beacon parsing in
> cfg80211 or move ieee802_11_parse_elems from mac80211?
There's ieee80211_bss_get_ie() in cfg80211, which doesn't give you the
length/data in two separate values, but otherwise behaves pretty
similarly. IOW, something like
const u8 *ssid = ieee80211_bss_get_ie(bss /* or &bss->pub */, WLAN_EID_SSID);
if (ssid) {
ssid_len = ssid[1];
ssid_data = ssid + 2;
}
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 001/002] [MAC80211] Retry probe request few times
From: Johannes Berg @ 2009-08-05 5:33 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: Marcel Holtmann, linux-wireless, linville, Reinette Chatre
In-Reply-To: <1249450153.6083.4.camel@maxim-laptop>
[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]
On Wed, 2009-08-05 at 08:29 +0300, Maxim Levitsky wrote:
> > [54632.657912] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
> > [54633.154560] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2
> > [54873.231210] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
> > [55113.467840] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
> > [55113.964510] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2
> > [55114.464516] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 3
> > [55114.967868] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 4
> > [55115.464511] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, disconnecting.
> >
> > Should we increase the value to 8 or something? Or just accept that
> > sometimes we get a disconnect?
> >
> I think a disconnect or two aren't a problem, they are always handled
> automatically, and can be caused by natural events.
>
> Even without these patches (I have WPA2, and disconnects were every 4
> five seconds), and still it was possible to use network.
>
> One disconnect in a day is really nothing to worry about (I have seen
> such here as well)
>
> You can increase try count, probably won't hurt much (each try is 0.5
> seconds, so even 10 tries gives total of 5 seconds, before disconnect on
> a really unaccessible AP, anyway)
Mind you, each try will end up sending a LOT of probe request frames,
iwlwifi sends like 12 frames for every try and never gets a response for
some reason, so I wouldn't really increase it much further since you'd
be spamming around a lot.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 001/002] [MAC80211] Retry probe request few times
From: Maxim Levitsky @ 2009-08-05 5:29 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-wireless, linville, Reinette Chatre, Johannes Berg
In-Reply-To: <1249438947.3094.30.camel@localhost.localdomain>
On Tue, 2009-08-04 at 19:22 -0700, Marcel Holtmann wrote:
> Hi Maxim,
>
> > From: Maxim Levitsky <maximlevitsky@gmail.com>
> > Date: Fri, 31 Jul 2009 18:54:12 +0300
> > Subject: [PATCH] [MAC80211] Retry probe request few times
> >
> > Retry 5 times (chosen arbitary ), before assuming
> > that station is out of range.
>
> so today I got the disconnect :(
>
> [54632.657912] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
> [54633.154560] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2
> [54873.231210] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
> [55113.467840] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
> [55113.964510] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2
> [55114.464516] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 3
> [55114.967868] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 4
> [55115.464511] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, disconnecting.
>
> Should we increase the value to 8 or something? Or just accept that
> sometimes we get a disconnect?
>
I think a disconnect or two aren't a problem, they are always handled
automatically, and can be caused by natural events.
Even without these patches (I have WPA2, and disconnects were every 4
five seconds), and still it was possible to use network.
One disconnect in a day is really nothing to worry about (I have seen
such here as well)
You can increase try count, probably won't hurt much (each try is 0.5
seconds, so even 10 tries gives total of 5 seconds, before disconnect on
a really unaccessible AP, anyway)
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: [PATCH] wireless: display wext SSID when connected by cfg80211
From: Zhu Yi @ 2009-08-05 5:27 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <1249449590.4168.16.camel@johannes.local>
On Wed, 2009-08-05 at 13:19 +0800, Johannes Berg wrote:
> On Wed, 2009-08-05 at 10:05 +0800, Zhu Yi wrote:
> > cfg80211 displays correct link info when connected by wext. But if
> > the connection is setup by cfg80211, wext cannot display the SSID.
> > This patch fixed this issue.
> >
> > Signed-off-by: Zhu Yi <yi.zhu@intel.com>
> > ---
> > diff --git a/net/wireless/wext-sme.c b/net/wireless/wext-sme.c
> > index 7bacbd1..48c165b 100644
> > --- a/net/wireless/wext-sme.c
> > +++ b/net/wireless/wext-sme.c
> > @@ -210,6 +210,10 @@ int cfg80211_mgd_wext_giwessid(struct net_device *dev,
> > data->flags = 1;
> > data->length = wdev->wext.connect.ssid_len;
> > memcpy(ssid, wdev->wext.connect.ssid, data->length);
> > + } else if (wdev->ssid && wdev->ssid_len) {
> > + data->flags = 1;
> > + data->length = wdev->ssid_len;
> > + memcpy(ssid, wdev->ssid, data->length);
>
> Hmm. I suspect using wdev->current_bss would be less prone to breakage,
> since we've had some trouble with wdev->ssid already, and current_bss
> has to be present all the time for various nl80211 too. I guess
> ultimately it doesn't matter that much since somebody will see the
> problem.
Yeah, I'm lazy to parse the current_bss.pub->information_elements for
SSID in the first instance. Should we implement some beacon parsing in
cfg80211 or move ieee802_11_parse_elems from mac80211?
Thanks,
-yi
^ permalink raw reply
* Re: [PATCH] wireless: display wext SSID when connected by cfg80211
From: Johannes Berg @ 2009-08-05 5:19 UTC (permalink / raw)
To: Zhu Yi; +Cc: linville, linux-wireless
In-Reply-To: <1249437950-8059-1-git-send-email-yi.zhu@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]
On Wed, 2009-08-05 at 10:05 +0800, Zhu Yi wrote:
> cfg80211 displays correct link info when connected by wext. But if
> the connection is setup by cfg80211, wext cannot display the SSID.
> This patch fixed this issue.
>
> Signed-off-by: Zhu Yi <yi.zhu@intel.com>
> ---
> diff --git a/net/wireless/wext-sme.c b/net/wireless/wext-sme.c
> index 7bacbd1..48c165b 100644
> --- a/net/wireless/wext-sme.c
> +++ b/net/wireless/wext-sme.c
> @@ -210,6 +210,10 @@ int cfg80211_mgd_wext_giwessid(struct net_device *dev,
> data->flags = 1;
> data->length = wdev->wext.connect.ssid_len;
> memcpy(ssid, wdev->wext.connect.ssid, data->length);
> + } else if (wdev->ssid && wdev->ssid_len) {
> + data->flags = 1;
> + data->length = wdev->ssid_len;
> + memcpy(ssid, wdev->ssid, data->length);
Hmm. I suspect using wdev->current_bss would be less prone to breakage,
since we've had some trouble with wdev->ssid already, and current_bss
has to be present all the time for various nl80211 too. I guess
ultimately it doesn't matter that much since somebody will see the
problem.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] wl12xx: make irq handling interface specific
From: Kalle Valo @ 2009-08-05 5:05 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless
In-Reply-To: <20090804122229.GA3337@hash.localnet>
Bob Copeland <me@bobcopeland.com> writes:
> On Tue, Aug 04, 2009 at 10:26:39AM +0300, Kalle Valo wrote:
>> So this patch is only needed on top of the rebased sdio patchset I sent
>> few weeks ago to get sdio working? Or did I miss any patches? I'm just
>> being careful here because I want to get sdio support to 2.6.32 (if it's
>> ok for John) and there isn't that much time for that.
>
> Hi Kalle,
>
> Yes, the only other patch I have is for the platform gpios for the MSM
> kernel (msm_wifi.ko module for HTC Dream) which doesn't touch this at all
> and is platform specific.
Yes, that's a separate issue.
> The plan was to turn that into a platform rfkill driver, though it can
> probably go to staging in its present form with the other Dream stuff.
I'm planning to add rfkill support to wl1251, it's just that my todo
list is currently a mile long :)
But thanks, good to know that I now have everything for sdio support.
Outstanding work, Bob!
--
Kalle Valo
^ permalink raw reply
* Re: regression IWl3945 - doesn't work with recent 2.6.30-rcX
From: Johannes Berg @ 2009-08-05 5:03 UTC (permalink / raw)
To: reinette chatre
Cc: Zdenek Kabelac, John W. Linville, Linux Kernel Mailing List,
linux-wireless@vger.kernel.org
In-Reply-To: <1249422260.30019.4553.camel@rc-desk>
[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]
Hi Reinette,
> I think I can see how this could happen. From what I can tell there is
> no checking if a scan is in progress when userspace triggers a new scan.
There isn't anywhere in mac80211, but all scans are now triggered by
cfg80211, which does the checking.
> ieee80211_scan -> ieee80211_request_scan -> __ieee80211_start_scan
> without local->hw_scanning or local->sw_scanning being checked.
>
> Considering this the above warning could happen in the following
> scenario:
> * userspace triggers scan, this sets local->hw_scanning and goes off
> scanning
> * userspace triggers another scan, even though local->hw_scanning is set
> it continues anyway and calls the drivers scanning function, this
> function returns error (which will cause ieee80211_scan_completed to be
> called) or calls ieee80211_scan_completed immediately because it is
> still busy with previous scan
> * now original scan completes and it tries to call
> ieee80211_scan_completed, but this triggers the warning because previous
> call of ieee80211_scan_completed cleared local->hw_scanning
Due to the check in cfg80211, I don't see how this could possibly
happen. But there are IWL_DEBUG_MAC80211 calls, so it should be easy to
figure it out if reproducible.
Zdenek, are you taking the interface down at the same time maybe? I
could see a race condition here where mac80211 assumes the scan must
have finished when the interface goes down, and maybe iwlwifi does that
too or something. Haven't looked at the code right now.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: rtl818x driver (linux-2.6.30.4)
From: Larry Finger @ 2009-08-05 3:42 UTC (permalink / raw)
To: Carl Purvis; +Cc: wireless
In-Reply-To: <4F889FF7-D1AF-4F0D-B478-BD8672DE476F@security-assessment.com>
Carl Purvis wrote:
>
> Not sure of the proper process for this but I found your email in the
> driver source.
> It looks like the rtl8187 driver no longer allows TX Power to be set
> above 100mw (20dBm), Previous incarnations of the driver would allow
> txpower to be set to 27dbm (501mw).
> I have an alfa USB wifi card.
>
> safe:/usr/src/linux-2.6.30.4/drivers/net/wireless/rtl818x# iwconfig
> wlan0 txpower 27
> Error for wireless request "Set Tx Power" (8B26) :
> SET failed on device wlan0 ; Invalid argument.
>
> safe:/usr/src/linux-2.6.30.4/drivers/net/wireless/rtl818x# iwconfig
> wlan0 txpower 20
--snip--
>
> Sorry if this is the incorrect way to contact you/the people doing
> driver work.
The correct way to address wireless issues through the mailing list
linux-wireless@vger.kernel.org, which I have Cc'd in my reply.
The change is not that the driver has been modified to restrict the
power, but the entire wireless system is modified to abide by
regulatory domain data.
How are you setting the regulatory info? You should be using the CRDA
system (http://linuxwireless.org/en/developers/Regulatory/CRDA) and
set the country code to your location. Based on the mention of the
"New Zealand Electronic Transactions Act 2002" in your signature, I
guess that you would need to add the line
options cfg80211 ieee80211_regdom=NZ"
to the file /etc/modprobe.conf.local. When you do that, you will see
the following in the log:
cfg80211: Regulatory domain changed to country: NZ
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 3000 mBm)
With that data, your device could have a maximum power of 30 dBm (3000
mBm). I didn't check if the device could handle that much power, but
if it can, the regulatory authorities would allow it.
In the US, we get the following:
cfg80211: Regulatory domain changed to country: US
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
By regulation, we may use as much as 2700 mBm. From the frequency
data, you can use channels 12 and 13, which I cannot.
Based on your report, you are effectively getting the same as
(2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm).
What you see is the result of considerable work to make Linux abide by
the broadcast rules. Unfortunately, there is no reliable way to
determine the geographic location of a computer.
Larry
^ permalink raw reply
* Re: [PATCH V3] b43: implement baseband init for LP-PHY <= rev1
From: Larry Finger @ 2009-08-05 2:39 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Michael Buesch, Broadcom Wireless, linux-wireless
In-Reply-To: <4A78C336.9000503@gmail.com>
Gábor Stefanik wrote:
> Implement baseband init for rev.0 and rev.1 LP PHYs. Convert
> boardflags_hi values to defines.
> Implement b43_phy_copy for easier copying between registers, as needed
> by LP-PHY init.
>
> Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
> Cc: Michael Buesch <mb@bu3sch.de>
> Cc: Larry Finger <larry.finger@lwfinger.net>
> ---
> V3:
> -Added FIXME to the b43_hf_write call.
> -The b43_hf_write call now uses a #defined value, rather than a magic
> number.
It looks to me that V2 was put into wireless-testing. You will need to
prepare a separate patch to make the V2 => V3 changes.
Larry
^ permalink raw reply
* Re: [PATCH 001/002] [MAC80211] Retry probe request few times
From: Marcel Holtmann @ 2009-08-05 2:22 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: linux-wireless, linville, Reinette Chatre, Johannes Berg
In-Reply-To: <1249056896.20593.3.camel@maxim-laptop>
Hi Maxim,
> From: Maxim Levitsky <maximlevitsky@gmail.com>
> Date: Fri, 31 Jul 2009 18:54:12 +0300
> Subject: [PATCH] [MAC80211] Retry probe request few times
>
> Retry 5 times (chosen arbitary ), before assuming
> that station is out of range.
so today I got the disconnect :(
[54632.657912] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
[54633.154560] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2
[54873.231210] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
[55113.467840] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 1
[55113.964510] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 2
[55114.464516] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 3
[55114.967868] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, try 4
[55115.464511] No probe response from AP 00:1c:f0:xx:xx:xx after 500ms, disconnecting.
Should we increase the value to 8 or something? Or just accept that
sometimes we get a disconnect?
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/2] ar9170: cleanup of bss_info_changed and beacon config
From: Christian Lamparter @ 2009-08-05 2:04 UTC (permalink / raw)
To: Joerg Albert; +Cc: John W. Linville, linux-wireless@vger.kernel.org
In-Reply-To: <4A78CE98.70903@gmx.de>
On Wednesday 05 August 2009 02:13:12 Joerg Albert wrote:
> Enable/Disable the beacon in ar910_set_beacon_timers() independently
> of ar->vif, but controlled by BSS_CHANGED_BEACON_ENABLED and
> bss_conf->enable_beacon from mac80211.
no signed/cc here?
> ---
> drivers/net/wireless/ath/ar9170/ar9170.h | 1 +
> drivers/net/wireless/ath/ar9170/mac.c | 4 +++-
> drivers/net/wireless/ath/ar9170/main.c | 15 ++++++++-------
> 3 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ar9170/mac.c b/drivers/net/wireless/ath/ar9170/mac.c
> index d9f1f46..9f2801c 100644
> --- a/drivers/net/wireless/ath/ar9170/mac.c
> +++ b/drivers/net/wireless/ath/ar9170/mac.c
> @@ -388,7 +388,9 @@ int ar9170_set_beacon_timers(struct ar9170 *ar)
> u32 v = 0;
> u32 pretbtt = 0;
>
> - if (ar->vif) {
> + if (ar->enable_beacon) {
> + if (WARN_ON(!ar->vif))
> + return -ENODEV;
> v |= ar->vif->bss_conf.beacon_int;
>
> switch (ar->vif->type) {
err, guess that's why. (not fatal, but WARN)
the beacon timer isn't exclusively used to notify the driver when its
time for a new beacon... The STA mode uses the same _timer_
in reverse to wait for the next beacon form the assoc. AP.
that said: It does not look like the firmware implements anything
in this direction... But this is a clearly MAC register and there
could be something in the silicon which does something useful with
this information.
so, to be on the safe side: why not preserve the old behavior for the
STA mode as well and simply tell the hardware about dtim & beacon interval?
The only remaining question is where to disabled the timer for STA.
(which is in some way relevant to: [PATCH 2/2] because previously,
these timers were always disabled by remove_interface.)
I think the best place is in ar9170_op_bss_info_changed:
if (changed & BSS_CHANGED_ASSOC) {
just when bss_conf->assoc gets "0".
Regards,
Chr
^ permalink raw reply
* [PATCH] wireless: display wext SSID when connected by cfg80211
From: Zhu Yi @ 2009-08-05 2:05 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Zhu Yi
cfg80211 displays correct link info when connected by wext. But if
the connection is setup by cfg80211, wext cannot display the SSID.
This patch fixed this issue.
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
diff --git a/net/wireless/wext-sme.c b/net/wireless/wext-sme.c
index 7bacbd1..48c165b 100644
--- a/net/wireless/wext-sme.c
+++ b/net/wireless/wext-sme.c
@@ -210,6 +210,10 @@ int cfg80211_mgd_wext_giwessid(struct net_device *dev,
data->flags = 1;
data->length = wdev->wext.connect.ssid_len;
memcpy(ssid, wdev->wext.connect.ssid, data->length);
+ } else if (wdev->ssid && wdev->ssid_len) {
+ data->flags = 1;
+ data->length = wdev->ssid_len;
+ memcpy(ssid, wdev->ssid, data->length);
} else
data->flags = 0;
wdev_unlock(wdev);
^ permalink raw reply related
* [PATCH 2/2] ar9170: remove unnecessary calls to ar9170_set_beacon_timers
From: Joerg Albert @ 2009-08-05 0:16 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless@vger.kernel.org, Christian Lamparter
ar9170_op_remove_interface: mac80211 calls us before with
BSS_CHANGED_BEACON_ENABLED set and bss_conf->enable_beacon == 0
ar9170_op_config: this was a bogus call; mac80211 never sets
BSS_CHANGED_BEACON_ENABLED here
Signed-off-by: Joerg Albert <jal2@gmx.de>
---
drivers/net/wireless/ath/ar9170/main.c | 7 -------
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ar9170/main.c b/drivers/net/wireless/ath/ar9170/main.c
index d51b6ad..693a999 100644
--- a/drivers/net/wireless/ath/ar9170/main.c
+++ b/drivers/net/wireless/ath/ar9170/main.c
@@ -1990,7 +1990,6 @@ static void ar9170_op_remove_interface(struct ieee80211_hw *hw,
ar->vif = NULL;
ar->want_filter = 0;
ar9170_update_frame_filter(ar);
- ar9170_set_beacon_timers(ar);
dev_kfree_skb(ar->beacon);
ar->beacon = NULL;
ar->sniffer_enabled = false;
@@ -2032,12 +2031,6 @@ static int ar9170_op_config(struct ieee80211_hw *hw, u32 changed)
goto out;
}
- if (changed & BSS_CHANGED_BEACON_INT) {
- err = ar9170_set_beacon_timers(ar);
- if (err)
- goto out;
- }
-
if (changed & IEEE80211_CONF_CHANGE_CHANNEL) {
/* adjust slot time for 5 GHz */
--
1.6.0.4
^ permalink raw reply related
* [PATCH 1/2] ar9170: cleanup of bss_info_changed and beacon config
From: Joerg Albert @ 2009-08-05 0:13 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless@vger.kernel.org, Christian Lamparter
Enable/Disable the beacon in ar910_set_beacon_timers() independently
of ar->vif, but controlled by BSS_CHANGED_BEACON_ENABLED and
bss_conf->enable_beacon from mac80211.
---
drivers/net/wireless/ath/ar9170/ar9170.h | 1 +
drivers/net/wireless/ath/ar9170/mac.c | 4 +++-
drivers/net/wireless/ath/ar9170/main.c | 15 ++++++++-------
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ar9170/ar9170.h b/drivers/net/wireless/ath/ar9170/ar9170.h
index e6c3ee3..0db304a 100644
--- a/drivers/net/wireless/ath/ar9170/ar9170.h
+++ b/drivers/net/wireless/ath/ar9170/ar9170.h
@@ -177,6 +177,7 @@ struct ar9170 {
/* beaconing */
struct sk_buff *beacon;
struct work_struct beacon_work;
+ bool enable_beacon;
/* cryptographic engine */
u64 usedkeys;
diff --git a/drivers/net/wireless/ath/ar9170/mac.c b/drivers/net/wireless/ath/ar9170/mac.c
index d9f1f46..9f2801c 100644
--- a/drivers/net/wireless/ath/ar9170/mac.c
+++ b/drivers/net/wireless/ath/ar9170/mac.c
@@ -388,7 +388,9 @@ int ar9170_set_beacon_timers(struct ar9170 *ar)
u32 v = 0;
u32 pretbtt = 0;
- if (ar->vif) {
+ if (ar->enable_beacon) {
+ if (WARN_ON(!ar->vif))
+ return -ENODEV;
v |= ar->vif->bss_conf.beacon_int;
switch (ar->vif->type) {
diff --git a/drivers/net/wireless/ath/ar9170/main.c b/drivers/net/wireless/ath/ar9170/main.c
index 099ed3c..d51b6ad 100644
--- a/drivers/net/wireless/ath/ar9170/main.c
+++ b/drivers/net/wireless/ath/ar9170/main.c
@@ -2177,11 +2177,18 @@ static void ar9170_op_bss_info_changed(struct ieee80211_hw *hw,
goto out;
}
- if (changed & (BSS_CHANGED_BEACON | BSS_CHANGED_BEACON_ENABLED)) {
+ if (changed & BSS_CHANGED_BEACON_ENABLED) {
+ ar->enable_beacon = bss_conf->enable_beacon;
+ }
+
+ if (changed & BSS_CHANGED_BEACON) {
err = ar9170_update_beacon(ar);
if (err)
goto out;
+ }
+ if (changed & (BSS_CHANGED_BEACON_ENABLED | BSS_CHANGED_BEACON |
+ BSS_CHANGED_BEACON_INT)) {
err = ar9170_set_beacon_timers(ar);
if (err)
goto out;
@@ -2194,12 +2201,6 @@ static void ar9170_op_bss_info_changed(struct ieee80211_hw *hw,
#endif /* CONFIG_AR9170_LEDS */
}
- if (changed & BSS_CHANGED_BEACON_INT) {
- err = ar9170_set_beacon_timers(ar);
- if (err)
- goto out;
- }
-
if (changed & BSS_CHANGED_HT) {
/* TODO */
err = 0;
--
1.6.0.4
^ permalink raw reply related
* [PATCH v3] ath5k: fix missing output in monitor mode after ifconfig up
From: Joerg Albert @ 2009-08-04 23:52 UTC (permalink / raw)
To: John W. Linville
Cc: Bob Copeland, ath5k-devel, Luis R. Rodriguez,
linux-wireless@vger.kernel.org
In-Reply-To: <20090804154153.GB4995@tuxdriver.com>
Let ath5k_chan_set() always call ath5k_reset().
This fixes the bug that we don't
get any packets in monitor mode after:
ifconfig wlan0 down
iwconfig wlan0 mode monitor channel 1
ifconfig wlan0 up
but they arrive after
iwconfig wlan0 channel 2
Signed-off-by: Joerg Albert <jal2@gmx.de>
---
Same version as [PATCH v2] but with correct whitespaces (hopefully).
drivers/net/wireless/ath/ath5k/base.c | 35 ++++++++++++++------------------
1 files changed, 15 insertions(+), 20 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 3a1c156..5d50285 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1071,10 +1071,9 @@ ath5k_setup_bands(struct ieee80211_hw *hw)
}
/*
- * Set/change channels. If the channel is really being changed,
- * it's done by reseting the chip. To accomplish this we must
- * first cleanup any pending DMA, then restart stuff after a la
- * ath5k_init.
+ * Set/change channels. We always reset the chip.
+ * To accomplish this we must first cleanup any pending DMA,
+ * then restart stuff after a la ath5k_init.
*
* Called with sc->lock.
*/
@@ -1084,19 +1083,13 @@ ath5k_chan_set(struct ath5k_softc *sc, struct ieee80211_channel *chan)
ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "(%u MHz) -> (%u MHz)\n",
sc->curchan->center_freq, chan->center_freq);
- if (chan->center_freq != sc->curchan->center_freq ||
- chan->hw_value != sc->curchan->hw_value) {
-
- /*
- * To switch channels clear any pending DMA operations;
- * wait long enough for the RX fifo to drain, reset the
- * hardware at the new frequency, and then re-enable
- * the relevant bits of the h/w.
- */
- return ath5k_reset(sc, chan);
- }
-
- return 0;
+ /*
+ * To switch channels clear any pending DMA operations;
+ * wait long enough for the RX fifo to drain, reset the
+ * hardware at the new frequency, and then re-enable
+ * the relevant bits of the h/w.
+ */
+ return ath5k_reset(sc, chan);
}
static void
@@ -2811,9 +2804,11 @@ ath5k_config(struct ieee80211_hw *hw, u32 changed)
mutex_lock(&sc->lock);
- ret = ath5k_chan_set(sc, conf->channel);
- if (ret < 0)
- goto unlock;
+ if (changed & IEEE80211_CONF_CHANGE_CHANNEL) {
+ ret = ath5k_chan_set(sc, conf->channel);
+ if (ret < 0)
+ goto unlock;
+ }
if ((changed & IEEE80211_CONF_CHANGE_POWER) &&
(sc->power_level != conf->power_level)) {
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH v2] ath5k: fix missing output in monitor mode after ifconfig up
From: Joerg Albert @ 2009-08-04 23:46 UTC (permalink / raw)
To: John W. Linville
Cc: Bob Copeland, ath5k-devel, Luis R. Rodriguez,
linux-wireless@vger.kernel.org
In-Reply-To: <20090804154153.GB4995@tuxdriver.com>
On 08/04/2009 05:41 PM, John W. Linville wrote:
> On Sun, Aug 02, 2009 at 09:50:58AM +0200, Joerg Albert wrote:
>> Let ath5k_chan_set() always call ath5k_reset().
>> This fixes the bug that we don't
>> get any packets in monitor mode after:
>>
>> ifconfig wlan0 down
>> iwconfig wlan0 mode monitor channel 1
>> ifconfig wlan0 up
>>
>> but they arrive after
>>
>> iwconfig wlan0 channel 2
>>
>> Signed-off-by: Joerg Albert <jal2@gmx.de>
>
> patching file drivers/net/wireless/ath/ath5k/base.c
> Hunk #1 FAILED at 1071.
> Hunk #2 FAILED at 1083.
> Hunk #3 FAILED at 2804.
> 3 out of 3 hunks FAILED -- saving rejects to file drivers/net/wireless/ath/ath5k/base.c.rej
Sorry, seems like Thunderbird has converted the whitespaces.
I'll repost the patch.
^ permalink raw reply
* [PATCH] b43: Fix fallout from the IEEE80211_IF_TYPE to NL80211_IFTYPE change.
From: Gábor Stefanik @ 2009-08-04 23:28 UTC (permalink / raw)
To: John Linville, Michael Buesch
Cc: Larry Finger, Broadcom Wireless, linux-wireless
Update a comment that still says IEEE80211_IF_TYPE instead of NL80211_IFTYPE.
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
---
This patch replaces "b43: Typo fixes and minor cleanup",
the other half of which has been integrated into the LP rev01 init patch.
drivers/net/wireless/b43/b43.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/b43/b43.h b/drivers/net/wireless/b43/b43.h
index 41ca727..52fd6d6 100644
--- a/drivers/net/wireless/b43/b43.h
+++ b/drivers/net/wireless/b43/b43.h
@@ -627,7 +627,7 @@ struct b43_wl {
u8 mac_addr[ETH_ALEN];
/* Current BSSID */
u8 bssid[ETH_ALEN];
- /* Interface type. (IEEE80211_IF_TYPE_XXX) */
+ /* Interface type. (NL80211_IFTYPE_XXX) */
int if_type;
/* Is the card operating in AP, STA or IBSS mode? */
bool operating;
--
1.6.2.4
^ permalink raw reply related
* [PATCH V3] b43: implement baseband init for LP-PHY <= rev1
From: Gábor Stefanik @ 2009-08-04 23:24 UTC (permalink / raw)
To: John Linville, Michael Buesch
Cc: Larry Finger, Broadcom Wireless, linux-wireless
Implement baseband init for rev.0 and rev.1 LP PHYs. Convert boardflags_hi values to defines.
Implement b43_phy_copy for easier copying between registers, as needed by LP-PHY init.
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
Cc: Michael Buesch <mb@bu3sch.de>
Cc: Larry Finger <larry.finger@lwfinger.net>
---
V3:
-Added FIXME to the b43_hf_write call.
-The b43_hf_write call now uses a #defined value, rather than a magic number.
V2:
-Reversed argument order for b43_phy_copy.
-Named all registers, no more magic numbers.
-Whitespace errors hopefully fixed (I hope my mailer doesn't re-introduce them...)
drivers/net/wireless/b43/b43.h | 11 ++++
drivers/net/wireless/b43/phy_common.c | 7 +++
drivers/net/wireless/b43/phy_common.h | 5 ++
drivers/net/wireless/b43/phy_lp.c | 95 ++++++++++++++++++++++++++++++++-
drivers/net/wireless/b43/phy_lp.h | 11 +++-
drivers/net/wireless/b43/phy_n.c | 3 +-
6 files changed, 128 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/b43/b43.h b/drivers/net/wireless/b43/b43.h
index 4e8ad84..41ca727 100644
--- a/drivers/net/wireless/b43/b43.h
+++ b/drivers/net/wireless/b43/b43.h
@@ -142,6 +142,17 @@
#define B43_BFL_BTCMOD 0x4000 /* BFL_BTCOEXIST is given in alternate GPIOs */
#define B43_BFL_ALTIQ 0x8000 /* alternate I/Q settings */
+/* SPROM boardflags_hi values */
+#define B43_BFH_NOPA 0x0001 /* has no PA */
+#define B43_BFH_RSSIINV 0x0002 /* RSSI uses positive slope (not TSSI) */
+#define B43_BFH_PAREF 0x0004 /* uses the PARef LDO */
+#define B43_BFH_3TSWITCH 0x0008 /* uses a triple throw switch shared
+ * with bluetooth */
+#define B43_BFH_PHASESHIFT 0x0010 /* can support phase shifter */
+#define B43_BFH_BUCKBOOST 0x0020 /* has buck/booster */
+#define B43_BFH_FEM_BT 0x0040 /* has FEM and switch to share antenna
+ * with bluetooth */
+
/* GPIO register offset, in both ChipCommon and PCI core. */
#define B43_GPIO_CONTROL 0x6c
diff --git a/drivers/net/wireless/b43/phy_common.c b/drivers/net/wireless/b43/phy_common.c
index e176b6e..1661b03 100644
--- a/drivers/net/wireless/b43/phy_common.c
+++ b/drivers/net/wireless/b43/phy_common.c
@@ -240,6 +240,13 @@ void b43_phy_write(struct b43_wldev *dev, u16 reg, u16 value)
dev->phy.ops->phy_write(dev, reg, value);
}
+void b43_phy_copy(struct b43_wldev *dev, u16 destreg, u16 srcreg)
+{
+ assert_mac_suspended(dev);
+ dev->phy.ops->phy_write(dev, destreg,
+ dev->phy.ops->phy_read(dev, srcreg));
+}
+
void b43_phy_mask(struct b43_wldev *dev, u16 offset, u16 mask)
{
b43_phy_write(dev, offset,
diff --git a/drivers/net/wireless/b43/phy_common.h b/drivers/net/wireless/b43/phy_common.h
index b2d9910..c7a7d6b 100644
--- a/drivers/net/wireless/b43/phy_common.h
+++ b/drivers/net/wireless/b43/phy_common.h
@@ -291,6 +291,11 @@ u16 b43_phy_read(struct b43_wldev *dev, u16 reg);
void b43_phy_write(struct b43_wldev *dev, u16 reg, u16 value);
/**
+ * b43_phy_copy - copy contents of 16bit PHY register to another
+ */
+void b43_phy_copy(struct b43_wldev *dev, u16 destreg, u16 srcreg);
+
+/**
* b43_phy_mask - Mask a PHY register with a mask
*/
void b43_phy_mask(struct b43_wldev *dev, u16 offset, u16 mask);
diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
index 58e319d..e47eca6 100644
--- a/drivers/net/wireless/b43/phy_lp.c
+++ b/drivers/net/wireless/b43/phy_lp.c
@@ -66,7 +66,100 @@ static void lpphy_table_init(struct b43_wldev *dev)
static void lpphy_baseband_rev0_1_init(struct b43_wldev *dev)
{
- B43_WARN_ON(1);//TODO rev < 2 not supported, yet.
+ struct ssb_bus *bus = dev->dev->bus;
+ u16 tmp, tmp2;
+
+ if (dev->phy.rev == 1 &&
+ (bus->sprom.boardflags_hi & B43_BFH_FEM_BT)) {
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_1, 0xFFC0, 0x000A);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_1, 0x3F00, 0x0900);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_2, 0xFFC0, 0x000A);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_2, 0xC0FF, 0x0B00);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_3, 0xFFC0, 0x000A);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_3, 0xC0FF, 0x0400);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_4, 0xFFC0, 0x000A);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_4, 0xC0FF, 0x0B00);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_5, 0xFFC0, 0x000A);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_5, 0xC0FF, 0x0900);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_6, 0xFFC0, 0x000A);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_6, 0xC0FF, 0x0B00);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_7, 0xFFC0, 0x000A);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_7, 0xC0FF, 0x0900);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_8, 0xFFC0, 0x000A);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_8, 0xC0FF, 0x0B00);
+ } else if (b43_current_band(dev->wl) == IEEE80211_BAND_5GHZ ||
+ (bus->boardinfo.type == 0x048A) || ((dev->phy.rev == 0) &&
+ (bus->sprom.boardflags_lo & B43_BFL_FEM))) {
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_1, 0xFFC0, 0x0001);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_1, 0xC0FF, 0x0400);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_2, 0xFFC0, 0x0001);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_2, 0xC0FF, 0x0500);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_3, 0xFFC0, 0x0002);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_3, 0xC0FF, 0x0800);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_4, 0xFFC0, 0x0002);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_4, 0xC0FF, 0x0A00);
+ } else if (dev->phy.rev == 1 ||
+ (bus->sprom.boardflags_lo & B43_BFL_FEM)) {
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_1, 0xFFC0, 0x0004);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_1, 0xC0FF, 0x0800);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_2, 0xFFC0, 0x0004);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_2, 0xC0FF, 0x0C00);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_3, 0xFFC0, 0x0002);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_3, 0xC0FF, 0x0100);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_4, 0xFFC0, 0x0002);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_4, 0xC0FF, 0x0300);
+ } else {
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_1, 0xFFC0, 0x000A);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_1, 0xC0FF, 0x0900);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_2, 0xFFC0, 0x000A);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_2, 0xC0FF, 0x0B00);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_3, 0xFFC0, 0x0006);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_3, 0xC0FF, 0x0500);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_4, 0xFFC0, 0x0006);
+ b43_phy_maskset(dev, B43_LPPHY_TR_LOOKUP_4, 0xC0FF, 0x0700);
+ }
+ if (dev->phy.rev == 1) {
+ b43_phy_copy(dev, B43_LPPHY_TR_LOOKUP_5, B43_LPPHY_TR_LOOKUP_1);
+ b43_phy_copy(dev, B43_LPPHY_TR_LOOKUP_6, B43_LPPHY_TR_LOOKUP_2);
+ b43_phy_copy(dev, B43_LPPHY_TR_LOOKUP_7, B43_LPPHY_TR_LOOKUP_3);
+ b43_phy_copy(dev, B43_LPPHY_TR_LOOKUP_8, B43_LPPHY_TR_LOOKUP_4);
+ }
+ if ((bus->sprom.boardflags_hi & B43_BFH_FEM_BT) &&
+ (bus->chip_id == 0x5354) &&
+ (bus->chip_package == SSB_CHIPPACK_BCM4712S)) {
+ b43_phy_set(dev, B43_LPPHY_CRSGAIN_CTL, 0x0006);
+ b43_phy_write(dev, B43_LPPHY_GPIO_SELECT, 0x0005);
+ b43_phy_write(dev, B43_LPPHY_GPIO_OUTEN, 0xFFFF);
+ b43_hf_write(dev, b43_hf_read(dev) | B43_HF_PR45960W);
+ /* FIXME the spec requires this hf_write to be cached! */
+ }
+ if (b43_current_band(dev->wl) == IEEE80211_BAND_2GHZ) {
+ b43_phy_set(dev, B43_LPPHY_LP_PHY_CTL, 0x8000);
+ b43_phy_set(dev, B43_LPPHY_CRSGAIN_CTL, 0x0040);
+ b43_phy_maskset(dev, B43_LPPHY_MINPWR_LEVEL, 0x00FF, 0xA400);
+ b43_phy_maskset(dev, B43_LPPHY_CRSGAIN_CTL, 0xF0FF, 0x0B00);
+ b43_phy_maskset(dev, B43_LPPHY_SYNCPEAKCNT, 0xFFF8, 0x0007);
+ b43_phy_maskset(dev, B43_LPPHY_DSSS_CONFIRM_CNT, 0xFFF8, 0x0003);
+ b43_phy_maskset(dev, B43_LPPHY_DSSS_CONFIRM_CNT, 0xFFC7, 0x0020);
+ b43_phy_mask(dev, B43_LPPHY_IDLEAFTERPKTRXTO, 0x00FF);
+ } else { /* 5GHz */
+ b43_phy_mask(dev, B43_LPPHY_LP_PHY_CTL, 0x7FFF);
+ b43_phy_mask(dev, B43_LPPHY_CRSGAIN_CTL, 0xFFBF);
+ }
+ if (dev->phy.rev == 1) {
+ tmp = b43_phy_read(dev, B43_LPPHY_CLIPCTRTHRESH);
+ tmp2 = (tmp & 0x03E0) >> 5;
+ tmp2 |= tmp << 5;
+ b43_phy_write(dev, B43_LPPHY_4C3, tmp2);
+ tmp = b43_phy_read(dev, B43_LPPHY_OFDMSYNCTHRESH0);
+ tmp2 = (tmp & 0x1F00) >> 8;
+ tmp2 |= tmp << 5;
+ b43_phy_write(dev, B43_LPPHY_4C4, tmp2);
+ tmp = b43_phy_read(dev, B43_LPPHY_VERYLOWGAINDB);
+ tmp2 = tmp & 0x00FF;
+ tmp2 |= tmp << 8;
+ b43_phy_write(dev, B43_LPPHY_4C5, tmp2);
+ }
}
static void lpphy_baseband_rev2plus_init(struct b43_wldev *dev)
diff --git a/drivers/net/wireless/b43/phy_lp.h b/drivers/net/wireless/b43/phy_lp.h
index 18370b4..829b2bb 100644
--- a/drivers/net/wireless/b43/phy_lp.h
+++ b/drivers/net/wireless/b43/phy_lp.h
@@ -273,12 +273,19 @@
#define B43_LPPHY_AFE_DDFS_POINTER_INIT B43_PHY_OFDM(0xB8) /* AFE DDFS pointer init */
#define B43_LPPHY_AFE_DDFS_INCR_INIT B43_PHY_OFDM(0xB9) /* AFE DDFS incr init */
#define B43_LPPHY_MRCNOISEREDUCTION B43_PHY_OFDM(0xBA) /* mrcNoiseReduction */
-#define B43_LPPHY_TRLOOKUP3 B43_PHY_OFDM(0xBB) /* TRLookup3 */
-#define B43_LPPHY_TRLOOKUP4 B43_PHY_OFDM(0xBC) /* TRLookup4 */
+#define B43_LPPHY_TR_LOOKUP_3 B43_PHY_OFDM(0xBB) /* TR Lookup 3 */
+#define B43_LPPHY_TR_LOOKUP_4 B43_PHY_OFDM(0xBC) /* TR Lookup 4 */
#define B43_LPPHY_RADAR_FIFO_STAT B43_PHY_OFDM(0xBD) /* Radar FIFO Status */
#define B43_LPPHY_GPIO_OUTEN B43_PHY_OFDM(0xBE) /* GPIO Out enable */
#define B43_LPPHY_GPIO_SELECT B43_PHY_OFDM(0xBF) /* GPIO Select */
#define B43_LPPHY_GPIO_OUT B43_PHY_OFDM(0xC0) /* GPIO Out */
+#define B43_LPPHY_4C3 B43_PHY_OFDM(0xC3) /* unknown, used during BB init */
+#define B43_LPPHY_4C4 B43_PHY_OFDM(0xC4) /* unknown, used during BB init */
+#define B43_LPPHY_4C5 B43_PHY_OFDM(0xC5) /* unknown, used during BB init */
+#define B43_LPPHY_TR_LOOKUP_5 B43_PHY_OFDM(0xC7) /* TR Lookup 5 */
+#define B43_LPPHY_TR_LOOKUP_6 B43_PHY_OFDM(0xC8) /* TR Lookup 6 */
+#define B43_LPPHY_TR_LOOKUP_7 B43_PHY_OFDM(0xC9) /* TR Lookup 7 */
+#define B43_LPPHY_TR_LOOKUP_8 B43_PHY_OFDM(0xCA) /* TR Lookup 8 */
diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index 8bcfda5..14ad95a 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -137,7 +137,8 @@ static void b43_radio_init2055_post(struct b43_wldev *dev)
b43_radio_mask(dev, B2055_MASTER1, 0xFFF3);
msleep(1);
- if ((sprom->revision != 4) || !(sprom->boardflags_hi & 0x0002)) {
+ if ((sprom->revision != 4) ||
+ !(sprom->boardflags_hi & B43_BFH_RSSIINV)) {
if ((binfo->vendor != PCI_VENDOR_ID_BROADCOM) ||
(binfo->type != 0x46D) ||
(binfo->rev < 0x41)) {
--
1.6.2.4
^ permalink raw reply related
* Re: [PATCH] b43: Typo fixes & minor cleanup
From: Larry Finger @ 2009-08-04 23:05 UTC (permalink / raw)
To: Michael Buesch
Cc: Gábor Stefanik, John Linville, Broadcom Wireless,
linux-wireless
In-Reply-To: <200908050017.53378.mb@bu3sch.de>
Michael Buesch wrote:
>
> Uhm, no?
> http://bcm-v4.sipsolutions.net/802.11/Host Flags
I just made some changes to that page. The modifications do not affect
the above criticism.
Larry
^ permalink raw reply
* [PATCH V2] remove wrong probe_resp_plcp write
From: gregor kowski @ 2009-08-04 22:44 UTC (permalink / raw)
To: bcm43xx-dev; +Cc: Johannes Berg, John W. Linville, linux-wireless
The tkip hw support uncovered a bug in b43_write_probe_resp_template : it is
writing at the wrong shm offset, it is in the B43_SHM_SH_TKIPTSCTTAK
zone. Remove b43_write_probe_resp_template, b43_write_probe_resp_plcp
and b43_write_probe_resp_plcp because the probe response offload is
currently not supported by mac80211.
Signed-off-by: Gregor Kowski <gregor.kowski@gmail.com>
Index: linux-2.6/drivers/net/wireless/b43/main.c
===================================================================
--- linux-2.6.orig/drivers/net/wireless/b43/main.c 2009-08-04
22:28:09.000000000 +0000
+++ linux-2.6/drivers/net/wireless/b43/main.c 2009-08-04
22:39:59.000000000 +0000
@@ -1431,113 +1431,6 @@
b43dbg(dev->wl, "Updated beacon template at 0x%x\n", ram_offset);
}
-static void b43_write_probe_resp_plcp(struct b43_wldev *dev,
- u16 shm_offset, u16 size,
- struct ieee80211_rate *rate)
-{
- struct b43_plcp_hdr4 plcp;
- u32 tmp;
- __le16 dur;
-
- plcp.data = 0;
- b43_generate_plcp_hdr(&plcp, size + FCS_LEN, rate->hw_value);
- dur = ieee80211_generic_frame_duration(dev->wl->hw,
- dev->wl->vif, size,
- rate);
- /* Write PLCP in two parts and timing for packet transfer */
- tmp = le32_to_cpu(plcp.data);
- b43_shm_write16(dev, B43_SHM_SHARED, shm_offset, tmp & 0xFFFF);
- b43_shm_write16(dev, B43_SHM_SHARED, shm_offset + 2, tmp >> 16);
- b43_shm_write16(dev, B43_SHM_SHARED, shm_offset + 6, le16_to_cpu(dur));
-}
-
-/* Instead of using custom probe response template, this function
- * just patches custom beacon template by:
- * 1) Changing packet type
- * 2) Patching duration field
- * 3) Stripping TIM
- */
-static const u8 *b43_generate_probe_resp(struct b43_wldev *dev,
- u16 *dest_size,
- struct ieee80211_rate *rate)
-{
- const u8 *src_data;
- u8 *dest_data;
- u16 src_size, elem_size, src_pos, dest_pos;
- __le16 dur;
- struct ieee80211_hdr *hdr;
- size_t ie_start;
-
- src_size = dev->wl->current_beacon->len;
- src_data = (const u8 *)dev->wl->current_beacon->data;
-
- /* Get the start offset of the variable IEs in the packet. */
- ie_start = offsetof(struct ieee80211_mgmt, u.probe_resp.variable);
- B43_WARN_ON(ie_start != offsetof(struct ieee80211_mgmt, u.beacon.variable));
-
- if (B43_WARN_ON(src_size < ie_start))
- return NULL;
-
- dest_data = kmalloc(src_size, GFP_ATOMIC);
- if (unlikely(!dest_data))
- return NULL;
-
- /* Copy the static data and all Information Elements, except the TIM. */
- memcpy(dest_data, src_data, ie_start);
- src_pos = ie_start;
- dest_pos = ie_start;
- for ( ; src_pos < src_size - 2; src_pos += elem_size) {
- elem_size = src_data[src_pos + 1] + 2;
- if (src_data[src_pos] == 5) {
- /* This is the TIM. */
- continue;
- }
- memcpy(dest_data + dest_pos, src_data + src_pos,
- elem_size);
- dest_pos += elem_size;
- }
- *dest_size = dest_pos;
- hdr = (struct ieee80211_hdr *)dest_data;
-
- /* Set the frame control. */
- hdr->frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT |
- IEEE80211_STYPE_PROBE_RESP);
- dur = ieee80211_generic_frame_duration(dev->wl->hw,
- dev->wl->vif, *dest_size,
- rate);
- hdr->duration_id = dur;
-
- return dest_data;
-}
-
-static void b43_write_probe_resp_template(struct b43_wldev *dev,
- u16 ram_offset,
- u16 shm_size_offset,
- struct ieee80211_rate *rate)
-{
- const u8 *probe_resp_data;
- u16 size;
-
- size = dev->wl->current_beacon->len;
- probe_resp_data = b43_generate_probe_resp(dev, &size, rate);
- if (unlikely(!probe_resp_data))
- return;
-
- /* Looks like PLCP headers plus packet timings are stored for
- * all possible basic rates
- */
- b43_write_probe_resp_plcp(dev, 0x31A, size, &b43_b_ratetable[0]);
- b43_write_probe_resp_plcp(dev, 0x32C, size, &b43_b_ratetable[1]);
- b43_write_probe_resp_plcp(dev, 0x33E, size, &b43_b_ratetable[2]);
- b43_write_probe_resp_plcp(dev, 0x350, size, &b43_b_ratetable[3]);
-
- size = min((size_t) size, 0x200 - sizeof(struct b43_plcp_hdr6));
- b43_write_template_common(dev, probe_resp_data,
- size, ram_offset, shm_size_offset,
- rate->hw_value);
- kfree(probe_resp_data);
-}
-
static void b43_upload_beacon0(struct b43_wldev *dev)
{
struct b43_wl *wl = dev->wl;
@@ -1545,10 +1438,6 @@
if (wl->beacon0_uploaded)
return;
b43_write_beacon_template(dev, 0x68, 0x18);
- /* FIXME: Probe resp upload doesn't really belong here,
- * but we don't use that feature anyway. */
- b43_write_probe_resp_template(dev, 0x268, 0x4A,
- &__b43_ratetable[3]);
wl->beacon0_uploaded = 1;
}
^ permalink raw reply
* Re: [RESEND] [PATCHv2] b43 add harware tkip
From: gregor kowski @ 2009-08-04 22:32 UTC (permalink / raw)
To: Michael Buesch; +Cc: bcm43xx-dev, linux-wireless
In-Reply-To: <200908050027.29829.mb@bu3sch.de>
>
> Yeah, I do understand this bug. My question was if that is the only bug.
>
Sorry, yes this is the only one.
>> So max_nr_keys seems wrong in case of new API.
>
> It's not that simple, actually.
> The max_nr_keys thing was never meant to specify which API we're on.
> It was invented to do the RCMTA vs *oldcrappymechanismiforgotthenameof*.
> max_nr_keys essentially became obsolete and dead code when b43 did not
> support <rev5 anymore. I will submit a patch which removes it and cleans up
> the code alltogether.
Ok, thanks
^ permalink raw reply
* Re: [PATCH] cfg80211: clear SSID on disconnect
From: Joerg Albert @ 2009-08-04 22:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1249388766.9415.6.camel@johannes.local>
On 08/04/2009 02:26 PM, Johannes Berg wrote:
> On Tue, 2009-08-04 at 08:24 +0000, Joerg Albert wrote:
>> Johannes Berg <johannes@...> writes:
>>
>>
>>
>>> Aha. yes, the same assignment is _also_ missing in
>>> __cfg80211_connect_result(), can you add it there manually (in the
>>> status != WLAN_STATUS_SUCCESS block at the end) and see what happens?
>> Yes, that helped in my case.
>
> The v2 patch I posted to this thread should fix the issue then, and also
> fix two more places where it could occur.
Yes, the v2 patch worked well, too.
^ permalink raw reply
* Re: [RESEND] [PATCHv2] b43 add harware tkip
From: Michael Buesch @ 2009-08-04 22:27 UTC (permalink / raw)
To: gregor kowski; +Cc: bcm43xx-dev, linux-wireless
In-Reply-To: <83a869cd0908041523m7b2be0c9t4ae21dc2e22c537@mail.gmail.com>
On Wednesday 05 August 2009 00:23:23 gregor kowski wrote:
> On 8/5/09, Michael Buesch <mb@bu3sch.de> wrote:
> > On Wednesday 05 August 2009 00:03:11 gregor kowski wrote:
> >> On 8/4/09, Michael Buesch <mb@bu3sch.de> wrote:
> >> > On Tuesday 04 August 2009 23:54:42 gregor kowski wrote:
> >> >
> >> > You always talk about "bugs". What are these "bugs"? Is it just the
> >> > wrong
> >> > max_nr_keys assignment? That's trivial to fix.
> >> >
> >> So [1] is ok ?
> >
> > Could you answer my question?
> That's [1]. But may be my description wasn't good.
> I will try a new one.
> we can have up to 50 pairwise keys (due to RCMTA and tkip stuff).
>
> In the case of new API :
> - max_nr_keys is set to 58
> - in b43_key_clear we call do_key_write for index in [0 ... 58]
> - in do_key_write we call keymac_write for index in [4 ... 58]
> - in keymac_write write to RCMTA index [0 ... 54]
> We write too much pairwise keys.
>
> - max_nr_keys is set to 58
> - b43_key_write generate pairwise keys in [sta_keys_start ...
> max_nr_keys] = [0 ... 58] and call do_key_write
> - in do_key_write we call keymac_write for index in [4 ... 58]
> - in keymac_write write to RCMTA index [0 ... 54]
> We write too much pairwise keys.
Yeah, I do understand this bug. My question was if that is the only bug.
> So max_nr_keys seems wrong in case of new API.
It's not that simple, actually.
The max_nr_keys thing was never meant to specify which API we're on.
It was invented to do the RCMTA vs *oldcrappymechanismiforgotthenameof*.
max_nr_keys essentially became obsolete and dead code when b43 did not
support <rev5 anymore. I will submit a patch which removes it and cleans up
the code alltogether.
--
Greetings, Michael.
^ permalink raw reply
* [PATCH v2] b43: Typo fixes & minor cleanup
From: Gábor Stefanik @ 2009-08-04 22:25 UTC (permalink / raw)
To: John Linville, Michael Buesch
Cc: Larry Finger, Broadcom Wireless, linux-wireless
Make use of HostFlags defines in the LP-PHY code.
Fix fallout from the IEEE80211_IF_TYPE to NL80211_IFTYPE change.
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
---
v2: Drop incorrect hunk.
drivers/net/wireless/b43/b43.h | 2 +-
drivers/net/wireless/b43/phy_lp.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/b43/b43.h b/drivers/net/wireless/b43/b43.h
index 41ca727..52fd6d6 100644
--- a/drivers/net/wireless/b43/b43.h
+++ b/drivers/net/wireless/b43/b43.h
@@ -627,7 +627,7 @@ struct b43_wl {
u8 mac_addr[ETH_ALEN];
/* Current BSSID */
u8 bssid[ETH_ALEN];
- /* Interface type. (IEEE80211_IF_TYPE_XXX) */
+ /* Interface type. (NL80211_IFTYPE_XXX) */
int if_type;
/* Is the card operating in AP, STA or IBSS mode? */
bool operating;
diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
index 5d50943..03a9b50 100644
--- a/drivers/net/wireless/b43/phy_lp.c
+++ b/drivers/net/wireless/b43/phy_lp.c
@@ -130,7 +130,7 @@ static void lpphy_baseband_rev0_1_init(struct b43_wldev *dev)
b43_phy_set(dev, B43_LPPHY_CRSGAIN_CTL, 0x0006);
b43_phy_write(dev, B43_LPPHY_GPIO_SELECT, 0x0005);
b43_phy_write(dev, B43_LPPHY_GPIO_OUTEN, 0xFFFF);
- b43_hf_write(dev, b43_hf_read(dev) | 0x0800ULL << 32);
+ b43_hf_write(dev, b43_hf_read(dev) | B43_HF_PR45960W);
}
if (b43_current_band(dev->wl) == IEEE80211_BAND_2GHZ) {
b43_phy_set(dev, B43_LPPHY_LP_PHY_CTL, 0x8000);
--
1.6.2.4
^ permalink raw reply related
* Re: [RESEND] [PATCHv2] b43 add harware tkip
From: gregor kowski @ 2009-08-04 22:23 UTC (permalink / raw)
To: Michael Buesch; +Cc: bcm43xx-dev, linux-wireless
In-Reply-To: <200908050006.02754.mb@bu3sch.de>
On 8/5/09, Michael Buesch <mb@bu3sch.de> wrote:
> On Wednesday 05 August 2009 00:03:11 gregor kowski wrote:
>> On 8/4/09, Michael Buesch <mb@bu3sch.de> wrote:
>> > On Tuesday 04 August 2009 23:54:42 gregor kowski wrote:
>> >
>> > You always talk about "bugs". What are these "bugs"? Is it just the
>> > wrong
>> > max_nr_keys assignment? That's trivial to fix.
>> >
>> So [1] is ok ?
>
> Could you answer my question?
That's [1]. But may be my description wasn't good.
I will try a new one.
we can have up to 50 pairwise keys (due to RCMTA and tkip stuff).
In the case of new API :
- max_nr_keys is set to 58
- in b43_key_clear we call do_key_write for index in [0 ... 58]
- in do_key_write we call keymac_write for index in [4 ... 58]
- in keymac_write write to RCMTA index [0 ... 54]
We write too much pairwise keys.
- max_nr_keys is set to 58
- b43_key_write generate pairwise keys in [sta_keys_start ...
max_nr_keys] = [0 ... 58] and call do_key_write
- in do_key_write we call keymac_write for index in [4 ... 58]
- in keymac_write write to RCMTA index [0 ... 54]
We write too much pairwise keys.
So max_nr_keys seems wrong in case of new API.
Gregor.
[1]
> if b43_new_kidx_api is true :
> - we set max_nr_keys to 58
> - we program B43_MMIO_RCMTA_COUNT to 50
> - in b43_key_write we can allocate key up to index 58 (4 for default,
> 54 for sta)
>
> But there is only 50 entries for TKIPTSCTTAK, and a comment on bcm-v4
> suggest there is 50 entries for RCMTA. So if there more than 50
> station we will overflow RCMTA and TKIPTSCTTAK.
^ 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