* Re: Rfkill rewrite
From: Johannes Berg @ 2009-07-18 17:40 UTC (permalink / raw)
To: Alan Jenkins; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <4A61EE43.4060003@tuffmail.co.uk>
[-- Attachment #1: Type: text/plain, Size: 343 bytes --]
On Sat, 2009-07-18 at 16:46 +0100, Alan Jenkins wrote:
> It seems my GCC has a stronger definition of "must" than you do :-).
> I can't get rid of the warning by casting it to void. So I'm not sure
> __must_check is really appropriate here.
Heh, my gcc agrees with you :)
I'm happy to remove it -- want to send a patch?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: WARN_ON at minstrel_get_rate (include/net/mac80211.h:2111)
From: Christian Lamparter @ 2009-07-18 17:48 UTC (permalink / raw)
To: Larry Finger; +Cc: Johannes Berg, wireless
In-Reply-To: <200907181808.05142.chunkeey@web.de>
On Saturday 18 July 2009 18:08:04 Christian Lamparter wrote:
> On Saturday 18 July 2009 17:03:18 Larry Finger wrote:
> > Thanks for the patch. I'll let you know what happens.
> I have my doubts. Do you still have the WARN_ON dump?
> or at least which of the two functions are listed in the dump?
> - rate_control_get_rate
> - rate_control_rate_init <- unlikely/really surprising
found a similar WARNINGs on kerneloops:
http://www.kerneloops.org/raw.php?rawid=449304&msgid=
but the user has ath5k.
and there's more: iwlagn used to have this issue, but they fixed it.
---
commit c338ba3ca5bef2df2082d9e8d336ff7b2880c326
Author: Abbas, Mohamed <mohamed.abbas@intel.com>
Date: Wed Jan 21 10:58:02 2009 -0800
iwlwifi: fix rs_get_rate WARN_ON()
In ieee80211_sta structure there is u64 supp_rates[IEEE80211_NUM_BANDS]
this is filled with all support rate from assoc_resp. If we associate
with G-band AP only supp_rates of G-band will be set the other band
supp_rates will be set to 0. If the user type this command
this will cause mac80211 to set to new channel, mac80211
does not disassociate in setting new channel, so the active
band is now A-band. then in handling the new essid mac80211 will
kick in the assoc steps which involve sending disassociation frame.
in this mac80211 will WARN_ON sta->supp_rates[A_BAND] == 0.
---
Larry, can you confirm that the frame which triggers the WARN is a
disassociation frame.
^ permalink raw reply
* [PATCH] rfkill: remove too-strict __must_check
From: Alan Jenkins @ 2009-07-18 18:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1247938802.18391.0.camel@johannes.local>
Some drivers don't need the return value of rfkill_set_hw_state(),
so it should not be marked as __must_check.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
include/linux/rfkill.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
index f3d5812..1020290 100644
--- a/include/linux/rfkill.h
+++ b/include/linux/rfkill.h
@@ -238,7 +238,7 @@ void rfkill_destroy(struct rfkill *rfkill);
* should be blocked) so that drivers need not keep track of the soft
* block state -- which they might not be able to.
*/
-bool __must_check rfkill_set_hw_state(struct rfkill *rfkill, bool blocked);
+bool rfkill_set_hw_state(struct rfkill *rfkill, bool blocked);
/**
* rfkill_set_sw_state - Set the internal rfkill software block state
--
1.6.3.2
^ permalink raw reply related
* [PATCH] rt2x00: Don't alter rt2x00dev->default_ant
From: Ivo van Doorn @ 2009-07-18 18:21 UTC (permalink / raw)
To: John Linville, users, linux-wireless, Lars Ericsson
From: Lars Ericsson <Lars_Ericsson@telia.com>
rt2x00dev->default_ant should be initialized once by the driver,
and should not be changed afterwards. Because rt2x00lib_config_antenna()
was using a reference to the struct antenna_setup it actually had the oppurtunity
to change the default antenna setting and it actually did that during the validation.
Instead of passing a pointer to antenna_setup the entire structure should be copied.
Signed-off-by: Lars Ericsson <Lars_Ericsson@telia.com>
Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
---
diff --git a/drivers/net/wireless/rt2x00/rt2x00config.c b/drivers/net/wireless/rt2x00/rt2x00config.c
index c6e0bcf..3845316 100644
--- a/drivers/net/wireless/rt2x00/rt2x00config.c
+++ b/drivers/net/wireless/rt2x00/rt2x00config.c
@@ -124,7 +124,7 @@ enum antenna rt2x00lib_config_antenna_check(enum antenna current_ant,
}
void rt2x00lib_config_antenna(struct rt2x00_dev *rt2x00dev,
- struct antenna_setup *ant)
+ struct antenna_setup ant)
{
struct antenna_setup *def = &rt2x00dev->default_ant;
struct antenna_setup *active = &rt2x00dev->link.ant.active;
@@ -138,10 +138,10 @@ void rt2x00lib_config_antenna(struct rt2x00_dev *rt2x00dev,
* might have caused that we restore back to the already
* active setting. If that has happened we can quit.
*/
- ant->rx = rt2x00lib_config_antenna_check(ant->rx, def->rx);
- ant->tx = rt2x00lib_config_antenna_check(ant->tx, def->tx);
+ ant.rx = rt2x00lib_config_antenna_check(ant.rx, def->rx);
+ ant.tx = rt2x00lib_config_antenna_check(ant.tx, def->tx);
- if (ant->rx == active->rx && ant->tx == active->tx)
+ if (ant.rx == active->rx && ant.tx == active->tx)
return;
/*
@@ -156,11 +156,11 @@ void rt2x00lib_config_antenna(struct rt2x00_dev *rt2x00dev,
* The latter is required since we need to recalibrate the
* noise-sensitivity ratio for the new setup.
*/
- rt2x00dev->ops->lib->config_ant(rt2x00dev, ant);
+ rt2x00dev->ops->lib->config_ant(rt2x00dev, &ant);
rt2x00link_reset_tuner(rt2x00dev, true);
- memcpy(active, ant, sizeof(*ant));
+ memcpy(active, &ant, sizeof(ant));
if (test_bit(DEVICE_STATE_ENABLED_RADIO, &rt2x00dev->flags))
rt2x00lib_toggle_rx(rt2x00dev, STATE_RADIO_RX_ON_LINK);
diff --git a/drivers/net/wireless/rt2x00/rt2x00lib.h b/drivers/net/wireless/rt2x00/rt2x00lib.h
index 2c3c239..c0aa2e6 100644
--- a/drivers/net/wireless/rt2x00/rt2x00lib.h
+++ b/drivers/net/wireless/rt2x00/rt2x00lib.h
@@ -88,7 +88,7 @@ void rt2x00lib_config_erp(struct rt2x00_dev *rt2x00dev,
struct rt2x00_intf *intf,
struct ieee80211_bss_conf *conf);
void rt2x00lib_config_antenna(struct rt2x00_dev *rt2x00dev,
- struct antenna_setup *ant);
+ struct antenna_setup ant);
void rt2x00lib_config(struct rt2x00_dev *rt2x00dev,
struct ieee80211_conf *conf,
const unsigned int changed_flags);
diff --git a/drivers/net/wireless/rt2x00/rt2x00link.c b/drivers/net/wireless/rt2x00/rt2x00link.c
index 3257075..7991568 100644
--- a/drivers/net/wireless/rt2x00/rt2x00link.c
+++ b/drivers/net/wireless/rt2x00/rt2x00link.c
@@ -173,7 +173,7 @@ static void rt2x00lib_antenna_diversity_sample(struct rt2x00_dev *rt2x00dev)
if (ant->flags & ANTENNA_TX_DIVERSITY)
new_ant.tx = (sample_a > sample_b) ? ANTENNA_A : ANTENNA_B;
- rt2x00lib_config_antenna(rt2x00dev, &new_ant);
+ rt2x00lib_config_antenna(rt2x00dev, new_ant);
}
static void rt2x00lib_antenna_diversity_eval(struct rt2x00_dev *rt2x00dev)
@@ -213,7 +213,7 @@ static void rt2x00lib_antenna_diversity_eval(struct rt2x00_dev *rt2x00dev)
if (ant->flags & ANTENNA_TX_DIVERSITY)
new_ant.tx = (new_ant.tx == ANTENNA_A) ? ANTENNA_B : ANTENNA_A;
- rt2x00lib_config_antenna(rt2x00dev, &new_ant);
+ rt2x00lib_config_antenna(rt2x00dev, new_ant);
}
static void rt2x00lib_antenna_diversity(struct rt2x00_dev *rt2x00dev)
diff --git a/drivers/net/wireless/rt2x00/rt2x00mac.c b/drivers/net/wireless/rt2x00/rt2x00mac.c
index 54fd2e8..8e8e46c 100644
--- a/drivers/net/wireless/rt2x00/rt2x00mac.c
+++ b/drivers/net/wireless/rt2x00/rt2x00mac.c
@@ -378,7 +378,7 @@ int rt2x00mac_config(struct ieee80211_hw *hw, u32 changed)
*/
if (changed & IEEE80211_CONF_CHANGE_RADIO_ENABLED)
rt2x00lib_config_antenna(rt2x00dev,
- &rt2x00dev->default_ant);
+ rt2x00dev->default_ant);
/* Turn RX back on */
rt2x00lib_toggle_rx(rt2x00dev, STATE_RADIO_RX_ON);
^ permalink raw reply related
* Re: [PATCH] rfkill: remove too-strict __must_check
From: Johannes Berg @ 2009-07-18 18:22 UTC (permalink / raw)
To: Alan Jenkins; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <4A621264.4030102@tuffmail.co.uk>
[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]
On Sat, 2009-07-18 at 19:20 +0100, Alan Jenkins wrote:
> Some drivers don't need the return value of rfkill_set_hw_state(),
> so it should not be marked as __must_check.
>
> Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Thanks.
> ---
> include/linux/rfkill.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h
> index f3d5812..1020290 100644
> --- a/include/linux/rfkill.h
> +++ b/include/linux/rfkill.h
> @@ -238,7 +238,7 @@ void rfkill_destroy(struct rfkill *rfkill);
> * should be blocked) so that drivers need not keep track of the soft
> * block state -- which they might not be able to.
> */
> -bool __must_check rfkill_set_hw_state(struct rfkill *rfkill, bool blocked);
> +bool rfkill_set_hw_state(struct rfkill *rfkill, bool blocked);
>
> /**
> * rfkill_set_sw_state - Set the internal rfkill software block state
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Generic events for wake up from S1-S4
From: Luis R. Rodriguez @ 2009-07-18 20:02 UTC (permalink / raw)
To: Pavel Machek
Cc: Rafael J. Wysocki, linux-kernel, Johannes Berg, John W. Linville,
Jouni Malinen, linux-wireless, Stephen Chen
In-Reply-To: <20090718103756.GA11381@elf.ucw.cz>
On Sat, Jul 18, 2009 at 3:37 AM, Pavel Machek<pavel@ucw.cz> wrote:
> On Wed 2009-07-15 11:00:07, Luis R. Rodriguez wrote:
>> On Wed, Jul 15, 2009 at 8:51 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
>> > On Tue, Jul 14, 2009 at 4:53 PM, Pavel Machek<pavel@ucw.cz> wrote:
>> >> On Tue 2009-07-14 15:11:45, Luis R. Rodriguez wrote:
>> >>> I'm working on Wake-on-Wireless support for wireless right now [1].
>> >>> Upon wake up I wanted to inform the kernel of the event which caused
>> >>> the wake up but am not clear if there is a generic API for this. Mind
>> >>> you, for WoW we'll need at least some AC power to the card so we'll
>> >>> need to at least be in S3-Hot so we'll only need events for that for
>> >>> now.
>> >>>
>> >>> Do we have some generic infrastructure to gather reasons for wake up
>> >>> from S1-S4 and pass this to userspace yet?
>> >>
>> >> I do not think generic api exists...
>>
>> Going back to this topic -- any suggestions? Will a generic netlink
>> family be OK? Or perhaps easier a udev event for some suitable
>> existing parent ?
>
> Is "who woke me" information even relevant? Yes, it may be interesting
> enough for printk, but... What will userspace do with that information?
Splashy event notification thingies?
I was just trying to avoid verbose debug info for WoW upon wakeup and
figured it be nice to report back through a generic interface.
> Imagine WoW packet comes, 5msec later WoL packet comes, 5msec later
> user opens the lid. You report WoW as wakeup reason, but it is
> inherently "racy".
Hm yeah, but I doubt someone will do that, generally we'd get one wake
up event. Can't we just report the first one and ignore the rest?
> What about simply reporting "wake event happened on this device" and
> doing that for all the devices?
That's fine too. Just think it would be nice to be more specific if possible.
Luis
^ permalink raw reply
* Re: WARN_ON at minstrel_get_rate (include/net/mac80211.h:2111) with p54usb
From: Bob Copeland @ 2009-07-18 21:19 UTC (permalink / raw)
To: Larry Finger; +Cc: Christian Lamparter, Johannes Berg, wireless
In-Reply-To: <4A61E436.9060808@lwfinger.net>
On Sat, Jul 18, 2009 at 11:03 AM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
> Christian Lamparter wrote:
>> On Saturday 18 July 2009 03:05:04 Larry Finger wrote:
>>> Johannes and Christian,
>>>
>>> I am getting a WARN_ON from mac80211 in the location stated in the
>>> subject. I put in some test prints and got the following:
>>>
>>> sband->n_bitrates 8, Band 1, supp_rates 0x0
>> hmm, so something decides to talk to a 5GHz network here?
>> But the AP doesn't have any available rates in that band!?
>
> Ah, band 1 is 5GHz, not 2.4. There are no 802.11a AP's in my neighborhood.
>
>> If my memory serves my right some people have triggered the same WARN_ON
>> with the ath5k driver as well...
>> unfortunately, I didn't follow the thread and now I can't find it anymore.
>>
>> (btw: is your b43 11a capable as well?)
>
> Yes it is, but that section is software crippled.
>
> Thanks for the patch. I'll let you know what happens.
In the ath5k case as well, I'm willing to bet it has something to do with dual
band operation. IIRC at least some instances of this in the past were due to
getting the rate after the band was changed, e.g. due to scanning, and the peer
of course didn't support any rates on that band.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* compat-wireless-2.6.31-rc1 build problem
From: Rob @ 2009-07-18 21:27 UTC (permalink / raw)
To: linux-wireless
Hope this is the correct place to report it. I can't build the above
with 2.6.27.23-0.1-default, gcc v4.3.2, openSUSE 11.1.
compat-wireless-2.6.30 is ok however.
CC [M] /compat-wireless-2.6.31-rc1/net/mac80211/main.o
/compat-wireless-2.6.31-rc1/net/mac80211/main.c: In function
‘ieee80211_bss_info_change_notify’:
/compat-wireless-2.6.31-rc1/net/mac80211/main.c:293: warning:
‘beacon_int’ is deprecated (declared at
/compat-wireless-2.6.31-rc1/include/net/mac80211.h:593)
/compat-wireless-2.6.31-rc1/net/mac80211/main.c: In function
‘ieee80211_alloc_hw’:
/compat-wireless-2.6.31-rc1/net/mac80211/main.c:714: warning:
‘radio_enabled’ is deprecated (declared at
/compat-wireless-2.6.31-rc1/include/net/mac80211.h:599)
/compat-wireless-2.6.31-rc1/net/mac80211/main.c: At top level:
/compat-wireless-2.6.31-rc1/net/mac80211/main.c:758: error: variable
‘ieee80211_master_ops’ has initializer but incomplete type
/compat-wireless-2.6.31-rc1/net/mac80211/main.c:759: error: unknown
field ‘ndo_start_xmit’ specified in initializer
/compat-wireless-2.6.31-rc1/net/mac80211/main.c:759: warning: excess
elements in struct initializer
/compat-wireless-2.6.31-rc1/net/mac80211/main.c:759: warning: (near
initialization for ‘ieee80211_master_ops’)
/compat-wireless-2.6.31-rc1/net/mac80211/main.c:760: error: unknown
field ‘ndo_open’ specified in initializer
/compat-wireless-2.6.31-rc1/net/mac80211/main.c:760: warning: excess
elements in struct initializer
/compat-wireless-2.6.31-rc1/net/mac80211/main.c:760: warning: (near
initialization for ‘ieee80211_master_ops’)
/compat-wireless-2.6.31-rc1/net/mac80211/main.c:761: error: unknown
field ‘ndo_stop’ specified in initializer
/compat-wireless-2.6.31-rc1/net/mac80211/main.c:761: warning: excess
elements in struct initializer
/compat-wireless-2.6.31-rc1/net/mac80211/main.c:761: warning: (near
initialization for ‘ieee80211_master_ops’)
/compat-wireless-2.6.31-rc1/net/mac80211/main.c:762: error: unknown
field ‘ndo_set_multicast_list’ specified in initializer
/compat-wireless-2.6.31-rc1/net/mac80211/main.c:762: warning: excess
elements in struct initializer
/compat-wireless-2.6.31-rc1/net/mac80211/main.c:762: warning: (near
initialization for ‘ieee80211_master_ops’)
/compat-wireless-2.6.31-rc1/net/mac80211/main.c:763: error: unknown
field ‘ndo_select_queue’ specified in initializer
/compat-wireless-2.6.31-rc1/net/mac80211/main.c:763: warning: excess
elements in struct initializer
/compat-wireless-2.6.31-rc1/net/mac80211/main.c:763: warning: (near
initialization for ‘ieee80211_master_ops’)
/compat-wireless-2.6.31-rc1/net/mac80211/main.c: In function
‘ieee80211_master_setup’:
/compat-wireless-2.6.31-rc1/net/mac80211/main.c:769: error: ‘struct
net_device’ has no member named ‘netdev_ops’
make[5]: *** [/compat-wireless-2.6.31-rc1/net/mac80211/main.o] Error 1
make[4]: *** [/compat-wireless-2.6.31-rc1/net/mac80211] Error 2
make[3]: *** [_module_/compat-wireless-2.6.31-rc1] Error 2
make[2]: *** [sub-make] Error 2
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.27.23-0.1-obj/i386/default'
make: *** [modules] Error 2
^ permalink raw reply
* [PATCH] ath5k: fix values for bus error bits in ISR2
From: Pavel Roskin @ 2009-07-18 22:12 UTC (permalink / raw)
To: ath5k-devel, linux-wireless, John W. Linville
The new values are taken from the recently open sourced Atheros HAL.
Correctness is also confirmed by the users with access to Atheros
documentation.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
drivers/net/wireless/ath/ath5k/reg.h | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/reg.h b/drivers/net/wireless/ath/ath5k/reg.h
index 6809b54..9ebe188 100644
--- a/drivers/net/wireless/ath/ath5k/reg.h
+++ b/drivers/net/wireless/ath/ath5k/reg.h
@@ -339,9 +339,9 @@
#define AR5K_SISR2 0x008c /* Register Address [5211+] */
#define AR5K_SISR2_QCU_TXURN 0x000003ff /* Mask for QCU_TXURN */
#define AR5K_SISR2_QCU_TXURN_S 0
-#define AR5K_SISR2_MCABT 0x00100000 /* Master Cycle Abort */
-#define AR5K_SISR2_SSERR 0x00200000 /* Signaled System Error */
-#define AR5K_SISR2_DPERR 0x00400000 /* Bus parity error */
+#define AR5K_SISR2_MCABT 0x00010000 /* Master Cycle Abort */
+#define AR5K_SISR2_SSERR 0x00020000 /* Signaled System Error */
+#define AR5K_SISR2_DPERR 0x00040000 /* Bus parity error */
#define AR5K_SISR2_TIM 0x01000000 /* [5212+] */
#define AR5K_SISR2_CAB_END 0x02000000 /* [5212+] */
#define AR5K_SISR2_DTIM_SYNC 0x04000000 /* DTIM sync lost [5212+] */
^ permalink raw reply related
* Re: WARN_ON at minstrel_get_rate (include/net/mac80211.h:2111) with p54usb
From: Christian Lamparter @ 2009-07-18 22:32 UTC (permalink / raw)
To: Bob Copeland; +Cc: Larry Finger, Johannes Berg, wireless
In-Reply-To: <b6c5339f0907181419h28b84166s72ba9386f2833c61@mail.gmail.com>
On Saturday 18 July 2009 23:19:36 Bob Copeland wrote:
> On Sat, Jul 18, 2009 at 11:03 AM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
> > Christian Lamparter wrote:
> >> On Saturday 18 July 2009 03:05:04 Larry Finger wrote:
> >>> Johannes and Christian,
> >>>
> >>> I am getting a WARN_ON from mac80211 in the location stated in the
> >>> subject. I put in some test prints and got the following:
> >>>
> >>> sband->n_bitrates 8, Band 1, supp_rates 0x0
> >> hmm, so something decides to talk to a 5GHz network here?
> >> But the AP doesn't have any available rates in that band!?
> >
> > Ah, band 1 is 5GHz, not 2.4. There are no 802.11a AP's in my neighborhood.
> >
> >> If my memory serves my right some people have triggered the same WARN_ON
> >> with the ath5k driver as well...
> >> unfortunately, I didn't follow the thread and now I can't find it anymore.
> >>
> >> (btw: is your b43 11a capable as well?)
> >
> > Yes it is, but that section is software crippled.
> >
> > Thanks for the patch. I'll let you know what happens.
>
> In the ath5k case as well, I'm willing to bet it has something to do with dual
> band operation. IIRC at least some instances of this in the past were due to
> getting the rate after the band was changed, e.g. due to scanning, and the peer
> of course didn't support any rates on that band.
>
well, ieee80211_sta_monitor_work - which probes the AP every now and then -
didn't check if we're scanning.
The attached diff survives a non-stop scanning without throwing the WARN in
rate_lowest_index once.
However, I'm not so sure about the locking for hw_scanning and sw_scanning.
It looks like only scan.c manipulates them under the scan mutex.
But then, do we need locking for a single threaded workqueue? guess not.
---
Larry,
here's another _fix_ which might even fix the problem after all ;-)
Regards,
Chr
---
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 18dad22..4833e7c 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2210,6 +2210,9 @@ static void ieee80211_sta_monitor_work(struct work_struct *work)
container_of(work, struct ieee80211_sub_if_data,
u.mgd.monitor_work);
+ if (sdata->local->sw_scanning || sdata->local->hw_scanning)
+ return;
+
ieee80211_mgd_probe_ap(sdata, false);
}
^ permalink raw reply related
* Re: Generic events for wake up from S1-S4
From: Henrique de Moraes Holschuh @ 2009-07-18 23:56 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Pavel Machek, Rafael J. Wysocki, linux-kernel, Johannes Berg,
John W. Linville, Jouni Malinen, linux-wireless, Stephen Chen
In-Reply-To: <43e72e890907181302j600506d5oc208167206c44745@mail.gmail.com>
On Sat, 18 Jul 2009, Luis R. Rodriguez wrote:
> Hm yeah, but I doubt someone will do that, generally we'd get one wake
> up event. Can't we just report the first one and ignore the rest?
Well, I'd say keeping it simple is best, here. What if you ignore the more
interesting wakeup events by chance (and it is really up to userspace to
know what it considers interesting...)? IMHO, just issue as many
notifications as needed, let userspace filter it if it wants.
But if you guys are talking about something really generic, shouldn't it
also provide the important "why" along with the "who"?
Even for the most common cases, the "why" is useful: userspace may well want
to run special routines when it wakes up because of WoL and WoW (instead of
a key press, lid open or mouse movement...).
When you factor in wakeups caused by platform alarms, well, the "why"
becomes even more interesting.
> > What about simply reporting "wake event happened on this device" and
> > doing that for all the devices?
>
> That's fine too. Just think it would be nice to be more specific if possible.
A generic way for a device (of any sort, not just network devices!) to
report that they just issued a system wakeup message, as well as the reason
it did that seems like a good way to do it to me.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply
* [PATCH] cfg80211: double free in __cfg80211_scan_done
From: Christian Lamparter @ 2009-07-19 3:05 UTC (permalink / raw)
To: wireless; +Cc: Luis R. Rodriguez, Johannes Berg, John W. Linville
This patch fixes a double free corruption in __cfg80211_scan_done:
================================================
BUG kmalloc-512: Object already free
------------------------------------------------
INFO: Allocated in load_elf_binary+0x18b/0x19af age=6
INFO: Freed in load_elf_binary+0x104e/0x19af age=5
INFO: Slab 0xffffea0001bae4c0 objects=14 used=7
INFO: Object 0xffff88007e8a9918 @offset=6424 fp=0xffff88007e8a9488
Bytes b4 0xffff88007e8a9908: 00 00 00 00 00 00 00 00 5a 5a
[...]
Pid: 28705, comm: rmmod Tainted: P C 2.6.31-rc2-wl #1
Call Trace:
[<ffffffff810da9f4>] print_trailer+0x14e/0x16e
[<ffffffff810daa56>] object_err+0x42/0x61
[<ffffffff810dbcd9>] __slab_free+0x2af/0x396
[<ffffffffa0ec9694>] ? wiphy_unregister+0x92/0x142 [cfg80211]
[<ffffffff810dd5e3>] kfree+0x13c/0x17a
[<ffffffffa0ec9694>] ? wiphy_unregister+0x92/0x142 [cfg80211]
[<ffffffffa0ec9694>] wiphy_unregister+0x92/0x142 [cfg80211]
[<ffffffffa0eed163>] ieee80211_unregister_hw+0xc8/0xff [mac80211]
[<ffffffffa0f3fbc8>] p54_unregister_common+0x31/0x66 [p54common]
[...]
FIX kmalloc-512: Object at 0xffff88007e8a9918 not freed
The code path which leads to the *funny* double free:
request = rdev->scan_req;
dev = dev_get_by_index(&init_net, request->ifidx);
/*
* the driver was unloaded recently and
* therefore dev_get_by_index will return NULL!
*/
if (!dev)
goto out;
[...]
rdev->scan_req = NULL; /* not executed... */
[...]
out:
kfree(request);
Signed-off-by: Christian Lamparter <chunkeey@web.de>
---
huh, no one spotted that bug before?
---
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 4f552c3..4ad8b4b 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -48,8 +48,6 @@ void __cfg80211_scan_done(struct work_struct *wk)
else
nl80211_send_scan_done(wiphy_to_dev(request->wiphy), dev);
- wiphy_to_dev(request->wiphy)->scan_req = NULL;
-
#ifdef CONFIG_WIRELESS_EXT
if (!request->aborted) {
memset(&wrqu, 0, sizeof(wrqu));
@@ -61,6 +59,7 @@ void __cfg80211_scan_done(struct work_struct *wk)
dev_put(dev);
out:
+ rdev->scan_req = NULL;
cfg80211_unlock_rdev(rdev);
kfree(request);
}
^ permalink raw reply related
* [PATCH] acer-wmi: fix rfkill conversion
From: Alan Jenkins @ 2009-07-19 8:48 UTC (permalink / raw)
To: John W. Linville; +Cc: Troy Moure, linux-wireless, Johannes Berg
In-Reply-To: <alpine.LFD.2.00.0906171135080.3376@troy-laptop>
On 6/17/09, Troy Moure <twmoure@szypr.net> wrote:
> Commit 19d337dff95cbf76ed ("rfkill: rewrite") incorrectly reversed
> the meaning of 'state' in acer_rfkill_update() when it changed
> rfkill_force_state() to rfkill_set_sw_state(). Fix it.
>
> Signed-off-by: Troy Moure <twmoure@szypr.net>
> ---
> This fixes the rfkill switch on my Acer laptop, which was behaving
> backwards (the state reported in the logs was the opposite of the
> state indicated by the LED).
I think there's another reversal error that you didn't notice :-). I found that acer-wmi disables the wireless when it is loaded.
The core tries to initialize the wireless to enabled, but the polarity is wrong in acer_rfkill_set(). It ends up disabling the wireless instead.
Here's a patch for it.
--->
>From 75953366b4958a77019729662a997f5d361a7529 Mon Sep 17 00:00:00 2001
From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Date: Sun, 19 Jul 2009 09:29:21 +0100
Subject: [PATCH] acer-wmi: fix rfkill conversion
Fix another polarity error introduced by the rfkill rewrite,
this time in acer_rfkill_set().
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
drivers/platform/x86/acer-wmi.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index be2fd6f..fb45f5e 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -973,7 +973,7 @@ static int acer_rfkill_set(void *data, bool blocked)
{
acpi_status status;
u32 cap = (unsigned long)data;
- status = set_u32(!!blocked, cap);
+ status = set_u32(!blocked, cap);
if (ACPI_FAILURE(status))
return -ENODEV;
return 0;
--
1.6.3.2
^ permalink raw reply related
* Re: [PATCH] acer-wmi: fix rfkill conversion
From: Johannes Berg @ 2009-07-19 8:53 UTC (permalink / raw)
To: Alan Jenkins; +Cc: John W. Linville, Troy Moure, linux-wireless
In-Reply-To: <4A62DDDC.5090100@tuffmail.co.uk>
[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]
On Sun, 2009-07-19 at 09:48 +0100, Alan Jenkins wrote:
> On 6/17/09, Troy Moure <twmoure@szypr.net> wrote:
> > Commit 19d337dff95cbf76ed ("rfkill: rewrite") incorrectly reversed
> > the meaning of 'state' in acer_rfkill_update() when it changed
> > rfkill_force_state() to rfkill_set_sw_state(). Fix it.
> >
> > Signed-off-by: Troy Moure <twmoure@szypr.net>
> > ---
> > This fixes the rfkill switch on my Acer laptop, which was behaving
> > backwards (the state reported in the logs was the opposite of the
> > state indicated by the LED).
>
> I think there's another reversal error that you didn't notice :-). I
> found that acer-wmi disables the wireless when it is loaded.
Ahrg.
> The core tries to initialize the wireless to enabled, but the polarity
> is wrong in acer_rfkill_set(). It ends up disabling the wireless
> instead.
>
> Here's a patch for it.
I really should go back and audit it again, but every instance takes me
about 5 minutes to do the (not state != unblocked) thing in my
head ... :/
Thanks!
johannes
> --->
> From 75953366b4958a77019729662a997f5d361a7529 Mon Sep 17 00:00:00 2001
> From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> Date: Sun, 19 Jul 2009 09:29:21 +0100
> Subject: [PATCH] acer-wmi: fix rfkill conversion
>
> Fix another polarity error introduced by the rfkill rewrite,
> this time in acer_rfkill_set().
>
> Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> ---
> drivers/platform/x86/acer-wmi.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
> index be2fd6f..fb45f5e 100644
> --- a/drivers/platform/x86/acer-wmi.c
> +++ b/drivers/platform/x86/acer-wmi.c
> @@ -973,7 +973,7 @@ static int acer_rfkill_set(void *data, bool blocked)
> {
> acpi_status status;
> u32 cap = (unsigned long)data;
> - status = set_u32(!!blocked, cap);
> + status = set_u32(!blocked, cap);
> if (ACPI_FAILURE(status))
> return -ENODEV;
> return 0;
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Using compat-wireless w/ 2.6.27.26
From: Philip A. Prindeville @ 2009-07-19 8:58 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4A612514.4050708@redfish-solutions.com>
Errr... building 2.6.27.26 rather, as per the title...
Philip A. Prindeville wrote:
> I'm the lead developer on the Astlinux project, which I might have
> mentioned in a previous posting. This means that I have my hands in
> many pots, so I'm not an expert in the latest Linux kernel changes... be
> patient with me. Hard to keep track of 200+ individual projects.
>
> I'm building 2.6.26.27 as I said for (amongst other things) an Alix 2D3
> (GeodeLX) with EMP-8602 (AR-5413) as a test platform.
>
> My kernel gets built with:
>
> #
> # Wireless
> #
> CONFIG_CFG80211=m
> CONFIG_NL80211=y
> CONFIG_WIRELESS_EXT=y
> # CONFIG_WIRELESS_EXT_SYSFS is not set
> CONFIG_MAC80211=m
>
> #
> # Rate control algorithm selection
> #
> CONFIG_MAC80211_RC_PID=y
> CONFIG_MAC80211_RC_DEFAULT_PID=y
> CONFIG_MAC80211_RC_DEFAULT="pid"
> # CONFIG_MAC80211_MESH is not set
> CONFIG_MAC80211_LEDS=y
> # CONFIG_MAC80211_DEBUG_MENU is not set
> # CONFIG_IEEE80211 is not set
> CONFIG_RFKILL=m
> CONFIG_RFKILL_INPUT=m
> CONFIG_RFKILL_LEDS=y
> # CONFIG_NET_9P is not set
>
>
> I build compat-wireless-2.6.30 into /lib/modules/2.6.27.26-astlinux/kernel/... as a Kbuild.
>
> The system also has iw-0.9.15 and hostapd-0.6.9.
>
> All of this is fairly straightforward.
>
> On boot, our /etc/init.d scripts do the following:
>
> + modprobe ath5k
> ath5k phy0: Atheros AR5413 chip found (MAC: 0xa4, PHY: 0x61)
>
> + iw dev wlan0 interface add ap0 type managed
> + ip link set ap0 up
> + iw dev ap0 connect xxxx
> command failed: Operation not supported (-95)
>
>
>
> So doing some sanity checks by hand I get:
>
> pbx ~ # lsmod | head
> Module Size Used by
> ath5k 104772 0
> mac80211 153304 1 ath5k
> cfg80211 54584 2 ath5k,mac80211
> binfmt_misc 7112 1
> aes_i586 7456 0
> aes_generic 28968 1 aes_i586
> lm90 11944 0
> hwmon 2324 1 lm90
> scx200_acb 4356 0
> pbx ~ # iw dev ap0 info
> Interface ap0
> ifindex 9
> type managed
> pbx ~ # iw phy phy0 info
> command failed: No buffer space available (-105)
> pbx ~ #
>
>
> Not sure why the "phy ... info" command fails.
>
> pbx ~ # hostapd -v
> hostapd v0.6.9
> User space daemon for IEEE 802.11 AP management,
> IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator
> Copyright (c) 2002-2009, Jouni Malinen <j@w1.fi> and contributors
> pbx ~ # cat /etc/hostapd.conf
> # automatically generated. do not edit!
>
> logger_syslog=-1
> logger_syslog_level=2
> logger_stdout=--1
> logger_stdout_level=2
>
> debug=0
>
> ctrl_interface_group=0
>
> # should this be per-ssid?
> macaddr_acl=0
>
> dump_file=/tmp/hostapd.dump
>
> # should this be an option?
> hw_mode=b
>
> bridge=br1
> interface=ap0
> driver=nl80211
> ssid=xxxxx
> channel=0
>
> auth_algs=1
>
> wpa_passphrase=yyyyy
> wpa=2
> wpa_key_mgmt=WPA-PSK
> wpa_pairwise=TKIP
> rsn_pairwise=CCMP
>
> ignore_broadcast_ssid=1
>
> wpa_strict_rekey=1
> wpa_group_rekey=600
> wpa_gmk_rekey=14400
>
> pbx ~ # ip link show ap0
> 9: ap0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
> link/ether 00:02:6f:5a:d2:2b brd ff:ff:ff:ff:ff:ff
> pbx ~ # brctl show
> bridge name bridge id STP enabled interfaces
> br1 8000.00026f5ad22b no ap0
> eth0
> pbx ~ #
> pbx ~ # hostapd -dddd -P /var/run/hostapd.pid /etc/hostapd.conf
> Configuration file: /etc/hostapd.conf
> Line 8: DEPRECATED: 'debug' configuration variable is not used anymore
> ctrl_interface_group=0
> Failed to set interface ap0 to master mode.
> nl80211 driver initialization failed.
> ap0: Unable to setup interface.
> ELOOP: remaining socket: sock=5 eloop_data=0x8098028 user_data=(nil) handler=0x806f503
> pbx ~ #
> pbx ~ # ldd /usr/bin/hostapd
> libnl.so.1 => /usr/lib/libnl.so.1 (0xb7f04000)
> libcrypto.so.0.9.8 => /lib/libcrypto.so.0.9.8 (0xb7df8000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7def000)
> libc.so.0 => /lib/libc.so.0 (0xb7da5000)
> libm.so.0 => /lib/libm.so.0 (0xb7d97000)
> libdl.so.0 => /lib/libdl.so.0 (0xb7d94000)
> ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0xb7f3d000)
> pbx ~ #
>
>
> And on the host that this was cross-compiled:
>
> [philipp@builder ~/kernel]$ cat build_i586/hostapd-0.6.9/hostapd/.config
> CFLAGS+=-Os -Wall -Os -pipe -fomit-frame-pointer -march=k6-2 -fno-align-functions -fno-align-loops -fno-align-jumps -fno-align-labels
> CFLAGS+= -DUSE_KERNEL_HEADERS -I/home/philipp/kernel/build_i586/linux-2.6.27.26-astlinux/include
> CONFIG_IEEE80211N=y
> CONFIG_DRIVER_NL80211=y
> CFLAGS+=-I/home/philipp/kernel/build_i586/staging_dir/usr/include
> LIBS+=-L/home/philipp/kernel/build_i586/root/usr/lib
> CONFIG_DRIVER_NONE=y
> CONFIG_DRIVER_WIRED=y
> CONFIG_IAPP=y
> CONFIG_RSN_PREAUTH=y
> CONFIG_PEERKEY=y
> CONFIG_EAP=y
> CONFIG_EAP_MD5=y
> CONFIG_EAP_MSCHAPV2=y
> CONFIG_EAP_GTC=y
> CONFIG_EAP_SIM=y
> CONFIG_EAP_AKA=y
> CONFIG_EAP_AKA_PRIME=y
> CONFIG_EAP_PAX=y
> CONFIG_EAP_PSK=y
> CONFIG_EAP_SAKE=y
> CONFIG_EAP_GPSK=y
> CONFIG_EAP_GPSK_SHA256=y
> CONFIG_EAP_IKEV2=y
> CONFIG_PKCS12=y
> CONFIG_IPV6=y
> CONFIG_IEEE80211R=y
> CONFIG_IEEE80211N=y
> [philipp@builder ~/kernel]$
>
>
>
> What am I missing?
>
> How should I go about debugging this?
>
> Thanks,
>
> -Philip
>
^ permalink raw reply
* Re: [PATCH] ath: add support for special 0x8000 regulatory domain
From: Joerg Albert @ 2009-07-19 12:35 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linville, linux-wireless, ath9k-devel, Stephen Chen, David Quan,
Tony Yang
In-Reply-To: <1247779124-29204-1-git-send-email-lrodriguez@atheros.com>
On 07/16/2009 11:18 PM, Luis R. Rodriguez wrote:
> Two users of ar9170 devices have now reported their cards
> have been programmed with a regulatory domain of 0x8000.
> This is not a valid regulatory domain as such these users were
> unable to use these devices. Since this doesn't seem to be
> a device EEPROM corruption we must treat it specially.
>
> We default these devices to the default Atheros 0x64 world
> regulatory domain.
> ...
> David, or Joerg, can you please test this patch.
Hi Luis,
this patch doesn't work, I still get:
ath: EEPROM regdomain: 0x8000
ath: EEPROM indicates we should expect a country code
ath: No regulatory domain pair found, cannot continue
ar9170usb: probe of 1-1:1.0 failed with error -22
I guess that's due to reg->current_rd == 0x8000, while CTRY_DEFAULT
== 0 in ath_regd_sanitize().
Applying
diff --git a/drivers/net/wireless/ath/regd.c
b/drivers/net/wireless/ath/regd.c
index 62aa270..eae9a58 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -483,7 +483,7 @@ ath_regd_init_wiphy(struct ath_regulatory *reg,
*/
static void ath_regd_sanitize(struct ath_regulatory *reg)
{
- if (reg->current_rd != CTRY_DEFAULT)
+ if (reg->current_rd != (CTRY_DEFAULT|COUNTRY_ERD_FLAG))
return;
printk(KERN_DEBUG "ath: EEPROM regdomain sanitized\n");
reg->current_rd = 0x64;
on top of your patch worked:
ath: EEPROM regdomain sanitized
ath: EEPROM regdomain: 0x64
ath: EEPROM indicates we should expect a direct regpair map
ath: Country alpha2 being used: 00
ath: Regpair used: 0x64
Why do we handle a regdomain of 0x8000 differently from a regdomain
of 0?
0x8000 leads to regdomain 0x64 in ath_regd_sanitize() while 0 is
mapped into country code CTRY_UNITED_STATES.
With the above patch I don't see channels 12,13,100-140 in "iwlist
wlan0 channel", which are allowed in DE, but I guess that's due to
using regdomain WOR4_WORLD (0x64).
Do calibration data in the EEPROM really depend on the regdomain,
i.e. do manufacturers calibrate only for a subset of channels due to
the regdomain the device will be programmed with?
BTW, I bought this device refurbished in an U.K. webshop.
^ permalink raw reply related
* iwmc3200wifi: using freed memory in iwm_hal_send_target_cmd()
From: Dan Carpenter @ 2009-07-19 11:53 UTC (permalink / raw)
To: yi.zhu; +Cc: linux-wireless
Hello,
I found this with a source code checker (http://repo.or.cz/w/smatch.git).
We free "cmd" on line 390 and then dereference it on line 396. I don't
know what we should return in that case or I would have sent a patch.
Sorry.
drivers/net/wireless/iwmc3200wifi/hal.c
390 if (!udma_cmd->resp)
391 kfree(cmd);
392
393 if (ret < 0)
394 return ret;
395
396 return cmd->seq_num;
regards,
dan carpenter
^ permalink raw reply
* [patch] wireless: potential null deref in p54spi.c
From: Dan Carpenter @ 2009-07-19 11:53 UTC (permalink / raw)
To: flamingice; +Cc: linux-wireless
We can't use dev_err() becuase "priv" is NULL.
Found by smatch (http://repo.or.cz/w/smatch.git).
regards,
dan carpenter
Signed-off-by: Dan Carpenter <error27@gmail.com>
--- orig/drivers/net/wireless/p54/p54spi.c 2009-07-17 16:04:20.000000000 +0300
+++ new/drivers/net/wireless/p54/p54spi.c 2009-07-17 16:05:28.000000000 +0300
@@ -635,7 +635,7 @@
hw = p54_init_common(sizeof(*priv));
if (!hw) {
- dev_err(&priv->spi->dev, "could not alloc ieee80211_hw");
+ printk(KERN_ERR "could not alloc ieee80211_hw");
return -ENOMEM;
}
^ permalink raw reply
* [PATCH] wl12xx: fix spelling
From: Stefan Weil @ 2009-07-19 13:00 UTC (permalink / raw)
To: Kalle Valo; +Cc: Stefan Weil, Kalle Valo, John W. Linville, Linux wireless
In-Reply-To: <87y6qmtssc.fsf@nokia.com>
Changes (comments and debug output):
* couldnt -> couldn't
* frmware -> firmware
* recevied -> received
Cc: Kalle Valo <kalle.valo@nokia.com>
Cc: John W. Linville <linville@tuxdriver.com>
Cc: Linux wireless <linux-wireless@vger.kernel.org>
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
---
drivers/net/wireless/wl12xx/wl1251_acx.c | 4 ++--
drivers/net/wireless/wl12xx/wl1251_ops.c | 4 ++--
drivers/net/wireless/wl12xx/wl1251_rx.h | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1251_acx.c b/drivers/net/wireless/wl12xx/wl1251_acx.c
index 5a8d21c..a46c92a 100644
--- a/drivers/net/wireless/wl12xx/wl1251_acx.c
+++ b/drivers/net/wireless/wl12xx/wl1251_acx.c
@@ -84,7 +84,7 @@ int wl1251_acx_default_key(struct wl1251 *wl, u8 key_id)
ret = wl1251_cmd_configure(wl, DOT11_DEFAULT_KEY,
default_key, sizeof(*default_key));
if (ret < 0) {
- wl1251_error("Couldnt set default key");
+ wl1251_error("Couldn't set default key");
goto out;
}
@@ -231,7 +231,7 @@ int wl1251_acx_feature_cfg(struct wl1251 *wl)
ret = wl1251_cmd_configure(wl, ACX_FEATURE_CFG,
feature, sizeof(*feature));
if (ret < 0) {
- wl1251_error("Couldnt set HW encryption");
+ wl1251_error("Couldn't set HW encryption");
goto out;
}
diff --git a/drivers/net/wireless/wl12xx/wl1251_ops.c b/drivers/net/wireless/wl12xx/wl1251_ops.c
index 96a45f5..e7b9aab 100644
--- a/drivers/net/wireless/wl12xx/wl1251_ops.c
+++ b/drivers/net/wireless/wl12xx/wl1251_ops.c
@@ -423,7 +423,7 @@ static void wl1251_irq_work(struct work_struct *work)
wl->rx_counter =
wl1251_mem_read32(wl, wl->data_path->rx_control_addr);
- /* We handle a frmware bug here */
+ /* We handle a firmware bug here */
switch ((wl->rx_counter - wl->rx_handled) & 0xf) {
case 0:
wl1251_debug(DEBUG_IRQ, "RX: FW and host in sync");
@@ -575,7 +575,7 @@ static int wl1251_hw_init_data_path_config(struct wl1251 *wl)
wl->data_path = kzalloc(sizeof(struct acx_data_path_params_resp),
GFP_KERNEL);
if (!wl->data_path) {
- wl1251_error("Couldnt allocate data path parameters");
+ wl1251_error("Couldn't allocate data path parameters");
return -ENOMEM;
}
diff --git a/drivers/net/wireless/wl12xx/wl1251_rx.h b/drivers/net/wireless/wl12xx/wl1251_rx.h
index 81156b9..563a3fd 100644
--- a/drivers/net/wireless/wl12xx/wl1251_rx.h
+++ b/drivers/net/wireless/wl12xx/wl1251_rx.h
@@ -88,7 +88,7 @@ struct wl1251_rx_descriptor {
u8 type;
/*
- * Recevied Rate:
+ * Received Rate:
* 0x0A - 1MBPS
* 0x14 - 2MBPS
* 0x37 - 5_5MBPS
--
1.5.6.5
^ permalink raw reply related
* Re: [RFC PATCH v2 0/8] wl1251 sdio interface
From: Luciano Coelho @ 2009-07-19 13:03 UTC (permalink / raw)
To: ext Kalle Valo; +Cc: Bob Copeland, linux-wireless@vger.kernel.org
In-Reply-To: <87r5wfp1v4.fsf@litku.valot.fi>
ext Kalle Valo wrote:
> Kalle Valo <kalle.valo@iki.fi> writes:
>
>
>> Here is v2 of Bob's wl1251 sdio patches. I have now rebased them on
>> top of wl1251/wl1271 split patches. Only compile-tested because I
>> don't have working test setup right now (neither spi or sdio), but I
>> should have access to one in two weeks.
>>
>
> I forgot to mention that wl1251 most probably is still broken regards to
> bssid handling. I will fix this after my (current) vacation, unless
> someone else is faster. To get wl1251 temporarily working, this patch
> must be reverted:
>
Wow! This is just what I needed to know. I have been struggling the
whole of last week trying to figure out why the wl1271 driver that I'm
planning to submit doesn't work with the latest wireless-testing. I've
been using the wl1251 from wireless-testing as a reference and I was
running out of ideas as to why wl1251 was working and my version of the
wl1271 wasn't. So, it's very good to know that wl1251 isn't working
either :)
This is the only thing that is currently preventing me from submitting
the wl1271 code. Obviously I want to make sure that it works before
sending it for inclusion in wireless-testing...
> commit cc3ec8cb518534c1c593e5f2682710d33c903627
> Author: Johannes Berg <johannes@sipsolutions.net>
> Date: Thu May 14 13:10:14 2009 +0200
>
> mac80211: fix managed mode BSSID handling
>
> Currently, we will ask the driver to configure right away
> when somebody changes the desired BSSID. That's totally
> strange because then we will configure the driver without
> even knowing whether the BSS exists. Change this to only
> configure the BSSID when associated, and configure a zero
> BSSID when not associated.
>
> Oddly enough I can't find this patch anymore in wireless-testing, I
> could only find a revert. I don't know what happened to it.
>
The original patch *is* there, but it has been reverted. In any case, I
noticed that the change introduced by this patch is there, so I guess
some other patch has replaced it later.
Now I need to read the archives of the linux-wireless mailing list to
figure out exactly what has changed and what I need to do to get wl1271
to work with the new API. Or is anyone willing to give me a brief
summary of what the driver is expected to do with the new API? (yeah,
it's a sunny Sunday and I'm a bit lazy today :P)
--
Cheers,
Luca.
^ permalink raw reply
* Re: Using compat-wireless w/ 2.6.27.26
From: Bob Copeland @ 2009-07-19 13:38 UTC (permalink / raw)
To: Philip A. Prindeville; +Cc: linux-wireless
In-Reply-To: <4A612514.4050708@redfish-solutions.com>
On Fri, Jul 17, 2009 at 9:27 PM, Philip A.
Prindeville<philipp_subx@redfish-solutions.com> wrote:
> + modprobe ath5k
> ath5k phy0: Atheros AR5413 chip found (MAC: 0xa4, PHY: 0x61)
>
> + iw dev wlan0 interface add ap0 type managed
> + ip link set ap0 up
> + iw dev ap0 connect xxxx
> command failed: Operation not supported (-95)
Why are you adding another interface? Should be able to use "iw dev wlan0..."
> pbx ~ # iw phy phy0 info
> command failed: No buffer space available (-105)
Means the netlink buffer was exceeded. In the past this was because there
were too many channels -- are you sure you're loading the compat-wireless
ath5k instead of the .29 one (and not using all_channels modparam)?
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Enabling and disabling Atheros AR9258 wireless card
From: Emiel Bruijntjes @ 2009-07-19 13:41 UTC (permalink / raw)
To: linux-wireless
Hi,
I hope this is the right channel to report a bug/feature-request.
My laptop (Toshiba NB200) uses a Atheros AR9285 wireless card. Wireless is
currently disabled, and the wireless LED is off. This is the default factory
setting. There is no way to enable the wireless module from Linux. On
Windows, the Fn/F8 key combination enables and disables the wireless module,
and turns on or off the LED. On Linux however, this isn't working.
The advice that I read on discussion forums on the web was to boot Windows,
turn on wireless, and then boot Linux again (see http://tjmcgrew.com/). It
is - as far as I know - not possible to use the Atheros AR9285 wireless card
on a Linux computer, without running Windows first to enable it. This is not
very good.
To sum up:
- From Linux it is not possible to enable/disable the Atheros AR9285
wireless card, and to turn on and off the wireless LED.
- This should be fixed as the wireless card is disabled by default, and it
is thus impossible to use it on a system without installing and running
Windows first.
Emiel Bruijntjes
^ permalink raw reply
* Re: WARN_ON at minstrel_get_rate (include/net/mac80211.h:2111) with p54usb
From: Larry Finger @ 2009-07-19 14:37 UTC (permalink / raw)
To: Christian Lamparter; +Cc: Bob Copeland, Johannes Berg, wireless
In-Reply-To: <200907190032.58156.chunkeey@web.de>
Christian Lamparter wrote:
> well, ieee80211_sta_monitor_work - which probes the AP every now and then -
> didn't check if we're scanning.
> The attached diff survives a non-stop scanning without throwing the WARN in
> rate_lowest_index once.
>
> However, I'm not so sure about the locking for hw_scanning and sw_scanning.
> It looks like only scan.c manipulates them under the scan mutex.
> But then, do we need locking for a single threaded workqueue? guess not.
> ---
> Larry,
>
> here's another _fix_ which might even fix the problem after all ;-)
>
> Regards,
> Chr
> ---
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 18dad22..4833e7c 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -2210,6 +2210,9 @@ static void ieee80211_sta_monitor_work(struct work_struct *work)
> container_of(work, struct ieee80211_sub_if_data,
> u.mgd.monitor_work);
>
> + if (sdata->local->sw_scanning || sdata->local->hw_scanning)
> + return;
> +
> ieee80211_mgd_probe_ap(sdata, false);
> }
Yes - this patch gets rid of the warnings.
Thanks,
Larry
^ permalink raw reply
* Re: [PATCH] handle broken V4 fw region code shift
From: Marek Vasut @ 2009-07-19 17:19 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Dan Williams, libertas-dev
In-Reply-To: <200907162229.41697.marek.vasut@gmail.com>
Dne Čt 16. července 2009 22:29:41 Marek Vasut napsal(a):
> Dne Čt 16. července 2009 22:11:26 Luis R. Rodriguez napsal(a):
> > On Thu, Jul 16, 2009 at 11:32 AM, Marek Vasut<marek.vasut@gmail.com>
wrote:
> > > Dne Čt 16. července 2009 20:21:30 Dan Williams napsal(a):
> > >> On Thu, 2009-07-16 at 19:40 +0200, Marek Vasut wrote:
> > >> > Hi,
> > >> >
> > >> > please consider applying/commenting on the following trivial fix.
> > >> > The description is in the patch. Thanks.
> > >>
> > >> Please CC to linux-wireless@vger.kernel and I'll ack there so Linville
> > >> will pick it up. Any patch that you consider appropriate for actual
> > >> inclusion at the time you send it is better on linux-wireless.
> > >> libertas-dev should really be only for hardware/firmware discussions
> > >> and not-yet-ready patches.
> > >>
> > >> Thanks!
> > >> Dan
> > >
> > > Done, thanks! :-)
> > > (sorry for sending it twice, I missed the address was incomplete in
> > > your mail)
> >
> > Please resend inline
> >
> > Luis
>
> Here you go
Any update ?
>
> From d69e6db9d424e40dade6bbf107dbab2ff4d692d5 Mon Sep 17 00:00:00 2001
> From: Marek Vasut <marek.vasut@gmail.com>
> Date: Thu, 16 Jul 2009 19:19:53 +0200
> Subject: [PATCH] Fix problem with broken V4 firmware on CF8381
>
> Firmware V4 on CF8381 reports region code shifted by 1 byte to left.
> The following patch checks for this and handles it properly.
>
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> ---
> drivers/net/wireless/libertas/cmd.c | 8 +++++++-
> drivers/net/wireless/libertas/defs.h | 2 ++
> 2 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/cmd.c
> b/drivers/net/wireless/libertas/cmd.c
> index 01db705..445288d 100644
> --- a/drivers/net/wireless/libertas/cmd.c
> +++ b/drivers/net/wireless/libertas/cmd.c
> @@ -135,8 +135,14 @@ int lbs_update_hw_spec(struct lbs_private *priv)
> /* Clamp region code to 8-bit since FW spec indicates that it
> should * only ever be 8-bit, even though the field size is 16-bit. Some
> firmware
> * returns non-zero high 8 bits here.
> + *
> + * Firmware version 4.0.102 used in CF8381 has region code shifted.
> We + * need to check for this problem and handle it properly.
> */
> - priv->regioncode = le16_to_cpu(cmd.regioncode) & 0xFF;
> + if (MRVL_FW_MAJOR_REV(priv->fwrelease) == MRVL_FW_V4)
> + priv->regioncode = (le16_to_cpu(cmd.regioncode) >> 8) &
> 0xFF; + else
> + priv->regioncode = le16_to_cpu(cmd.regioncode) & 0xFF;
>
> for (i = 0; i < MRVDRV_MAX_REGION_CODE; i++) {
> /* use the region code to search for the index */
> diff --git a/drivers/net/wireless/libertas/defs.h
> b/drivers/net/wireless/libertas/defs.h
> index 48da157..72f3479 100644
> --- a/drivers/net/wireless/libertas/defs.h
> +++ b/drivers/net/wireless/libertas/defs.h
> @@ -234,6 +234,8 @@ static inline void lbs_deb_hex(unsigned int grp, const
> char *prompt, u8 *buf, in
> /** Mesh enable bit in FW capability */
> #define MESH_CAPINFO_ENABLE_MASK (1<<16)
>
> +/** FW definition from Marvell v4 */
> +#define MRVL_FW_V4 (0x04)
> /** FW definition from Marvell v5 */
> #define MRVL_FW_V5 (0x05)
> /** FW definition from Marvell v10 */
> --
> 1.6.3.3
^ permalink raw reply
* Re: Using compat-wireless w/ 2.6.27.26
From: Philip A. Prindeville @ 2009-07-19 17:55 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless
In-Reply-To: <b6c5339f0907190638jc1bdacbo801adcd39a1cf5@mail.gmail.com>
Bob Copeland wrote:
> On Fri, Jul 17, 2009 at 9:27 PM, Philip A.
> Prindeville<philipp_subx@redfish-solutions.com> wrote:
>> + modprobe ath5k
>> ath5k phy0: Atheros AR5413 chip found (MAC: 0xa4, PHY: 0x61)
>>
>> + iw dev wlan0 interface add ap0 type managed
>> + ip link set ap0 up
>> + iw dev ap0 connect xxxx
>> command failed: Operation not supported (-95)
>
> Why are you adding another interface? Should be able to use "iw dev wlan0..."
Because I might want to run two access points (two SSIDs, anyway) on the same radio... one with WEP on one VLAN (for Wifi SIP handsets), and one with WPA-PSK2 on another VLAN (for laptops, etc).
>> pbx ~ # iw phy phy0 info
>> command failed: No buffer space available (-105)
>
> Means the netlink buffer was exceeded. In the past this was because there
> were too many channels -- are you sure you're loading the compat-wireless
> ath5k instead of the .29 one (and not using all_channels modparam)?
>
Reasonably sure, yes. I stopped the distro build and did an "ls -R" after building linux, and there were no drivers other than cfg80211.ko and mac80211.ko that get duplicated.
After resuming the rest of the build, there were drivers from compat-wireless including ath5k, and cfg80211.ko and mac80211.ko also had refreshed timestamps matching everything else.
But, if you think there's still a doubt, what to look for in the modinfo?
-Philip
^ 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