* Re: Merging SSB and HND/AI support
From: Michael Büsch @ 2011-01-17 12:00 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Jonas Gorski, linux-mips, linux-wireless, netdev
In-Reply-To: <201101171220.52292.florian@openwrt.org>
On Mon, 2011-01-17 at 12:20 +0100, Florian Fainelli wrote:
> On Monday 17 January 2011 11:56:23 Michael Büsch wrote:
> > On Mon, 2011-01-17 at 11:46 +0100, Jonas Gorski wrote:
> > > Hello,
> > >
> > > I am currently looking into adding support for the newer Broadcom
> > > BCM47xx/53xx SoCs. They require having HND/AI support, which probably
> > > means merging the current SSB code and the HND/AI code from the
> > > brcm80211 driver. Is anyone already working on this?
> > >
> > > As far as I can see, there are two possibilities:
> > >
> > > a) Merge the HND/AI code into the current SSB code, or
> > >
> > > b) add the missing code for SoCs to brcm80211 and replace the SSB code
> > > with it.
> >
> > Why can't we keep those two platforms separated?
>
> That is also what I am wondering about. Considering that previous BCM47xx
> platforms use a MIPS4k core and newer one use MIPS74k or later, you would not
> be able to build a single kernel for both which takes advantages of compile-
> time optimizations targetting MIPS74k. If this ist not a big concern, then
> let's target a single kernel.
Ok, but it should be easily possible to compile both SSB and HND/AI
bus support into one kernel anyway. Nothing prevents drivers from having
an SSB and an HND/AI probe callback.
--
Greetings Michael.
^ permalink raw reply
* Re: Merging SSB and HND/AI support
From: Michael Büsch @ 2011-01-17 11:57 UTC (permalink / raw)
To: Jonas Gorski; +Cc: linux-mips, linux-wireless, netdev
In-Reply-To: <AANLkTikJcug7LUTgX_YDD4Z8ZBrdkAdLq8_Epa6TkA5f@mail.gmail.com>
On Mon, 2011-01-17 at 12:21 +0100, Jonas Gorski wrote:
> On 17 January 2011 11:56, Michael Büsch <mb@bu3sch.de> wrote:
> > On Mon, 2011-01-17 at 11:46 +0100, Jonas Gorski wrote:
> >> a) Merge the HND/AI code into the current SSB code, or
> >>
> >> b) add the missing code for SoCs to brcm80211 and replace the SSB code with it.
> >
> > Why can't we keep those two platforms separated?
> > Is there really a lot of shared code between SSB and HND/AI?
>
> Yes, as far as I understand the AI bus behaves mostly like a SSB bus
> except for places like enabling/disabling cores. E.g. the AI bus also
> has a common core, which has a bit for telling whether its a SSB or AI
> bus, and has the mostly the same registers as the SSB common cores (so
> most driver_chipcommon_* stuff also applies for the AI bus).
Well... I don't really like the idea of running one driver and
subsystem implementation on completely distinct types of silicon.
We will end up with the same mess that broadcom ended up with in
their "SB" code (broadcom's SSB backplane implementation).
For example, in their code the driver calls pci_enable_device() and
related PCI functions, even if there is no PCI device at all. The calls
are magically re-routed to the actual SB backplane.
You'd have to do the same mess with SSB. Calling ssb_device_enable()
will mean "enable the SSB device", if the backplane is SSB, and will
mean "enable the HND/AI" device, if the backplane is HND/AI.
So I'm still in favor of doing a separate HND/AI bus implementation,
even if
that means duplicating a few lines of code. I think that compared to the
workarounds and conditionals needed for getting SSB to run on HND/AI
hardware, it will be a net win.
> > So why do we need to replace or merge SSB in the first place? Can't
> > it co-exist with HND/AI?
>
> It probably can, but then the SSB code must be at least made AI aware
> so it doesn't try to attach itself if it finds one.
SSB doesn't search for SSB busses in the system, because there's no
way to do so. The architecture (or the PCI/PCMCIA/SDIO device) registers
the bus,
if it detected an SSB device. So for the embedded case, it's hardcoded
in the arch code. For the PCI case it simply depends on the PCI IDs.
I don't see a problem here. Your arch code will already have to know
what machine it is running on. So it will have to decide whether to
register a SSB or HND/AI bus.
It's like a platform_device. However, it doesn't use the platform_device
mechanism. There's no technical reason. It would be trivial to port the
SSB bus registration to use platform_device, however.
> Also I don't know
> if it is a good idea to let arch-specific code depend on code in
> staging.
Sure. The code needs to be cleaned up and moved to the mainline kernel
_anyway_. You don't get around this.
--
Greetings Michael.
^ permalink raw reply
* [PATCH] wl12xx: Increase scan channel dwell time for passive scans
From: juuso.oikarinen @ 2011-01-17 11:32 UTC (permalink / raw)
To: coelho; +Cc: linux-wireless
From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
The passive scan channel dwell time currently used is 30ms-60ms. A typical
beacon interval for AP's is 100ms. This leads to a ~30% worst-case probability
of finding an AP via passive scanning.
For 5GHz bands for DFS frequencies passive scanning is the only scanning
option. Hence for these, the probability of finding an AP is very low.
To fix this, increase the passive channel scan dwell times (also the early
leave value, as 5GHz channels are still typically very silent.) Use a value
of 100ms, because that covers most typical AP configurations.
Based on testing the probability of finding an AP (102.4ms beacon interval) on
a single scan round are as follows (based on 100 iterations):
dwell min/max (ms) | probability
---------------------+------------
30/60 | 35%
60/60 | 56%
80/80 | 77%
100/100 | 100%
Total scan times now and after the change:
Region | Before (s) | After (s)
-------+------------+----------
00 | 0.77 | 1.48
FI | 0.95 | 2.01
US | 0.91 | 1.76
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
drivers/net/wireless/wl12xx/conf.h | 16 ++++++++--------
drivers/net/wireless/wl12xx/main.c | 4 ++--
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/conf.h b/drivers/net/wireless/wl12xx/conf.h
index f5c048c..21b72a5 100644
--- a/drivers/net/wireless/wl12xx/conf.h
+++ b/drivers/net/wireless/wl12xx/conf.h
@@ -1084,30 +1084,30 @@ struct conf_scan_settings {
/*
* The minimum time to wait on each channel for active scans
*
- * Range: 0 - 65536 tu
+ * Range: u32 tu/1000
*/
- u16 min_dwell_time_active;
+ u32 min_dwell_time_active;
/*
* The maximum time to wait on each channel for active scans
*
- * Range: 0 - 65536 tu
+ * Range: u32 tu/1000
*/
- u16 max_dwell_time_active;
+ u32 max_dwell_time_active;
/*
* The maximum time to wait on each channel for passive scans
*
- * Range: 0 - 65536 tu
+ * Range: u32 tu/1000
*/
- u16 min_dwell_time_passive;
+ u32 min_dwell_time_passive;
/*
* The maximum time to wait on each channel for passive scans
*
- * Range: 0 - 65536 tu
+ * Range: u32 tu/1000
*/
- u16 max_dwell_time_passive;
+ u32 max_dwell_time_passive;
/*
* Number of probe requests to transmit on each active scan channel
diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
index 863e660..c1814f2 100644
--- a/drivers/net/wireless/wl12xx/main.c
+++ b/drivers/net/wireless/wl12xx/main.c
@@ -279,8 +279,8 @@ static struct conf_drv_settings default_conf = {
.scan = {
.min_dwell_time_active = 7500,
.max_dwell_time_active = 30000,
- .min_dwell_time_passive = 30000,
- .max_dwell_time_passive = 60000,
+ .min_dwell_time_passive = 100000,
+ .max_dwell_time_passive = 100000,
.num_probe_reqs = 2,
},
.rf = {
--
1.7.1
^ permalink raw reply related
* Re: Merging SSB and HND/AI support
From: Jonas Gorski @ 2011-01-17 11:21 UTC (permalink / raw)
To: Michael Büsch; +Cc: linux-mips, linux-wireless, netdev
In-Reply-To: <1295261783.24530.3.camel@maggie>
On 17 January 2011 11:56, Michael Büsch <mb@bu3sch.de> wrote:
> On Mon, 2011-01-17 at 11:46 +0100, Jonas Gorski wrote:
>> a) Merge the HND/AI code into the current SSB code, or
>>
>> b) add the missing code for SoCs to brcm80211 and replace the SSB code with it.
>
> Why can't we keep those two platforms separated?
> Is there really a lot of shared code between SSB and HND/AI?
Yes, as far as I understand the AI bus behaves mostly like a SSB bus
except for places like enabling/disabling cores. E.g. the AI bus also
has a common core, which has a bit for telling whether its a SSB or AI
bus, and has the mostly the same registers as the SSB common cores (so
most driver_chipcommon_* stuff also applies for the AI bus).
> It's true that there's currently a lot of device functionality built
> into ssb. Like pci bridge, mips core, extif, etc...
> If you take all that code out, you're probably not left with anything.
That's because most shared code isn't in brcm80211, but only found in
the SDKs for the SoCs.
> So why do we need to replace or merge SSB in the first place? Can't
> it co-exist with HND/AI?
It probably can, but then the SSB code must be at least made AI aware
so it doesn't try to attach itself if it finds one. Also I don't know
if it is a good idea to let arch-specific code depend on code in
staging.
Jonas
^ permalink raw reply
* Re: Merging SSB and HND/AI support
From: Florian Fainelli @ 2011-01-17 11:20 UTC (permalink / raw)
To: Michael Büsch; +Cc: Jonas Gorski, linux-mips, linux-wireless, netdev
In-Reply-To: <1295261783.24530.3.camel@maggie>
On Monday 17 January 2011 11:56:23 Michael Büsch wrote:
> On Mon, 2011-01-17 at 11:46 +0100, Jonas Gorski wrote:
> > Hello,
> >
> > I am currently looking into adding support for the newer Broadcom
> > BCM47xx/53xx SoCs. They require having HND/AI support, which probably
> > means merging the current SSB code and the HND/AI code from the
> > brcm80211 driver. Is anyone already working on this?
> >
> > As far as I can see, there are two possibilities:
> >
> > a) Merge the HND/AI code into the current SSB code, or
> >
> > b) add the missing code for SoCs to brcm80211 and replace the SSB code
> > with it.
>
> Why can't we keep those two platforms separated?
That is also what I am wondering about. Considering that previous BCM47xx
platforms use a MIPS4k core and newer one use MIPS74k or later, you would not
be able to build a single kernel for both which takes advantages of compile-
time optimizations targetting MIPS74k. If this ist not a big concern, then
let's target a single kernel.
> Is there really a lot of shared code between SSB and HND/AI?
>
> It's true that there's currently a lot of device functionality built
> into ssb. Like pci bridge, mips core, extif, etc...
> If you take all that code out, you're probably not left with anything.
>
> So why do we need to replace or merge SSB in the first place? Can't
> it co-exist with HND/AI?
^ permalink raw reply
* Re: Merging SSB and HND/AI support
From: Michael Büsch @ 2011-01-17 11:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: Jonas Gorski, linux-mips, linux-wireless, netdev
In-Reply-To: <1295262781.3726.6.camel@jlt3.sipsolutions.net>
On Mon, 2011-01-17 at 12:13 +0100, Johannes Berg wrote:
> On Mon, 2011-01-17 at 11:56 +0100, Michael Büsch wrote:
>
> > > As far as I can see, there are two possibilities:
> > >
> > > a) Merge the HND/AI code into the current SSB code, or
> > >
> > > b) add the missing code for SoCs to brcm80211 and replace the SSB code with it.
> >
> > Why can't we keep those two platforms separated?
> > Is there really a lot of shared code between SSB and HND/AI?
>
> I don't think there's a lot of shared code, but I believe that you need
> b43 to be able to target cores on both? And b43 currently uses the SSB
> APIs only.
Yeah right. That's what I was thinking about, too. Just leave SSB alone
and add bus glues to b43 for HND/AI. There's almost no SSB specific code
in b43. So it should be easily possible to add another probe entry from
the (to be written or derived from brcm80211) HND/AI subsystem.
--
Greetings Michael.
^ permalink raw reply
* Re: Merging SSB and HND/AI support
From: Johannes Berg @ 2011-01-17 11:13 UTC (permalink / raw)
To: Michael Büsch; +Cc: Jonas Gorski, linux-mips, linux-wireless, netdev
In-Reply-To: <1295261783.24530.3.camel@maggie>
On Mon, 2011-01-17 at 11:56 +0100, Michael Büsch wrote:
> > As far as I can see, there are two possibilities:
> >
> > a) Merge the HND/AI code into the current SSB code, or
> >
> > b) add the missing code for SoCs to brcm80211 and replace the SSB code with it.
>
> Why can't we keep those two platforms separated?
> Is there really a lot of shared code between SSB and HND/AI?
I don't think there's a lot of shared code, but I believe that you need
b43 to be able to target cores on both? And b43 currently uses the SSB
APIs only.
johannes
^ permalink raw reply
* Re: Merging SSB and HND/AI support
From: Michael Büsch @ 2011-01-17 10:56 UTC (permalink / raw)
To: Jonas Gorski; +Cc: linux-mips, linux-wireless, netdev
In-Reply-To: <AANLkTi=GDcy50zsC6=Dgv1-Ty3cYK2qpx9o=q3JdXuCh@mail.gmail.com>
On Mon, 2011-01-17 at 11:46 +0100, Jonas Gorski wrote:
> Hello,
>
> I am currently looking into adding support for the newer Broadcom
> BCM47xx/53xx SoCs. They require having HND/AI support, which probably
> means merging the current SSB code and the HND/AI code from the
> brcm80211 driver. Is anyone already working on this?
>
> As far as I can see, there are two possibilities:
>
> a) Merge the HND/AI code into the current SSB code, or
>
> b) add the missing code for SoCs to brcm80211 and replace the SSB code with it.
Why can't we keep those two platforms separated?
Is there really a lot of shared code between SSB and HND/AI?
It's true that there's currently a lot of device functionality built
into ssb. Like pci bridge, mips core, extif, etc...
If you take all that code out, you're probably not left with anything.
So why do we need to replace or merge SSB in the first place? Can't
it co-exist with HND/AI?
--
Greetings Michael.
^ permalink raw reply
* Merging SSB and HND/AI support
From: Jonas Gorski @ 2011-01-17 10:46 UTC (permalink / raw)
To: Michael Buesch, linux-mips, linux-wireless, netdev
Hello,
I am currently looking into adding support for the newer Broadcom
BCM47xx/53xx SoCs. They require having HND/AI support, which probably
means merging the current SSB code and the HND/AI code from the
brcm80211 driver. Is anyone already working on this?
As far as I can see, there are two possibilities:
a) Merge the HND/AI code into the current SSB code, or
b) add the missing code for SoCs to brcm80211 and replace the SSB code with it.
The former is probably the less intrusive one, but requires a bit of
ssb-named-but-actually-not-ssb code unless one renames several
functions and structs.
The latter has the advantage of having a certain bus abstraction
already built-in, but would require adapting the b43 code to it. It
also looks like it doesn't support (very) old SoCs.
Regards,
Jonas
P.S: The Maintainers file says SSB's list is netdev, but I would have
expected it to be linux-wireless. Is this still correct?
^ permalink raw reply
* [PATCH] ath9k_hw: do PA offset calibration only on longcal interval
From: Rajkumar Manoharan @ 2011-01-17 9:51 UTC (permalink / raw)
To: linux-wireless; +Cc: Rajkumar Manoharan, stable, Vasanthakumar Thiagarajan
The power detector adc offset calibration has to be done
on 4 minutes interval (longcal * pa_skip_count). But the commit
"ath9k_hw: fix a noise floor calibration related race condition"
makes the PA calibration executed more frequently beased on
nfcal_pending value. Running PAOffset calibration lesser than
longcal interval doesn't help anything and the worse part is that
it causes NF load timeouts and RX deaf conditions.
In a very noisy environment, where the distance b/w AP & station
is ~10 meter and running a downlink udp traffic with frequent
background scan causes "Timeout while waiting for nf to load:
AR_PHY_AGC_CONTROL=0x40d1a" and moves the chip into deaf state.
This issue was originaly reported in Android platform where
the network-manager application does bgscan more frequently
on AR9271 chips. (AR9285 family usb device).
Cc: stable@kernel.org
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/ar9002_calib.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_calib.c b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
index 14d7d2a..76388c6 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
@@ -679,10 +679,6 @@ static bool ar9002_hw_calibrate(struct ath_hw *ah,
/* Do NF cal only at longer intervals */
if (longcal || nfcal_pending) {
- /* Do periodic PAOffset Cal */
- ar9002_hw_pa_cal(ah, false);
- ar9002_hw_olc_temp_compensation(ah);
-
/*
* Get the value from the previous NF cal and update
* history buffer.
@@ -697,8 +693,12 @@ static bool ar9002_hw_calibrate(struct ath_hw *ah,
ath9k_hw_loadnf(ah, ah->curchan);
}
- if (longcal)
+ if (longcal) {
ath9k_hw_start_nfcal(ah, false);
+ /* Do periodic PAOffset Cal */
+ ar9002_hw_pa_cal(ah, false);
+ ar9002_hw_olc_temp_compensation(ah);
+ }
}
return iscaldone;
--
1.7.3.5
^ permalink raw reply related
* Re: Fwd: [PATCH 06/10] mac80211: add HW flag for disabling auto link-PS in AP mode
From: Johannes Berg @ 2011-01-17 9:35 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless, Luciano Coelho
In-Reply-To: <AANLkTi=FRAjCxOBAtXFdzwSqG6DQ+oneoe-THQjsd_Wx@mail.gmail.com>
On Sun, 2011-01-16 at 23:53 +0200, Arik Nemtsov wrote:
> > Also, I'm worried about races between this and RX. All of the RX path
> > assumes that it is running at the same time. The ap_sta_ps_{start,end}
> > functions won't be called from the RX path when the flag is set, and
> > this is dependent on setting the flag, but is there really nothing in
> > them that could race?
>
> They might race if the user is not careful. On a SMP machine a user
> can call ieee80211_rx() and ap_sta_ps_start() from two different
> workqueues for example.
> I can add an explicit mutex, but a documentation warning will suffice here no?
Well, a mutex won't be possible, and we don't do "code path locking"
anyway. I'd appreciate if you could actually see which things would
potentially race -- I took a brief look into these functions and it
didn't look like there are actually races except of these two against
each other maybe?
> > Finally, I'm worried about this calling back into the driver's
> > sta_notify callback. If that is to remain that way, it needs to be
> > *very* clearly documented, I'd *much* prefer it not doing that but
> > handing off to a work struct or so internally.
> >
>
> sta_notify is pretty useless when the low level driver calls toggles
> the PS-mode by itself. How about I simply remove the call to
> sta_notify in case IEEE80211_HW_AP_LINK_PS is set?
> If a low level driver needs to do some deferred processing after a
> PS-mode transition, it can queue a work on its own..
Yes, that's probably a good idea -- but definitely needs to be
documented in the sta_notify docs. OTOH, mac80211 de-bounces sta_notify
in a way. Maybe that needs to be done for the function call as well,
maybe via a return value?
johannes
^ permalink raw reply
* [PATCH] wl12xx: add missing MODULE_FIRMWARE statment for AP-mode FW
From: Arik Nemtsov @ 2011-01-17 9:16 UTC (permalink / raw)
To: linux-wireless; +Cc: Luciano Coelho, Arik Nemtsov
In wl12xx cards AP-mode requires a separate FW file. Add this file to
the module info.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
---
drivers/net/wireless/wl12xx/sdio.c | 1 +
drivers/net/wireless/wl12xx/spi.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/sdio.c b/drivers/net/wireless/wl12xx/sdio.c
index 93cbb8d..d5e8748 100644
--- a/drivers/net/wireless/wl12xx/sdio.c
+++ b/drivers/net/wireless/wl12xx/sdio.c
@@ -345,3 +345,4 @@ MODULE_LICENSE("GPL");
MODULE_AUTHOR("Luciano Coelho <luciano.coelho@nokia.com>");
MODULE_AUTHOR("Juuso Oikarinen <juuso.oikarinen@nokia.com>");
MODULE_FIRMWARE(WL1271_FW_NAME);
+MODULE_FIRMWARE(WL1271_AP_FW_NAME);
diff --git a/drivers/net/wireless/wl12xx/spi.c b/drivers/net/wireless/wl12xx/spi.c
index 8f7ea2c..0132dad 100644
--- a/drivers/net/wireless/wl12xx/spi.c
+++ b/drivers/net/wireless/wl12xx/spi.c
@@ -495,4 +495,5 @@ MODULE_LICENSE("GPL");
MODULE_AUTHOR("Luciano Coelho <luciano.coelho@nokia.com>");
MODULE_AUTHOR("Juuso Oikarinen <juuso.oikarinen@nokia.com>");
MODULE_FIRMWARE(WL1271_FW_NAME);
+MODULE_FIRMWARE(WL1271_AP_FW_NAME);
MODULE_ALIAS("spi:wl1271");
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] wl12xx: Cleanup PLT mode when module is removed
From: Juuso Oikarinen @ 2011-01-17 6:26 UTC (permalink / raw)
To: ext Luciano Coelho; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1295244269.18570.106.camel@wimaxnb.nmp.nokia.com>
On Mon, 2011-01-17 at 08:04 +0200, ext Juuso Oikarinen wrote:
> On Fri, 2011-01-14 at 15:16 +0200, ext Luciano Coelho wrote:
> > Hi Juuso,
> >
> > On Fri, 2011-01-14 at 12:48 +0100, juuso.oikarinen@nokia.com wrote:
> > > diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
> > > index 9076555..863e660 100644
> > > --- a/drivers/net/wireless/wl12xx/main.c
> > > +++ b/drivers/net/wireless/wl12xx/main.c
> > > @@ -917,12 +917,10 @@ out:
> > > return ret;
> > > }
> >
> > Again we have this kind of unlock-lock case. Wouldn't it be better to
> > move the cancel_work calls outside this function and call them after
> > __wl1271_plt_stop() has returned? Yeah, there will be duplicate code if
> > we do this, but I think it's a bit safer, isn't it?
> >
>
> Heh, I did consider this too. But I did come to the conclusion that in
> this case it is safer to unlock/lock than to duplicate the code -
> duplicating this type of code has its risks too, and in this case
> nothing is actually performed after the last mutex-lock - except for
> unlocking in again.
>
> I'll change this to benefit both PoVs: I'll create a separate function
> to cancel the works, and just call that function from two places. That
> way, the to-be cancelled work items are in a single place.
>
And then I realise we can't easily do that. In the typical case (user
space stops plt mode) there is no work after the last mutex lock, but in
this module-removal scenario there is.
To solve that, we'd have to extend the knowledge about the plt mode onto
the bus specific modules (sdio/spi) because they call the wl12xx
unregister_hw function with the mutex already held.
So in essence, I would like to keep the current patch :o
-Juuso
^ permalink raw reply
* Re: [PATCH] wl12xx: Cleanup PLT mode when module is removed
From: Juuso Oikarinen @ 2011-01-17 6:04 UTC (permalink / raw)
To: ext Luciano Coelho; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1295011013.1960.269.camel@pimenta>
On Fri, 2011-01-14 at 15:16 +0200, ext Luciano Coelho wrote:
> Hi Juuso,
>
> On Fri, 2011-01-14 at 12:48 +0100, juuso.oikarinen@nokia.com wrote:
> > diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
> > index 9076555..863e660 100644
> > --- a/drivers/net/wireless/wl12xx/main.c
> > +++ b/drivers/net/wireless/wl12xx/main.c
> > @@ -917,12 +917,10 @@ out:
> > return ret;
> > }
> >
> > -int wl1271_plt_stop(struct wl1271 *wl)
> > +int __wl1271_plt_stop(struct wl1271 *wl)
> > {
> > int ret = 0;
> >
> > - mutex_lock(&wl->mutex);
> > -
> > wl1271_notice("power down");
> >
> > if (wl->state != WL1271_STATE_PLT) {
> > @@ -938,12 +936,21 @@ int wl1271_plt_stop(struct wl1271 *wl)
> > wl->state = WL1271_STATE_OFF;
> > wl->rx_counter = 0;
> >
> > -out:
> > mutex_unlock(&wl->mutex);
> > -
> > cancel_work_sync(&wl->irq_work);
> > cancel_work_sync(&wl->recovery_work);
> > + mutex_lock(&wl->mutex);
> > +out:
> > + return ret;
> > +}
>
> Again we have this kind of unlock-lock case. Wouldn't it be better to
> move the cancel_work calls outside this function and call them after
> __wl1271_plt_stop() has returned? Yeah, there will be duplicate code if
> we do this, but I think it's a bit safer, isn't it?
>
Heh, I did consider this too. But I did come to the conclusion that in
this case it is safer to unlock/lock than to duplicate the code -
duplicating this type of code has its risks too, and in this case
nothing is actually performed after the last mutex-lock - except for
unlocking in again.
I'll change this to benefit both PoVs: I'll create a separate function
to cancel the works, and just call that function from two places. That
way, the to-be cancelled work items are in a single place.
-Juuso
^ permalink raw reply
* [PATCH 2] cfg80211: Extend channel to frequency mapping for 802.11j
From: Bruno Randolf @ 2011-01-17 4:37 UTC (permalink / raw)
To: johannes, linville
Cc: gwingerde, libertas-dev, dcbw, IvDoorn, linux-wireless, users,
bprodoehl
Extend channel to frequency mapping for 802.11j Japan 4.9GHz band, according to
IEEE802.11 section 17.3.8.3.2 and Annex J. Because there are now overlapping
channel numbers in the 2GHz and 5GHz band we can't map from channel to
frequency without knowing the band. This is no problem as in most contexts we
know the band. In places where we don't know the band (and WEXT compatibility)
we assume the 2GHz band for channels below 14.
This patch does not implement all channel to frequency mappings defined in
802.11, it's just an extension for 802.11j 20MHz channels. 5MHz and 10MHz
channels as well as 802.11y channels have been omitted.
The following drivers have been updated to reflect the API changes:
iwl-3945, iwl-agn, iwmc3200wifi, libertas, mwl8k, rt2x00, wl1251, wl12xx.
The drivers have been compile-tested only.
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
v2: Added necessary driver changes first posted by Brian Prodoehl.
Brian, do you want to add your Signed-off-by?
---
drivers/net/wireless/iwlwifi/iwl-3945.c | 5 ++--
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 5 ++--
drivers/net/wireless/iwlwifi/iwl-core.c | 3 +-
drivers/net/wireless/iwmc3200wifi/cfg80211.c | 3 +-
drivers/net/wireless/iwmc3200wifi/rx.c | 7 ++++-
drivers/net/wireless/libertas/cfg.c | 6 +++-
drivers/net/wireless/mwl8k.c | 6 +++-
drivers/net/wireless/rt2x00/rt2x00dev.c | 5 +++-
drivers/net/wireless/wl1251/rx.c | 3 +-
drivers/net/wireless/wl12xx/rx.c | 2 +
include/net/cfg80211.h | 3 +-
net/mac80211/ibss.c | 3 +-
net/mac80211/mesh.c | 2 +
net/mac80211/mlme.c | 8 ++++--
net/mac80211/scan.c | 3 +-
net/wireless/reg.c | 6 ++--
net/wireless/util.c | 36 ++++++++++++++++----------
net/wireless/wext-compat.c | 5 +++-
18 files changed, 71 insertions(+), 40 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-3945.c b/drivers/net/wireless/iwlwifi/iwl-3945.c
index a9b852b..1d9dcd7 100644
--- a/drivers/net/wireless/iwlwifi/iwl-3945.c
+++ b/drivers/net/wireless/iwlwifi/iwl-3945.c
@@ -594,10 +594,11 @@ static void iwl3945_rx_reply_rx(struct iwl_priv *priv,
rx_status.flag = 0;
rx_status.mactime = le64_to_cpu(rx_end->timestamp);
- rx_status.freq =
- ieee80211_channel_to_frequency(le16_to_cpu(rx_hdr->channel));
rx_status.band = (rx_hdr->phy_flags & RX_RES_PHY_FLAGS_BAND_24_MSK) ?
IEEE80211_BAND_2GHZ : IEEE80211_BAND_5GHZ;
+ rx_status.freq =
+ ieee80211_channel_to_frequency(le16_to_cpu(rx_hdr->channel),
+ rx_status.band);
rx_status.rate_idx = iwl3945_hwrate_to_plcp_idx(rx_hdr->rate);
if (rx_status.band == IEEE80211_BAND_5GHZ)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
index 3dee87e..a800318 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
@@ -1157,10 +1157,11 @@ void iwlagn_rx_reply_rx(struct iwl_priv *priv,
/* rx_status carries information about the packet to mac80211 */
rx_status.mactime = le64_to_cpu(phy_res->timestamp);
- rx_status.freq =
- ieee80211_channel_to_frequency(le16_to_cpu(phy_res->channel));
rx_status.band = (phy_res->phy_flags & RX_RES_PHY_FLAGS_BAND_24_MSK) ?
IEEE80211_BAND_2GHZ : IEEE80211_BAND_5GHZ;
+ rx_status.freq =
+ ieee80211_channel_to_frequency(le16_to_cpu(phy_res->channel),
+ rx_status.band);
rx_status.rate_idx =
iwlagn_hwrate_to_mac80211_idx(rate_n_flags, rx_status.band);
rx_status.flag = 0;
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index efbde1f..a8d4a93 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -227,7 +227,8 @@ int iwlcore_init_geos(struct iwl_priv *priv)
geo_ch = &sband->channels[sband->n_channels++];
geo_ch->center_freq =
- ieee80211_channel_to_frequency(ch->channel);
+ ieee80211_channel_to_frequency(ch->channel,
+ sband->band);
geo_ch->max_power = ch->max_power_avg;
geo_ch->max_antenna_gain = 0xff;
geo_ch->hw_value = ch->channel;
diff --git a/drivers/net/wireless/iwmc3200wifi/cfg80211.c b/drivers/net/wireless/iwmc3200wifi/cfg80211.c
index 5a49822..ed57e44 100644
--- a/drivers/net/wireless/iwmc3200wifi/cfg80211.c
+++ b/drivers/net/wireless/iwmc3200wifi/cfg80211.c
@@ -287,7 +287,8 @@ int iwm_cfg80211_inform_bss(struct iwm_priv *iwm)
return -EINVAL;
}
- freq = ieee80211_channel_to_frequency(umac_bss->channel);
+ freq = ieee80211_channel_to_frequency(umac_bss->channel,
+ band->band);
channel = ieee80211_get_channel(wiphy, freq);
signal = umac_bss->rssi * 100;
diff --git a/drivers/net/wireless/iwmc3200wifi/rx.c b/drivers/net/wireless/iwmc3200wifi/rx.c
index a944893..9a57cf6 100644
--- a/drivers/net/wireless/iwmc3200wifi/rx.c
+++ b/drivers/net/wireless/iwmc3200wifi/rx.c
@@ -543,7 +543,10 @@ static int iwm_mlme_assoc_complete(struct iwm_priv *iwm, u8 *buf,
switch (le32_to_cpu(complete->status)) {
case UMAC_ASSOC_COMPLETE_SUCCESS:
chan = ieee80211_get_channel(wiphy,
- ieee80211_channel_to_frequency(complete->channel));
+ ieee80211_channel_to_frequency(complete->channel,
+ complete->band == UMAC_BAND_2GHZ ?
+ IEEE80211_BAND_2GHZ :
+ IEEE80211_BAND_5GHZ));
if (!chan || chan->flags & IEEE80211_CHAN_DISABLED) {
/* Associated to a unallowed channel, disassociate. */
__iwm_invalidate_mlme_profile(iwm);
@@ -841,7 +844,7 @@ static int iwm_mlme_update_bss_table(struct iwm_priv *iwm, u8 *buf,
goto err;
}
- freq = ieee80211_channel_to_frequency(umac_bss->channel);
+ freq = ieee80211_channel_to_frequency(umac_bss->channel, band->band);
channel = ieee80211_get_channel(wiphy, freq);
signal = umac_bss->rssi * 100;
diff --git a/drivers/net/wireless/libertas/cfg.c b/drivers/net/wireless/libertas/cfg.c
index 698a1f7..30ef035 100644
--- a/drivers/net/wireless/libertas/cfg.c
+++ b/drivers/net/wireless/libertas/cfg.c
@@ -607,7 +607,8 @@ static int lbs_ret_scan(struct lbs_private *priv, unsigned long dummy,
/* No channel, no luck */
if (chan_no != -1) {
struct wiphy *wiphy = priv->wdev->wiphy;
- int freq = ieee80211_channel_to_frequency(chan_no);
+ int freq = ieee80211_channel_to_frequency(chan_no,
+ IEEE80211_BAND_2GHZ);
struct ieee80211_channel *channel =
ieee80211_get_channel(wiphy, freq);
@@ -1597,7 +1598,8 @@ static int lbs_get_survey(struct wiphy *wiphy, struct net_device *dev,
lbs_deb_enter(LBS_DEB_CFG80211);
survey->channel = ieee80211_get_channel(wiphy,
- ieee80211_channel_to_frequency(priv->channel));
+ ieee80211_channel_to_frequency(priv->channel,
+ IEEE80211_BAND_2GHZ));
ret = lbs_get_rssi(priv, &signal, &noise);
if (ret == 0) {
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index 809f2bf..b62f7ef 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -906,7 +906,8 @@ mwl8k_rxd_8366_ap_process(void *_rxd, struct ieee80211_rx_status *status,
} else {
status->band = IEEE80211_BAND_2GHZ;
}
- status->freq = ieee80211_channel_to_frequency(rxd->channel);
+ status->freq = ieee80211_channel_to_frequency(rxd->channel,
+ status->band);
*qos = rxd->qos_control;
@@ -1013,7 +1014,8 @@ mwl8k_rxd_sta_process(void *_rxd, struct ieee80211_rx_status *status,
} else {
status->band = IEEE80211_BAND_2GHZ;
}
- status->freq = ieee80211_channel_to_frequency(rxd->channel);
+ status->freq = ieee80211_channel_to_frequency(rxd->channel,
+ status->band);
*qos = rxd->qos_control;
if ((rxd->rx_ctrl & MWL8K_STA_RX_CTRL_DECRYPT_ERROR) &&
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c b/drivers/net/wireless/rt2x00/rt2x00dev.c
index 9597a03..31b7db0 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -649,7 +649,10 @@ static void rt2x00lib_channel(struct ieee80211_channel *entry,
const int channel, const int tx_power,
const int value)
{
- entry->center_freq = ieee80211_channel_to_frequency(channel);
+ /* XXX: this assumption about the band is wrong for 802.11j */
+ entry->band = channel <= 14 ? IEEE80211_BAND_2GHZ : IEEE80211_BAND_5GHZ;
+ entry->center_freq = ieee80211_channel_to_frequency(channel,
+ entry->band);
entry->hw_value = value;
entry->max_power = tx_power;
entry->max_antenna_gain = 0xff;
diff --git a/drivers/net/wireless/wl1251/rx.c b/drivers/net/wireless/wl1251/rx.c
index efa5360..86eef45 100644
--- a/drivers/net/wireless/wl1251/rx.c
+++ b/drivers/net/wireless/wl1251/rx.c
@@ -78,7 +78,8 @@ static void wl1251_rx_status(struct wl1251 *wl,
*/
wl->noise = desc->rssi - desc->snr / 2;
- status->freq = ieee80211_channel_to_frequency(desc->channel);
+ status->freq = ieee80211_channel_to_frequency(desc->channel,
+ status->band);
status->flag |= RX_FLAG_TSFT;
diff --git a/drivers/net/wireless/wl12xx/rx.c b/drivers/net/wireless/wl12xx/rx.c
index 682304c..ec8d843 100644
--- a/drivers/net/wireless/wl12xx/rx.c
+++ b/drivers/net/wireless/wl12xx/rx.c
@@ -76,7 +76,7 @@ static void wl1271_rx_status(struct wl1271 *wl,
*/
wl->noise = desc->rssi - (desc->snr >> 1);
- status->freq = ieee80211_channel_to_frequency(desc->channel);
+ status->freq = ieee80211_channel_to_frequency(desc->channel, desc_band);
if (desc->flags & WL1271_RX_DESC_ENCRYPT_MASK) {
status->flag |= RX_FLAG_IV_STRIPPED | RX_FLAG_MMIC_STRIPPED;
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 1322695..679a049 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1790,8 +1790,9 @@ static inline void *wdev_priv(struct wireless_dev *wdev)
/**
* ieee80211_channel_to_frequency - convert channel number to frequency
* @chan: channel number
+ * @band: band, necessary due to channel number overlap
*/
-extern int ieee80211_channel_to_frequency(int chan);
+extern int ieee80211_channel_to_frequency(int chan, enum ieee80211_band band);
/**
* ieee80211_frequency_to_channel - convert frequency to channel number
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 53c7077..775fb63 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -270,7 +270,8 @@ static void ieee80211_rx_bss_info(struct ieee80211_sub_if_data *sdata,
enum ieee80211_band band = rx_status->band;
if (elems->ds_params && elems->ds_params_len == 1)
- freq = ieee80211_channel_to_frequency(elems->ds_params[0]);
+ freq = ieee80211_channel_to_frequency(elems->ds_params[0],
+ band);
else
freq = rx_status->freq;
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 2563fd1..2a57cc0 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -574,7 +574,7 @@ static void ieee80211_mesh_rx_bcn_presp(struct ieee80211_sub_if_data *sdata,
&elems);
if (elems.ds_params && elems.ds_params_len == 1)
- freq = ieee80211_channel_to_frequency(elems.ds_params[0]);
+ freq = ieee80211_channel_to_frequency(elems.ds_params[0], band);
else
freq = rx_status->freq;
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 45fbb9e..33bd6d4 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -176,7 +176,7 @@ static u32 ieee80211_enable_ht(struct ieee80211_sub_if_data *sdata,
/* check that channel matches the right operating channel */
if (local->hw.conf.channel->center_freq !=
- ieee80211_channel_to_frequency(hti->control_chan))
+ ieee80211_channel_to_frequency(hti->control_chan, sband->band))
enable_ht = false;
if (enable_ht) {
@@ -429,7 +429,8 @@ void ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
container_of((void *)bss, struct cfg80211_bss, priv);
struct ieee80211_channel *new_ch;
struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
- int new_freq = ieee80211_channel_to_frequency(sw_elem->new_ch_num);
+ int new_freq = ieee80211_channel_to_frequency(sw_elem->new_ch_num,
+ cbss->channel->band);
ASSERT_MGD_MTX(ifmgd);
@@ -1519,7 +1520,8 @@ static void ieee80211_rx_bss_info(struct ieee80211_sub_if_data *sdata,
}
if (elems->ds_params && elems->ds_params_len == 1)
- freq = ieee80211_channel_to_frequency(elems->ds_params[0]);
+ freq = ieee80211_channel_to_frequency(elems->ds_params[0],
+ rx_status->band);
else
freq = rx_status->freq;
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index fb274db..1ef73be 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -196,7 +196,8 @@ ieee80211_scan_rx(struct ieee80211_sub_if_data *sdata, struct sk_buff *skb)
ieee802_11_parse_elems(elements, skb->len - baselen, &elems);
if (elems.ds_params && elems.ds_params_len == 1)
- freq = ieee80211_channel_to_frequency(elems.ds_params[0]);
+ freq = ieee80211_channel_to_frequency(elems.ds_params[0],
+ rx_status->band);
else
freq = rx_status->freq;
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 37693b6..c565689 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1801,9 +1801,9 @@ void regulatory_hint_disconnect(void)
static bool freq_is_chan_12_13_14(u16 freq)
{
- if (freq == ieee80211_channel_to_frequency(12) ||
- freq == ieee80211_channel_to_frequency(13) ||
- freq == ieee80211_channel_to_frequency(14))
+ if (freq == ieee80211_channel_to_frequency(12, IEEE80211_BAND_2GHZ) ||
+ freq == ieee80211_channel_to_frequency(13, IEEE80211_BAND_2GHZ) ||
+ freq == ieee80211_channel_to_frequency(14, IEEE80211_BAND_2GHZ))
return true;
return false;
}
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 7620ae2..4ed065d 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -29,29 +29,37 @@ ieee80211_get_response_rate(struct ieee80211_supported_band *sband,
}
EXPORT_SYMBOL(ieee80211_get_response_rate);
-int ieee80211_channel_to_frequency(int chan)
+int ieee80211_channel_to_frequency(int chan, enum ieee80211_band band)
{
- if (chan < 14)
- return 2407 + chan * 5;
-
- if (chan == 14)
- return 2484;
-
- /* FIXME: 802.11j 17.3.8.3.2 */
- return (chan + 1000) * 5;
+ /* see 802.11 17.3.8.3.2 and Annex J
+ * there are overlapping channel numbers in 5GHz and 2GHz bands */
+ if (band == IEEE80211_BAND_5GHZ) {
+ if (chan >= 182 && chan <= 196)
+ return 4000 + chan * 5;
+ else
+ return 5000 + chan * 5;
+ } else { /* IEEE80211_BAND_2GHZ */
+ if (chan == 14)
+ return 2484;
+ else if (chan < 14)
+ return 2407 + chan * 5;
+ else
+ return 0; /* not supported */
+ }
}
EXPORT_SYMBOL(ieee80211_channel_to_frequency);
int ieee80211_frequency_to_channel(int freq)
{
+ /* see 802.11 17.3.8.3.2 and Annex J */
if (freq == 2484)
return 14;
-
- if (freq < 2484)
+ else if (freq < 2484)
return (freq - 2407) / 5;
-
- /* FIXME: 802.11j 17.3.8.3.2 */
- return freq/5 - 1000;
+ else if (freq >= 4910 && freq <= 4980)
+ return (freq - 4000) / 5;
+ else
+ return (freq - 5000) / 5;
}
EXPORT_SYMBOL(ieee80211_frequency_to_channel);
diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index 3e5dbd4..7f1f4ec 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -267,9 +267,12 @@ int cfg80211_wext_freq(struct wiphy *wiphy, struct iw_freq *freq)
* -EINVAL for impossible things.
*/
if (freq->e == 0) {
+ enum ieee80211_band band = IEEE80211_BAND_2GHZ;
if (freq->m < 0)
return 0;
- return ieee80211_channel_to_frequency(freq->m);
+ if (freq->m > 14)
+ band = IEEE80211_BAND_5GHZ;
+ return ieee80211_channel_to_frequency(freq->m, band);
} else {
int i, div = 1000000;
for (i = 0; i < freq->e; i++)
^ permalink raw reply related
* issues with AHB support on ubiquiti bullet 2 (AR2315)
From: Hugh Davenport @ 2011-01-17 2:12 UTC (permalink / raw)
To: ath5k-devel; +Cc: linux-wireless
Hey all,
I'm just letting you know that I have been having issues getting the the
AHB support with the ath5k driver working (from compat-wireless 2011-01-05).
I'm testing it on an ubiquiti bullet 2 device which internally is a
AR2315 WiSoC. I am using openwrt backfire with the mac80211 package
patched to use a later version of compat-wireless (ie one with AHB
support in ath5k). I had to modify some of the patches in openwrt so
they applied cleanly, but don't think any affected the ath5k (and would
cause the problem i have).
Basically the issue is this. When I try to load the module as is in the
source tree, the system hangs and module never loads (device restarts
itself).
I tried a bit of debugging (sorry about any newbie techniques here, im
new to kernel debugging) by just printing and returning errors after
every main function called. The problem seemed to be with the first time
it called ath5k_hw_reg_write, which from my tracing seemed to be in th
wisoc reset function in the following chain.
ath5k_hw_reg_write (ath5k.h)
ath5k_hw_wisoc_reset (reset.c)
ath5k_hw_nic_wakeup (reset.c)
ath5k_hw_init (attach.c)
ath5k_init_softc (base.c)
ath_ahb_probe (ahb.c)
I then tried out a few things in the vain attempt to get it to load the
module, one which seemed to work is taking out the ioremap_nocache call
in ath_ahb_probe, and set mem to be res->start (on my system this is
0xb0000000 (the same as what madwifi tells me as well)). With this /fix/
the module now loads, gives the output below, but i can't bring the
interface up (device crashes again).
Atheros AR2315 chip found (MAC: 0x87, PHY: 0x48)
continuing traces when bring interface up brings me to another
ath5k_hw_reg_write call in the following chain
ath5k_hw_reg_write (ath5k.h)
ath5k_hw_start_rx_dma (dma.c)
ath5k_rx_start (base.c)
ath5k_reset (base.c)
ath5k_init_hw (base.c)
ath5k_start (mac80211-ops.c)
I am sorry about the long email, but I thought the more info you guys
have, the better.
If you have any ideas I can try, any more testing you may need me to do,
or anything that could help me get it working, let me know, and i'll do
my best to get anything done asap.
Cheers,
Hugh Davenport
^ permalink raw reply
* Fwd: [PATCH 06/10] mac80211: add HW flag for disabling auto link-PS in AP mode
From: Arik Nemtsov @ 2011-01-16 21:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Luciano Coelho
In-Reply-To: <AANLkTik=WDsehr0EgW7QemfdmokvaLzg1ugASwiuCOXt@mail.gmail.com>
[ resending - html mail rejected ]
On Sun, Jan 16, 2011 at 10:50, Johannes Berg <johannes@sipsolutions.net> wrote:
>
> > +/**
> > + * ieee80211_start_ps - start PS for connected sta
> > + *
> > + * When operating in AP mode, use this function to inform mac80211
> > + * about a station entering PS mode.
> > + * Note that by default mac80211 will automatically call the internal
> > + * equivalent of this function according to the PM bit of incoming frames.
> > + * Use the IEEE80211_HW_AP_LINK_PS flag to change this.
>
> I think that explanation should be clearer and say that you must call
> this only when the flag is set and vice versa. Also, there should be a
>
> WARN_ON(hw->flags & HW_AP_LINK_PS)
>
> in the functions.
will fix in v2.
>
> Also, maybe just a single function with a bool argument would be more
> appropriate? Call it "ieee80211_sta_ps_transition()" or something like
> that. You should also remove the text about calling the internal
> equivalent -- the internal details might change at any time but the API
> should be documented in a way that makes sense without the internal
> details for the benefit of both sides -- people implementing a driver
> don't need to know about the internal details, and people changing the
> internal details know what semantics to keep.
a single function sounds good. v2.
>
> > + * This function may not be called in IRQ context or process context.
>
> This can't be true -- the latter part you must mean "or with softirqs
> enabled".
Yes you're right.
(While looking at this I discovered that I forgot to disable softirqs
myself. These functions are called from a workqueue in wl12xx - will
be fixed in v2)
>
> Also, I'm worried about races between this and RX. All of the RX path
> assumes that it is running at the same time. The ap_sta_ps_{start,end}
> functions won't be called from the RX path when the flag is set, and
> this is dependent on setting the flag, but is there really nothing in
> them that could race?
They might race if the user is not careful. On a SMP machine a user
can call ieee80211_rx() and ap_sta_ps_start() from two different
workqueues for example.
I can add an explicit mutex, but a documentation warning will suffice here no?
>
> Finally, I'm worried about this calling back into the driver's
> sta_notify callback. If that is to remain that way, it needs to be
> *very* clearly documented, I'd *much* prefer it not doing that but
> handing off to a work struct or so internally.
>
sta_notify is pretty useless when the low level driver calls toggles
the PS-mode by itself. How about I simply remove the call to
sta_notify in case IEEE80211_HW_AP_LINK_PS is set?
If a low level driver needs to do some deferred processing after a
PS-mode transition, it can queue a work on its own..
Regards,
Arik
^ permalink raw reply
* Compat-wireless release for 2011-01-16 is baked
From: Compat-wireless cronjob account @ 2011-01-16 20:03 UTC (permalink / raw)
To: linux-wireless
compat-wireless code metrics
782520 - Total upstream lines of code being pulled
2103 - backport code changes
1843 - backport code additions
260 - backport code deletions
7279 - backport from compat module
9382 - total backport code
1.1989 - % of code consists of backport work
1531 - Crap changes not yet posted
1488 - Crap additions not yet posted
43 - Crap deletions not yet posted
0.1956 - % of crap code
Base tree: linux-next.git
Base tree version: next-20110115
compat-wireless release: compat-wireless-2011-01-06-3-g8db1608-pc
^ permalink raw reply
* Kernel Panic on Associate with brcm80211.
From: Ilya Kogan @ 2011-01-16 19:54 UTC (permalink / raw)
To: linux-wireless
Hi,
I've solved my issue regarding not being able to get the card to
scan (apparently there was a conflict with acer_wmi). Now that I can get
it to come up, I've discovered the following panic on associate:
[ 80.856072] wlan0: authenticated
[ 80.856175] wlan0: associate with 00:23:69:56:27:b1 (try 1)
[ 80.859729] wlan0: RX AssocResp from 00:23:69:56:27:b1 (capab=0x411
status=0 aid=2)
[ 80.859803] wlan0: associated
[ 80.859877] ieee80211 phy0: Allocated STA 00:23:69:56:27:b1
[ 80.860489] ieee80211 phy0: Inserted STA 00:23:69:56:27:b1
[ 80.860586] ieee80211 phy0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15
cWmax=1023 txop=0 uapsd=0
[ 80.860750] ieee80211 phy0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15
cWmax=1023 txop=0 uapsd=0
[ 80.860915] ieee80211 phy0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7
cWmax=15 txop=94 uapsd=0
[ 80.861080] ieee80211 phy0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3
cWmax=7 txop=47 uapsd=0
[ 80.861245] Associated: True
[ 80.861693] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 80.866030] wl0: wlc_d11hdrs_mac80211: AC_BE txop exceeded phylen
159/256 dur 1778/1504
[ 80.875589] wl0: wlc_d11hdrs_mac80211: AC_BE txop exceeded phylen
137/256 dur 1602/1504
[ 80.956792] Intel AES-NI instructions are not detected.
[ 81.022228] padlock: VIA PadLock not detected.
[ 81.103155] wl0: wlc_d11hdrs_mac80211: AC_BE txop exceeded phylen
382/256 dur 3562/1504
[ 81.440181] Kernel panic - not syncing: <3>assertion "!(sdu->cloned)"
failed: file "wlc_mac80211.c", line 5129
[ 81.440185]
[ 81.440352] Pid: 0, comm: swapper Tainted: P
2.6.35-25-debug #43
[ 81.440409] Call Trace:
[ 81.440460] <IRQ> [<ffffffff815ad3c7>] panic+0x90/0x118
[ 81.440586] [<ffffffffa06fb876>] osl_assert+0xb6/0x170 [brcm80211]
[ 81.440665] [<ffffffffa074a238>] ? dma64_txfast+0xd8/0x3e0 [brcm80211]
[ 81.440740] [<ffffffffa0707833>] ? wlc_txfifo+0xb3/0x180 [brcm80211]
[ 81.440815] [<ffffffffa0707997>] ? wlc_send_q+0x97/0x230 [brcm80211]
[ 81.440889] [<ffffffffa070364f>] ? wlc_prec_enq_head+0xdf/0x260
[brcm80211]
[ 81.440964] [<ffffffffa070be00>] wlc_sendpkt_mac80211+0x1720/0x2830
[brcm80211]
[ 81.441043] [<ffffffffa07037e1>] ? wlc_prec_enq+0x11/0x20 [brcm80211]
[ 81.441117] [<ffffffffa070bb0f>] ?
wlc_sendpkt_mac80211+0x142f/0x2830 [brcm80211]
[ 81.441193] [<ffffffffa070fbcc>] ? wl_ops_tx+0x2c/0xa0 [brcm80211]
[ 81.441252] [<ffffffff812dd1e4>] ? do_raw_spin_lock+0x54/0x150
[ 81.441327] [<ffffffffa070fbee>] wl_ops_tx+0x4e/0xa0 [brcm80211]
[ 81.441404] [<ffffffffa06a15e7>] __ieee80211_tx+0x147/0x230 [mac80211]
[ 81.441479] [<ffffffffa06a0f56>] ?
ieee80211_tx_h_calculate_duration+0x56/0x80 [mac80211]
[ 81.441559] [<ffffffffa06a2d9e>] ieee80211_tx+0xfe/0x2e0 [mac80211]
[ 81.441632] [<ffffffffa06a2cde>] ? ieee80211_tx+0x3e/0x2e0 [mac80211]
[ 81.441707] [<ffffffffa06a3062>] ieee80211_xmit+0xe2/0x240 [mac80211]
[ 81.441781] [<ffffffffa06a2f80>] ? ieee80211_xmit+0x0/0x240 [mac80211]
[ 81.441855] [<ffffffffa06a389b>] ?
ieee80211_subif_start_xmit+0x5bb/0x9d0 [mac80211]
[ 81.441935] [<ffffffffa06a368f>]
ieee80211_subif_start_xmit+0x3af/0x9d0 [mac80211]
[ 81.442013] [<ffffffffa06a3827>] ?
ieee80211_subif_start_xmit+0x547/0x9d0 [mac80211]
[ 81.442076] [<ffffffff814a7aae>] ? sock_def_write_space+0x9e/0xd0
[ 81.442132] [<ffffffff814a7a10>] ? sock_def_write_space+0x0/0xd0
[ 81.442189] [<ffffffff814b813a>] dev_hard_start_xmit+0x13a/0x2e0
[ 81.442245] [<ffffffff814d4626>] sch_direct_xmit+0xf6/0x260
[ 81.442300] [<ffffffff814ba7cd>] dev_queue_xmit+0x13d/0x680
[ 81.442360] [<ffffffff814ba6ea>] ? dev_queue_xmit+0x5a/0x680
[ 81.442425] [<ffffffff81098e3d>] ? trace_hardirqs_on+0xd/0x10
[ 81.442482] [<ffffffff8106a547>] ? local_bh_enable_ip+0x97/0xf0
[ 81.442538] [<ffffffff814c3400>] neigh_resolve_output+0x110/0x3e0
[ 81.442595] [<ffffffff8154ce97>] ip6_finish_output2+0x107/0x410
[ 81.442651] [<ffffffff8154e058>] ip6_finish_output+0x98/0x150
[ 81.442707] [<ffffffff8154e1a8>] ip6_output+0x98/0x1b0
[ 81.442763] [<ffffffff81562b03>] ndisc_send_skb+0x303/0x3c0
[ 81.442819] [<ffffffff815628b2>] ? ndisc_send_skb+0xb2/0x3c0
[ 81.442875] [<ffffffff81562c21>] __ndisc_send+0x61/0x80
[ 81.442931] [<ffffffff81553fb0>] ? addrconf_dad_timer+0x0/0x190
[ 81.442989] [<ffffffff81563442>] ndisc_send_ns+0x72/0xc0
[ 81.443044] [<ffffffff81553fb0>] ? addrconf_dad_timer+0x0/0x190
[ 81.443099] [<ffffffff81553fb0>] ? addrconf_dad_timer+0x0/0x190
[ 81.443154] [<ffffffff815540f0>] addrconf_dad_timer+0x140/0x190
[ 81.443212] [<ffffffff810725c4>] call_timer_fn+0x84/0x180
[ 81.443267] [<ffffffff81072540>] ? call_timer_fn+0x0/0x180
[ 81.443323] [<ffffffff81553fb0>] ? addrconf_dad_timer+0x0/0x190
[ 81.443378] [<ffffffff8107320c>] run_timer_softirq+0x14c/0x260
[ 81.443435] [<ffffffff8102b5fd>] ? lapic_next_event+0x1d/0x30
[ 81.443491] [<ffffffff81069c23>] __do_softirq+0xd3/0x220
[ 81.443548] [<ffffffff81087080>] ? hrtimer_interrupt+0x140/0x250
[ 81.443605] [<ffffffff8100c05c>] call_softirq+0x1c/0x30
[ 81.443659] [<ffffffff8100db9d>] do_softirq+0x9d/0xd0
[ 81.443716] [<ffffffff810697e5>] irq_exit+0x95/0xa0
[ 81.443771] [<ffffffff815b8970>] smp_apic_timer_interrupt+0x70/0x9b
[ 81.443827] [<ffffffff8100bb13>] apic_timer_interrupt+0x13/0x20
[ 81.443880] <EOI> [<ffffffff810141dd>] ? default_idle+0x3d/0xa0
[ 81.443983] [<ffffffff810371ab>] ? native_safe_halt+0xb/0x10
[ 81.444041] [<ffffffff81098e3d>] ? trace_hardirqs_on+0xd/0x10
[ 81.444097] [<ffffffff810141e2>] default_idle+0x42/0xa0
[ 81.444152] [<ffffffff810142da>] c1e_idle+0x9a/0x130
[ 81.444208] [<ffffffff81009da8>] cpu_idle+0xb8/0x110
[ 81.444264] [<ffffffff815964bf>] rest_init+0xcf/0xe0
[ 81.444319] [<ffffffff815963f0>] ? rest_init+0x0/0xe0
[ 81.444375] [<ffffffff81afdcbe>] start_kernel+0x3aa/0x3b3
[ 81.444440] [<ffffffff81afd341>] x86_64_start_reservations+0x12c/0x130
[ 81.444504] [<ffffffff81afd43f>] x86_64_start_kernel+0xfa/0x109
Kernel is: Linux Lulzer 2.6.35-25-debug #43 SMP Sat Jan 15 22:29:10 EST
2011 x86_64 GNU/Linux
Card is: 06:00.0 Network controller [0280]: Broadcom Corporation
BCM43225 802.11b/g/n [14e4:4357] (rev 01)
Module is: [ 78.955414] wl0: Broadcom BCM43xx 802.11 MAC80211 Driver
(1.82.8.0) (Compiled at 01:50:33 on Jan 16 2011)
This is based on the latest compat-wireless git revision as of the
module compile date.
Thanks,
-- Ilya Kogan
^ permalink raw reply
* Re: ath9k - cannot reconnect few meters from the antenna
From: Tomek @ 2011-01-16 19:27 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20110114182345.GB11920@vmraj-lnx.users.atheros.com>
Hi
Thank you for the support.
I did as you told me - there are a lot of following messages:
ath: ffff880001c03d70
I think the problem may be power save mode. There is something like
this in the logs - it seems that the card after going into some kind
of sleep (no clients active). The problem does not occur if there is a
wireless client associated all the time.
This is what is happening if the wireless network card tries to reconnect:
Jan 16 19:53:42 tomasz-htpc kernel: [1245668.441903] ieee80211 phy0:
Allocated STA 00:1e:64:7d:b3:ee
Jan 16 19:53:42 tomasz-htpc kernel: [1245668.442019] ieee80211 phy0:
Inserted STA 00:1e:64:7d:b3:ee
Jan 16 19:54:34 tomasz-htpc kernel: [1245721.374459] wlan0: STA
00:1e:64:7d:b3:ee aid 1 enters power save mode
Jan 16 19:54:35 tomasz-htpc kernel: [1245721.560981] wlan0: STA
00:1e:64:7d:b3:ee aid 1 exits power save mode
Jan 16 19:54:35 tomasz-htpc kernel: [1245721.561000] wlan0: STA
00:1e:64:7d:b3:ee aid 1 sending 1 filtered/0 PS frames since STA not
sleeping anymore
Jan 16 19:54:35 tomasz-htpc kernel: [1245722.012452] wlan0: STA
00:1e:64:7d:b3:ee aid 1 enters power save mode
Jan 16 19:54:35 tomasz-htpc kernel: [1245722.045244] wlan0: STA
00:1e:64:7d:b3:ee aid 1 exits power save mode
Jan 16 19:54:35 tomasz-htpc kernel: [1245722.045263] wlan0: STA
00:1e:64:7d:b3:ee aid 1 sending 0 filtered/0 PS frames since STA not
sleeping anymore
Jan 16 19:54:36 tomasz-htpc kernel: [1245723.070050] ieee80211 phy0:
Removed STA 00:1e:64:7d:b3:ee
Jan 16 19:54:36 tomasz-htpc kernel: [1245723.070139] ieee80211 phy0:
Destroyed STA 00:1e:64:7d:b3:ee
Jan 16 19:54:37 tomasz-htpc kernel: [1245723.660913] wlan0: dropped
frame to 00:1e:64:7d:b3:ee (unauthorized port)
Jan 16 19:54:38 tomasz-htpc kernel: [1245724.797561] wlan0: dropped
frame to 00:1e:64:7d:b3:ee (unauthorized port)
Jan 16 19:54:38 tomasz-htpc kernel: [1245724.801741] wlan0: dropped
frame to 00:1e:64:7d:b3:ee (unauthorized port)
Jan 16 19:54:38 tomasz-htpc kernel: [1245725.208031] wlan0: dropped
frame to 00:1e:64:7d:b3:ee (unauthorized port)
Jan 16 19:54:38 tomasz-htpc kernel: [1245725.209209] wlan0: dropped
frame to 00:1e:64:7d:b3:ee (unauthorized port)
Jan 16 19:54:39 tomasz-htpc kernel: [1245725.808240] wlan0: dropped
frame to 00:1e:64:7d:b3:ee (unauthorized port)
Jan 16 19:54:39 tomasz-htpc kernel: [1245726.007755] wlan0: dropped
frame to 00:1e:64:7d:b3:ee (unauthorized port)
Jan 16 19:54:39 tomasz-htpc kernel: [1245726.007799] wlan0: dropped
frame to 00:1e:64:7d:b3:ee (unauthorized port)
Jan 16 19:54:39 tomasz-htpc kernel: [1245726.028789] wlan0: dropped
frame to 00:1e:64:7d:b3:ee (unauthorized port)
Jan 16 19:54:39 tomasz-htpc kernel: [1245726.208536] wlan0: dropped
frame to 00:1e:64:7d:b3:ee (unauthorized port)
Jan 16 19:54:44 tomasz-htpc kernel: [1245730.601089] __ratelimit: 10
callbacks suppressed
And again and again - but if I go closer to AP it works, even if I walk away.
Regards
Tomasz
2011/1/14 Rajkumar Manoharan <rmanoharan@atheros.com>
>
> On Fri, Jan 14, 2011 at 04:16:37AM +0530, Tomasz wrote:
> > Hi All
> > I've spend a lot of time on this issue and I cannot fix it, thus I am asking for
> > help
> > It looks like that:
> >
> > I am running wireless access point based on:
> > Ubuntu 10.04 vmlinuz-2.6.32-27-generic
> > compat-wireless-2010-12-26
> > hostapd 0.7.3 (wpa/wpa2)
> > Dnsmasq version 2.52
> > Zotac Ion board
> > Minipcie card: ieee80211 phy0: Atheros AR9285 Rev:2
> > ath9k driver
> > Single antenna (but the behaviour with two antenna is similar)
> >
> > Everything works perfectly fine when I am within the few meters from the antenna.
> > So the clients are connecting and I get 25 mbps data rates.
> > But if more then 10 meters from the antenna strange things are happening.
> > - If I am connected to the network and will walk away everything works perfect.
> > - But if i disconnect (disassociate) when I am away I cannot connect back. -
> > this also means I cannot connect when turning the notebook on :)
> > - if I go closer to antenna I am able to connect and while walking away the
> > connection seems perfectly stable ...
> Hi Tomasz,
>
> Do you have any interference with the oper channel? Please enable debug option
> CONFIG_ATH_DEBUG=y in config.mk and modprobe ath9k debug=0x701 and
> post dmesg/kern.log
>
> --
> Rajkumar
^ permalink raw reply
* Re: [PATCH v3 2/2] wl12xx: BA receiver support
From: Levi, Shahar @ 2011-01-16 13:38 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTimNRzc9M0wKZsQLMh4ihSHEeycFJ-S34CA=jPAc@mail.gmail.com>
On Tue, Jan 11, 2011 at 2:54 AM, Levi, Shahar <shahar_levi@ti.com> wrote:
>>> diff --git a/drivers/net/wireless/wl12xx/acx.c b/drivers/net/wireless/wl12xx/acx.c
>>> index 54fd68d..f33ab50 100644
>>> --- a/drivers/net/wireless/wl12xx/acx.c
>>> +++ b/drivers/net/wireless/wl12xx/acx.c
>>> @@ -1359,6 +1359,42 @@ out:
>>> return ret;
>>> }
>>>
>>> +/* setup BA session receiver setting in the FW. */
>>> +int wl1271_acx_set_ba_receiver_session(struct wl1271 *wl, u8 tid_index,
>>> + u16 *ssn, u8 policy)
>>
>> You don't modify ssn here, so why pass it as a pointer? Use u16 directly
>> here instead.
>>
>> Actually it's even worse. As stated in mac80211.h, ssn can be NULL
>> here, so you would be accessing a NULL pointer in that case.
>>
>> I see that you check "policy", which indicates whether ssn is valid or
>> not, but why not make it cleaner by checking if ssn is NULL and setting
>> it to zero before passing instead?
> good chtch. it was left from previous implantation. will be fix.
There is two options from you suggestion:
a) move ssn directly and then check policy if it is valid
b) keep ssn as pointer and check it to validate it is valid.
I will use a option.
Thanks,
Shahar
^ permalink raw reply
* Re: Dividing by a non-static value in carl9170-fw?
From: Ignacy Gawedzki @ 2011-01-16 12:48 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
In-Reply-To: <201101161245.54221.chunkeey@googlemail.com>
On Sun, Jan 16, 2011 at 12:45:53PM +0100, thus spake Christian Lamparter:
> Hello,
>
> please CC your mails to linux-wireless mailing-list in the future.
Okay, sorry about that.
> On Sunday 16 January 2011 04:16:00 Ignacy Gawedzki wrote:
> > Since I recently noticed that you added the support for the ticks_per_msec
> > field in fw, I thought it would be better to use that to convert durations
> > from ticks to milliseconds, instead of the fixed 44 literal. =)
>
> Is this a regression on my part? I don't see any references to __udivsi3_i4i
> during build.
Absolutely not. I'm talking about my (experimental) modifications to the
firmware code to measure TX frame service time and report that in msec in the
tx status.
> Also, you can almost always get around it by converting "a / b = c" to
> "a = b * c".
I doubt so, since what I need to do is roughly
msec_to_report = ticks_measured / ticks_per_msec;
my input being of course ticks_measured. :/
> > Unfortunately, it seems that dividing by a non-static value is not supported
> > natively on that platform and I get undefined reference to __udivsi3_i4i. Do
> > you, by any chance, know how to fix that? Apparently there are some support
> > libs in the toolchain's gcc with that symbol, but I just got lost in the CMake
> > file hierarchy while looking for a place to start hacking that in.
>
> No need for a hack, just get a udivsi3_i4i.S (a good place is the linux kernel
> library sources in arch/sh/lib, you could also import one from the original
> ar9170fw.git) and place it into carlfw/src. Next, you need to modify the
> carlfw/CMakeLists.txt: add src/udivsi3_i4i.S to carl9170_lib_src and put
> "set_source_files_properties(src/udivsi3_i4i.S PROPERTIES LANGUAGE C)"
> a few lines further down.
>
> compile...
>
> [Note: you probably have to change the name of the __udivsi3_i4i symbol
> to ___udivsi3_i4i too]
Great, thanks for the hint, I'll try that as soon as I can.
Regards,
Ignacy
--
To err is human, to moo bovine.
^ permalink raw reply
* [PATCH] ath9k_htc: abort tx/rx on fast channel change
From: Sujith @ 2011-01-16 11:20 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: linux-wireless
In-Reply-To: <1295158794-3088-1-git-send-email-rmanoharan@atheros.com>
Rajkumar Manoharan wrote:
> - if (!fastcc)
> + if (fastcc) {
> + /* abort pending tx frames */
> + WMI_CMD(WMI_ABORT_TX_DMA_CMDID);
Why abort instead of stop ?
And if i remember correctly, aborting of TX is enabled
only for the AR9003 family.
> + WMI_CMD(WMI_ABORT_TXQ_CMDID);
This is exactly the same as DRAIN_TXQ_ALL.
> + /* Clear receive filter */
> + ath9k_hw_setrxfilter(ah, 0);
Why should the filter be cleared ?
> + WMI_CMD(WMI_STOP_DMA_RECV_CMDID);
WMI_STOP_RECV does this already.
> + WMI_CMD(WMI_RX_LINK_CMDID);
The host should have nothing to do with setting the rx_link
variable on the target. This WMI command should really be
removed.
A little more information on what this patch fixes would be nice.
Sujith
^ permalink raw reply
* Re: [PATCH v5 1/2] wl12xx: BA initiator support
From: Levi, Shahar @ 2011-01-16 9:12 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless@vger.kernel.org, Luciano Coelho
In-Reply-To: <1294733082.12992.21.camel@pimenta>
On Tue, Jan 11, 2011 at 10:04 AM, Luciano Coelho <coelho@ti.com> wrote:
> On Tue, 2011-01-11 at 01:18 +0100, Levi, Shahar wrote:
>> On Tue, Jan 11, 2011 at 2:13 AM, Levi, Shahar <shahar_levi@ti.com> wrote:
>> >
>> > On Mon, Jan 10, 2011 at 5:00 PM, Luciano Coelho <coelho@ti.com> wrote:
>> >>
>> >> On Mon, 2011-01-03 at 14:42 +0100, Shahar Levi wrote:
>> >> > diff --git a/drivers/net/wireless/wl12xx/acx.h b/drivers/net/wireless/wl12xx/acx.h
>> >> > index 9cbc3f4..df48468 100644
>> >> > --- a/drivers/net/wireless/wl12xx/acx.h
>> >> > +++ b/drivers/net/wireless/wl12xx/acx.h
>> >> > @@ -1051,6 +1051,40 @@ struct wl1271_acx_ht_information {
>> >> > u8 padding[3];
>> >> > } __packed;
>> >> >
>> >> > +#define BA_WIN_SIZE 8
>> >>
>> >> Should this be DEFAULT_BA_WIN_SIZE?
>> >
>> No, the FW support win size of 8. it is not configurable.
>
> If only 8 is supported, why do we even have to pass it to the firmware
> in the ACX_BA_SESSION_POLICY_CFG command? I think that, even though this
> cannot be really changed, it should be part of the conf structure.
i did some more investigation on that, the WLAN_BACK_INITIATOR win
size could be up to 64 pacets; the WLAN_BACK_RECIPIENT could be up to
8.
i will fix by call the macro RX_BA_WIN_SIZE 8 and add in conf
structure tx_ba_win_size
>
>
>> >> > +{
>> >> > + char fw_ver_str[ETHTOOL_BUSINFO_LEN];
>> >>
>> >> This is weird, but it seem to be what is used in cfg80211 (as Shahar
>> >> pointed out on IRC). IMHO it should be ETHTOOL_FWVERS_LEN instead, both
>> >> here and in cfg80211.
>> >>
>> >> In any case, this is a bit confusing here, because we don't use the
>> >> fw_version in the wiphy struct (we probably should). Let's keep it like
>> >> this for now and maybe later we can change.
>> >>
>> >> Also, I don't see why you need a local copy here.
>> >
>> i use local copy in order to remove '.' (*fw_ver_point = '\0') without
>> destroyed wl->chip.fw_ver_str.
>
> Ah, I see, but if you use sscanf, as I suggested, this won't be needed
> anymore.
>
>
>> >> > @@ -161,10 +166,13 @@ struct wl1271_partition_set {
>> >> >
>> >> > struct wl1271;
>> >> >
>> >> > +#define WL12XX_NUM_FW_VER 5
>> >> > +
>> >>
>> >> WL12XX_FW_VER_OFFSET sounds better to me.
>> >>
>> >> And it shouldn't it be 4,
>> >> which is the "Rev " prefix?
>> >
>> the macro represent the number of numbers in the version. it is not offset.
>
> Right, I guess I didn't follow your algorithm in details, since using
> sscanf would be much easier.
>
>
> --
> Cheers,
> Luca.
>
>
np, i will try to use sscanf and update.
Thanks.
^ permalink raw reply
* [PATCH v2] wl12xx: fix some endianess bugs
From: Eliad Peller @ 2011-01-16 9:07 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
pointed out by sparse warnings:
CHECK drivers/net/wireless/wl12xx/cmd.c
drivers/net/wireless/wl12xx/cmd.c:987:20: warning: incorrect type in assignment (different base types)
drivers/net/wireless/wl12xx/cmd.c:987:20: expected restricted __le16 [usertype] aging_period
drivers/net/wireless/wl12xx/cmd.c:987:20: got int
CHECK drivers/net/wireless/wl12xx/tx.c
drivers/net/wireless/wl12xx/tx.c:197:2: warning: cast from restricted __le16
drivers/net/wireless/wl12xx/tx.c:197:2: warning: cast from restricted __le16
drivers/net/wireless/wl12xx/tx.c:197:2: warning: cast from restricted __le16
CHECK drivers/net/wireless/wl12xx/acx.c
drivers/net/wireless/wl12xx/acx.c:816:23: warning: incorrect type in assignment (different base types)
drivers/net/wireless/wl12xx/acx.c:816:23: expected restricted __le32 [usertype] rate_policy_idx
drivers/net/wireless/wl12xx/acx.c:816:23: got unsigned char [unsigned] [usertype] idx
Signed-off-by: Eliad Peller <eliad@wizery.com>
---
v1->v2:
don't use the underscore versions of the casting functions
rephrase commit message
drivers/net/wireless/wl12xx/acx.c | 2 +-
drivers/net/wireless/wl12xx/cmd.c | 2 +-
drivers/net/wireless/wl12xx/tx.c | 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/acx.c b/drivers/net/wireless/wl12xx/acx.c
index 646d278..679bb37 100644
--- a/drivers/net/wireless/wl12xx/acx.c
+++ b/drivers/net/wireless/wl12xx/acx.c
@@ -813,7 +813,7 @@ int wl1271_acx_ap_rate_policy(struct wl1271 *wl, struct conf_tx_rate_class *c,
acx->rate_policy.long_retry_limit = c->long_retry_limit;
acx->rate_policy.aflags = c->aflags;
- acx->rate_policy_idx = idx;
+ acx->rate_policy_idx = cpu_to_le32(idx);
ret = wl1271_cmd_configure(wl, ACX_RATE_POLICY, acx, sizeof(*acx));
if (ret < 0) {
diff --git a/drivers/net/wireless/wl12xx/cmd.c b/drivers/net/wireless/wl12xx/cmd.c
index e28d9ca..1bb8be5 100644
--- a/drivers/net/wireless/wl12xx/cmd.c
+++ b/drivers/net/wireless/wl12xx/cmd.c
@@ -984,7 +984,7 @@ int wl1271_cmd_start_bss(struct wl1271 *wl)
memcpy(cmd->bssid, bss_conf->bssid, ETH_ALEN);
- cmd->aging_period = WL1271_AP_DEF_INACTIV_SEC;
+ cmd->aging_period = cpu_to_le16(WL1271_AP_DEF_INACTIV_SEC);
cmd->bss_index = WL1271_AP_BSS_INDEX;
cmd->global_hlid = WL1271_AP_GLOBAL_HLID;
cmd->broadcast_hlid = WL1271_AP_BROADCAST_HLID;
diff --git a/drivers/net/wireless/wl12xx/tx.c b/drivers/net/wireless/wl12xx/tx.c
index 2347f25..3507c81 100644
--- a/drivers/net/wireless/wl12xx/tx.c
+++ b/drivers/net/wireless/wl12xx/tx.c
@@ -195,9 +195,9 @@ static void wl1271_tx_fill_hdr(struct wl1271 *wl, struct sk_buff *skb,
desc->tx_attr = cpu_to_le16(tx_attr);
wl1271_debug(DEBUG_TX, "tx_fill_hdr: pad: %d hlid: %d "
- "tx_attr: 0x%x len: %d life: %d mem: %d", pad, (int)desc->hlid,
- (int)desc->tx_attr, (int)desc->length, (int)desc->life_time,
- (int)desc->total_mem_blocks);
+ "tx_attr: 0x%x len: %d life: %d mem: %d", pad, desc->hlid,
+ le16_to_cpu(desc->tx_attr), le16_to_cpu(desc->length),
+ le16_to_cpu(desc->life_time), desc->total_mem_blocks);
}
/* caller must hold wl->mutex */
--
1.7.0.4
^ permalink raw reply related
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