* [PATCH] wireless: remove unnecessary reg_same_country_ie_hint
From: John W. Linville @ 2010-07-20 19:15 UTC (permalink / raw)
To: linux-wireless; +Cc: Luis R. Rodriguez, John W. Linville
In-Reply-To: <AANLkTinPnjtbDM8AE7gKMA9lBnIJDqG-KXc04ynZ6wLg@mail.gmail.com>
"Might as well remove reg_same_country_ie_hint() completely since we
already dealt with suspend/resume through the regulatory hint
disconnect." -- Luis
Reported-by: Luis R. Rodriguez <mcgrof@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/wireless/reg.c | 45 ---------------------------------------------
1 files changed, 0 insertions(+), 45 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 678d0bd..48baf28 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1483,39 +1483,6 @@ int regulatory_hint(struct wiphy *wiphy, const char *alpha2)
}
EXPORT_SYMBOL(regulatory_hint);
-/* Caller must hold reg_mutex */
-static bool reg_same_country_ie_hint(struct wiphy *wiphy,
- char *alpha2, enum environment_cap env)
-{
- struct wiphy *request_wiphy;
-
- assert_reg_lock();
-
- if (unlikely(last_request->initiator !=
- NL80211_REGDOM_SET_BY_COUNTRY_IE))
- return false;
-
- request_wiphy = wiphy_idx_to_wiphy(last_request->wiphy_idx);
-
- if (!request_wiphy)
- return false;
-
- if (likely(request_wiphy != wiphy))
- return (last_request->alpha2[0] == alpha2[0] &&
- last_request->alpha2[1] == alpha2[1] &&
- last_request->country_ie_env == env);
- /*
- * We should not have let these through at this point, they
- * should have been picked up earlier by the first alpha2 check
- * on the device
- */
- if (WARN_ON((last_request->alpha2[0] == alpha2[0] &&
- last_request->alpha2[1] == alpha2[1] &&
- last_request->country_ie_env == env )))
- return true;
- return false;
-}
-
/*
* We hold wdev_lock() here so we cannot hold cfg80211_mutex() and
* therefore cannot iterate over the rdev list here.
@@ -1560,18 +1527,6 @@ void regulatory_hint_11d(struct wiphy *wiphy,
wiphy_idx_valid(last_request->wiphy_idx)))
goto out;
- /*
- * This will not happen right now but we leave it here for the
- * the future when we want to add suspend/resume support and having
- * the user move to another country after doing so, or having the user
- * move to another AP. Right now we just trust the first AP.
- *
- * If we hit this before we add this support we want to be informed of
- * it as it would indicate a mistake in the current design
- */
- if (WARN_ON(reg_same_country_ie_hint(wiphy, alpha2, env)))
- goto free_rd_out;
-
request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
if (!request)
goto free_rd_out;
--
1.7.1.1
^ permalink raw reply related
* [PATCH v2] rtl8180: improve signal reporting for rtl8185 hardware
From: John W. Linville @ 2010-07-20 20:56 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
In-Reply-To: <1279572443-14361-1-git-send-email-linville@tuxdriver.com>
The existing code seemed to be somewhat based on the datasheet, but
varied substantially from the vendor-provided driver. This mirrors the
handling of the rtl8185 case from that driver, but still neglects the
specifics for the rtl8180 hardware. Those details are a bit muddled...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
v2 -- Add missing "subtract from constant" pieces of the signal formulas...
drivers/net/wireless/rtl818x/rtl8180_dev.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8180_dev.c b/drivers/net/wireless/rtl818x/rtl8180_dev.c
index 4270502..31808f9 100644
--- a/drivers/net/wireless/rtl818x/rtl8180_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8180_dev.c
@@ -103,6 +103,7 @@ static void rtl8180_handle_rx(struct ieee80211_hw *dev)
{
struct rtl8180_priv *priv = dev->priv;
unsigned int count = 32;
+ u8 signal;
while (count--) {
struct rtl8180_rx_desc *entry = &priv->rx_ring[priv->rx_idx];
@@ -130,10 +131,14 @@ static void rtl8180_handle_rx(struct ieee80211_hw *dev)
skb_put(skb, flags & 0xFFF);
rx_status.antenna = (flags2 >> 15) & 1;
- /* TODO: improve signal/rssi reporting */
- rx_status.signal = (flags2 >> 8) & 0x7F;
- /* XXX: is this correct? */
rx_status.rate_idx = (flags >> 20) & 0xF;
+ /* TODO: improve signal/rssi reporting for !rtl8185 */
+ signal = (flags2 >> 17) & 0x7F;
+ if (rx_status.rate_idx > 3)
+ signal = 90 - clamp_t(u8, signal, 25, 90);
+ else
+ signal = 95 - clamp_t(u8, signal, 30, 95);
+ rx_status.signal = signal;
rx_status.freq = dev->conf.channel->center_freq;
rx_status.band = dev->conf.channel->band;
rx_status.mactime = le64_to_cpu(entry->tsft);
--
1.7.1.1
^ permalink raw reply related
* Re: [ath5k-devel] ath5k Ad Hoc Association
From: Derek Smithies @ 2010-07-20 22:11 UTC (permalink / raw)
To: Bob Copeland; +Cc: Jonathan Guerin, Ath5k Devel issues., linux-wireless
In-Reply-To: <AANLkTintLd8YTgMQuzbEB36t_i5AL4TePBSDAa7G2zvl@mail.gmail.com>
Hi,
On Mon, 19 Jul 2010, Bob Copeland wrote:
> On Mon, Jul 19, 2010 at 12:35 AM, Jonathan Guerin <jonathan@guerin.id.au> wrote:
>> Hi,
>>
>> I'm trying to get my wireless nodes to associate in ad hoc mode.
[[[snipped]]]
> $ su
> # modprobe -r ath5k
> # modprobe ath5k
> # iw dev wlan0 set type ibss
> # ifconfig wlan0 192.168.10.1 up
> # iw dev wlan0 ibss join myibss 2462
>
> Then on the other machine (Vista) I just located 'myibss' (so beacons
> are working) and selected it, then successfully pinged 192.168.10.1.
Wrong.
If the other machine located your node, then one of the four statements
is true:
a)beacons are working
b)probes are working - which means a scan is happening.
c)beacons and probes are working
d)beacons and probes are not working. The vista machine saw a data
packet, and sent a probe request, which your machine answered.
>>>>>>>>
My colleague here did some work with a slightly older kernel.
He found that the association process worked sometimes - not always.
There was a time dependency - both nodes have to go through this at the
same time.
Further - scans - it seems that nodes have to scan to find things.
Old information in the mac80211 has to be expired and removed.
A scan should not be necessary - if both ends are put on channel 2462- a
scan should not be required - there is no channel changing. Yet - my
colleague noted a scan helped nodes to associate.
I would say this:::
I cannot deduce what is happening from the initial posters report. I
need a packet dump of the beacons/probes and all the other packets on the
air.
Cheers,
Derek.
--
Derek Smithies Ph.D.
IndraNet Technologies Ltd.
ph +64 3 365 6485
Web: http://www.indranet-technologies.com/
"How did you make it work??"
"Oh, the usual, get everything right".
^ permalink raw reply
* Re: [ath5k-devel] ath5k Ad Hoc Association
From: Jonathan Guerin @ 2010-07-20 22:54 UTC (permalink / raw)
To: Derek Smithies; +Cc: Bob Copeland, Ath5k Devel issues., linux-wireless
In-Reply-To: <alpine.DEB.2.00.1007211002410.21858@kauri.acheron.indranet.co.nz>
I am happy to provide such data. Tell me what config you want me to
put in place and I'll set up a capture.
Cheers,
--
Jonathan Guerin
On Wed, Jul 21, 2010 at 8:11 AM, Derek Smithies <derek@indranet.co.nz> wrote:
> Hi,
> On Mon, 19 Jul 2010, Bob Copeland wrote:
>
>> On Mon, Jul 19, 2010 at 12:35 AM, Jonathan Guerin <jonathan@guerin.id.au>
>> wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to get my wireless nodes to associate in ad hoc mode.
>
> [[[snipped]]]
>>
>> $ su
>> # modprobe -r ath5k
>> # modprobe ath5k
>> # iw dev wlan0 set type ibss
>> # ifconfig wlan0 192.168.10.1 up
>> # iw dev wlan0 ibss join myibss 2462
>>
>> Then on the other machine (Vista) I just located 'myibss' (so beacons
>> are working) and selected it, then successfully pinged 192.168.10.1.
>
> Wrong.
> If the other machine located your node, then one of the four statements is
> true:
> a)beacons are working
> b)probes are working - which means a scan is happening.
> c)beacons and probes are working
> d)beacons and probes are not working. The vista machine saw a data
> packet, and sent a probe request, which your machine answered.
>
>>>>>>>>>
>
> My colleague here did some work with a slightly older kernel.
>
> He found that the association process worked sometimes - not always.
> There was a time dependency - both nodes have to go through this at the same
> time.
>
> Further - scans - it seems that nodes have to scan to find things. Old
> information in the mac80211 has to be expired and removed.
>
> A scan should not be necessary - if both ends are put on channel 2462- a
> scan should not be required - there is no channel changing. Yet - my
> colleague noted a scan helped nodes to associate.
>
> I would say this:::
> I cannot deduce what is happening from the initial posters report. I need a
> packet dump of the beacons/probes and all the other packets on the air.
>
> Cheers,
> Derek.
> --
> Derek Smithies Ph.D.
> IndraNet Technologies Ltd.
> ph +64 3 365 6485
> Web: http://www.indranet-technologies.com/
>
> "How did you make it work??"
> "Oh, the usual, get everything right".
>
^ permalink raw reply
* Re: [RFC] cfg80211: fix race between sysfs and cfg80211
From: Maxime Bizon @ 2010-07-20 23:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1279394982.3931.0.camel@jlt3.sipsolutions.net>
On Sat, 2010-07-17 at 21:29 +0200, Johannes Berg wrote:
Hi Johannes,
> Maybe we should hold the mutex around the debugfs stuff as well? Then
> tools could even access that race-free, and we can simplify the code by
> having an "out_unlock" label.
Any comment on the last patch I sent ?
Thanks !
--
Maxime
^ permalink raw reply
* Re: [ath5k-devel] ath5k Ad Hoc Association
From: Bob Copeland @ 2010-07-20 23:16 UTC (permalink / raw)
To: Derek Smithies; +Cc: Jonathan Guerin, Ath5k Devel issues., linux-wireless
In-Reply-To: <alpine.DEB.2.00.1007211002410.21858@kauri.acheron.indranet.co.nz>
On Wed, Jul 21, 2010 at 10:11:14AM +1200, Derek Smithies wrote:
>> Then on the other machine (Vista) I just located 'myibss' (so beacons
>> are working) and selected it, then successfully pinged 192.168.10.1.
> Wrong.
> If the other machine located your node, then one of the four statements
> is true:
Ok, fine, I just set up a monitor interface and I see beacons
(and probe responses) for my setup on that channel.
> A scan should not be necessary - if both ends are put on channel 2462- a
> scan should not be required - there is no channel changing. Yet - my
> colleague noted a scan helped nodes to associate.
There was a bug in older kernels that wouldn't fully configure the
beacons until after a reset, which scanning happens to do. It's
possible something similar is going on.
Also, scanning might open a previously passive channel because we might
get lucky and receive a beacon from another node on it. The 'iw phy
phy0 info' can show this kind of thing.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [ath5k-devel] ath5k Ad Hoc Association
From: Jonathan Guerin @ 2010-07-21 0:00 UTC (permalink / raw)
To: Bob Copeland; +Cc: Derek Smithies, Ath5k Devel issues., linux-wireless
In-Reply-To: <20100720231629.GC7049@hash.localnet>
Do you remember what version kernel this was fixed in? I can update
the nodes to at least this version and see if it helps...
On my setup, I am not seeing ANY probes from the ath5k nodes at all.
If I start a MadWifi node and the ath5k nodes join it, then bring down
the MadWifi node, the ath5k nodes ALL start beaconing...
Cheers,
--
Jonathan Guerin
On Wed, Jul 21, 2010 at 9:16 AM, Bob Copeland <me@bobcopeland.com> wrote:
> On Wed, Jul 21, 2010 at 10:11:14AM +1200, Derek Smithies wrote:
>>> Then on the other machine (Vista) I just located 'myibss' (so beacons
>>> are working) and selected it, then successfully pinged 192.168.10.1.
>> Wrong.
>> If the other machine located your node, then one of the four statements
>> is true:
>
> Ok, fine, I just set up a monitor interface and I see beacons
> (and probe responses) for my setup on that channel.
>
>> A scan should not be necessary - if both ends are put on channel 2462- a
>> scan should not be required - there is no channel changing. Yet - my
>> colleague noted a scan helped nodes to associate.
>
> There was a bug in older kernels that wouldn't fully configure the
> beacons until after a reset, which scanning happens to do. It's
> possible something similar is going on.
>
> Also, scanning might open a previously passive channel because we might
> get lucky and receive a beacon from another node on it. The 'iw phy
> phy0 info' can show this kind of thing.
>
> --
> Bob Copeland %% www.bobcopeland.com
>
>
^ permalink raw reply
* Re: [PATCH/RFC 3/3] ath5k: trace resets
From: Bruno Randolf @ 2010-07-21 1:04 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, ath5k-devel, johannes
In-Reply-To: <20100720145200.GB7049@hash.localnet>
On Tue July 20 2010 23:52:00 Bob Copeland wrote:
> > again, here my same concerns: printing the reasons for resets is
> > something which is useful on embedded boards and production setups which
> > can't have tracing enabled. which is why i want to object against this
> > change!
>
> What Johannes said wrt performance: during tracing, only the binary
> representations of the data are written to the trace ring buffer, so
> unlike the current debug code, we aren't doing printk formatting until
> the trace buffer is read. You can save the raw binary data from the
> trace and do formatting on another machine.
that's true, but try to run a kernel with tracing compiled in and NOT runtime
enabled on a small embedded board (soekris net48xx for example) and you'll see
the difference. without tracing you can get 22Mbps, with tracing max 15Mbps
UDP thruput. that means you cannot run a kernel with tracing enabled on a
production system, which also means you cannot log the reasons for a reset
there any more. and most of the problems we what to trace (e.g. stuck queue)
happen only after days or weeks of operation in production environments...
> Another advantage is better granularity: if you only care about watching
> tx on the cab queue, you can dynamically filter based on the tracepoint
> arguments, something like:
>
> # echo "qnum == 6" > /debug/tracing/events/ath5k/ath5k_tx/filter
>
> With the debug printks, you have to hack the driver or grep and hope
> the printk buffer didn't overflow and spill what you were looking for.
no doubt, i can see the advantages...
so let's go ahead with tracing, since we can always build less performant
tracing kernels when we want to track down problems.
bruno
^ permalink raw reply
* Re: [ath5k-devel] [PATCH/RFC 3/3] ath5k: trace resets
From: Luis R. Rodriguez @ 2010-07-21 1:12 UTC (permalink / raw)
To: Bruno Randolf
Cc: Bob Copeland, johannes@sipsolutions.net,
ath5k-devel@lists.ath5k.org, linux-wireless@vger.kernel.org
In-Reply-To: <201007211004.59372.br1@einfach.org>
On Tue, Jul 20, 2010 at 06:04:59PM -0700, Bruno Randolf wrote:
> On Tue July 20 2010 23:52:00 Bob Copeland wrote:
> > > again, here my same concerns: printing the reasons for resets is
> > > something which is useful on embedded boards and production setups which
> > > can't have tracing enabled. which is why i want to object against this
> > > change!
> >
> > What Johannes said wrt performance: during tracing, only the binary
> > representations of the data are written to the trace ring buffer, so
> > unlike the current debug code, we aren't doing printk formatting until
> > the trace buffer is read. You can save the raw binary data from the
> > trace and do formatting on another machine.
>
> that's true, but try to run a kernel with tracing compiled in and NOT runtime
> enabled on a small embedded board (soekris net48xx for example) and you'll see
> the difference. without tracing you can get 22Mbps, with tracing max 15Mbps
> UDP thruput. that means you cannot run a kernel with tracing enabled on a
> production system, which also means you cannot log the reasons for a reset
> there any more. and most of the problems we what to trace (e.g. stuck queue)
> happen only after days or weeks of operation in production environments...
>
> > Another advantage is better granularity: if you only care about watching
> > tx on the cab queue, you can dynamically filter based on the tracepoint
> > arguments, something like:
> >
> > # echo "qnum == 6" > /debug/tracing/events/ath5k/ath5k_tx/filter
> >
> > With the debug printks, you have to hack the driver or grep and hope
> > the printk buffer didn't overflow and spill what you were looking for.
>
> no doubt, i can see the advantages...
>
> so let's go ahead with tracing, since we can always build less performant
> tracing kernels when we want to track down problems.
FWIW I intend on adding tracing as well to ath9k_hw on the hw-ops.
Hence the hw-ops.h file, etc.
Luis
^ permalink raw reply
* Re: ath5k Ad Hoc Association
From: Jonathan Guerin @ 2010-07-21 1:16 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <20100720112041.GA7049@hash.localnet>
On Tue, Jul 20, 2010 at 9:20 PM, Bob Copeland <me@bobcopeland.com> wrote:
>> Yes, I've checked the channel (36, 5180) allows beaconing. I've tried
>> the commands you mentioned, but no luck. If I monitor the interface
>> from another station, the ath5k drive never appears to beacon.
>
> What does "iw phy phy0 info" show?
iw phy phy0 info
Wiphy phy0
Band 1:
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (disabled)
* 2472 MHz [13] (disabled)
* 2484 MHz [14] (disabled)
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Band 2:
Frequencies:
* 5180 MHz [36] (17.0 dBm)
* 5200 MHz [40] (17.0 dBm)
* 5220 MHz [44] (17.0 dBm)
* 5240 MHz [48] (17.0 dBm)
* 5260 MHz [52] (20.0 dBm) (passive scanning,
no IBSS, radar detection)
* 5280 MHz [56] (20.0 dBm) (passive scanning,
no IBSS, radar detection)
* 5300 MHz [60] (20.0 dBm) (passive scanning,
no IBSS, radar detection)
* 5320 MHz [64] (20.0 dBm) (passive scanning,
no IBSS, radar detection)
* 5500 MHz [100] (disabled)
* 5520 MHz [104] (disabled)
* 5540 MHz [108] (disabled)
* 5560 MHz [112] (disabled)
* 5580 MHz [116] (disabled)
* 5600 MHz [120] (disabled)
* 5620 MHz [124] (disabled)
* 5640 MHz [128] (disabled)
* 5660 MHz [132] (disabled)
* 5680 MHz [136] (disabled)
* 5700 MHz [140] (disabled)
* 5745 MHz [149] (30.0 dBm)
* 5765 MHz [153] (30.0 dBm)
* 5785 MHz [157] (30.0 dBm)
* 5805 MHz [161] (30.0 dBm)
* 5825 MHz [165] (30.0 dBm)
Bitrates (non-HT):
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
max # scan SSIDs: 4
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
Supported commands:
* new_interface
* set_interface
* new_key
* new_beacon
* new_station
* new_mpath
* set_mesh_params
* set_bss
* authenticate
* associate
* deauthenticate
* disassociate
* join_ibss
* set_wiphy_netns
* connect
* disconnect
iw reg get
country AU:
(2402 - 2482 @ 40), (N/A, 20)
(5170 - 5250 @ 40), (3, 23)
(5250 - 5330 @ 40), (3, 23), DFS
(5735 - 5835 @ 40), (3, 30)
Cheers,
Jonathan
^ permalink raw reply
* Re: [PATCH/RFC 3/3] ath5k: trace resets
From: Bob Copeland @ 2010-07-21 3:41 UTC (permalink / raw)
To: Bruno Randolf; +Cc: linux-wireless, ath5k-devel, johannes
In-Reply-To: <201007211004.59372.br1@einfach.org>
On Wed, Jul 21, 2010 at 10:04:59AM +0900, Bruno Randolf wrote:
> the difference. without tracing you can get 22Mbps, with tracing max 15Mbps
> UDP thruput.
If so, and it's not an i-cache effect, then something is wrong with
the tracing subsystem. It's supposed to compile to something like
if (tracing) {
trace_callback();
}
That is exactly what we have with the debug infrastructure, but
the debug stuff is theoretically a bit worse since it tests for
tracing inside the callback.
Oh well, I guess I need to get my hands on one of these boards.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH] rtl8180: improve signal reporting for rtl8185 hardware
From: Pauli Nieminen @ 2010-07-21 5:08 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <1279572443-14361-1-git-send-email-linville@tuxdriver.com>
On Mon, Jul 19, 2010 at 11:47 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> The existing code seemed to be somewhat based on the datasheet, but
> varied substantially from the vendor-provided driver. This mirrors the
> handling of the rtl8185 case from that driver, but still neglects the
> specifics for the rtl8180 hardware. Those details are a bit muddled...
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> drivers/net/wireless/rtl818x/rtl8180_dev.c | 11 ++++++++---
> 1 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/rtl818x/rtl8180_dev.c b/drivers/net/wireless/rtl818x/rtl8180_dev.c
> index 4270502..90046dc 100644
> --- a/drivers/net/wireless/rtl818x/rtl8180_dev.c
> +++ b/drivers/net/wireless/rtl818x/rtl8180_dev.c
> @@ -103,6 +103,7 @@ static void rtl8180_handle_rx(struct ieee80211_hw *dev)
> {
> struct rtl8180_priv *priv = dev->priv;
> unsigned int count = 32;
> + u8 signal;
>
> while (count--) {
> struct rtl8180_rx_desc *entry = &priv->rx_ring[priv->rx_idx];
> @@ -130,10 +131,14 @@ static void rtl8180_handle_rx(struct ieee80211_hw *dev)
> skb_put(skb, flags & 0xFFF);
>
> rx_status.antenna = (flags2 >> 15) & 1;
> - /* TODO: improve signal/rssi reporting */
> - rx_status.signal = (flags2 >> 8) & 0x7F;
> - /* XXX: is this correct? */
> rx_status.rate_idx = (flags >> 20) & 0xF;
> + /* TODO: improve signal/rssi reporting for !rtl8185 */
> + signal = (flags2 >> 17) & 0x7F;
> + if (rx_status.rate_idx > 3)
> + signal = clamp_t(u8, signal, 25, 90);
> + else
> + signal = clamp_t(u8, signal, 30, 95);
> + rx_status.signal = signal;
> rx_status.freq = dev->conf.channel->center_freq;
> rx_status.band = dev->conf.channel->band;
> rx_status.mactime = le64_to_cpu(entry->tsft);
> --
> 1.7.1.1
>
>
I tested this version of patch. Patch didn't apply cleanly for some
reason even tough when I mnauly typed it diff looks same.
The patch lets me use wifi but signal value is not yet correct. When I
have closed AP only 50 cm away from my laptop.
sudo iwlist wlan0 scan | grep Signal
Quality=46/100 Signal level=46/100
Quality=46/100 Signal level=46/100
Quality=46/100 Signal level=46/100
Quality=46/100 Signal level=46/100
Quality=46/100 Signal level=46/100
Quality=46/100 Signal level=46/100
Quality=46/100 Signal level=46/100
Quality=46/100 Signal level=46/100
Quality=46/100 Signal level=46/100
Quality=46/100 Signal level=46/100
Quality=46/100 Signal level=46/100
Quality=46/100 Signal level=46/100
Quality=46/100 Signal level=46/100
Quality=46/100 Signal level=46/100
Quality=46/100 Signal level=46/100
Quality=46/100 Signal level=46/100
^ permalink raw reply
* Re: [PATCH/RFC 3/3] ath5k: trace resets
From: Bruno Randolf @ 2010-07-21 5:17 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, ath5k-devel, johannes
In-Reply-To: <20100721034150.GA16632@hash.localnet>
On Wed July 21 2010 12:41:50 Bob Copeland wrote:
> On Wed, Jul 21, 2010 at 10:04:59AM +0900, Bruno Randolf wrote:
> > the difference. without tracing you can get 22Mbps, with tracing max
> > 15Mbps UDP thruput.
>
> If so, and it's not an i-cache effect, then something is wrong with
> the tracing subsystem. It's supposed to compile to something like
>
> if (tracing) {
> trace_callback();
> }
>
> That is exactly what we have with the debug infrastructure, but
> the debug stuff is theoretically a bit worse since it tests for
> tracing inside the callback.
but that's for all tracepoints all over the kernel... i think it's natural
that this takes some CPU time. note that on these boards even the 22Mbps are
limited by the CPU processing power.
> Oh well, I guess I need to get my hands on one of these boards.
could be helpful, allthough i have to admit that these boards are getting old
and more current embedded boards usually do have faster CPUs...
bruno
^ permalink raw reply
* Re: [PATCH/RFC 3/3] ath5k: trace resets
From: Ben Gamari @ 2010-07-21 5:46 UTC (permalink / raw)
To: Bruno Randolf, Bob Copeland; +Cc: linux-wireless, ath5k-devel, johannes
In-Reply-To: <201007211417.23512.br1@einfach.org>
On Wed, 21 Jul 2010 14:17:23 +0900, Bruno Randolf <br1@einfach.org> wrote:
> but that's for all tracepoints all over the kernel... i think it's natural
> that this takes some CPU time. note that on these boards even the 22Mbps are
> limited by the CPU processing power.
>
The key word here is some. The numbers that you pointed out suggest that
the effect here is quite large. I find it hard to believe that something
isn't going wrong here. A single branch instruction really shouldn't be
this onerous unless it's in a fast path, in which case it should
probably be a compile-time option. What is the difference in image size
between kernels with and without tracing?
- Ben
^ permalink raw reply
* Re: ath5k Ad Hoc Association
From: Jonathan Guerin @ 2010-07-21 5:47 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <AANLkTinr0RbmNLgM_pRsa0WrSqQ_Mr9aQhKGuK63xIJ6@mail.gmail.com>
TXkgYXBvbG9naWVzIGFsbCwgSSBoYWQgdGhlIGFudGVubmEgcGx1Z2dlZCBpbiB0byB0aGUgZmly
c3QgY29ubmVjdG9yLgphdGg1ayBhcHBlYXJzIHRvIG9ubHkgdXNlIHRoZSBzZWNvbmQuIFBsdWdn
aW5nIGluIHRvIHRoZSBzZWNvbmQgb25lCmZpeGVzIG1vc3QgcHJvYmxlbXMuIEkgZGlkbid0IGdl
dCBhIGNoYW5jZSB0byBzZWUgaWYgdGhlIGF0aDVrIHdheSBvZgpjcmVhdGluZyBhbmQgam9pbmlu
ZyBhbiBpYnNzIHdvcmtzIG5vdywgYnV0IHdlIGNhbiBub3cgZ2V0IGZ1bGwKdGhyb3VnaHB1dCBp
biBhZGhvYyBtb2RlLiBJIHdpbGwgdHJ5IHRoZSBpYnNzIGpvaW5pbmcgd2l0aG91dCBNYWRXaWZp
CnRvbW9ycm93LgoKVGhhbmtzIGZvciBhbGwgdGhlIGhlbHAuCgotLQpKb25hdGhhbiBHdWVyaW4K
CgoKT24gV2VkLCBKdWwgMjEsIDIwMTAgYXQgMTE6MTYgQU0sIEpvbmF0aGFuIEd1ZXJpbiA8am9u
YXRoYW5AZ3VlcmluLmlkLmF1PiB3cm90ZToKPiBPbiBUdWUsIEp1bCAyMCwgMjAxMCBhdCA5OjIw
IFBNLCBCb2IgQ29wZWxhbmQgPG1lQGJvYmNvcGVsYW5kLmNvbT4gd3JvdGU6Cj4+PiBZZXMsIEkn
dmUgY2hlY2tlZCB0aGUgY2hhbm5lbCAoMzYsIDUxODApIGFsbG93cyBiZWFjb25pbmcuIEkndmUg
dHJpZWQKPj4+IHRoZSBjb21tYW5kcyB5b3UgbWVudGlvbmVkLCBidXQgbm8gbHVjay4gSWYgSSBt
b25pdG9yIHRoZSBpbnRlcmZhY2UKPj4+IGZyb20gYW5vdGhlciBzdGF0aW9uLCB0aGUgYXRoNWsg
ZHJpdmUgbmV2ZXIgYXBwZWFycyB0byBiZWFjb24uCj4+Cj4+IFdoYXQgZG9lcyAiaXcgcGh5IHBo
eTAgaW5mbyIgc2hvdz8KPgo+IGl3IHBoeSBwaHkwIGluZm8KPiBXaXBoeSBwaHkwCj4goCCgIKAg
oEJhbmQgMToKPiCgIKAgoCCgIKAgoCCgIKBGcmVxdWVuY2llczoKPiCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCogMjQxMiBNSHogWzFdICgyMC4wIGRCbSkKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCogMjQxNyBNSHogWzJdICgyMC4wIGRCbSkKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCogMjQy
MiBNSHogWzNdICgyMC4wIGRCbSkKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCogMjQyNyBNSHog
WzRdICgyMC4wIGRCbSkKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCogMjQzMiBNSHogWzVdICgy
MC4wIGRCbSkKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCogMjQzNyBNSHogWzZdICgyMC4wIGRC
bSkKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCogMjQ0MiBNSHogWzddICgyMC4wIGRCbSkKPiCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCogMjQ0NyBNSHogWzhdICgyMC4wIGRCbSkKPiCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCogMjQ1MiBNSHogWzldICgyMC4wIGRCbSkKPiCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCogMjQ1NyBNSHogWzEwXSAoMjAuMCBkQm0pCj4goCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAqIDI0NjIgTUh6IFsxMV0gKDIwLjAgZEJtKQo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
KiAyNDY3IE1IeiBbMTJdIChkaXNhYmxlZCkKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCogMjQ3
MiBNSHogWzEzXSAoZGlzYWJsZWQpCj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAqIDI0ODQgTUh6
IFsxNF0gKGRpc2FibGVkKQo+IKAgoCCgIKAgoCCgIKAgoEJpdHJhdGVzIChub24tSFQpOgo+IKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgKiAxLjAgTWJwcwo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
KiAyLjAgTWJwcyAoc2hvcnQgcHJlYW1ibGUgc3VwcG9ydGVkKQo+IKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgKiA1LjUgTWJwcyAoc2hvcnQgcHJlYW1ibGUgc3VwcG9ydGVkKQo+IKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgKiAxMS4wIE1icHMgKHNob3J0IHByZWFtYmxlIHN1cHBvcnRlZCkKPiCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCogNi4wIE1icHMKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCog
OS4wIE1icHMKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCogMTIuMCBNYnBzCj4goCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAqIDE4LjAgTWJwcwo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgKiAyNC4w
IE1icHMKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCogMzYuMCBNYnBzCj4goCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAqIDQ4LjAgTWJwcwo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgKiA1NC4wIE1i
cHMKPiCgIKAgoCCgQmFuZCAyOgo+IKAgoCCgIKAgoCCgIKAgoEZyZXF1ZW5jaWVzOgo+IKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgKiA1MTgwIE1IeiBbMzZdICgxNy4wIGRCbSkKPiCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCogNTIwMCBNSHogWzQwXSAoMTcuMCBkQm0pCj4goCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAqIDUyMjAgTUh6IFs0NF0gKDE3LjAgZEJtKQo+IKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgKiA1MjQwIE1IeiBbNDhdICgxNy4wIGRCbSkKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCog
NTI2MCBNSHogWzUyXSAoMjAuMCBkQm0pIChwYXNzaXZlIHNjYW5uaW5nLAo+IG5vIElCU1MsIHJh
ZGFyIGRldGVjdGlvbikKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCogNTI4MCBNSHogWzU2XSAo
MjAuMCBkQm0pIChwYXNzaXZlIHNjYW5uaW5nLAo+IG5vIElCU1MsIHJhZGFyIGRldGVjdGlvbikK
PiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCogNTMwMCBNSHogWzYwXSAoMjAuMCBkQm0pIChwYXNz
aXZlIHNjYW5uaW5nLAo+IG5vIElCU1MsIHJhZGFyIGRldGVjdGlvbikKPiCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCogNTMyMCBNSHogWzY0XSAoMjAuMCBkQm0pIChwYXNzaXZlIHNjYW5uaW5nLAo+
IG5vIElCU1MsIHJhZGFyIGRldGVjdGlvbikKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCogNTUw
MCBNSHogWzEwMF0gKGRpc2FibGVkKQo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgKiA1NTIwIE1I
eiBbMTA0XSAoZGlzYWJsZWQpCj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAqIDU1NDAgTUh6IFsx
MDhdIChkaXNhYmxlZCkKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCogNTU2MCBNSHogWzExMl0g
KGRpc2FibGVkKQo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgKiA1NTgwIE1IeiBbMTE2XSAoZGlz
YWJsZWQpCj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAqIDU2MDAgTUh6IFsxMjBdIChkaXNhYmxl
ZCkKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCogNTYyMCBNSHogWzEyNF0gKGRpc2FibGVkKQo+
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgKiA1NjQwIE1IeiBbMTI4XSAoZGlzYWJsZWQpCj4goCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAqIDU2NjAgTUh6IFsxMzJdIChkaXNhYmxlZCkKPiCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCogNTY4MCBNSHogWzEzNl0gKGRpc2FibGVkKQo+IKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgKiA1NzAwIE1IeiBbMTQwXSAoZGlzYWJsZWQpCj4goCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAqIDU3NDUgTUh6IFsxNDldICgzMC4wIGRCbSkKPiCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCogNTc2NSBNSHogWzE1M10gKDMwLjAgZEJtKQo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
KiA1Nzg1IE1IeiBbMTU3XSAoMzAuMCBkQm0pCj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAqIDU4
MDUgTUh6IFsxNjFdICgzMC4wIGRCbSkKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCogNTgyNSBN
SHogWzE2NV0gKDMwLjAgZEJtKQo+IKAgoCCgIKAgoCCgIKAgoEJpdHJhdGVzIChub24tSFQpOgo+
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgKiA2LjAgTWJwcwo+IKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgKiA5LjAgTWJwcwo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgKiAxMi4wIE1icHMKPiCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCogMTguMCBNYnBzCj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAq
IDI0LjAgTWJwcwo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgKiAzNi4wIE1icHMKPiCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCogNDguMCBNYnBzCj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAqIDU0
LjAgTWJwcwo+IKAgoCCgIKBtYXggIyBzY2FuIFNTSURzOiA0Cj4goCCgIKAgoFN1cHBvcnRlZCBp
bnRlcmZhY2UgbW9kZXM6Cj4goCCgIKAgoCCgIKAgoCCgICogSUJTUwo+IKAgoCCgIKAgoCCgIKAg
oCAqIG1hbmFnZWQKPiCgIKAgoCCgIKAgoCCgIKAgKiBBUAo+IKAgoCCgIKAgoCCgIKAgoCAqIEFQ
L1ZMQU4KPiCgIKAgoCCgIKAgoCCgIKAgKiBtb25pdG9yCj4goCCgIKAgoCCgIKAgoCCgICogbWVz
aCBwb2ludAo+IKAgoCCgIKBTdXBwb3J0ZWQgY29tbWFuZHM6Cj4goCCgIKAgoCCgIKAgoCCgICog
bmV3X2ludGVyZmFjZQo+IKAgoCCgIKAgoCCgIKAgoCAqIHNldF9pbnRlcmZhY2UKPiCgIKAgoCCg
IKAgoCCgIKAgKiBuZXdfa2V5Cj4goCCgIKAgoCCgIKAgoCCgICogbmV3X2JlYWNvbgo+IKAgoCCg
IKAgoCCgIKAgoCAqIG5ld19zdGF0aW9uCj4goCCgIKAgoCCgIKAgoCCgICogbmV3X21wYXRoCj4g
oCCgIKAgoCCgIKAgoCCgICogc2V0X21lc2hfcGFyYW1zCj4goCCgIKAgoCCgIKAgoCCgICogc2V0
X2Jzcwo+IKAgoCCgIKAgoCCgIKAgoCAqIGF1dGhlbnRpY2F0ZQo+IKAgoCCgIKAgoCCgIKAgoCAq
IGFzc29jaWF0ZQo+IKAgoCCgIKAgoCCgIKAgoCAqIGRlYXV0aGVudGljYXRlCj4goCCgIKAgoCCg
IKAgoCCgICogZGlzYXNzb2NpYXRlCj4goCCgIKAgoCCgIKAgoCCgICogam9pbl9pYnNzCj4goCCg
IKAgoCCgIKAgoCCgICogc2V0X3dpcGh5X25ldG5zCj4goCCgIKAgoCCgIKAgoCCgICogY29ubmVj
dAo+IKAgoCCgIKAgoCCgIKAgoCAqIGRpc2Nvbm5lY3QKPgo+IKBpdyByZWcgZ2V0Cj4gY291bnRy
eSBBVToKPiCgIKAgoCCgKDI0MDIgLSAyNDgyIEAgNDApLCAoTi9BLCAyMCkKPiCgIKAgoCCgKDUx
NzAgLSA1MjUwIEAgNDApLCAoMywgMjMpCj4goCCgIKAgoCg1MjUwIC0gNTMzMCBAIDQwKSwgKDMs
IDIzKSwgREZTCj4goCCgIKAgoCg1NzM1IC0gNTgzNSBAIDQwKSwgKDMsIDMwKQo+Cj4gQ2hlZXJz
LAo+Cj4gSm9uYXRoYW4KPgo=
^ permalink raw reply
* Re: [PATCH] iw: Add support for setting transmit power level
From: Luciano Coelho @ 2010-07-21 7:04 UTC (permalink / raw)
To: johannes
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
Oikarinen Juuso (Nokia-MS/Tampere)
In-Reply-To: <1277284377-11048-1-git-send-email-juuso.oikarinen@nokia.com>
Hi Johannes,
Just trying to make sure you have seen this patch (you haven't applied
it yet). Juuso sent it to John instead of you, so you may have missed
it. ;)
On Wed, 2010-06-23 at 11:12 +0200, Oikarinen Juuso (Nokia-MS/Tampere)
wrote:
> Add a "set txpower" option to specify the current transmit power level. Modes
> supported are automatic, fixed and limited, and the limit may be specified
> in signed mBm units.
>
> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> ---
> nl80211.h | 22 ++++++++++++++++++++++
> phy.c | 50 +++++++++++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 71 insertions(+), 1 deletions(-)
>
> diff --git a/nl80211.h b/nl80211.h
> index 64fb32b..2c87016 100644
> --- a/nl80211.h
> +++ b/nl80211.h
> @@ -725,6 +725,12 @@ enum nl80211_commands {
> * @NL80211_ATTR_AP_ISOLATE: (AP mode) Do not forward traffic between stations
> * connected to this BSS.
> *
> + * @NL80211_ATTR_WIPHY_TX_POWER_SETTING: Transmit power setting type. See
> + * &enum nl80211_tx_power_setting for possible values.
> + * @NL80211_ATTR_WIPHY_TX_POWER_LEVEL: Transmit power level in signed mBm units.
> + * This is used in association with @NL80211_ATTR_WIPHY_TX_POWER_SETTING
> + * for non-automatic settings.
> + *
> * @NL80211_ATTR_MAX: highest attribute number currently defined
> * @__NL80211_ATTR_AFTER_LAST: internal use
> */
> @@ -882,6 +888,9 @@ enum nl80211_attrs {
>
> NL80211_ATTR_AP_ISOLATE,
>
> + NL80211_ATTR_WIPHY_TX_POWER_SETTING,
> + NL80211_ATTR_WIPHY_TX_POWER_LEVEL,
> +
> /* add attributes here, update the policy in nl80211.c */
>
> __NL80211_ATTR_AFTER_LAST,
> @@ -1659,4 +1668,17 @@ enum nl80211_cqm_rssi_threshold_event {
> NL80211_CQM_RSSI_THRESHOLD_EVENT_HIGH,
> };
>
> +
> +/**
> + * enum nl80211_tx_power_setting - TX power adjustment
> + * @NL80211_TX_POWER_AUTOMATIC: automatically determine transmit power
> + * @NL80211_TX_POWER_LIMITED: limit TX power by the mBm parameter
> + * @NL80211_TX_POWER_FIXED: fix TX power to the mBm parameter
> + */
> +enum nl80211_tx_power_setting {
> + NL80211_TX_POWER_AUTOMATIC,
> + NL80211_TX_POWER_LIMITED,
> + NL80211_TX_POWER_FIXED,
> +};
> +
> #endif /* __LINUX_NL80211_H */
> diff --git a/phy.c b/phy.c
> index 8f8d757..f042dc2 100644
> --- a/phy.c
> +++ b/phy.c
> @@ -175,7 +175,7 @@ static int handle_netns(struct nl80211_state *state,
> return 1;
>
> NLA_PUT_U32(msg, NL80211_ATTR_PID,
> - strtoul(argv[0], &end, 10));
> + strtoul(argv[0], &end, 10));
>
> if (*end != '\0')
> return 1;
> @@ -258,3 +258,51 @@ COMMAND(set, distance, "<distance>",
> NL80211_CMD_SET_WIPHY, 0, CIB_PHY, handle_distance,
> "Set appropriate coverage class for given link distance in meters.\n"
> "Valid values: 0 - 114750");
> +
> +static int handle_txpower(struct nl80211_state *state,
> + struct nl_cb *cb,
> + struct nl_msg *msg,
> + int argc, char **argv)
> +{
> + enum nl80211_tx_power_setting type;
> + int ret = -ENOSPC;
> + int mbm;
> +
> + /* get the required args */
> + if (argc != 1 && argc != 2)
> + return 1;
> +
> + if (!strcmp(argv[0], "auto"))
> + type = NL80211_TX_POWER_AUTOMATIC;
> + else if (!strcmp(argv[0], "fixed"))
> + type = NL80211_TX_POWER_FIXED;
> + else if (!strcmp(argv[0], "limit"))
> + type = NL80211_TX_POWER_LIMITED;
> + else {
> + printf("Invalid parameter: %s\n", argv[0]);
> + return 2;
> + }
> +
> + NLA_PUT_U32(msg, NL80211_ATTR_WIPHY_TX_POWER_SETTING, type);
> +
> + if (type != NL80211_TX_POWER_AUTOMATIC) {
> + if (argc != 2) {
> + printf("Missing TX power level argument.\n");
> + return 2;
> + }
> +
> + mbm = atoi(argv[1]);
> + NLA_PUT_U32(msg, NL80211_ATTR_WIPHY_TX_POWER_LEVEL, mbm);
> + }
> +
> + ret = 0;
> +
> + nla_put_failure:
> + return ret;
> +}
> +COMMAND(set, txpower, "<auto|fixed|limit> [<tx power in mBm>]",
> + NL80211_CMD_SET_WIPHY, 0, CIB_PHY, handle_txpower,
> + "Specify transmit power level and setting type.");
> +COMMAND(set, txpower, "<auto|fixed|limit> [<tx power in mBm>]",
> + NL80211_CMD_SET_WIPHY, 0, CIB_NETDEV, handle_txpower,
> + "Specify transmit power level and setting type.");
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH/RFC 3/3] ath5k: trace resets
From: Johannes Berg @ 2010-07-21 7:53 UTC (permalink / raw)
To: Bruno Randolf; +Cc: Bob Copeland, linux-wireless, ath5k-devel
In-Reply-To: <201007211417.23512.br1@einfach.org>
On Wed, 2010-07-21 at 14:17 +0900, Bruno Randolf wrote:
> but that's for all tracepoints all over the kernel...
Well you definitely don't want to enable like function graph tracing,
that's expected to be more expensive unless you also have the callsite
patching version of it. But _just_ enabling tracing + the ath5k tracer
definitely will not have this effect.
johannes
^ permalink raw reply
* [PATCH] mac80211: refuse shared key auth when WEP is unavailable
From: Johannes Berg @ 2010-07-21 8:09 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20100720185643.GB3468@tuxdriver.com>
From: Johannes Berg <johannes.berg@intel.com>
When WEP is not available, we should reject shared
key authentication because it could never succeed.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/mlme.c | 2 ++
1 file changed, 2 insertions(+)
--- wireless-testing.orig/net/mac80211/mlme.c 2010-07-21 10:07:20.000000000 +0200
+++ wireless-testing/net/mac80211/mlme.c 2010-07-21 10:07:20.000000000 +0200
@@ -2030,6 +2030,8 @@ int ieee80211_mgd_auth(struct ieee80211_
auth_alg = WLAN_AUTH_OPEN;
break;
case NL80211_AUTHTYPE_SHARED_KEY:
+ if (IS_ERR(sdata->local->wep_tx_tfm))
+ return -EOPNOTSUPP;
auth_alg = WLAN_AUTH_SHARED_KEY;
break;
case NL80211_AUTHTYPE_FT:
^ permalink raw reply
* Re: [PATCH] iw: Add support for setting transmit power level
From: Johannes Berg @ 2010-07-21 8:24 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless
In-Reply-To: <1277284377-11048-1-git-send-email-juuso.oikarinen@nokia.com>
On Wed, 2010-06-23 at 12:12 +0300, Juuso Oikarinen wrote:
> Add a "set txpower" option to specify the current transmit power level. Modes
> supported are automatic, fixed and limited, and the limit may be specified
> in signed mBm units.
Merged, but I fixed a few nits, please look at the new version in my git
tree.
johannes
^ permalink raw reply
* [PATCH] mac80211: fix IBSS lockdep complaint
From: Johannes Berg @ 2010-07-21 8:52 UTC (permalink / raw)
To: John Linville; +Cc: Bob Copeland, linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
Bob reported a lockdep complaint originating in
the mac80211 IBSS code due to the common work
struct patch. The reason is that the IBSS and
station mode code have different locking orders
for the cfg80211 wdev lock and the work struct
(where "locking" implies running/canceling).
Fix this by simply not canceling the work in
the IBSS code, it is not necessary since when
the REQ_RUN bit is cleared, the work will run
without effect if it runs. When the interface
is set down, it is flushed anyway, so there's
no concern about it running after memory has
been invalidated either.
This fixes
https://bugzilla.kernel.org/show_bug.cgi?id=16419
Additionally, looking into this I noticed that
there's a small window while the IBSS is torn
down in which the work may be rescheduled and
the REQ_RUN bit be set again after leave() has
cleared it when a scan finishes at exactly the
same time. Avoid that by setting the ssid_len
to zero before clearing REQ_RUN which signals
to the scan finish code that this interface is
not active.
Reported-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/ibss.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
--- wireless-testing.orig/net/mac80211/ibss.c 2010-07-20 10:25:03.000000000 +0200
+++ wireless-testing/net/mac80211/ibss.c 2010-07-20 10:27:56.000000000 +0200
@@ -943,11 +943,6 @@ int ieee80211_ibss_leave(struct ieee8021
}
}
- del_timer_sync(&sdata->u.ibss.timer);
- clear_bit(IEEE80211_IBSS_REQ_RUN, &sdata->u.ibss.request);
- cancel_work_sync(&sdata->work);
- clear_bit(IEEE80211_IBSS_REQ_RUN, &sdata->u.ibss.request);
-
sta_info_flush(sdata->local, sdata);
/* remove beacon */
@@ -964,6 +959,20 @@ int ieee80211_ibss_leave(struct ieee8021
memset(sdata->u.ibss.bssid, 0, ETH_ALEN);
sdata->u.ibss.ssid_len = 0;
+ /*
+ * ssid_len indicates active or not, so needs to be visible to
+ * everybody, especially ieee80211_ibss_notify_scan_completed,
+ * so it won't restart the timer after we remove it here.
+ */
+ mb();
+
+ del_timer_sync(&sdata->u.ibss.timer);
+ clear_bit(IEEE80211_IBSS_REQ_RUN, &sdata->u.ibss.request);
+ /*
+ * Since the REQ_RUN bit is clear, the work won't do
+ * anything if it runs after this.
+ */
+
ieee80211_recalc_idle(sdata->local);
return 0;
^ permalink raw reply
* [PATCH] mac80211: proper IBSS locking
From: Johannes Berg @ 2010-07-21 9:30 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Johannes Berg <johannes.berg@intel.com>
IBSS has never had locking, instead relying on some
memory barriers etc. That's hard to get right, and
I think we had it wrong too until the previous patch.
Since this is not performance sensitive, it doesn't
make sense to have the maintenance overhead of that,
so add proper locking.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/ibss.c | 97 ++++++++++++++++++++++++---------------------
net/mac80211/ieee80211_i.h | 7 ---
2 files changed, 54 insertions(+), 50 deletions(-)
--- wireless-testing.orig/net/mac80211/ibss.c 2010-07-21 11:23:19.000000000 +0200
+++ wireless-testing/net/mac80211/ibss.c 2010-07-21 11:23:21.000000000 +0200
@@ -43,6 +43,8 @@ static void ieee80211_rx_mgmt_auth_ibss(
{
u16 auth_alg, auth_transaction, status_code;
+ lockdep_assert_held(&sdata->u.ibss.mtx);
+
if (len < 24 + 6)
return;
@@ -78,6 +80,8 @@ static void __ieee80211_sta_join_ibss(st
u32 bss_change;
u8 supp_rates[IEEE80211_MAX_SUPP_RATES];
+ lockdep_assert_held(&ifibss->mtx);
+
/* Reset own TSF to allow time synchronization work. */
drv_reset_tsf(local);
@@ -205,6 +209,8 @@ static void ieee80211_sta_join_ibss(stru
int i, j;
u16 beacon_int = cbss->beacon_interval;
+ lockdep_assert_held(&sdata->u.ibss.mtx);
+
if (beacon_int < 10)
beacon_int = 10;
@@ -449,6 +455,8 @@ static int ieee80211_sta_active_ibss(str
int active = 0;
struct sta_info *sta;
+ lockdep_assert_held(&sdata->u.ibss.mtx);
+
rcu_read_lock();
list_for_each_entry_rcu(sta, &local->sta_list, list) {
@@ -473,6 +481,8 @@ static void ieee80211_sta_merge_ibss(str
{
struct ieee80211_if_ibss *ifibss = &sdata->u.ibss;
+ lockdep_assert_held(&ifibss->mtx);
+
mod_timer(&ifibss->timer,
round_jiffies(jiffies + IEEE80211_IBSS_MERGE_INTERVAL));
@@ -505,6 +515,8 @@ static void ieee80211_sta_create_ibss(st
u16 capability;
int i;
+ lockdep_assert_held(&ifibss->mtx);
+
if (ifibss->fixed_bssid) {
memcpy(bssid, ifibss->bssid, ETH_ALEN);
} else {
@@ -549,6 +561,8 @@ static void ieee80211_sta_find_ibss(stru
int active_ibss;
u16 capability;
+ lockdep_assert_held(&ifibss->mtx);
+
active_ibss = ieee80211_sta_active_ibss(sdata);
#ifdef CONFIG_MAC80211_IBSS_DEBUG
printk(KERN_DEBUG "%s: sta_find_ibss (active_ibss=%d)\n",
@@ -637,6 +651,8 @@ static void ieee80211_rx_mgmt_probe_req(
struct ieee80211_mgmt *resp;
u8 *pos, *end;
+ lockdep_assert_held(&ifibss->mtx);
+
if (ifibss->state != IEEE80211_IBSS_MLME_JOINED ||
len < 24 + 2 || !ifibss->presp)
return;
@@ -740,6 +756,8 @@ void ieee80211_ibss_rx_queued_mgmt(struc
mgmt = (struct ieee80211_mgmt *) skb->data;
fc = le16_to_cpu(mgmt->frame_control);
+ mutex_lock(&sdata->u.ibss.mtx);
+
switch (fc & IEEE80211_FCTL_STYPE) {
case IEEE80211_STYPE_PROBE_REQ:
ieee80211_rx_mgmt_probe_req(sdata, mgmt, skb->len);
@@ -756,14 +774,23 @@ void ieee80211_ibss_rx_queued_mgmt(struc
ieee80211_rx_mgmt_auth_ibss(sdata, mgmt, skb->len);
break;
}
+
+ mutex_unlock(&sdata->u.ibss.mtx);
}
void ieee80211_ibss_work(struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_if_ibss *ifibss = &sdata->u.ibss;
- if (!test_and_clear_bit(IEEE80211_IBSS_REQ_RUN, &ifibss->request))
- return;
+ mutex_lock(&ifibss->mtx);
+
+ /*
+ * Work could be scheduled after scan or similar
+ * when we aren't even joined (or trying) with a
+ * network.
+ */
+ if (!ifibss->ssid_len)
+ goto out;
switch (ifibss->state) {
case IEEE80211_IBSS_MLME_SEARCH:
@@ -776,15 +803,9 @@ void ieee80211_ibss_work(struct ieee8021
WARN_ON(1);
break;
}
-}
-static void ieee80211_queue_ibss_work(struct ieee80211_sub_if_data *sdata)
-{
- struct ieee80211_if_ibss *ifibss = &sdata->u.ibss;
- struct ieee80211_local *local = sdata->local;
-
- set_bit(IEEE80211_IBSS_REQ_RUN, &ifibss->request);
- ieee80211_queue_work(&local->hw, &sdata->work);
+ out:
+ mutex_unlock(&ifibss->mtx);
}
static void ieee80211_ibss_timer(unsigned long data)
@@ -799,7 +820,7 @@ static void ieee80211_ibss_timer(unsigne
return;
}
- ieee80211_queue_ibss_work(sdata);
+ ieee80211_queue_work(&local->hw, &sdata->work);
}
#ifdef CONFIG_PM
@@ -828,6 +849,7 @@ void ieee80211_ibss_setup_sdata(struct i
setup_timer(&ifibss->timer, ieee80211_ibss_timer,
(unsigned long) sdata);
+ mutex_init(&ifibss->mtx);
}
/* scan finished notification */
@@ -841,10 +863,8 @@ void ieee80211_ibss_notify_scan_complete
continue;
if (sdata->vif.type != NL80211_IFTYPE_ADHOC)
continue;
- if (!sdata->u.ibss.ssid_len)
- continue;
sdata->u.ibss.last_scan_completed = jiffies;
- ieee80211_queue_ibss_work(sdata);
+ ieee80211_queue_work(&local->hw, &sdata->work);
}
mutex_unlock(&local->iflist_mtx);
}
@@ -854,6 +874,17 @@ int ieee80211_ibss_join(struct ieee80211
{
struct sk_buff *skb;
+ skb = dev_alloc_skb(sdata->local->hw.extra_tx_headroom +
+ 36 /* bitrates */ +
+ 34 /* SSID */ +
+ 3 /* DS params */ +
+ 4 /* IBSS params */ +
+ params->ie_len);
+ if (!skb)
+ return -ENOMEM;
+
+ mutex_lock(&sdata->u.ibss.mtx);
+
if (params->bssid) {
memcpy(sdata->u.ibss.bssid, params->bssid, ETH_ALEN);
sdata->u.ibss.fixed_bssid = true;
@@ -882,35 +913,19 @@ int ieee80211_ibss_join(struct ieee80211
sdata->u.ibss.ie_len = params->ie_len;
}
- skb = dev_alloc_skb(sdata->local->hw.extra_tx_headroom +
- 36 /* bitrates */ +
- 34 /* SSID */ +
- 3 /* DS params */ +
- 4 /* IBSS params */ +
- params->ie_len);
- if (!skb)
- return -ENOMEM;
-
sdata->u.ibss.skb = skb;
sdata->u.ibss.state = IEEE80211_IBSS_MLME_SEARCH;
sdata->u.ibss.ibss_join_req = jiffies;
memcpy(sdata->u.ibss.ssid, params->ssid, IEEE80211_MAX_SSID_LEN);
-
- /*
- * The ssid_len setting below is used to see whether
- * we are active, and we need all other settings
- * before that may get visible.
- */
- mb();
-
sdata->u.ibss.ssid_len = params->ssid_len;
ieee80211_recalc_idle(sdata->local);
- set_bit(IEEE80211_IBSS_REQ_RUN, &sdata->u.ibss.request);
ieee80211_queue_work(&sdata->local->hw, &sdata->work);
+ mutex_unlock(&sdata->u.ibss.mtx);
+
return 0;
}
@@ -921,7 +936,9 @@ int ieee80211_ibss_leave(struct ieee8021
struct ieee80211_local *local = sdata->local;
struct cfg80211_bss *cbss;
u16 capability;
- int active_ibss = 0;
+ int active_ibss;
+
+ mutex_lock(&sdata->u.ibss.mtx);
active_ibss = ieee80211_sta_active_ibss(sdata);
@@ -959,19 +976,9 @@ int ieee80211_ibss_leave(struct ieee8021
memset(sdata->u.ibss.bssid, 0, ETH_ALEN);
sdata->u.ibss.ssid_len = 0;
- /*
- * ssid_len indicates active or not, so needs to be visible to
- * everybody, especially ieee80211_ibss_notify_scan_completed,
- * so it won't restart the timer after we remove it here.
- */
- mb();
-
del_timer_sync(&sdata->u.ibss.timer);
- clear_bit(IEEE80211_IBSS_REQ_RUN, &sdata->u.ibss.request);
- /*
- * Since the REQ_RUN bit is clear, the work won't do
- * anything if it runs after this.
- */
+
+ mutex_unlock(&sdata->u.ibss.mtx);
ieee80211_recalc_idle(sdata->local);
--- wireless-testing.orig/net/mac80211/ieee80211_i.h 2010-07-21 11:22:31.000000000 +0200
+++ wireless-testing/net/mac80211/ieee80211_i.h 2010-07-21 11:23:21.000000000 +0200
@@ -377,14 +377,11 @@ struct ieee80211_if_managed {
int last_cqm_event_signal;
};
-enum ieee80211_ibss_request {
- IEEE80211_IBSS_REQ_RUN = 0,
-};
-
struct ieee80211_if_ibss {
struct timer_list timer;
- unsigned long request;
+ struct mutex mtx;
+
unsigned long last_scan_completed;
u32 basic_rates;
^ permalink raw reply
* Re: [PATCH] rtl8180: improve signal reporting for rtl8185 hardware
From: John W. Linville @ 2010-07-21 13:33 UTC (permalink / raw)
To: Pauli Nieminen; +Cc: linux-wireless
In-Reply-To: <AANLkTino_4FKtMWZU7_lKGzPUXNOtfrmlw_rmmr836eA@mail.gmail.com>
On Wed, Jul 21, 2010 at 08:08:41AM +0300, Pauli Nieminen wrote:
> On Mon, Jul 19, 2010 at 11:47 PM, John W. Linville
> <linville@tuxdriver.com> wrote:
> > The existing code seemed to be somewhat based on the datasheet, but
> > varied substantially from the vendor-provided driver. This mirrors the
> > handling of the rtl8185 case from that driver, but still neglects the
> > specifics for the rtl8180 hardware. Those details are a bit muddled...
> >
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
> > ---
> > drivers/net/wireless/rtl818x/rtl8180_dev.c | 11 ++++++++---
> > 1 files changed, 8 insertions(+), 3 deletions(-)
> I tested this version of patch. Patch didn't apply cleanly for some
> reason even tough when I mnauly typed it diff looks same.
Please try the v2 version of the patch. Some "back of the envelope"
math suggests that the v2 version of the patch will give numbers more
to your liking.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] zd1211rw: make CR_INTERRUPT cast explicit
From: John W. Linville @ 2010-07-21 15:08 UTC (permalink / raw)
To: linux-wireless; +Cc: Daniel Drake, Ulrich Kunitz, John W. Linville
CHECK drivers/net/wireless/zd1211rw/zd_usb.c
drivers/net/wireless/zd1211rw/zd_usb.c:376:24: warning: implicit cast from nocast type
The value comparison is intentional, so forcing the cast seems warranted
in order to silence the sparse warning.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/zd1211rw/zd_usb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/zd1211rw/zd_usb.c b/drivers/net/wireless/zd1211rw/zd_usb.c
index 818e148..acbf4d9 100644
--- a/drivers/net/wireless/zd1211rw/zd_usb.c
+++ b/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -373,7 +373,7 @@ static inline void handle_regs_int(struct urb *urb)
spin_lock(&intr->lock);
int_num = le16_to_cpu(*(__le16 *)(urb->transfer_buffer+2));
- if (int_num == CR_INTERRUPT) {
+ if (int_num == (u16 __force) CR_INTERRUPT) {
struct zd_mac *mac = zd_hw_mac(zd_usb_to_hw(urb->context));
memcpy(&mac->intr_buffer, urb->transfer_buffer,
USB_MAX_EP_INT_BUFFER);
--
1.7.1.1
^ permalink raw reply related
* [PATCH] cfg80211: fix race between sysfs and cfg80211
From: Maxime Bizon @ 2010-07-21 15:21 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1279394982.3931.0.camel@jlt3.sipsolutions.net>
From: Maxime Bizon <mbizon@freebox.fr>
device_add() is called before adding the phy to the cfg80211 device
list.
So if a userspace program uses sysfs uevents to detect new phy
devices, and queries nl80211 to get phy info, it can get ENODEV even
though the phy exists in sysfs.
An easy workaround is to hold the cfg80211 mutex until the phy is
present in sysfs/cfg80211/debugfs.
Signed-off-by: Maxime Bizon <mbizon@freebox.fr>
---
net/wireless/core.c | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 6ac70c1..fd164db 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -472,24 +472,22 @@ int wiphy_register(struct wiphy *wiphy)
/* check and set up bitrates */
ieee80211_set_bitrate_flags(wiphy);
+ mutex_lock(&cfg80211_mutex);
+
res = device_add(&rdev->wiphy.dev);
if (res)
- return res;
+ goto out_unlock;
res = rfkill_register(rdev->rfkill);
if (res)
goto out_rm_dev;
- mutex_lock(&cfg80211_mutex);
-
/* set up regulatory info */
wiphy_update_regulatory(wiphy, NL80211_REGDOM_SET_BY_CORE);
list_add_rcu(&rdev->list, &cfg80211_rdev_list);
cfg80211_rdev_list_generation++;
- mutex_unlock(&cfg80211_mutex);
-
/* add to debugfs */
rdev->wiphy.debugfsdir =
debugfs_create_dir(wiphy_name(&rdev->wiphy),
@@ -509,11 +507,15 @@ int wiphy_register(struct wiphy *wiphy)
}
cfg80211_debugfs_rdev_add(rdev);
+ mutex_unlock(&cfg80211_mutex);
return 0;
- out_rm_dev:
+out_rm_dev:
device_del(&rdev->wiphy.dev);
+
+out_unlock:
+ mutex_unlock(&cfg80211_mutex);
return res;
}
EXPORT_SYMBOL(wiphy_register);
--
1.7.1
--
Maxime
^ permalink raw reply related
* [PATCH] b43: silense most sparse warnings
From: John W. Linville @ 2010-07-21 15:45 UTC (permalink / raw)
To: linux-wireless
Cc: Michael Buesch, Larry Finger, Gábor Stefanik,
Rafał Miłecki, John W. Linville
CHECK drivers/net/wireless/b43/main.c
drivers/net/wireless/b43/main.c:111:5: warning: symbol 'b43_modparam_pio' was not declared. Should it be static?
CHECK drivers/net/wireless/b43/phy_g.c
drivers/net/wireless/b43/phy_g.c:975:56: warning: cast truncates bits from constant value (ffff7fff becomes 7fff)
CHECK drivers/net/wireless/b43/phy_lp.c
drivers/net/wireless/b43/phy_lp.c:2701:6: warning: symbol 'b43_lpphy_op_switch_analog' was not declared. Should it be static?
drivers/net/wireless/b43/phy_lp.c:1148:30: warning: cast truncates bits from constant value (ffff1fff becomes 1fff)
drivers/net/wireless/b43/phy_lp.c:1525:30: warning: cast truncates bits from constant value (ffff1fff becomes 1fff)
drivers/net/wireless/b43/phy_lp.c:1529:30: warning: cast truncates bits from constant value (ffff1fff becomes 1fff)
CHECK drivers/net/wireless/b43/wa.c
drivers/net/wireless/b43/wa.c:385:60: warning: cast truncates bits from constant value (ffff00ff becomes ff)
drivers/net/wireless/b43/wa.c:403:55: warning: cast truncates bits from constant value (ffff00ff becomes ff)
drivers/net/wireless/b43/wa.c:405:55: warning: cast truncates bits from constant value (ffff00ff becomes ff)
drivers/net/wireless/b43/wa.c:415:71: warning: cast truncates bits from constant value (ffff0fff becomes fff)
AFAICT, none of these amount to real bugs. But this reduces warning
spam from sparse w/o significantly affecting readability of the code (IMHO).
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/b43/main.c | 2 +-
drivers/net/wireless/b43/phy_g.c | 2 +-
drivers/net/wireless/b43/phy_lp.c | 8 ++++----
drivers/net/wireless/b43/wa.c | 8 ++++----
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index 8e24379..20631ae 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -108,7 +108,7 @@ int b43_modparam_verbose = B43_VERBOSITY_DEFAULT;
module_param_named(verbose, b43_modparam_verbose, int, 0644);
MODULE_PARM_DESC(verbose, "Log message verbosity: 0=error, 1=warn, 2=info(default), 3=debug");
-int b43_modparam_pio = B43_PIO_DEFAULT;
+static int b43_modparam_pio = B43_PIO_DEFAULT;
module_param_named(pio, b43_modparam_pio, int, 0644);
MODULE_PARM_DESC(pio, "Use PIO accesses by default: 0=DMA, 1=PIO");
diff --git a/drivers/net/wireless/b43/phy_g.c b/drivers/net/wireless/b43/phy_g.c
index 29bf34c..0dc33b6 100644
--- a/drivers/net/wireless/b43/phy_g.c
+++ b/drivers/net/wireless/b43/phy_g.c
@@ -972,7 +972,7 @@ b43_radio_interference_mitigation_enable(struct b43_wldev *dev, int mode)
b43_phy_maskset(dev, 0x04A2, 0xFFF0, 0x000B);
if (phy->rev >= 3) {
- b43_phy_mask(dev, 0x048A, (u16)~0x8000);
+ b43_phy_mask(dev, 0x048A, 0x7FFF);
b43_phy_maskset(dev, 0x0415, 0x8000, 0x36D8);
b43_phy_maskset(dev, 0x0416, 0x8000, 0x36D8);
b43_phy_maskset(dev, 0x0417, 0xFE00, 0x016D);
diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
index c6afe9d..fd50eb1 100644
--- a/drivers/net/wireless/b43/phy_lp.c
+++ b/drivers/net/wireless/b43/phy_lp.c
@@ -1145,7 +1145,7 @@ static void lpphy_write_tx_pctl_mode_to_hardware(struct b43_wldev *dev)
B43_WARN_ON(1);
}
b43_phy_maskset(dev, B43_LPPHY_TX_PWR_CTL_CMD,
- (u16)~B43_LPPHY_TX_PWR_CTL_CMD_MODE, ctl);
+ ~B43_LPPHY_TX_PWR_CTL_CMD_MODE & 0xFFFF, ctl);
}
static void lpphy_set_tx_power_control(struct b43_wldev *dev,
@@ -1522,11 +1522,11 @@ static void lpphy_tx_pctl_init_hw(struct b43_wldev *dev)
b43_phy_mask(dev, B43_LPPHY_TX_PWR_CTL_DELTAPWR_LIMIT, 0xFF);
b43_phy_write(dev, B43_LPPHY_TX_PWR_CTL_DELTAPWR_LIMIT, 0xA);
b43_phy_maskset(dev, B43_LPPHY_TX_PWR_CTL_CMD,
- (u16)~B43_LPPHY_TX_PWR_CTL_CMD_MODE,
+ ~B43_LPPHY_TX_PWR_CTL_CMD_MODE & 0xFFFF,
B43_LPPHY_TX_PWR_CTL_CMD_MODE_OFF);
b43_phy_mask(dev, B43_LPPHY_TX_PWR_CTL_NNUM, 0xF8FF);
b43_phy_maskset(dev, B43_LPPHY_TX_PWR_CTL_CMD,
- (u16)~B43_LPPHY_TX_PWR_CTL_CMD_MODE,
+ ~B43_LPPHY_TX_PWR_CTL_CMD_MODE & 0xFFFF,
B43_LPPHY_TX_PWR_CTL_CMD_MODE_SW);
if (dev->phy.rev < 2) {
@@ -2698,7 +2698,7 @@ static enum b43_txpwr_result b43_lpphy_op_recalc_txpower(struct b43_wldev *dev,
return B43_TXPWR_RES_DONE;
}
-void b43_lpphy_op_switch_analog(struct b43_wldev *dev, bool on)
+static void b43_lpphy_op_switch_analog(struct b43_wldev *dev, bool on)
{
if (on) {
b43_phy_mask(dev, B43_LPPHY_AFE_CTL_OVR, 0xfff8);
diff --git a/drivers/net/wireless/b43/wa.c b/drivers/net/wireless/b43/wa.c
index 97c7916..9a335da 100644
--- a/drivers/net/wireless/b43/wa.c
+++ b/drivers/net/wireless/b43/wa.c
@@ -382,7 +382,7 @@ static void b43_wa_altagc(struct b43_wldev *dev)
b43_ofdmtab_write16(dev, B43_OFDMTAB_AGC1, 3, 25);
}
- b43_phy_maskset(dev, B43_PHY_CCKSHIFTBITS_WA, (u16)~0xFF00, 0x5700);
+ b43_phy_maskset(dev, B43_PHY_CCKSHIFTBITS_WA, 0x00FF, 0x5700);
b43_phy_maskset(dev, B43_PHY_OFDM(0x1A), ~0x007F, 0x000F);
b43_phy_maskset(dev, B43_PHY_OFDM(0x1A), ~0x3F80, 0x2B80);
b43_phy_maskset(dev, B43_PHY_ANTWRSETT, 0xF0FF, 0x0300);
@@ -400,9 +400,9 @@ static void b43_wa_altagc(struct b43_wldev *dev)
b43_phy_maskset(dev, B43_PHY_OFDM(0x89), ~0x00FF, 0x0020);
b43_phy_maskset(dev, B43_PHY_OFDM(0x89), ~0x3F00, 0x0200);
b43_phy_maskset(dev, B43_PHY_OFDM(0x82), ~0x00FF, 0x002E);
- b43_phy_maskset(dev, B43_PHY_OFDM(0x96), (u16)~0xFF00, 0x1A00);
+ b43_phy_maskset(dev, B43_PHY_OFDM(0x96), 0x00FF, 0x1A00);
b43_phy_maskset(dev, B43_PHY_OFDM(0x81), ~0x00FF, 0x0028);
- b43_phy_maskset(dev, B43_PHY_OFDM(0x81), (u16)~0xFF00, 0x2C00);
+ b43_phy_maskset(dev, B43_PHY_OFDM(0x81), 0x00FF, 0x2C00);
if (phy->rev == 1) {
b43_phy_write(dev, B43_PHY_PEAK_COUNT, 0x092B);
b43_phy_maskset(dev, B43_PHY_OFDM(0x1B), ~0x001E, 0x0002);
@@ -412,7 +412,7 @@ static void b43_wa_altagc(struct b43_wldev *dev)
b43_phy_maskset(dev, B43_PHY_LPFGAINCTL, ~0x000F, 0x0004);
if (phy->rev >= 6) {
b43_phy_write(dev, B43_PHY_OFDM(0x22), 0x287A);
- b43_phy_maskset(dev, B43_PHY_LPFGAINCTL, (u16)~0xF000, 0x3000);
+ b43_phy_maskset(dev, B43_PHY_LPFGAINCTL, 0x0FFF, 0x3000);
}
}
b43_phy_maskset(dev, B43_PHY_DIVSRCHIDX, 0x8080, 0x7874);
--
1.7.1.1
^ 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