* [PATCH 1/2] ath9k: Fix inconsistency between txq->stopped and the actual queue state
From: Vasanthakumar Thiagarajan @ 2010-07-22 9:24 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Sometimes txq state(txq->stopped) can be marked as started but the actual
queue may not be started (in ATH_WIPHY_SCAN state, for example). Fix this.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/ath9k.h | 2 +-
drivers/net/wireless/ath/ath9k/virtual.c | 6 +++++-
drivers/net/wireless/ath/ath9k/xmit.c | 4 ++--
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 6e486a5..998ae2c 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -687,7 +687,7 @@ bool ath9k_all_wiphys_idle(struct ath_softc *sc);
void ath9k_set_wiphy_idle(struct ath_wiphy *aphy, bool idle);
void ath_mac80211_stop_queue(struct ath_softc *sc, u16 skb_queue);
-void ath_mac80211_start_queue(struct ath_softc *sc, u16 skb_queue);
+bool ath_mac80211_start_queue(struct ath_softc *sc, u16 skb_queue);
void ath_start_rfkill_poll(struct ath_softc *sc);
extern void ath9k_rfkill_poll_state(struct ieee80211_hw *hw);
diff --git a/drivers/net/wireless/ath/ath9k/virtual.c b/drivers/net/wireless/ath/ath9k/virtual.c
index 89423ca..fd20241 100644
--- a/drivers/net/wireless/ath/ath9k/virtual.c
+++ b/drivers/net/wireless/ath/ath9k/virtual.c
@@ -695,16 +695,18 @@ void ath9k_set_wiphy_idle(struct ath_wiphy *aphy, bool idle)
idle ? "idle" : "not-idle");
}
/* Only bother starting a queue on an active virtual wiphy */
-void ath_mac80211_start_queue(struct ath_softc *sc, u16 skb_queue)
+bool ath_mac80211_start_queue(struct ath_softc *sc, u16 skb_queue)
{
struct ieee80211_hw *hw = sc->pri_wiphy->hw;
unsigned int i;
+ bool txq_started = false;
spin_lock_bh(&sc->wiphy_lock);
/* Start the primary wiphy */
if (sc->pri_wiphy->state == ATH_WIPHY_ACTIVE) {
ieee80211_wake_queue(hw, skb_queue);
+ txq_started = true;
goto unlock;
}
@@ -718,11 +720,13 @@ void ath_mac80211_start_queue(struct ath_softc *sc, u16 skb_queue)
hw = aphy->hw;
ieee80211_wake_queue(hw, skb_queue);
+ txq_started = true;
break;
}
unlock:
spin_unlock_bh(&sc->wiphy_lock);
+ return txq_started;
}
/* Go ahead and propagate information to all virtual wiphys, it won't hurt */
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 0644f1e..21aa5bd 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2077,8 +2077,8 @@ static void ath_wake_mac80211_queue(struct ath_softc *sc, struct ath_txq *txq)
spin_lock_bh(&txq->axq_lock);
if (txq->stopped && sc->tx.pending_frames[qnum] < ATH_MAX_QDEPTH) {
- ath_mac80211_start_queue(sc, qnum);
- txq->stopped = 0;
+ if (ath_mac80211_start_queue(sc, qnum))
+ txq->stopped = 0;
}
spin_unlock_bh(&txq->axq_lock);
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] wl1251: fix sparse-generated warnings
From: Kalle Valo @ 2010-07-22 9:21 UTC (permalink / raw)
To: Luciano Coelho; +Cc: John W. Linville, linux-wireless@vger.kernel.org
In-Reply-To: <1279788739.2322.39.camel@powerslave>
On 07/22/2010 10:52 AM, Luciano Coelho wrote:
> On Thu, 2010-07-22 at 10:45 +0200, ext Kalle Valo wrote:
>> Hi John,
>>
>> On 07/21/2010 06:31 PM, John W. Linville wrote:
>>> @@ -225,7 +225,7 @@ static void wl1251_boot_set_ecpu_ctrl(struct wl1251 *wl, u32 flag)
>>> int wl1251_boot_run_firmware(struct wl1251 *wl)
>>> {
>>> int loop, ret;
>>> - u32 chip_id, interrupt;
>>> + u32 chip_id, acx_intr;
>>
>> I don't get why you did this change. I don't object renaming the
>> variable, but I can't figure out the reasoning behind it.
>
> Sparse complains that interrupt is shadowing the definition in hw_irq.h:
>
>> drivers/net/wireless/wl12xx/wl1251_boot.c:228:22: warning: symbol
>> 'interrupt' shadows an earlier one
>> /home/linville/git/wireless-next-2.6/arch/x86/include/asm/hw_irq.h:132:13: originally declared here
>
> So, it's just a cosmetic change, I guess.
Ah, I was blind as usual. It makes all sense now, thanks.
Kalle
^ permalink raw reply
* Re: [PATCH/RFC 3/3] ath5k: trace resets
From: Bruno Randolf @ 2010-07-22 9:21 UTC (permalink / raw)
To: Johannes Berg; +Cc: Bob Copeland, linux-wireless, ath5k-devel, Ben Gamari
In-Reply-To: <1279698801.3707.1.camel@jlt3.sipsolutions.net>
On Wed July 21 2010 16:53:21 Johannes Berg wrote:
> 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.
true. i just checked it again and enabling tracing does not affect the
performance as i have wrongly stated before. i must have had some other
debugging stuff enabled as well. sorry...
bruno
^ permalink raw reply
* Re: [patch -next] ath5k: snprintf() returns largish values
From: Jiri Slaby @ 2010-07-22 8:56 UTC (permalink / raw)
To: Dan Carpenter
Cc: Luis R. Rodriguez, Nick Kossifidis, Bob Copeland,
John W. Linville, Bruno Randolf, linux-wireless, ath5k-devel,
kernel-janitors
In-Reply-To: <20100722085202.GV17585@bicker>
On 07/22/2010 10:52 AM, Dan Carpenter wrote:
> snprintf() returns the number of characters that would have been written
> (not counting the NUL character). So we can't use it as the limiter to
> simple_read_from_buffer() without capping it first at sizeof(buf).
Doesn't scnprintf make more sense here?
thanks,
--
js
^ permalink raw reply
* Re: [PATCH] wl1251: fix sparse-generated warnings
From: Luciano Coelho @ 2010-07-22 8:52 UTC (permalink / raw)
To: ext Kalle Valo; +Cc: John W. Linville, linux-wireless@vger.kernel.org
In-Reply-To: <4C48053A.6080504@adurom.com>
On Thu, 2010-07-22 at 10:45 +0200, ext Kalle Valo wrote:
> Hi John,
>
> On 07/21/2010 06:31 PM, John W. Linville wrote:
> > @@ -225,7 +225,7 @@ static void wl1251_boot_set_ecpu_ctrl(struct wl1251 *wl, u32 flag)
> > int wl1251_boot_run_firmware(struct wl1251 *wl)
> > {
> > int loop, ret;
> > - u32 chip_id, interrupt;
> > + u32 chip_id, acx_intr;
>
> I don't get why you did this change. I don't object renaming the
> variable, but I can't figure out the reasoning behind it.
Sparse complains that interrupt is shadowing the definition in hw_irq.h:
> drivers/net/wireless/wl12xx/wl1251_boot.c:228:22: warning: symbol
> 'interrupt' shadows an earlier one
> /home/linville/git/wireless-next-2.6/arch/x86/include/asm/hw_irq.h:132:13: originally declared here
So, it's just a cosmetic change, I guess.
--
Cheers,
Luca.
^ permalink raw reply
* [patch -next] ath5k: snprintf() returns largish values
From: Dan Carpenter @ 2010-07-22 8:52 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Nick Kossifidis, Jiri Slaby, Bob Copeland, John W. Linville,
Bruno Randolf, linux-wireless, ath5k-devel, kernel-janitors
snprintf() returns the number of characters that would have been written
(not counting the NUL character). So we can't use it as the limiter to
simple_read_from_buffer() without capping it first at sizeof(buf).
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/wireless/ath/ath5k/debug.c b/drivers/net/wireless/ath/ath5k/debug.c
index ebb9c23..4cccc29 100644
--- a/drivers/net/wireless/ath/ath5k/debug.c
+++ b/drivers/net/wireless/ath/ath5k/debug.c
@@ -239,6 +239,9 @@ static ssize_t read_file_beacon(struct file *file, char __user *user_buf,
"TSF\t\t0x%016llx\tTU: %08x\n",
(unsigned long long)tsf, TSF_TO_TU(tsf));
+ if (len > sizeof(buf))
+ len = sizeof(buf);
+
return simple_read_from_buffer(user_buf, count, ppos, buf, len);
}
@@ -334,6 +337,9 @@ static ssize_t read_file_debug(struct file *file, char __user *user_buf,
sc->debug.level == dbg_info[i].level ? '+' : ' ',
dbg_info[i].level, dbg_info[i].desc);
+ if (len > sizeof(buf))
+ len = sizeof(buf);
+
return simple_read_from_buffer(user_buf, count, ppos, buf, len);
}
@@ -433,6 +439,9 @@ static ssize_t read_file_antenna(struct file *file, char __user *user_buf,
len += snprintf(buf+len, sizeof(buf)-len,
"AR5K_PHY_ANT_SWITCH_TABLE_1\t0x%08x\n", v);
+ if (len > sizeof(buf))
+ len = sizeof(buf);
+
return simple_read_from_buffer(user_buf, count, ppos, buf, len);
}
@@ -542,6 +551,9 @@ static ssize_t read_file_frameerrors(struct file *file, char __user *user_buf,
len += snprintf(buf+len, sizeof(buf)-len, "[TX all\t%d]\n",
st->tx_all_count);
+ if (len > sizeof(buf))
+ len = sizeof(buf);
+
return simple_read_from_buffer(user_buf, count, ppos, buf, len);
}
@@ -681,6 +693,9 @@ static ssize_t read_file_ani(struct file *file, char __user *user_buf,
ATH5K_ANI_CCK_TRIG_HIGH - (ATH5K_PHYERR_CNT_MAX -
ath5k_hw_reg_read(sc->ah, AR5K_PHYERR_CNT2)));
+ if (len > sizeof(buf))
+ len = sizeof(buf);
+
return simple_read_from_buffer(user_buf, count, ppos, buf, len);
}
@@ -766,6 +781,9 @@ static ssize_t read_file_queue(struct file *file, char __user *user_buf,
len += snprintf(buf+len, sizeof(buf)-len, " len: %d\n", n);
}
+ if (len > sizeof(buf))
+ len = sizeof(buf);
+
return simple_read_from_buffer(user_buf, count, ppos, buf, len);
}
^ permalink raw reply related
* [patch -next] ath9k: snprintf() returns largish values
From: Dan Carpenter @ 2010-07-22 8:50 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Jouni Malinen, Sujith Manoharan, Vasanthakumar Thiagarajan,
Senthil Balasubramanian, John W. Linville, Vivek Natarajan,
Felix Fietkau, linux-wireless, ath9k-devel, kernel-janitors
The snprintf() function returns the number of characters that would have
been written (not counting the NUL character on the end). It could
potentially be larger than the size of the buffer.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 3243877..cf9bcc6 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -524,6 +524,9 @@ static ssize_t read_file_tgt_stats(struct file *file, char __user *user_buf,
len += snprintf(buf + len, sizeof(buf) - len,
"%19s : %10u\n", "TX Rate", priv->debug.txrate);
+ if (len > sizeof(buf))
+ len = sizeof(buf);
+
return simple_read_from_buffer(user_buf, count, ppos, buf, len);
}
@@ -569,6 +572,9 @@ static ssize_t read_file_xmit(struct file *file, char __user *user_buf,
"%20s : %10u\n", "VO queued",
priv->debug.tx_stats.queue_stats[WME_AC_VO]);
+ if (len > sizeof(buf))
+ len = sizeof(buf);
+
return simple_read_from_buffer(user_buf, count, ppos, buf, len);
}
@@ -595,6 +601,9 @@ static ssize_t read_file_recv(struct file *file, char __user *user_buf,
"%20s : %10u\n", "SKBs Dropped",
priv->debug.rx_stats.skb_dropped);
+ if (len > sizeof(buf))
+ len = sizeof(buf);
+
return simple_read_from_buffer(user_buf, count, ppos, buf, len);
}
^ permalink raw reply related
* Re: [PATCH] wl1251: fix sparse-generated warnings
From: Kalle Valo @ 2010-07-22 8:45 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Luciano Coelho
In-Reply-To: <1279729917-4451-1-git-send-email-linville@tuxdriver.com>
Hi John,
On 07/21/2010 06:31 PM, John W. Linville wrote:
> @@ -225,7 +225,7 @@ static void wl1251_boot_set_ecpu_ctrl(struct wl1251 *wl, u32 flag)
> int wl1251_boot_run_firmware(struct wl1251 *wl)
> {
> int loop, ret;
> - u32 chip_id, interrupt;
> + u32 chip_id, acx_intr;
I don't get why you did this change. I don't object renaming the
variable, but I can't figure out the reasoning behind it.
Kalle
^ permalink raw reply
* Re: [PATCH] wl1251: fix sparse-generated warnings
From: Luciano Coelho @ 2010-07-22 7:57 UTC (permalink / raw)
To: ext Kalle Valo; +Cc: ext John W. Linville, linux-wireless@vger.kernel.org
In-Reply-To: <4C47F706.4060102@iki.fi>
On Thu, 2010-07-22 at 09:45 +0200, ext Kalle Valo wrote:
> On 07/22/2010 08:34 AM, Luciano Coelho wrote:
> >> @@ -191,11 +191,13 @@ static int wl1251_tx_send_packet(struct wl1251 *wl, struct sk_buff *skb,
> >> if (control->control.hw_key &&
> >> control->control.hw_key->alg == ALG_TKIP) {
> >> int hdrlen;
> >> - u16 fc;
> >> + __le16 fc;
> >> + u16 length;
> >> u8 *pos;
> >>
> >> - fc = *(u16 *)(skb->data + sizeof(*tx_hdr));
> >> - tx_hdr->length += WL1251_TKIP_IV_SPACE;
> >> + fc = *(__le16 *)(skb->data + sizeof(*tx_hdr));
> >
> > Is this going to work? sizeof(*tx_hdr), and the operation, will be in
> > the cpu's endianess, right?
>
> I think this is correct. We first calculate a pointer to a __le16 value
> and then dereference that value to a __le16 variable.
Yes, you're right, I got totally confused for some reason, as I already
pointed out on my other email. I completely missed the fact that we
were dealing with pointers here. It seems like my brain works as that
of a Java programmer before my morning dose of caffeine :P
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] wl1251: fix sparse-generated warnings
From: Kalle Valo @ 2010-07-22 7:45 UTC (permalink / raw)
To: Luciano Coelho; +Cc: ext John W. Linville, linux-wireless@vger.kernel.org
In-Reply-To: <1279780458.2322.25.camel@powerslave>
On 07/22/2010 08:34 AM, Luciano Coelho wrote:
> Hi John,
Hi Luca and John,
> Great that someone finally made the endianess changes that we never had
> the time to do for wl1251. Thanks for that! :)
Yeah, it really is. wl1251 endian support has been broken almost from
day one. Unfortunately I don't any hardware to test wl1251 right now, so
we have to rely on careful review :/
>> @@ -467,7 +467,7 @@ static int wl1251_boot_upload_nvs(struct wl1251 *wl)
>> val = (nvs_ptr[0] | (nvs_ptr[1] << 8)
>> | (nvs_ptr[2] << 16) | (nvs_ptr[3] << 24));
>>
>> - val = cpu_to_le32(val);
>> + val = (u32 __force) cpu_to_le32(val);
>
> This will work, but such casts always make me a bit suspicious. I think
> this is fine for now
This line was very suspicious already from beginning, I can't remember
why it was added and I don't see why it's needed here.
> but later I think we should make sure that all the
> _write() functions explicitly receive __le32 as val, or receives the
> cpu's u32 and converts it before actually writing the value, for
> clarity reasons. Kalle, what do you think?
I agree that we should change write() to handle endianess properly. I'm
in favor of having the conversion in write(), but I didn't think this
that much.
>> @@ -191,11 +191,13 @@ static int wl1251_tx_send_packet(struct wl1251 *wl, struct sk_buff *skb,
>> if (control->control.hw_key &&
>> control->control.hw_key->alg == ALG_TKIP) {
>> int hdrlen;
>> - u16 fc;
>> + __le16 fc;
>> + u16 length;
>> u8 *pos;
>>
>> - fc = *(u16 *)(skb->data + sizeof(*tx_hdr));
>> - tx_hdr->length += WL1251_TKIP_IV_SPACE;
>> + fc = *(__le16 *)(skb->data + sizeof(*tx_hdr));
>
> Is this going to work? sizeof(*tx_hdr), and the operation, will be in
> the cpu's endianess, right?
I think this is correct. We first calculate a pointer to a __le16 value
and then dereference that value to a __le16 variable.
> Wouldn't the following be the right thing to
> do then?
>
> fc = cpu_to_le16(le16_to_cpu(skb->data) + sizeof(*tx_hdr));
>
> Maybe some casts are needed too, I didn't check that, but regarding the
> endianess, I think this is how it should go. It's the same thing as the
> length parameter:
>
>> + length = le16_to_cpu(tx_hdr->length) + WL1251_TKIP_IV_SPACE;
>> + tx_hdr->length = cpu_to_le16(length);
>
> ...which is treated correctly here.
This is different. Here we are adding something to a __le16 value, not
calculating with pointers.
Kalle
^ permalink raw reply
* Re: [PATCH] wl1251: fix sparse-generated warnings
From: Luciano Coelho @ 2010-07-22 7:38 UTC (permalink / raw)
To: ext John W. Linville; +Cc: linux-wireless@vger.kernel.org, Kalle Valo
In-Reply-To: <1279780458.2322.25.camel@powerslave>
On Thu, 2010-07-22 at 08:34 +0200, Coelho Luciano (Nokia-MS/Helsinki)
wrote:
> > @@ -191,11 +191,13 @@ static int wl1251_tx_send_packet(struct wl1251 *wl, struct sk_buff *skb,
> > if (control->control.hw_key &&
> > control->control.hw_key->alg == ALG_TKIP) {
> > int hdrlen;
> > - u16 fc;
> > + __le16 fc;
> > + u16 length;
> > u8 *pos;
> >
> > - fc = *(u16 *)(skb->data + sizeof(*tx_hdr));
> > - tx_hdr->length += WL1251_TKIP_IV_SPACE;
> > + fc = *(__le16 *)(skb->data + sizeof(*tx_hdr));
>
> Is this going to work? sizeof(*tx_hdr), and the operation, will be in
> the cpu's endianess, right? Wouldn't the following be the right thing to
> do then?
>
> fc = cpu_to_le16(le16_to_cpu(skb->data) + sizeof(*tx_hdr));
Ugh, as Johannes pointed out, what I said here is completely non-sense.
Please ignore this before-my-morning-coffee lapse. ;)
--
Cheers,
Luca.
^ permalink raw reply
* Re: wl1271 firmware
From: Luciano Coelho @ 2010-07-22 6:40 UTC (permalink / raw)
To: ext Pazzo Da Legare
Cc: linux-wireless@vger.kernel.org, Levi, Shahar, Logan Gunthorpe
In-Reply-To: <AANLkTinnYeJPV-xxg7DdPXnWW_kD7X1TVcd9HrhupJWS@mail.gmail.com>
Hi Pazzo,
On Wed, 2010-07-21 at 19:27 +0200, ext Pazzo Da Legare wrote:
> Dear All again,
>
> I've just test with compact-wireless-2010-07-20 but I've the same problem:
>
> root@hawkboard:~# ifconfig wlan0 192.168.0.1 up
> [ 68.920000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-fw.bin
> [ 69.100000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-nvs.bin
> [ 69.510000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
> root@hawkboard:~# [ 70.020000] wl1271: ERROR ELP wakeup timeout!
> [ 70.520000] wl1271: ERROR ELP wakeup timeout!
>
>
> looking at dmesg:
>
> [ 68.920000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-fw.bin
> [ 69.100000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-nvs.bin
> [ 69.500000] wl1271: firmware booted (Rev 6.1.0.0.310)
> [ 69.510000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [ 70.020000] wl1271: ERROR ELP wakeup timeout!
> [ 70.520000] wl1271: ERROR ELP wakeup timeout!
>
> [ 68.920000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-fw.bin
> [ 69.100000] wl1271_sdio mmc0:0001:2: firmware: requesting wl1271-nvs.bin
> [ 69.500000] wl1271: firmware booted (Rev 6.1.0.0.310)
> [ 70.020000] wl1271: ERROR ELP wakeup timeout!
> [ 70.520000] wl1271: ERROR ELP wakeup timeout!
>
> Do you have any clue?
I'm not sure what this is, but usually an ERROR ELP wakeup timeout means
that the firmware has crashed.
Could you enable the following DEBUG flags in wl1271.h and send the logs
again? Maybe they provide more clues...
#define DEBUG_LEVEL (DEBUG_BOOT | DEBUG_ACX | DEBUG_CMD | DEBUG_PSM | \
DEBUG_IRQ | DEBUG_EVENT)
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] wl1251: fix sparse-generated warnings
From: Luciano Coelho @ 2010-07-22 6:34 UTC (permalink / raw)
To: ext John W. Linville; +Cc: linux-wireless@vger.kernel.org, Kalle Valo
In-Reply-To: <1279729917-4451-1-git-send-email-linville@tuxdriver.com>
Hi John,
Great that someone finally made the endianess changes that we never had
the time to do for wl1251. Thanks for that! :)
I took a look at your patch and I have a few minor comments below, but
the best person to comment would certainly be Kalle, not me ;)
On Wed, 2010-07-21 at 18:31 +0200, ext John W. Linville wrote:
> diff --git a/drivers/net/wireless/wl12xx/wl1251_boot.c b/drivers/net/wireless/wl12xx/wl1251_boot.c
> index 2545123..c688895 100644
> --- a/drivers/net/wireless/wl12xx/wl1251_boot.c
> +++ b/drivers/net/wireless/wl12xx/wl1251_boot.c
[...]
> @@ -467,7 +467,7 @@ static int wl1251_boot_upload_nvs(struct wl1251 *wl)
> val = (nvs_ptr[0] | (nvs_ptr[1] << 8)
> | (nvs_ptr[2] << 16) | (nvs_ptr[3] << 24));
>
> - val = cpu_to_le32(val);
> + val = (u32 __force) cpu_to_le32(val);
This will work, but such casts always make me a bit suspicious. I think
this is fine for now, but later I think we should make sure that all the
_write() functions explicitly receive __le32 as val, or receives the
cpu's u32 and converts it before actually writing the value, for clarity
reasons. Kalle, what do you think?
> diff --git a/drivers/net/wireless/wl12xx/wl1251_tx.c b/drivers/net/wireless/wl12xx/wl1251_tx.c
> index c822318..a38ec19 100644
> --- a/drivers/net/wireless/wl12xx/wl1251_tx.c
> +++ b/drivers/net/wireless/wl12xx/wl1251_tx.c
[...]
> @@ -191,11 +191,13 @@ static int wl1251_tx_send_packet(struct wl1251 *wl, struct sk_buff *skb,
> if (control->control.hw_key &&
> control->control.hw_key->alg == ALG_TKIP) {
> int hdrlen;
> - u16 fc;
> + __le16 fc;
> + u16 length;
> u8 *pos;
>
> - fc = *(u16 *)(skb->data + sizeof(*tx_hdr));
> - tx_hdr->length += WL1251_TKIP_IV_SPACE;
> + fc = *(__le16 *)(skb->data + sizeof(*tx_hdr));
Is this going to work? sizeof(*tx_hdr), and the operation, will be in
the cpu's endianess, right? Wouldn't the following be the right thing to
do then?
fc = cpu_to_le16(le16_to_cpu(skb->data) + sizeof(*tx_hdr));
Maybe some casts are needed too, I didn't check that, but regarding the
endianess, I think this is how it should go. It's the same thing as the
length parameter:
> + length = le16_to_cpu(tx_hdr->length) + WL1251_TKIP_IV_SPACE;
> + tx_hdr->length = cpu_to_le16(length);
...which is treated correctly here.
--
Cheers,
Luca.
^ permalink raw reply
* Re: ath5k debug mode
From: Jonathan Guerin @ 2010-07-22 6:32 UTC (permalink / raw)
To: Bruno Randolf; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <201007221423.28805.br1@einfach.org>
On Thu, Jul 22, 2010 at 3:23 PM, Bruno Randolf <br1@einfach.org> wrote:
> seems like ath5k is not compiled with debugging enabled (did you set
> CONFIG_ATH5K_DEBUG=y?), or you are using the wrong (old) module?
I copied the ath5k-debug config over config.mk and ran make. Make
appears to run gen-compat-autoconf with this new config, and I
double-checked that the config had CONFIG_ATH5K_DEBUG=y set.
I install the modules using: make install
When I modprobe ath5k in verbose mode, it is correctly loading the
modules from the updates directory.
Is this the correct way to do it?
Thanks heaps for replying!
--
Jonathan Guerin
^ permalink raw reply
* Re: [RFT] rtl8180: improve signal reporting for actual rtl8180 hardware
From: Pauli Nieminen @ 2010-07-22 6:07 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <1279744250-31397-1-git-send-email-linville@tuxdriver.com>
On Wed, Jul 21, 2010 at 11:30 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> Adapted from Realtek-provided driver...
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
This works for RTL8180L 802.11b MAC [10ec:8180] (rev 20)
Tested-by: Pauli Nieminen <suokkos@gmail.com>
> ---
> drivers/net/wireless/rtl818x/rtl8180_dev.c | 18 +++++++++------
> drivers/net/wireless/rtl818x/rtl8180_grf5101.c | 12 +++++++++-
> drivers/net/wireless/rtl818x/rtl8180_max2820.c | 19 +++++++++++++++-
> drivers/net/wireless/rtl818x/rtl8180_sa2400.c | 28 +++++++++++++++++++++++-
> drivers/net/wireless/rtl818x/rtl818x.h | 1 +
> 5 files changed, 68 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/wireless/rtl818x/rtl8180_dev.c b/drivers/net/wireless/rtl818x/rtl8180_dev.c
> index 31808f9..d8b186a 100644
> --- a/drivers/net/wireless/rtl818x/rtl8180_dev.c
> +++ b/drivers/net/wireless/rtl818x/rtl8180_dev.c
> @@ -103,7 +103,7 @@ static void rtl8180_handle_rx(struct ieee80211_hw *dev)
> {
> struct rtl8180_priv *priv = dev->priv;
> unsigned int count = 32;
> - u8 signal;
> + u8 signal, agc, sq;
>
> while (count--) {
> struct rtl8180_rx_desc *entry = &priv->rx_ring[priv->rx_idx];
> @@ -132,12 +132,16 @@ static void rtl8180_handle_rx(struct ieee80211_hw *dev)
>
> rx_status.antenna = (flags2 >> 15) & 1;
> 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);
> + agc = (flags2 >> 17) & 0x7F;
> + if (priv->r8185) {
> + if (rx_status.rate_idx > 3)
> + signal = 90 - clamp_t(u8, agc, 25, 90);
> + else
> + signal = 95 - clamp_t(u8, agc, 30, 95);
> + } else {
> + sq = flags2 & 0xff;
> + signal = priv->rf->calc_rssi(agc, sq);
> + }
> rx_status.signal = signal;
> rx_status.freq = dev->conf.channel->center_freq;
> rx_status.band = dev->conf.channel->band;
> diff --git a/drivers/net/wireless/rtl818x/rtl8180_grf5101.c b/drivers/net/wireless/rtl818x/rtl8180_grf5101.c
> index 947ee55..5cab9df 100644
> --- a/drivers/net/wireless/rtl818x/rtl8180_grf5101.c
> +++ b/drivers/net/wireless/rtl818x/rtl8180_grf5101.c
> @@ -69,6 +69,15 @@ static void grf5101_write_phy_antenna(struct ieee80211_hw *dev, short chan)
> rtl8180_write_phy(dev, 0x10, ant);
> }
>
> +static u8 grf5101_rf_calc_rssi(u8 agc, u8 sq)
> +{
> + if (agc > 60)
> + return 65;
> +
> + /* TODO(?): just return agc (or agc + 5) to avoid mult / div */
> + return 65 * agc / 60;
> +}
> +
> static void grf5101_rf_set_channel(struct ieee80211_hw *dev,
> struct ieee80211_conf *conf)
> {
> @@ -176,5 +185,6 @@ const struct rtl818x_rf_ops grf5101_rf_ops = {
> .name = "GCT",
> .init = grf5101_rf_init,
> .stop = grf5101_rf_stop,
> - .set_chan = grf5101_rf_set_channel
> + .set_chan = grf5101_rf_set_channel,
> + .calc_rssi = grf5101_rf_calc_rssi,
> };
> diff --git a/drivers/net/wireless/rtl818x/rtl8180_max2820.c b/drivers/net/wireless/rtl818x/rtl8180_max2820.c
> index 6c825fd..16c4655 100644
> --- a/drivers/net/wireless/rtl818x/rtl8180_max2820.c
> +++ b/drivers/net/wireless/rtl818x/rtl8180_max2820.c
> @@ -74,6 +74,22 @@ static void max2820_write_phy_antenna(struct ieee80211_hw *dev, short chan)
> rtl8180_write_phy(dev, 0x10, ant);
> }
>
> +static u8 max2820_rf_calc_rssi(u8 agc, u8 sq)
> +{
> + bool odd;
> +
> + odd = !!(agc & 1);
> +
> + agc >>= 1;
> + if (odd)
> + agc += 76;
> + else
> + agc += 66;
> +
> + /* TODO: change addends above to avoid mult / div below */
> + return 65 * agc / 100;
> +}
> +
> static void max2820_rf_set_channel(struct ieee80211_hw *dev,
> struct ieee80211_conf *conf)
> {
> @@ -148,5 +164,6 @@ const struct rtl818x_rf_ops max2820_rf_ops = {
> .name = "Maxim",
> .init = max2820_rf_init,
> .stop = max2820_rf_stop,
> - .set_chan = max2820_rf_set_channel
> + .set_chan = max2820_rf_set_channel,
> + .calc_rssi = max2820_rf_calc_rssi,
> };
> diff --git a/drivers/net/wireless/rtl818x/rtl8180_sa2400.c b/drivers/net/wireless/rtl818x/rtl8180_sa2400.c
> index cea4e0c..d064fcc 100644
> --- a/drivers/net/wireless/rtl818x/rtl8180_sa2400.c
> +++ b/drivers/net/wireless/rtl818x/rtl8180_sa2400.c
> @@ -76,6 +76,31 @@ static void sa2400_write_phy_antenna(struct ieee80211_hw *dev, short chan)
>
> }
>
> +static u8 sa2400_rf_rssi_map[] = {
> + 0x64, 0x64, 0x63, 0x62, 0x61, 0x60, 0x5f, 0x5e,
> + 0x5d, 0x5c, 0x5b, 0x5a, 0x57, 0x54, 0x52, 0x50,
> + 0x4e, 0x4c, 0x4a, 0x48, 0x46, 0x44, 0x41, 0x3f,
> + 0x3c, 0x3a, 0x37, 0x36, 0x36, 0x1c, 0x1c, 0x1b,
> + 0x1b, 0x1a, 0x1a, 0x19, 0x19, 0x18, 0x18, 0x17,
> + 0x17, 0x16, 0x16, 0x15, 0x15, 0x14, 0x14, 0x13,
> + 0x13, 0x12, 0x12, 0x11, 0x11, 0x10, 0x10, 0x0f,
> + 0x0f, 0x0e, 0x0e, 0x0d, 0x0d, 0x0c, 0x0c, 0x0b,
> + 0x0b, 0x0a, 0x0a, 0x09, 0x09, 0x08, 0x08, 0x07,
> + 0x07, 0x06, 0x06, 0x05, 0x04, 0x03, 0x02,
> +};
> +
> +static u8 sa2400_rf_calc_rssi(u8 agc, u8 sq)
> +{
> + if (sq == 0x80)
> + return 1;
> +
> + if (sq > 78)
> + return 32;
> +
> + /* TODO: recalc sa2400_rf_rssi_map to avoid mult / div */
> + return 65 * sa2400_rf_rssi_map[sq] / 100;
> +}
> +
> static void sa2400_rf_set_channel(struct ieee80211_hw *dev,
> struct ieee80211_conf *conf)
> {
> @@ -198,5 +223,6 @@ const struct rtl818x_rf_ops sa2400_rf_ops = {
> .name = "Philips",
> .init = sa2400_rf_init,
> .stop = sa2400_rf_stop,
> - .set_chan = sa2400_rf_set_channel
> + .set_chan = sa2400_rf_set_channel,
> + .calc_rssi = sa2400_rf_calc_rssi,
> };
> diff --git a/drivers/net/wireless/rtl818x/rtl818x.h b/drivers/net/wireless/rtl818x/rtl818x.h
> index 8522490..22d9384 100644
> --- a/drivers/net/wireless/rtl818x/rtl818x.h
> +++ b/drivers/net/wireless/rtl818x/rtl818x.h
> @@ -193,6 +193,7 @@ struct rtl818x_rf_ops {
> void (*stop)(struct ieee80211_hw *);
> void (*set_chan)(struct ieee80211_hw *, struct ieee80211_conf *);
> void (*conf_erp)(struct ieee80211_hw *, struct ieee80211_bss_conf *);
> + u8 (*calc_rssi)(u8 agc, u8 sq);
> };
>
> /**
> --
> 1.7.1.1
>
>
^ permalink raw reply
* Re: ath5k debug mode
From: Bruno Randolf @ 2010-07-22 5:23 UTC (permalink / raw)
To: Jonathan Guerin; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <AANLkTimWWGlhEhIRol_5kjhIIEILLgDuMmUXUHCCVUC1@mail.gmail.com>
On Thu July 22 2010 13:55:36 Jonathan Guerin wrote:
> Hi all,
>
> I'm not sure if I'm just misunderstanding something, or if they
> documentation is older than what's happening in practice. I'm trying
> to enable ath5k debug mode so that I can have a poke around in debufs.
>
> Unfortunately, enabling debug in the compat-wireless distro doesn't
> seem to output the same information as I've been reading about
> elsewhere on the 'net. My understanding is that ath5k should load an
> ath5k directory tree into debugfs:
> http://www.mail-archive.com/ath5k-devel@lists.ath5k.org/msg00266.html
>
> This doesn't seem to be happening at the moment - what I CAN see in
> the /debug tree is:
> bdi gpio ieee80211 kprobes mce pktcdvd sched_features tracing usb
> x86
>
> Some of the stuff I expect to see in ath5k is in ieee8022, but I
> cannot write to this tree. Trying to replicate the cat mentioned in
> the link above to set the debug level in this tree fails with a
> 'permission denied' error.
>
> Trying to load the module with the debug param fails with the following
> error: ath5k: Unknown parameter `debug'
>
> I'm wondering if someone would be able to point me in the right
> direction to get this working.
seems like ath5k is not compiled with debugging enabled (did you set
CONFIG_ATH5K_DEBUG=y?), or you are using the wrong (old) module?
bruno
^ permalink raw reply
* ath5k debug mode
From: Jonathan Guerin @ 2010-07-22 4:55 UTC (permalink / raw)
To: linux-wireless, ath5k-devel
Hi all,
I'm not sure if I'm just misunderstanding something, or if they
documentation is older than what's happening in practice. I'm trying
to enable ath5k debug mode so that I can have a poke around in debufs.
Unfortunately, enabling debug in the compat-wireless distro doesn't
seem to output the same information as I've been reading about
elsewhere on the 'net. My understanding is that ath5k should load an
ath5k directory tree into debugfs:
http://www.mail-archive.com/ath5k-devel@lists.ath5k.org/msg00266.html
This doesn't seem to be happening at the moment - what I CAN see in
the /debug tree is:
bdi gpio ieee80211 kprobes mce pktcdvd sched_features tracing usb x86
Some of the stuff I expect to see in ath5k is in ieee8022, but I
cannot write to this tree. Trying to replicate the cat mentioned in
the link above to set the debug level in this tree fails with a
'permission denied' error.
Trying to load the module with the debug param fails with the following error:
ath5k: Unknown parameter `debug'
I'm wondering if someone would be able to point me in the right
direction to get this working.
Your help would be greatly appreciated!
Thanks,
--
Jonathan Guerin
^ permalink raw reply
* Re: [PATCH] compat-wireless: refresh patch
From: Luis R. Rodriguez @ 2010-07-22 1:09 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-wireless, mcgrof
In-Reply-To: <1279740434-13086-1-git-send-email-hauke@hauke-m.de>
On Wed, Jul 21, 2010 at 12:27 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Thanks applied!
Luis
^ permalink raw reply
* Re: [ath9k-devel] ath9k: performance regressions / tx semi-stuck somehow
From: Felix Fietkau @ 2010-07-22 0:32 UTC (permalink / raw)
To: Björn Smedman; +Cc: ath9k-devel, linux-wireless
In-Reply-To: <AANLkTimQ7O2nOmh2Rda3d_PKWbS2WlGVBHYMCuhxW10W@mail.gmail.com>
On 2010-07-22 12:17 AM, Björn Smedman wrote:
> Hi all,
>
> I just tried out compat-wireless-2010-07-16 on AR913x (with
> openwrt/trunk@r22321) and saw some weird performance problems.
>
> That's in exactly the same spot I was getting 16Mbps consistently with
> AP was 11n!
>
> Any debuging I can do to help? Bisecting is unfortunately a lot of
> work on this embedded system...
Could you please try if the earlier version that was in OpenWrt
(2010-07-06) has the same issues?
- Felix
^ permalink raw reply
* ath9k: performance regressions / tx semi-stuck somehow
From: Björn Smedman @ 2010-07-21 22:17 UTC (permalink / raw)
To: ath9k-devel, linux-wireless
Hi all,
I just tried out compat-wireless-2010-07-16 on AR913x (with
openwrt/trunk@r22321) and saw some weird performance problems.
First, with the default 11n HT20 AP configuration I get really good
performance on an old 11g MacBook. 16Mbps downloads limited by WAN. :)
But then I try a newer 11n MacBook and performance absolutely sucks.
2-3Mbps downloads with erratic bursts and "hangs".
So, I start to think something is wrong with 11n and reconfigure for
11g only. Then the 11g MacBook performance also sucks. The same
2-3Mbps downloads with erratic bursts and "hangs". So 11n AP and 11g
client is good, but 11g AP and 11g client sucks. Looking at the
rc_stats it seems like tx completely breaks down from time to time:
root@OpenWrt:/sys/kernel/debug/ieee80211/phy0# cat stations/00\:17\:f2\:51\:b2\:
2d/rc_stats
rate throughput ewma prob this prob this succ/attempt
success attempts
t 1 0.1 18.3 0.0 0( 19) 28 731
2 0.0 0.0 0.0 0( 0) 0 18
5.5 0.0 0.0 0.0 0( 0) 0 10
11 0.0 0.0 0.0 0( 0) 0 14
6 0.0 0.0 0.0 0( 0) 0 11
9 0.0 0.0 0.0 0( 0) 0 18
12 0.0 0.0 0.0 0( 0) 0 12
18 0.0 0.0 0.0 0( 0) 0 16
24 0.0 0.0 0.0 0( 0) 0 18
36 0.1 0.4 0.0 0( 0) 2 1824
48 0.0 0.0 0.0 0( 2) 0 16
T P 54 27.3 63.1 0.0 0(180) 4749 13896
Total packet count:: ideal 4780 lookaround 532
That's in exactly the same spot I was getting 16Mbps consistently with
AP was 11n!
Any debuging I can do to help? Bisecting is unfortunately a lot of
work on this embedded system...
/Björn
^ permalink raw reply
* potential null deref in iwlagn_request_scan()?
From: Dan Carpenter @ 2010-07-21 22:16 UTC (permalink / raw)
To: johannes.berg; +Cc: linux-wireless
Smatch complains about iwlagn_request_scan().
drivers/net/wireless/iwlwifi/iwl-agn-lib.c +1354 iwlagn_request_scan(204)
error: we previously assumed 'vif' could be null.
1351 if (!priv->is_internal_short_scan) {
1352 cmd_len = iwl_fill_probe_req(priv,
1353 (struct ieee80211_mgmt *)scan->data,
1354 vif->addr,
^^^^^^^^^
1355 priv->scan_request->ie,
1356 priv->scan_request->ie_len,
1357 IWL_MAX_SCAN_SIZE - sizeof(*scan));
1358 } else {
1359 /* use bcast addr, will not be transmitted but must be valid */
This was added in 3a0b9aad0a8166e9f "iwlwifi: use virtual interface
address for scan". Prior to that commit the function assumed that vif
could be NULL throughout.
I don't know the code well enough to know what to do about this.
Also the same thing for:
drivers/net/wireless/iwlwifi/iwl3945-base.c +2963 iwl3945_request_scan(158)
error: we previously assumed 'vif' could be null.
2962 if (!priv->is_internal_short_scan) {
2963 scan->tx_cmd.len = cpu_to_le16(
2964 iwl_fill_probe_req(priv,
2965 (struct ieee80211_mgmt *)scan->data,
2966 vif->addr,
^^^^^^^^^
2967 priv->scan_request->ie,
2968 priv->scan_request->ie_len,
2969 IWL_MAX_SCAN_SIZE - sizeof(*scan)));
2970 } else {
This is from the above commit as well.
regards,
dan carpenter
^ permalink raw reply
* Re: iwlagn and many firmware restarts with Fedora kernel
From: drago01 @ 2010-07-21 21:00 UTC (permalink / raw)
To: Guy, Wey-Yi; +Cc: Marcel Holtmann, linux-wireless@vger.kernel.org
In-Reply-To: <1279744628.6548.0.camel@wwguy-ubuntu>
On Wed, Jul 21, 2010 at 10:37 PM, Guy, Wey-Yi <wey-yi.w.guy@intel.com> wrote:
> Hi drago,
> On Wed, 2010-07-21 at 12:59 -0700, drago01 wrote:
>> On Tue, Jul 20, 2010 at 1:56 AM, Guy, Wey-Yi <wey-yi.w.guy@intel.com> wrote:
>> > Hi drago,
>> >
>> >
>> > Are you using 5350? here I attach a "RFC patch", could you give a try to
>> > see if it help?
>>
>> Not quite I am on 5300; your patch seem to only touch the 5350 code
>> ... should I try the same change for 5300?
>
> Yes, please
Hi,
As there is no such field in .34 I patched the .35 driver which seems
to be fine with the change ... I couldn't trigger it using the close
lid (no suspend) and wait a bit trick ... but I have not used it for
long enough to say for certain that its gone.
But unfortunately the driver has a different issue it spams my log with tons of:
iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
iwlagn 0000:02:00.0: BA scd_flow 0 does not match txq_id 10
messages.
^ permalink raw reply
* Re: [PATCH] wireless: remove prism54
From: Luis R. Rodriguez @ 2010-07-21 20:58 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, Christian Lamparter
In-Reply-To: <1279735518-12515-1-git-send-email-linville@tuxdriver.com>
On Wed, Jul 21, 2010 at 11:05 AM, John W. Linville
<linville@tuxdriver.com> wrote:
> This driver is no longer necessary due to p54pci. It has seen very
> little maintenance for some time, and at least Fedora has had it
> disabled without any user complaints.
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Hm, we had a few users report back that only with prism54 and not
p54pci could they get their device functional. IIRC Christian noted
some issues with the EEPROM, and it seems the fault was on the
manufacturer. My memory may be foggy but indeed I do remember a few
users did complain about the feature removal plan. I can dig these
e-mails up if needed.
Luis
^ permalink raw reply
* [RFT] rtl8180: improve signal reporting for actual rtl8180 hardware
From: John W. Linville @ 2010-07-21 20:30 UTC (permalink / raw)
To: linux-wireless; +Cc: Pauli Nieminen, John W. Linville
In-Reply-To: <20100721171926.GE2355@tuxdriver.com>
Adapted from Realtek-provided driver...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/rtl818x/rtl8180_dev.c | 18 +++++++++------
drivers/net/wireless/rtl818x/rtl8180_grf5101.c | 12 +++++++++-
drivers/net/wireless/rtl818x/rtl8180_max2820.c | 19 +++++++++++++++-
drivers/net/wireless/rtl818x/rtl8180_sa2400.c | 28 +++++++++++++++++++++++-
drivers/net/wireless/rtl818x/rtl818x.h | 1 +
5 files changed, 68 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8180_dev.c b/drivers/net/wireless/rtl818x/rtl8180_dev.c
index 31808f9..d8b186a 100644
--- a/drivers/net/wireless/rtl818x/rtl8180_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8180_dev.c
@@ -103,7 +103,7 @@ static void rtl8180_handle_rx(struct ieee80211_hw *dev)
{
struct rtl8180_priv *priv = dev->priv;
unsigned int count = 32;
- u8 signal;
+ u8 signal, agc, sq;
while (count--) {
struct rtl8180_rx_desc *entry = &priv->rx_ring[priv->rx_idx];
@@ -132,12 +132,16 @@ static void rtl8180_handle_rx(struct ieee80211_hw *dev)
rx_status.antenna = (flags2 >> 15) & 1;
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);
+ agc = (flags2 >> 17) & 0x7F;
+ if (priv->r8185) {
+ if (rx_status.rate_idx > 3)
+ signal = 90 - clamp_t(u8, agc, 25, 90);
+ else
+ signal = 95 - clamp_t(u8, agc, 30, 95);
+ } else {
+ sq = flags2 & 0xff;
+ signal = priv->rf->calc_rssi(agc, sq);
+ }
rx_status.signal = signal;
rx_status.freq = dev->conf.channel->center_freq;
rx_status.band = dev->conf.channel->band;
diff --git a/drivers/net/wireless/rtl818x/rtl8180_grf5101.c b/drivers/net/wireless/rtl818x/rtl8180_grf5101.c
index 947ee55..5cab9df 100644
--- a/drivers/net/wireless/rtl818x/rtl8180_grf5101.c
+++ b/drivers/net/wireless/rtl818x/rtl8180_grf5101.c
@@ -69,6 +69,15 @@ static void grf5101_write_phy_antenna(struct ieee80211_hw *dev, short chan)
rtl8180_write_phy(dev, 0x10, ant);
}
+static u8 grf5101_rf_calc_rssi(u8 agc, u8 sq)
+{
+ if (agc > 60)
+ return 65;
+
+ /* TODO(?): just return agc (or agc + 5) to avoid mult / div */
+ return 65 * agc / 60;
+}
+
static void grf5101_rf_set_channel(struct ieee80211_hw *dev,
struct ieee80211_conf *conf)
{
@@ -176,5 +185,6 @@ const struct rtl818x_rf_ops grf5101_rf_ops = {
.name = "GCT",
.init = grf5101_rf_init,
.stop = grf5101_rf_stop,
- .set_chan = grf5101_rf_set_channel
+ .set_chan = grf5101_rf_set_channel,
+ .calc_rssi = grf5101_rf_calc_rssi,
};
diff --git a/drivers/net/wireless/rtl818x/rtl8180_max2820.c b/drivers/net/wireless/rtl818x/rtl8180_max2820.c
index 6c825fd..16c4655 100644
--- a/drivers/net/wireless/rtl818x/rtl8180_max2820.c
+++ b/drivers/net/wireless/rtl818x/rtl8180_max2820.c
@@ -74,6 +74,22 @@ static void max2820_write_phy_antenna(struct ieee80211_hw *dev, short chan)
rtl8180_write_phy(dev, 0x10, ant);
}
+static u8 max2820_rf_calc_rssi(u8 agc, u8 sq)
+{
+ bool odd;
+
+ odd = !!(agc & 1);
+
+ agc >>= 1;
+ if (odd)
+ agc += 76;
+ else
+ agc += 66;
+
+ /* TODO: change addends above to avoid mult / div below */
+ return 65 * agc / 100;
+}
+
static void max2820_rf_set_channel(struct ieee80211_hw *dev,
struct ieee80211_conf *conf)
{
@@ -148,5 +164,6 @@ const struct rtl818x_rf_ops max2820_rf_ops = {
.name = "Maxim",
.init = max2820_rf_init,
.stop = max2820_rf_stop,
- .set_chan = max2820_rf_set_channel
+ .set_chan = max2820_rf_set_channel,
+ .calc_rssi = max2820_rf_calc_rssi,
};
diff --git a/drivers/net/wireless/rtl818x/rtl8180_sa2400.c b/drivers/net/wireless/rtl818x/rtl8180_sa2400.c
index cea4e0c..d064fcc 100644
--- a/drivers/net/wireless/rtl818x/rtl8180_sa2400.c
+++ b/drivers/net/wireless/rtl818x/rtl8180_sa2400.c
@@ -76,6 +76,31 @@ static void sa2400_write_phy_antenna(struct ieee80211_hw *dev, short chan)
}
+static u8 sa2400_rf_rssi_map[] = {
+ 0x64, 0x64, 0x63, 0x62, 0x61, 0x60, 0x5f, 0x5e,
+ 0x5d, 0x5c, 0x5b, 0x5a, 0x57, 0x54, 0x52, 0x50,
+ 0x4e, 0x4c, 0x4a, 0x48, 0x46, 0x44, 0x41, 0x3f,
+ 0x3c, 0x3a, 0x37, 0x36, 0x36, 0x1c, 0x1c, 0x1b,
+ 0x1b, 0x1a, 0x1a, 0x19, 0x19, 0x18, 0x18, 0x17,
+ 0x17, 0x16, 0x16, 0x15, 0x15, 0x14, 0x14, 0x13,
+ 0x13, 0x12, 0x12, 0x11, 0x11, 0x10, 0x10, 0x0f,
+ 0x0f, 0x0e, 0x0e, 0x0d, 0x0d, 0x0c, 0x0c, 0x0b,
+ 0x0b, 0x0a, 0x0a, 0x09, 0x09, 0x08, 0x08, 0x07,
+ 0x07, 0x06, 0x06, 0x05, 0x04, 0x03, 0x02,
+};
+
+static u8 sa2400_rf_calc_rssi(u8 agc, u8 sq)
+{
+ if (sq == 0x80)
+ return 1;
+
+ if (sq > 78)
+ return 32;
+
+ /* TODO: recalc sa2400_rf_rssi_map to avoid mult / div */
+ return 65 * sa2400_rf_rssi_map[sq] / 100;
+}
+
static void sa2400_rf_set_channel(struct ieee80211_hw *dev,
struct ieee80211_conf *conf)
{
@@ -198,5 +223,6 @@ const struct rtl818x_rf_ops sa2400_rf_ops = {
.name = "Philips",
.init = sa2400_rf_init,
.stop = sa2400_rf_stop,
- .set_chan = sa2400_rf_set_channel
+ .set_chan = sa2400_rf_set_channel,
+ .calc_rssi = sa2400_rf_calc_rssi,
};
diff --git a/drivers/net/wireless/rtl818x/rtl818x.h b/drivers/net/wireless/rtl818x/rtl818x.h
index 8522490..22d9384 100644
--- a/drivers/net/wireless/rtl818x/rtl818x.h
+++ b/drivers/net/wireless/rtl818x/rtl818x.h
@@ -193,6 +193,7 @@ struct rtl818x_rf_ops {
void (*stop)(struct ieee80211_hw *);
void (*set_chan)(struct ieee80211_hw *, struct ieee80211_conf *);
void (*conf_erp)(struct ieee80211_hw *, struct ieee80211_bss_conf *);
+ u8 (*calc_rssi)(u8 agc, u8 sq);
};
/**
--
1.7.1.1
^ permalink raw reply related
* [PATCH] rtl8180: silence "dubious: x | !y" sparse warning
From: John W. Linville @ 2010-07-21 20:38 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
CHECK drivers/net/wireless/rtl818x/rtl8180_rtl8225.c
drivers/net/wireless/rtl818x/rtl8180_rtl8225.c:53:33: warning: dubious: x | !y
The existing code is clever and works fine, but it's not worth even a
single line of Sparse warning SPAM...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/rtl818x/rtl8180_rtl8225.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8180_rtl8225.c b/drivers/net/wireless/rtl818x/rtl8180_rtl8225.c
index 4d2be0d..69e4d47 100644
--- a/drivers/net/wireless/rtl818x/rtl8180_rtl8225.c
+++ b/drivers/net/wireless/rtl818x/rtl8180_rtl8225.c
@@ -50,7 +50,10 @@ static void rtl8225_write(struct ieee80211_hw *dev, u8 addr, u16 data)
udelay(10);
for (i = 15; i >= 0; i--) {
- u16 reg = reg80 | !!(bangdata & (1 << i));
+ u16 reg = reg80;
+
+ if (bangdata & (1 << i))
+ reg |= 1;
if (i & 1)
rtl818x_iowrite16(priv, &priv->map->RFPinsOutput, reg);
--
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