* 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] 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: 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: 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: [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: [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] 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: [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: [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: 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: [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
* [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
* [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
* Compat-wireless release for 2010-07-20 is baked
From: Compat-wireless cronjob account @ 2010-07-20 19:06 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat
7b8245a..8444e0f master -> origin/master
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
c6d612697..ce38023 history -> origin/history
+ 058395f...d8d58e7 master -> origin/master (forced update)
a9f7f2e..d0c6f62 stable -> origin/stable
* [new tag] next-20100720 -> next-20100720
compat-wireless code metrics
494339 - Total upstream lines of code being pulled
1447 - backport code changes
1211 - backport code additions
236 - backport code deletions
5764 - backport from compat module
7211 - total backport code
1.4587 - % of code consists of backport work
1218 - Crap changes not yet posted
1179 - Crap additions not yet posted
39 - Crap deletions not yet posted
0.2464 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100720
compat-wireless release: compat-wireless-2010-07-13-3-g1a05138
^ permalink raw reply
* Re: [PATCH v3] mac80211: remove wep dependency
From: John W. Linville @ 2010-07-20 18:56 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1279623588.3706.17.camel@jlt3.sipsolutions.net>
On Tue, Jul 20, 2010 at 12:59:48PM +0200, Johannes Berg wrote:
> On Wed, 2010-07-07 at 15:07 -0400, John W. Linville wrote:
> > The current mac80211 code assumes that WEP is always available. If WEP
> > fails to initialize, ieee80211_register_hw will always fail.
> >
> > In some cases (e.g. FIPS certification), the cryptography used by WEP is
> > unavailable. However, in such cases there is no good reason why CCMP
> > encryption (or even no link level encryption) cannot be used. So, this
> > patch removes mac80211's assumption that WEP (and TKIP) will always be
> > available for use.
> >
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
> > ---
> > v3 -> actually post changed patch...
> > v2 -> make it safe to call ieee80211_wep_free even if ieee80211_wep_init
> > had failed
>
> I think this is missing a change like this:
>
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -1228,6 +1228,10 @@ static int ieee80211_scan(struct wiphy *wiphy,
> static int ieee80211_auth(struct wiphy *wiphy, struct net_device *dev,
> struct cfg80211_auth_request *req)
> {
> + if (req->auth_type == NL80211_AUTHTYPE_SHARED_KEY &&
> + IS_ERR(sdata->local->wep_tx_tfm))
> + return -EINVAL;
> +
> return ieee80211_mgd_auth(IEEE80211_DEV_TO_SUB_IF(dev), req);
> }
>
>
> since otherwise you could end up trying to encrypt the auth frame with
> the uninitialised WEP TFM?
Yes, I think that makes sense. The check in ieee80211_wep_encrypt_data
will make it safe either way, but that will trigger a warning
in ieee80211_send_auth and leave us unable to return an error to
the ieee80211_auth caller. Also, it will send the auth request
unencrypted...
Care to send that as a "real" patch? :-)
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
* Re: [PATCH v2] mwl8k: correct/silence sparse warnings
From: Lennert Buytenhek @ 2010-07-20 18:53 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <1279651154-11985-1-git-send-email-linville@tuxdriver.com>
On Tue, Jul 20, 2010 at 02:39:14PM -0400, John W. Linville wrote:
> drivers/net/wireless/mwl8k.c:1541:21: warning: incorrect type in assignment (different base types)
> drivers/net/wireless/mwl8k.c:1541:21: expected restricted __le16 [usertype] result
> drivers/net/wireless/mwl8k.c:1541:21: got int
> drivers/net/wireless/mwl8k.c:1575:42: expected unsigned short [unsigned] [usertype] cmd
> drivers/net/wireless/mwl8k.c:1575:42: got restricted __le16 [usertype] code
> drivers/net/wireless/mwl8k.c:1587:50: warning: incorrect type in argument 1 (different base types)
> drivers/net/wireless/mwl8k.c:1587:50: expected unsigned short [unsigned] [usertype] cmd
> drivers/net/wireless/mwl8k.c:1587:50: got restricted __le16 [usertype] code
> drivers/net/wireless/mwl8k.c:1592:50: warning: incorrect type in argument 1 (different base types)
> drivers/net/wireless/mwl8k.c:1592:50: expected unsigned short [unsigned] [usertype] cmd
> drivers/net/wireless/mwl8k.c:1592:50: got restricted __le16 [usertype] code
> drivers/net/wireless/mwl8k.c:1845:27: warning: incorrect type in argument 1 (different base types)
> drivers/net/wireless/mwl8k.c:1845:27: expected unsigned int [unsigned] [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1845:27: got restricted __le32 [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1848:27: warning: incorrect type in argument 1 (different base types)
> drivers/net/wireless/mwl8k.c:1848:27: expected unsigned int [unsigned] [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1848:27: got restricted __le32 [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1851:27: warning: incorrect type in argument 1 (different base types)
> drivers/net/wireless/mwl8k.c:1851:27: expected unsigned int [unsigned] [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1851:27: got restricted __le32 [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1854:27: warning: incorrect type in argument 1 (different base types)
> drivers/net/wireless/mwl8k.c:1854:27: expected unsigned int [unsigned] [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1854:27: got restricted __le32 [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1857:27: warning: incorrect type in argument 1 (different base types)
> drivers/net/wireless/mwl8k.c:1857:27: expected unsigned int [unsigned] [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1857:27: got restricted __le32 [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1860:27: warning: incorrect type in argument 1 (different base types)
> drivers/net/wireless/mwl8k.c:1860:27: expected unsigned int [unsigned] [usertype] <noident>
> drivers/net/wireless/mwl8k.c:1860:27: got restricted __le32 [usertype] <noident>
> drivers/net/wireless/mwl8k.c:3055:20: warning: incorrect type in assignment (different base types)
> drivers/net/wireless/mwl8k.c:3055:20: expected restricted __le16 [usertype] ht_caps
> drivers/net/wireless/mwl8k.c:3055:20: got unsigned short [unsigned] [usertype] cap
>
> At least the last one looks like a real bug...
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Looks good!
Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
^ permalink raw reply
* [PATCH v2] mwl8k: correct/silence sparse warnings
From: John W. Linville @ 2010-07-20 18:39 UTC (permalink / raw)
To: linux-wireless; +Cc: Lennert Buytenhek, John W. Linville
In-Reply-To: <1279650123.3706.45.camel@jlt3.sipsolutions.net>
drivers/net/wireless/mwl8k.c:1541:21: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mwl8k.c:1541:21: expected restricted __le16 [usertype] result
drivers/net/wireless/mwl8k.c:1541:21: got int
drivers/net/wireless/mwl8k.c:1575:42: expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1575:42: got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1587:50: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1587:50: expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1587:50: got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1592:50: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1592:50: expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1592:50: got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1845:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1845:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1845:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1848:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1848:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1848:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1851:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1851:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1851:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1854:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1854:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1854:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1857:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1857:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1857:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1860:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1860:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1860:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:3055:20: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mwl8k.c:3055:20: expected restricted __le16 [usertype] ht_caps
drivers/net/wireless/mwl8k.c:3055:20: got unsigned short [unsigned] [usertype] cap
At least the last one looks like a real bug...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/mwl8k.c | 22 ++++++++++++----------
1 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index cd37b2a..e3f130c 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -314,13 +314,15 @@ static const struct ieee80211_rate mwl8k_rates_50[] = {
#define MWL8K_CMD_SET_NEW_STN 0x1111 /* per-vif */
#define MWL8K_CMD_UPDATE_STADB 0x1123
-static const char *mwl8k_cmd_name(u16 cmd, char *buf, int bufsize)
+static const char *mwl8k_cmd_name(__le16 cmd, char *buf, int bufsize)
{
+ u16 command = le16_to_cpu(cmd);
+
#define MWL8K_CMDNAME(x) case MWL8K_CMD_##x: do {\
snprintf(buf, bufsize, "%s", #x);\
return buf;\
} while (0)
- switch (cmd & ~0x8000) {
+ switch (command & ~0x8000) {
MWL8K_CMDNAME(CODE_DNLD);
MWL8K_CMDNAME(GET_HW_SPEC);
MWL8K_CMDNAME(SET_HW_SPEC);
@@ -1538,7 +1540,7 @@ static int mwl8k_post_cmd(struct ieee80211_hw *hw, struct mwl8k_cmd_pkt *cmd)
unsigned long timeout = 0;
u8 buf[32];
- cmd->result = 0xffff;
+ cmd->result = (__force __le16) 0xffff;
dma_size = le16_to_cpu(cmd->length);
dma_addr = pci_map_single(priv->pdev, cmd, dma_size,
PCI_DMA_BIDIRECTIONAL);
@@ -1842,22 +1844,22 @@ static int mwl8k_cmd_get_hw_spec_ap(struct ieee80211_hw *hw)
priv->sta_macids_supported = 0x00000000;
off = le32_to_cpu(cmd->wcbbase0) & 0xffff;
- iowrite32(cpu_to_le32(priv->txq[0].txd_dma), priv->sram + off);
+ iowrite32(priv->txq[0].txd_dma, priv->sram + off);
off = le32_to_cpu(cmd->rxwrptr) & 0xffff;
- iowrite32(cpu_to_le32(priv->rxq[0].rxd_dma), priv->sram + off);
+ iowrite32(priv->rxq[0].rxd_dma, priv->sram + off);
off = le32_to_cpu(cmd->rxrdptr) & 0xffff;
- iowrite32(cpu_to_le32(priv->rxq[0].rxd_dma), priv->sram + off);
+ iowrite32(priv->rxq[0].rxd_dma, priv->sram + off);
off = le32_to_cpu(cmd->wcbbase1) & 0xffff;
- iowrite32(cpu_to_le32(priv->txq[1].txd_dma), priv->sram + off);
+ iowrite32(priv->txq[1].txd_dma, priv->sram + off);
off = le32_to_cpu(cmd->wcbbase2) & 0xffff;
- iowrite32(cpu_to_le32(priv->txq[2].txd_dma), priv->sram + off);
+ iowrite32(priv->txq[2].txd_dma, priv->sram + off);
off = le32_to_cpu(cmd->wcbbase3) & 0xffff;
- iowrite32(cpu_to_le32(priv->txq[3].txd_dma), priv->sram + off);
+ iowrite32(priv->txq[3].txd_dma, priv->sram + off);
}
kfree(cmd);
@@ -3052,7 +3054,7 @@ static int mwl8k_cmd_update_stadb_add(struct ieee80211_hw *hw,
p->peer_type = MWL8K_PEER_TYPE_ACCESSPOINT;
p->basic_caps = cpu_to_le16(vif->bss_conf.assoc_capability);
p->ht_support = sta->ht_cap.ht_supported;
- p->ht_caps = sta->ht_cap.cap;
+ p->ht_caps = cpu_to_le16(sta->ht_cap.cap);
p->extended_ht_caps = (sta->ht_cap.ampdu_factor & 3) |
((sta->ht_cap.ampdu_density & 7) << 2);
if (hw->conf.channel->band == IEEE80211_BAND_2GHZ)
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH] rt2x00: correct sparse warning in rt2x00debug.c
From: Ivo Van Doorn @ 2010-07-20 18:32 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, gwingerde
In-Reply-To: <1279650227-11089-1-git-send-email-linville@tuxdriver.com>
On Tue, Jul 20, 2010 at 8:23 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> CHECK drivers/net/wireless/rt2x00/rt2x00debug.c
> drivers/net/wireless/rt2x00/rt2x00debug.c:193:28: warning: incorrect type in assignment (different base types)
> drivers/net/wireless/rt2x00/rt2x00debug.c:193:28: expected restricted __le32 [usertype] chip_rev
> drivers/net/wireless/rt2x00/rt2x00debug.c:193:28: got restricted __le16 [usertype] <noident>
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Thanks.
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2x00dump.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2x00dump.h b/drivers/net/wireless/rt2x00/rt2x00dump.h
> index 6df2e0b..5d6e0b8 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00dump.h
> +++ b/drivers/net/wireless/rt2x00/rt2x00dump.h
> @@ -116,7 +116,7 @@ struct rt2x00dump_hdr {
>
> __le16 chip_rt;
> __le16 chip_rf;
> - __le32 chip_rev;
> + __le16 chip_rev;
>
> __le16 type;
> __u8 queue_index;
> --
> 1.7.1.1
>
>
^ permalink raw reply
* [PATCH] libipw: correct sparse warnings and mark some variables static
From: John W. Linville @ 2010-07-20 18:17 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
CHECK drivers/net/wireless/ipw2x00/libipw_module.c
drivers/net/wireless/ipw2x00/libipw_module.c:65:21: warning: symbol 'libipw_config_ops' was not declared. Should it be static?
drivers/net/wireless/ipw2x00/libipw_module.c:66:6: warning: symbol 'libipw_wiphy_privid' was not declared. Should it be static?
CHECK drivers/net/wireless/ipw2x00/libipw_wx.c
drivers/net/wireless/ipw2x00/libipw_wx.c:415:17: warning: symbol 'ssid' shadows an earlier one
drivers/net/wireless/ipw2x00/libipw_wx.c:324:9: originally declared here
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/ipw2x00/libipw_module.c | 4 ++--
drivers/net/wireless/ipw2x00/libipw_wx.c | 4 ----
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ipw2x00/libipw_module.c b/drivers/net/wireless/ipw2x00/libipw_module.c
index 5596540..32dee2c 100644
--- a/drivers/net/wireless/ipw2x00/libipw_module.c
+++ b/drivers/net/wireless/ipw2x00/libipw_module.c
@@ -62,8 +62,8 @@ MODULE_DESCRIPTION(DRV_DESCRIPTION);
MODULE_AUTHOR(DRV_COPYRIGHT);
MODULE_LICENSE("GPL");
-struct cfg80211_ops libipw_config_ops = { };
-void *libipw_wiphy_privid = &libipw_wiphy_privid;
+static struct cfg80211_ops libipw_config_ops = { };
+static void *libipw_wiphy_privid = &libipw_wiphy_privid;
static int libipw_networks_allocate(struct libipw_device *ieee)
{
diff --git a/drivers/net/wireless/ipw2x00/libipw_wx.c b/drivers/net/wireless/ipw2x00/libipw_wx.c
index 3633c66..8a4bae4 100644
--- a/drivers/net/wireless/ipw2x00/libipw_wx.c
+++ b/drivers/net/wireless/ipw2x00/libipw_wx.c
@@ -411,10 +411,6 @@ int libipw_wx_set_encode(struct libipw_device *ieee,
/* If a new key was provided, set it up */
if (erq->length > 0) {
-#ifdef CONFIG_LIBIPW_DEBUG
- DECLARE_SSID_BUF(ssid);
-#endif
-
len = erq->length <= 5 ? 5 : 13;
memcpy(sec.keys[key], keybuf, erq->length);
if (len > erq->length)
--
1.7.1.1
^ permalink raw reply related
* [PATCH] rt2x00: correct sparse warning in rt2x00debug.c
From: John W. Linville @ 2010-07-20 18:23 UTC (permalink / raw)
To: linux-wireless; +Cc: ivdoorn, gwingerde, John W. Linville
CHECK drivers/net/wireless/rt2x00/rt2x00debug.c
drivers/net/wireless/rt2x00/rt2x00debug.c:193:28: warning: incorrect type in assignment (different base types)
drivers/net/wireless/rt2x00/rt2x00debug.c:193:28: expected restricted __le32 [usertype] chip_rev
drivers/net/wireless/rt2x00/rt2x00debug.c:193:28: got restricted __le16 [usertype] <noident>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/rt2x00/rt2x00dump.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2x00dump.h b/drivers/net/wireless/rt2x00/rt2x00dump.h
index 6df2e0b..5d6e0b8 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dump.h
+++ b/drivers/net/wireless/rt2x00/rt2x00dump.h
@@ -116,7 +116,7 @@ struct rt2x00dump_hdr {
__le16 chip_rt;
__le16 chip_rf;
- __le32 chip_rev;
+ __le16 chip_rev;
__le16 type;
__u8 queue_index;
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH] mwl8k: correct/silence sparse warnings
From: John W. Linville @ 2010-07-20 18:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Lennert Buytenhek
In-Reply-To: <1279650123.3706.45.camel@jlt3.sipsolutions.net>
On Tue, Jul 20, 2010 at 08:22:03PM +0200, Johannes Berg wrote:
> On Tue, 2010-07-20 at 14:07 -0400, John W. Linville wrote:
>
> > off = le32_to_cpu(cmd->rxwrptr) & 0xffff;
> > - iowrite32(cpu_to_le32(priv->rxq[0].rxd_dma), priv->sram + off);
> > + iowrite32((__force __u32) cpu_to_le32(priv->rxq[0].rxd_dma),
> > + priv->sram + off);
>
> Those don't seem right, it looks more like somebody thought they needed
> to byteswap the iowrite because PCI(e) is little endian, and were wrong?
Yeah, I agree. I was going with the thought that "it's working, so
I guess it is right". But then, development was probably done on an
LE system...
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
* Re: [RFC] wireless: only use alpha2 regulatory information from country IE
From: Luis R. Rodriguez @ 2010-07-20 18:23 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, kyle
In-Reply-To: <1279220807-18245-1-git-send-email-linville@tuxdriver.com>
On Thu, Jul 15, 2010 at 12:06 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> The meaning and/or usage of the country IE is somewhat poorly defined.
> In practice, this means that regulatory rulesets in a country IE are
> often incomplete and might be untrustworthy. This removes the code
> associated with interpreting those rulesets while preserving respect
> for country "alpha2" codes also contained in the country IE.
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> @@ -2026,13 +1501,17 @@ static bool reg_same_country_ie_hint(struct wiphy *wiphy,
> return false;
>
> if (likely(request_wiphy != wiphy))
> - return !country_ie_integrity_changes(country_ie_checksum);
> + 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(!country_ie_integrity_changes(country_ie_checksum)))
> + 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;
> }
Might as well remove reg_same_country_ie_hint() completely since we
already dealt with suspend/resume through the regulatory hint
disconnect. But this can technically be done through a secondary patch
to clarify this particular removal. Other than that this looks good.
Luis
^ permalink raw reply
* Re: [PATCH] mwl8k: correct/silence sparse warnings
From: Johannes Berg @ 2010-07-20 18:22 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Lennert Buytenhek
In-Reply-To: <1279649222-3042-1-git-send-email-linville@tuxdriver.com>
On Tue, 2010-07-20 at 14:07 -0400, John W. Linville wrote:
> off = le32_to_cpu(cmd->rxwrptr) & 0xffff;
> - iowrite32(cpu_to_le32(priv->rxq[0].rxd_dma), priv->sram + off);
> + iowrite32((__force __u32) cpu_to_le32(priv->rxq[0].rxd_dma),
> + priv->sram + off);
Those don't seem right, it looks more like somebody thought they needed
to byteswap the iowrite because PCI(e) is little endian, and were wrong?
johannes
^ permalink raw reply
* [PATCH] mwl8k: correct/silence sparse warnings
From: John W. Linville @ 2010-07-20 18:07 UTC (permalink / raw)
To: linux-wireless; +Cc: Lennert Buytenhek, John W. Linville
drivers/net/wireless/mwl8k.c:1541:21: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mwl8k.c:1541:21: expected restricted __le16 [usertype] result
drivers/net/wireless/mwl8k.c:1541:21: got int
drivers/net/wireless/mwl8k.c:1575:42: expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1575:42: got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1587:50: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1587:50: expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1587:50: got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1592:50: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1592:50: expected unsigned short [unsigned] [usertype] cmd
drivers/net/wireless/mwl8k.c:1592:50: got restricted __le16 [usertype] code
drivers/net/wireless/mwl8k.c:1845:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1845:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1845:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1848:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1848:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1848:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1851:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1851:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1851:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1854:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1854:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1854:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1857:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1857:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1857:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:1860:27: warning: incorrect type in argument 1 (different base types)
drivers/net/wireless/mwl8k.c:1860:27: expected unsigned int [unsigned] [usertype] <noident>
drivers/net/wireless/mwl8k.c:1860:27: got restricted __le32 [usertype] <noident>
drivers/net/wireless/mwl8k.c:3055:20: warning: incorrect type in assignment (different base types)
drivers/net/wireless/mwl8k.c:3055:20: expected restricted __le16 [usertype] ht_caps
drivers/net/wireless/mwl8k.c:3055:20: got unsigned short [unsigned] [usertype] cap
At least the last one looks like a real bug...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/mwl8k.c | 28 ++++++++++++++++++----------
1 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index cd37b2a..3576071 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -314,13 +314,15 @@ static const struct ieee80211_rate mwl8k_rates_50[] = {
#define MWL8K_CMD_SET_NEW_STN 0x1111 /* per-vif */
#define MWL8K_CMD_UPDATE_STADB 0x1123
-static const char *mwl8k_cmd_name(u16 cmd, char *buf, int bufsize)
+static const char *mwl8k_cmd_name(__le16 cmd, char *buf, int bufsize)
{
+ u16 command = le16_to_cpu(cmd);
+
#define MWL8K_CMDNAME(x) case MWL8K_CMD_##x: do {\
snprintf(buf, bufsize, "%s", #x);\
return buf;\
} while (0)
- switch (cmd & ~0x8000) {
+ switch (command & ~0x8000) {
MWL8K_CMDNAME(CODE_DNLD);
MWL8K_CMDNAME(GET_HW_SPEC);
MWL8K_CMDNAME(SET_HW_SPEC);
@@ -1538,7 +1540,7 @@ static int mwl8k_post_cmd(struct ieee80211_hw *hw, struct mwl8k_cmd_pkt *cmd)
unsigned long timeout = 0;
u8 buf[32];
- cmd->result = 0xffff;
+ cmd->result = (__force __le16) 0xffff;
dma_size = le16_to_cpu(cmd->length);
dma_addr = pci_map_single(priv->pdev, cmd, dma_size,
PCI_DMA_BIDIRECTIONAL);
@@ -1842,22 +1844,28 @@ static int mwl8k_cmd_get_hw_spec_ap(struct ieee80211_hw *hw)
priv->sta_macids_supported = 0x00000000;
off = le32_to_cpu(cmd->wcbbase0) & 0xffff;
- iowrite32(cpu_to_le32(priv->txq[0].txd_dma), priv->sram + off);
+ iowrite32((__force __u32) cpu_to_le32(priv->txq[0].txd_dma),
+ priv->sram + off);
off = le32_to_cpu(cmd->rxwrptr) & 0xffff;
- iowrite32(cpu_to_le32(priv->rxq[0].rxd_dma), priv->sram + off);
+ iowrite32((__force __u32) cpu_to_le32(priv->rxq[0].rxd_dma),
+ priv->sram + off);
off = le32_to_cpu(cmd->rxrdptr) & 0xffff;
- iowrite32(cpu_to_le32(priv->rxq[0].rxd_dma), priv->sram + off);
+ iowrite32((__force __u32) cpu_to_le32(priv->rxq[0].rxd_dma),
+ priv->sram + off);
off = le32_to_cpu(cmd->wcbbase1) & 0xffff;
- iowrite32(cpu_to_le32(priv->txq[1].txd_dma), priv->sram + off);
+ iowrite32((__force __u32) cpu_to_le32(priv->txq[1].txd_dma),
+ priv->sram + off);
off = le32_to_cpu(cmd->wcbbase2) & 0xffff;
- iowrite32(cpu_to_le32(priv->txq[2].txd_dma), priv->sram + off);
+ iowrite32((__force __u32) cpu_to_le32(priv->txq[2].txd_dma),
+ priv->sram + off);
off = le32_to_cpu(cmd->wcbbase3) & 0xffff;
- iowrite32(cpu_to_le32(priv->txq[3].txd_dma), priv->sram + off);
+ iowrite32((__force __u32) cpu_to_le32(priv->txq[3].txd_dma),
+ priv->sram + off);
}
kfree(cmd);
@@ -3052,7 +3060,7 @@ static int mwl8k_cmd_update_stadb_add(struct ieee80211_hw *hw,
p->peer_type = MWL8K_PEER_TYPE_ACCESSPOINT;
p->basic_caps = cpu_to_le16(vif->bss_conf.assoc_capability);
p->ht_support = sta->ht_cap.ht_supported;
- p->ht_caps = sta->ht_cap.cap;
+ p->ht_caps = cpu_to_le16(sta->ht_cap.cap);
p->extended_ht_caps = (sta->ht_cap.ampdu_factor & 3) |
((sta->ht_cap.ampdu_density & 7) << 2);
if (hw->conf.channel->band == IEEE80211_BAND_2GHZ)
--
1.7.1.1
^ permalink raw reply related
* [PATCH] ipw2100: mark ipw2100_pm_qos_req static
From: John W. Linville @ 2010-07-20 18:12 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
CHECK drivers/net/wireless/ipw2x00/ipw2100.c
drivers/net/wireless/ipw2x00/ipw2100.c:177:28: warning: symbol 'ipw2100_pm_qos_req' was not declared. Should it be static?
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/ipw2x00/ipw2100.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ipw2x00/ipw2100.c b/drivers/net/wireless/ipw2x00/ipw2100.c
index 18ebd60..5165db9 100644
--- a/drivers/net/wireless/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/ipw2x00/ipw2100.c
@@ -174,7 +174,7 @@ that only one external action is invoked at a time.
#define DRV_DESCRIPTION "Intel(R) PRO/Wireless 2100 Network Driver"
#define DRV_COPYRIGHT "Copyright(c) 2003-2006 Intel Corporation"
-struct pm_qos_request_list *ipw2100_pm_qos_req;
+static struct pm_qos_request_list *ipw2100_pm_qos_req;
/* Debugging stuff */
#ifdef CONFIG_IPW2100_DEBUG
--
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