* Compat-wireless release for 2011-10-08 is baked
From: Compat-wireless cronjob account @ 2011-10-08 19:02 UTC (permalink / raw)
To: linux-wireless
compat-wireless code metrics
811845 - Total upstream lines of code being pulled
2431 - backport code changes
2113 - backport code additions
318 - backport code deletions
8588 - backport from compat module
11019 - total backport code
1.3573 - % of code consists of backport work
^ permalink raw reply
* Re: [PATCH] wl12xx: remove warning message during IBSS Tx
From: Arik Nemtsov @ 2011-10-08 19:19 UTC (permalink / raw)
To: Luciano Coelho; +Cc: Shahar Lev, Johannes Berg, linux-wireless
In-Reply-To: <1318022253.3549.108.camel@cumari>
On Fri, Oct 7, 2011 at 23:17, Luciano Coelho <coelho@ti.com> wrote:
> On Fri, 2011-10-07 at 23:03 +0200, Shahar Lev wrote:
>> On Fri, Oct 7, 2011 at 6:20 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> > Maybe you should also change that? :-)
>>
>> Consider it added to our collective TODO.
>
> Well, the fix is probably supposed to be done in mac80211, instead of
> hiding the bug by removing the warning, isn't it?
Sometimes data is sent when the IBSS interface is not connected.
wl12xx handles this correctly by throwing the packets. In this sense
there's no "bug".
All this patch does is remove warning messages that confuse the users
(and developers).
I agree fixing mac80211 is the better thing to do, and we'll get to it
when time permits.
Arik
^ permalink raw reply
* problem in b43_nrssi_hw_update()?
From: Dan Carpenter @ 2011-10-08 19:29 UTC (permalink / raw)
To: mb; +Cc: linux-wireless
My latest testing version of Smatch complains about the wrapping in
b43_nrssi_hw_update() when val is 0xffff. The function is defined
like this:
/* http://bcm-specs.sipsolutions.net/NRSSILookupTable */
static void b43_nrssi_hw_update(struct b43_wldev *dev, u16 val)
{
u16 i;
s16 tmp;
for (i = 0; i < 64; i++) {
tmp = b43_nrssi_hw_read(dev, i);
tmp -= val;
tmp = clamp_val(tmp, -32, 31);
b43_nrssi_hw_write(dev, i, tmp);
}
}
It's only called from one place like this:
/* The specs state to update the NRSSI LT with
* the value 0x7FFFFFFF here. I think that is some weird
* compiler optimization in the original driver.
* Essentially, what we do here is resetting all NRSSI LT
* entries to -32 (see the clamp_val() in nrssi_hw_update())
*/
b43_nrssi_hw_update(dev, 0xFFFF); //FIXME?
Since tmp in b43_nrssi_hw_update() is s16 and val is always
(u16)0xFFFF, that means that:
tmp -= val;
is always the same just tmp += 1;
This code has a fixme, and it seems like an overly complicated way
of adding 1 to a variable, plus it doesn't seem to match the
documentation very well. :P
I know you've looked at this before and that's why it has the FIXME
comment... I'm not sure what to do...
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] wl12xx: remove warning message during IBSS Tx
From: Luciano Coelho @ 2011-10-08 19:45 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: Shahar Lev, Johannes Berg, linux-wireless
In-Reply-To: <CA+XVXfd+vN7b=oYrysPCuynAgy5=4SgRHuznJRW0h+6ez7YqsQ@mail.gmail.com>
On Sat, 2011-10-08 at 21:19 +0200, Arik Nemtsov wrote:
> On Fri, Oct 7, 2011 at 23:17, Luciano Coelho <coelho@ti.com> wrote:
> > On Fri, 2011-10-07 at 23:03 +0200, Shahar Lev wrote:
> >> On Fri, Oct 7, 2011 at 6:20 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> >> > Maybe you should also change that? :-)
> >>
> >> Consider it added to our collective TODO.
> >
> > Well, the fix is probably supposed to be done in mac80211, instead of
> > hiding the bug by removing the warning, isn't it?
>
> Sometimes data is sent when the IBSS interface is not connected.
> wl12xx handles this correctly by throwing the packets. In this sense
> there's no "bug".
> All this patch does is remove warning messages that confuse the users
> (and developers).
>
> I agree fixing mac80211 is the better thing to do, and we'll get to it
> when time permits.
Okay, not a big problem to do this in the driver.
But what I meant with "the bug" was that, if this can be avoided in
mac80211, why not do it there? Is it a a big effort to do it in
mac80211?
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] wl12xx: remove warning message during IBSS Tx
From: Arik Nemtsov @ 2011-10-08 19:55 UTC (permalink / raw)
To: Luciano Coelho; +Cc: Shahar Lev, Johannes Berg, linux-wireless
In-Reply-To: <1318103127.9690.46.camel@cumari>
On Sat, Oct 8, 2011 at 21:45, Luciano Coelho <coelho@ti.com> wrote:
>
> But what I meant with "the bug" was that, if this can be avoided in
> mac80211, why not do it there? Is it a a big effort to do it in
> mac80211?
Not sure it's a big effort, but it requires testing etc. I'm afraid
we're all pretty busy with other stuff right now :)
Arik
^ permalink raw reply
* Re: [PATCH] wl12xx: remove warning message during IBSS Tx
From: Luciano Coelho @ 2011-10-08 20:02 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: Shahar Lev, Johannes Berg, linux-wireless
In-Reply-To: <CA+XVXff_5isgfReUYXh8K1nNTtAqnFp5tb36EKLL7MBaTka+UQ@mail.gmail.com>
On Sat, 2011-10-08 at 21:55 +0200, Arik Nemtsov wrote:
> On Sat, Oct 8, 2011 at 21:45, Luciano Coelho <coelho@ti.com> wrote:
> >
> > But what I meant with "the bug" was that, if this can be avoided in
> > mac80211, why not do it there? Is it a a big effort to do it in
> > mac80211?
>
> Not sure it's a big effort, but it requires testing etc. I'm afraid
> we're all pretty busy with other stuff right now :)
Not a very good excuse when it comes to upstreaming, but okay, I'll take
this in anyway. :)
Thanks, Shahar, and welcome! :)
(BTW, Shahar Lev is not to be confused with Shahar Levi, as they are two
different persons :)
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH 1/2] ath9k_hw: fix a regression in key miss handling
From: Felix Fietkau @ 2011-10-08 20:02 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, mcgrof
The commit "ath9k_hw: Fix incorrect key_miss handling" changed the code
to only report key miss errors if a MIC error wasn't reported.
When checking the flags in that order in the MAC code, it might miss some
real events, because the value of the MIC error flag is undefined under
some conditions.
The primary issue addressed by the previous commit is making sure that
MIC errors are properly reported on the STA side. This can be fixed in
a better way by adding a separate rx status flag for key miss and
ignoring it for multicast frames.
This fix slightly improves stability in AP mode on some older hardware,
like AR9132.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
---
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 4 ++--
drivers/net/wireless/ath/ath9k/mac.c | 4 ++--
drivers/net/wireless/ath/ath9k/mac.h | 1 +
drivers/net/wireless/ath/ath9k/recv.c | 27 ++++++++++++++-------------
4 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
index 6cabc85..b363cc0 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -525,8 +525,8 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs,
rxs->rs_status |= ATH9K_RXERR_DECRYPT;
else if (rxsp->status11 & AR_MichaelErr)
rxs->rs_status |= ATH9K_RXERR_MIC;
- else if (rxsp->status11 & AR_KeyMiss)
- rxs->rs_status |= ATH9K_RXERR_DECRYPT;
+ if (rxsp->status11 & AR_KeyMiss)
+ rxs->rs_status |= ATH9K_RXERR_KEYMISS;
}
return 0;
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index 22f23ea..43f53d6 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -620,8 +620,8 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
rs->rs_status |= ATH9K_RXERR_DECRYPT;
else if (ads.ds_rxstatus8 & AR_MichaelErr)
rs->rs_status |= ATH9K_RXERR_MIC;
- else if (ads.ds_rxstatus8 & AR_KeyMiss)
- rs->rs_status |= ATH9K_RXERR_DECRYPT;
+ if (ads.ds_rxstatus8 & AR_KeyMiss)
+ rs->rs_status |= ATH9K_RXERR_KEYMISS;
}
return 0;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h b/drivers/net/wireless/ath/ath9k/mac.h
index 91c9654..934caa7 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -181,6 +181,7 @@ struct ath_htc_rx_status {
#define ATH9K_RXERR_FIFO 0x04
#define ATH9K_RXERR_DECRYPT 0x08
#define ATH9K_RXERR_MIC 0x10
+#define ATH9K_RXERR_KEYMISS 0x20
#define ATH9K_RX_MORE 0x01
#define ATH9K_RX_MORE_AGGR 0x02
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index f658ec6..c7306dc 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -823,7 +823,8 @@ static bool ath9k_rx_accept(struct ath_common *common,
test_bit(rx_stats->rs_keyix, common->tkip_keymap);
strip_mic = is_valid_tkip && ieee80211_is_data(fc) &&
!(rx_stats->rs_status &
- (ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC));
+ (ATH9K_RXERR_DECRYPT | ATH9K_RXERR_CRC | ATH9K_RXERR_MIC |
+ ATH9K_RXERR_KEYMISS));
if (!rx_stats->rs_datalen)
return false;
@@ -851,6 +852,8 @@ static bool ath9k_rx_accept(struct ath_common *common,
* descriptors.
*/
if (rx_stats->rs_status != 0) {
+ u8 status_mask;
+
if (rx_stats->rs_status & ATH9K_RXERR_CRC) {
rxs->flag |= RX_FLAG_FAILED_FCS_CRC;
mic_error = false;
@@ -858,7 +861,8 @@ static bool ath9k_rx_accept(struct ath_common *common,
if (rx_stats->rs_status & ATH9K_RXERR_PHY)
return false;
- if (rx_stats->rs_status & ATH9K_RXERR_DECRYPT) {
+ if ((rx_stats->rs_status & ATH9K_RXERR_DECRYPT) ||
+ (!is_mc && (rx_stats->rs_status & ATH9K_RXERR_KEYMISS))) {
*decrypt_error = true;
mic_error = false;
}
@@ -868,17 +872,14 @@ static bool ath9k_rx_accept(struct ath_common *common,
* decryption and MIC failures. For monitor mode,
* we also ignore the CRC error.
*/
- if (ah->is_monitoring) {
- if (rx_stats->rs_status &
- ~(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_MIC |
- ATH9K_RXERR_CRC))
- return false;
- } else {
- if (rx_stats->rs_status &
- ~(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_MIC)) {
- return false;
- }
- }
+ status_mask = ATH9K_RXERR_DECRYPT | ATH9K_RXERR_MIC |
+ ATH9K_RXERR_KEYMISS;
+
+ if (ah->is_monitoring)
+ status_mask |= ATH9K_RXERR_CRC;
+
+ if (rx_stats->rs_status & ~status_mask)
+ return false;
}
/*
--
1.7.3.2
^ permalink raw reply related
* [PATCH 2/2] ath9k: only send FCS-fail packets to mac80211 if requested
From: Felix Fietkau @ 2011-10-08 20:02 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, mcgrof
In-Reply-To: <1318104179-90126-1-git-send-email-nbd@openwrt.org>
Prevents lots of broken frames from showing up on monitor interfaces
by default.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/recv.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index c7306dc..bc71c0e 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -811,6 +811,7 @@ static bool ath9k_rx_accept(struct ath_common *common,
struct ath_rx_status *rx_stats,
bool *decrypt_error)
{
+ struct ath_softc *sc = (struct ath_softc *) common->priv;
bool is_mc, is_valid_tkip, strip_mic, mic_error;
struct ath_hw *ah = common->ah;
__le16 fc;
@@ -875,7 +876,7 @@ static bool ath9k_rx_accept(struct ath_common *common,
status_mask = ATH9K_RXERR_DECRYPT | ATH9K_RXERR_MIC |
ATH9K_RXERR_KEYMISS;
- if (ah->is_monitoring)
+ if (ah->is_monitoring && (sc->rx.rxfilter & FIF_FCSFAIL))
status_mask |= ATH9K_RXERR_CRC;
if (rx_stats->rs_status & ~status_mask)
--
1.7.3.2
^ permalink raw reply related
* Re: [PATCH] wl12xx: remove warning message during IBSS Tx
From: Shahar Lev @ 2011-10-08 20:30 UTC (permalink / raw)
To: Luciano Coelho; +Cc: Arik Nemtsov, Johannes Berg, linux-wireless
In-Reply-To: <1318104160.9690.49.camel@cumari>
Part of a plot to increase the chances of my submissions getting
through by posing as Mr. Levi.
Thanks,
The Other Shahar
On Sat, Oct 8, 2011 at 10:02 PM, Luciano Coelho <coelho@ti.com> wrote:
> On Sat, 2011-10-08 at 21:55 +0200, Arik Nemtsov wrote:
>> On Sat, Oct 8, 2011 at 21:45, Luciano Coelho <coelho@ti.com> wrote:
>> >
>> > But what I meant with "the bug" was that, if this can be avoided in
>> > mac80211, why not do it there? Is it a a big effort to do it in
>> > mac80211?
>>
>> Not sure it's a big effort, but it requires testing etc. I'm afraid
>> we're all pretty busy with other stuff right now :)
>
> Not a very good excuse when it comes to upstreaming, but okay, I'll take
> this in anyway. :)
>
> Thanks, Shahar, and welcome! :)
>
> (BTW, Shahar Lev is not to be confused with Shahar Levi, as they are two
> different persons :)
>
> --
> Cheers,
> Luca.
>
>
^ permalink raw reply
* [PATCH] ssb: Convert to use crc8 code in kernel library
From: Larry Finger @ 2011-10-08 22:28 UTC (permalink / raw)
To: John W Linville; +Cc: Michael Buesch, zajec5, b43-dev, linux-wireless
The kernel now contains library routines to establish crc8 tables and
to calculate the appropriate sums. Use them for ssb.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
John,
This is -next material.
This has been tested on both and little- and big-endian platforms.
Larry
---
Kconfig | 1
pci.c | 85 ++++++++++++++++++----------------------------------------------
2 files changed, 26 insertions(+), 60 deletions(-)
Index: wireless-testing-new/drivers/ssb/pci.c
===================================================================
--- wireless-testing-new.orig/drivers/ssb/pci.c
+++ wireless-testing-new/drivers/ssb/pci.c
@@ -20,6 +20,7 @@
#include <linux/slab.h>
#include <linux/pci.h>
#include <linux/delay.h>
+#include <linux/crc8.h>
#include "ssb_private.h"
@@ -179,71 +180,29 @@ err_pci:
SPEX16(_outvar, _offset, _mask, _shift)
-static inline u8 ssb_crc8(u8 crc, u8 data)
+static u8 srom_crc8_table[CRC8_TABLE_SIZE];
+
+/* Polynomial: x^8 + x^7 + x^6 + x^4 + x^2 + 1 */
+#define SROM_CRC8_POLY 0xAB
+
+static inline void ltoh16_buf(u16 *buf, unsigned int size)
{
- /* Polynomial: x^8 + x^7 + x^6 + x^4 + x^2 + 1 */
- static const u8 t[] = {
- 0x00, 0xF7, 0xB9, 0x4E, 0x25, 0xD2, 0x9C, 0x6B,
- 0x4A, 0xBD, 0xF3, 0x04, 0x6F, 0x98, 0xD6, 0x21,
- 0x94, 0x63, 0x2D, 0xDA, 0xB1, 0x46, 0x08, 0xFF,
- 0xDE, 0x29, 0x67, 0x90, 0xFB, 0x0C, 0x42, 0xB5,
- 0x7F, 0x88, 0xC6, 0x31, 0x5A, 0xAD, 0xE3, 0x14,
- 0x35, 0xC2, 0x8C, 0x7B, 0x10, 0xE7, 0xA9, 0x5E,
- 0xEB, 0x1C, 0x52, 0xA5, 0xCE, 0x39, 0x77, 0x80,
- 0xA1, 0x56, 0x18, 0xEF, 0x84, 0x73, 0x3D, 0xCA,
- 0xFE, 0x09, 0x47, 0xB0, 0xDB, 0x2C, 0x62, 0x95,
- 0xB4, 0x43, 0x0D, 0xFA, 0x91, 0x66, 0x28, 0xDF,
- 0x6A, 0x9D, 0xD3, 0x24, 0x4F, 0xB8, 0xF6, 0x01,
- 0x20, 0xD7, 0x99, 0x6E, 0x05, 0xF2, 0xBC, 0x4B,
- 0x81, 0x76, 0x38, 0xCF, 0xA4, 0x53, 0x1D, 0xEA,
- 0xCB, 0x3C, 0x72, 0x85, 0xEE, 0x19, 0x57, 0xA0,
- 0x15, 0xE2, 0xAC, 0x5B, 0x30, 0xC7, 0x89, 0x7E,
- 0x5F, 0xA8, 0xE6, 0x11, 0x7A, 0x8D, 0xC3, 0x34,
- 0xAB, 0x5C, 0x12, 0xE5, 0x8E, 0x79, 0x37, 0xC0,
- 0xE1, 0x16, 0x58, 0xAF, 0xC4, 0x33, 0x7D, 0x8A,
- 0x3F, 0xC8, 0x86, 0x71, 0x1A, 0xED, 0xA3, 0x54,
- 0x75, 0x82, 0xCC, 0x3B, 0x50, 0xA7, 0xE9, 0x1E,
- 0xD4, 0x23, 0x6D, 0x9A, 0xF1, 0x06, 0x48, 0xBF,
- 0x9E, 0x69, 0x27, 0xD0, 0xBB, 0x4C, 0x02, 0xF5,
- 0x40, 0xB7, 0xF9, 0x0E, 0x65, 0x92, 0xDC, 0x2B,
- 0x0A, 0xFD, 0xB3, 0x44, 0x2F, 0xD8, 0x96, 0x61,
- 0x55, 0xA2, 0xEC, 0x1B, 0x70, 0x87, 0xC9, 0x3E,
- 0x1F, 0xE8, 0xA6, 0x51, 0x3A, 0xCD, 0x83, 0x74,
- 0xC1, 0x36, 0x78, 0x8F, 0xE4, 0x13, 0x5D, 0xAA,
- 0x8B, 0x7C, 0x32, 0xC5, 0xAE, 0x59, 0x17, 0xE0,
- 0x2A, 0xDD, 0x93, 0x64, 0x0F, 0xF8, 0xB6, 0x41,
- 0x60, 0x97, 0xD9, 0x2E, 0x45, 0xB2, 0xFC, 0x0B,
- 0xBE, 0x49, 0x07, 0xF0, 0x9B, 0x6C, 0x22, 0xD5,
- 0xF4, 0x03, 0x4D, 0xBA, 0xD1, 0x26, 0x68, 0x9F,
- };
- return t[crc ^ data];
-}
-
-static u8 ssb_sprom_crc(const u16 *sprom, u16 size)
-{
- int word;
- u8 crc = 0xFF;
-
- for (word = 0; word < size - 1; word++) {
- crc = ssb_crc8(crc, sprom[word] & 0x00FF);
- crc = ssb_crc8(crc, (sprom[word] & 0xFF00) >> 8);
- }
- crc = ssb_crc8(crc, sprom[size - 1] & 0x00FF);
- crc ^= 0xFF;
+ size /= 2;
+ while (size--)
+ *(buf + size) = le16_to_cpu(*(__le16 *)(buf + size));
+}
- return crc;
+static inline void htol16_buf(u16 *buf, unsigned int size)
+{
+ size /= 2;
+ while (size--)
+ *(__le16 *)(buf + size) = cpu_to_le16(*(buf + size));
}
static int sprom_check_crc(const u16 *sprom, size_t size)
{
- u8 crc;
- u8 expected_crc;
- u16 tmp;
-
- crc = ssb_sprom_crc(sprom, size);
- tmp = sprom[size - 1] & SSB_SPROM_REVISION_CRC;
- expected_crc = tmp >> SSB_SPROM_REVISION_CRC_SHIFT;
- if (crc != expected_crc)
+ if (crc8(srom_crc8_table, (u8 *)sprom, 2 * size, CRC8_INIT_VALUE) !=
+ CRC8_GOOD_VALUE(srom_crc8_table))
return -EPROTO;
return 0;
@@ -690,8 +649,11 @@ static int ssb_pci_sprom_get(struct ssb_
buf = kcalloc(SSB_SPROMSIZE_WORDS_R123, sizeof(u16), GFP_KERNEL);
if (!buf)
return -ENOMEM;
+ crc8_populate_lsb(srom_crc8_table, SROM_CRC8_POLY);
bus->sprom_size = SSB_SPROMSIZE_WORDS_R123;
sprom_do_read(bus, buf);
+ /* convert to le */
+ htol16_buf(buf, 2 * bus->sprom_size);
err = sprom_check_crc(buf, bus->sprom_size);
if (err) {
/* try for a 440 byte SPROM - revision 4 and higher */
@@ -702,6 +664,7 @@ static int ssb_pci_sprom_get(struct ssb_
return -ENOMEM;
bus->sprom_size = SSB_SPROMSIZE_WORDS_R4;
sprom_do_read(bus, buf);
+ htol16_buf(buf, 2 * bus->sprom_size);
err = sprom_check_crc(buf, bus->sprom_size);
if (err) {
/* All CRC attempts failed.
@@ -721,9 +684,11 @@ static int ssb_pci_sprom_get(struct ssb_
goto out_free;
}
ssb_printk(KERN_WARNING PFX "WARNING: Invalid"
- " SPROM CRC (corrupt SPROM)\n");
+ " SPROM CRC (corrupt SPROM)\n");
}
}
+ /* restore endianess */
+ ltoh16_buf(buf, 2 * bus->sprom_size);
err = sprom_extract(bus, sprom, buf, bus->sprom_size);
out_free:
Index: wireless-testing-new/drivers/ssb/Kconfig
===================================================================
--- wireless-testing-new.orig/drivers/ssb/Kconfig
+++ wireless-testing-new/drivers/ssb/Kconfig
@@ -24,6 +24,7 @@ config SSB
# Common SPROM support routines
config SSB_SPROM
bool
+ select CRC8
# Support for Block-I/O. SELECT this from the driver that needs it.
config SSB_BLOCKIO
^ permalink raw reply
* Re: [PATCH] ssb: Convert to use crc8 code in kernel library
From: Joe Perches @ 2011-10-08 22:38 UTC (permalink / raw)
To: Larry Finger
Cc: John W Linville, Michael Buesch, zajec5, b43-dev, linux-wireless
In-Reply-To: <4e90ce9a.89uGF659NNpbpyA3%Larry.Finger@lwfinger.net>
On Sat, 2011-10-08 at 17:28 -0500, Larry Finger wrote:
> The kernel now contains library routines to establish crc8 tables and
> to calculate the appropriate sums. Use them for ssb.
[]
> --- wireless-testing-new.orig/drivers/ssb/pci.c
[]
> +static inline void ltoh16_buf(u16 *buf, unsigned int size)
Perhaps a rename and use le16_to_cpup?
> +static inline void htol16_buf(u16 *buf, unsigned int size)
and cpu_to_le16p?
^ permalink raw reply
* Re: [PATCH] ssb: Convert to use crc8 code in kernel library
From: Michael Büsch @ 2011-10-08 22:51 UTC (permalink / raw)
To: Larry Finger
Cc: John W Linville, Michael Buesch, zajec5, b43-dev, linux-wireless
In-Reply-To: <4e90ce9a.89uGF659NNpbpyA3%Larry.Finger@lwfinger.net>
On Sat, 08 Oct 2011 17:28:42 -0500
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> The kernel now contains library routines to establish crc8 tables and
> to calculate the appropriate sums. Use them for ssb.
> +static u8 srom_crc8_table[CRC8_TABLE_SIZE];
> +
> +/* Polynomial: x^8 + x^7 + x^6 + x^4 + x^2 + 1 */
> +#define SROM_CRC8_POLY 0xAB
> +
> +static inline void ltoh16_buf(u16 *buf, unsigned int size)
> {
> + size /= 2;
> + while (size--)
> + *(buf + size) = le16_to_cpu(*(__le16 *)(buf + size));
> +}
>
> - return crc;
> +static inline void htol16_buf(u16 *buf, unsigned int size)
> +{
> + size /= 2;
> + while (size--)
> + *(__le16 *)(buf + size) = cpu_to_le16(*(buf + size));
> }
> return -ENOMEM;
> + crc8_populate_lsb(srom_crc8_table, SROM_CRC8_POLY);
> bus->sprom_size = SSB_SPROMSIZE_WORDS_R123;
> sprom_do_read(bus, buf);
> + /* convert to le */
> + htol16_buf(buf, 2 * bus->sprom_size);
> bus->sprom_size = SSB_SPROMSIZE_WORDS_R4;
> sprom_do_read(bus, buf);
> + htol16_buf(buf, 2 * bus->sprom_size);
> err = sprom_check_crc(buf, bus->sprom_size);
> + /* restore endianess */
> + ltoh16_buf(buf, 2 * bus->sprom_size);
> err = sprom_extract(bus, sprom, buf, bus->sprom_size);
This endianness stuff is _really_ ugly.
Does this patch decrease the code size, at least? I'll almost doubt it.
If it doesn't, why are we actually doing this?
It doesn't even decrease the .data size. Worse, it converts a .const
table to a .data table.
Just my 2 cents.
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] ssb: Convert to use crc8 code in kernel library
From: Larry Finger @ 2011-10-08 23:00 UTC (permalink / raw)
To: Joe Perches
Cc: John W Linville, Michael Buesch, zajec5, b43-dev, linux-wireless
In-Reply-To: <1318113514.1844.34.camel@Joe-Laptop>
On 10/08/2011 05:38 PM, Joe Perches wrote:
> On Sat, 2011-10-08 at 17:28 -0500, Larry Finger wrote:
>> The kernel now contains library routines to establish crc8 tables and
>> to calculate the appropriate sums. Use them for ssb.
> []
>> --- wireless-testing-new.orig/drivers/ssb/pci.c
> []
>> +static inline void ltoh16_buf(u16 *buf, unsigned int size)
>
> Perhaps a rename and use le16_to_cpup?
>
>> +static inline void htol16_buf(u16 *buf, unsigned int size)
>
> and cpu_to_le16p?
I'm sorry, but I don't see any advantage to using a pointer version here. Please
enlighten me.
Thanks,
Larry
^ permalink raw reply
* Re: [PATCH] ssb: Convert to use crc8 code in kernel library
From: Joe Perches @ 2011-10-08 23:11 UTC (permalink / raw)
To: Larry Finger
Cc: John W Linville, Michael Buesch, zajec5, b43-dev, linux-wireless
In-Reply-To: <4E90D5F7.6020005@lwfinger.net>
On Sat, 2011-10-08 at 18:00 -0500, Larry Finger wrote:
> On 10/08/2011 05:38 PM, Joe Perches wrote:
> > On Sat, 2011-10-08 at 17:28 -0500, Larry Finger wrote:
> >> The kernel now contains library routines to establish crc8 tables and
> >> to calculate the appropriate sums. Use them for ssb.
> > []
> >> --- wireless-testing-new.orig/drivers/ssb/pci.c
> > []
> >> +static inline void ltoh16_buf(u16 *buf, unsigned int size)
> >
> > Perhaps a rename and use le16_to_cpup?
> >
> >> +static inline void htol16_buf(u16 *buf, unsigned int size)
> >
> > and cpu_to_le16p?
>
> I'm sorry, but I don't see any advantage to using a pointer version here. Please
> enlighten me.
It's just a naming consistency thing,
you already are using a pointer version,
and maybe this should go into byteorder.h
inline void array_cpu_to_le16p(u16 *p, size_t size)
{
while (size) {
cpu_to_le16p(p++);
size--;
}
}
^ permalink raw reply
* Re: Alfa AWUS036NHR with RTL8188RU chipset
From: Gábor Stefanik @ 2011-10-08 23:29 UTC (permalink / raw)
To: Larry Finger; +Cc: Toddy, linux-wireless
In-Reply-To: <4E907FB8.1040101@lwfinger.net>
On Sat, Oct 8, 2011 at 6:52 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 10/08/2011 11:24 AM, Toddy wrote:
>>
>> Hello Larry,
>>
>> thanks for the quick reply! Yes I know this version is a bit older, but
>> when I
>> use the newest compat-wireless (eg.
>>
>> http://www.orbit-lab.org/kernel/compat-wireless-2.6/compat-wireless-2011-10-07.tar.bz2)
>> the driver loads but some features like monitor-mode and packet injection
>> doesn't work. The listing of available networks (with airodump) doesn't
>> work
>> too. Usually I have 13 channels because I live in Germany but if I use the
>> newest driver I have only 11 channels. But if I use the older
>> compat-wireless
>> package all works fine.
>
> The difference between 11 and 13 channels depends on your CRDA settings. Do
> you have that package installed? Check the output of dmesg to see what
> domain is being set. If you have CRDA installed, then you can force the use
> of Germany in the domain by creating a file named
> /etc/modprobe.d/50-cfg80211.conf containing a single line with "options
> cfg80211 ieee80211_regdom=DE" (without the quote marks).
>
> You can get a list of available networks using iwconfig or iw. I know those
> work.
>
> As I do not test, support, nor condone packet injection, I cannot speak to
> it working on any driver.
Well, packet injection is required for Hostapd to work.
>
> Larry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH 1/2] wl12xx: sdio: use dev_dbg instead of wl1271_debug
From: Eliad Peller @ 2011-10-09 0:08 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
In-Reply-To: <1317987297-18172-1-git-send-email-coelho@ti.com>
On Fri, Oct 7, 2011 at 1:34 PM, Luciano Coelho <coelho@ti.com> wrote:
> To prevent a useless dependency between the sdio module and the wl12xx
> module, we need to replace the wl1271_debug macros (and friends) for
> dev_dbg and other equivalents.
>
> At the same time, remove the SDIO data hexdump, since this produces
> way too much data and is not particularly useful. There's not
> print_hex_dump() equivalent for dynamic debug, so it's hard to control
> when the dumps are printed out.
>
> Signed-off-by: Luciano Coelho <coelho@ti.com>
> ---
[...]
> if (!(sdio_flags & MMC_PM_KEEP_POWER)) {
> - wl1271_error("can't keep power while host "
> + dev_err(dev, "can't keep power while host \n"
> "is suspended");
you missed the concatenation here :)
^ permalink raw reply
* Re: [PATCH 1/2] wl12xx: sdio: use dev_dbg instead of wl1271_debug
From: Luciano Coelho @ 2011-10-09 6:09 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless
In-Reply-To: <CAB3XZEeiyAxzE6tiqe2D71jKuusa-hPz-2fw5bqHocaw+d1xWg@mail.gmail.com>
On Sun, 2011-10-09 at 02:08 +0200, Eliad Peller wrote:
> On Fri, Oct 7, 2011 at 1:34 PM, Luciano Coelho <coelho@ti.com> wrote:
> > To prevent a useless dependency between the sdio module and the wl12xx
> > module, we need to replace the wl1271_debug macros (and friends) for
> > dev_dbg and other equivalents.
> >
> > At the same time, remove the SDIO data hexdump, since this produces
> > way too much data and is not particularly useful. There's not
> > print_hex_dump() equivalent for dynamic debug, so it's hard to control
> > when the dumps are printed out.
> >
> > Signed-off-by: Luciano Coelho <coelho@ti.com>
> > ---
> [...]
> > if (!(sdio_flags & MMC_PM_KEEP_POWER)) {
> > - wl1271_error("can't keep power while host "
> > + dev_err(dev, "can't keep power while host \n"
> > "is suspended");
>
> you missed the concatenation here :)
Ouch! Et tu Brutus?! :)
My regex didn't spread across lines. I'll fix it, thanks for checking.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] ssb: Convert to use crc8 code in kernel library
From: Rafał Miłecki @ 2011-10-09 8:48 UTC (permalink / raw)
To: Michael Büsch
Cc: Larry Finger, John W Linville, Michael Buesch, b43-dev,
linux-wireless
In-Reply-To: <20111009005107.43a49372@milhouse>
2011/10/9 Michael Büsch <m@bues.ch>:
> On Sat, 08 Oct 2011 17:28:42 -0500
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
>> The kernel now contains library routines to establish crc8 tables and
>> to calculate the appropriate sums. Use them for ssb.
>
>> +static u8 srom_crc8_table[CRC8_TABLE_SIZE];
>> +
>> +/* Polynomial: x^8 + x^7 + x^6 + x^4 + x^2 + 1 */
>> +#define SROM_CRC8_POLY 0xAB
>> +
>> +static inline void ltoh16_buf(u16 *buf, unsigned int size)
>> {
>> + size /= 2;
>> + while (size--)
>> + *(buf + size) = le16_to_cpu(*(__le16 *)(buf + size));
>> +}
>>
>> - return crc;
>> +static inline void htol16_buf(u16 *buf, unsigned int size)
>> +{
>> + size /= 2;
>> + while (size--)
>> + *(__le16 *)(buf + size) = cpu_to_le16(*(buf + size));
>> }
>
>> return -ENOMEM;
>> + crc8_populate_lsb(srom_crc8_table, SROM_CRC8_POLY);
>> bus->sprom_size = SSB_SPROMSIZE_WORDS_R123;
>> sprom_do_read(bus, buf);
>> + /* convert to le */
>> + htol16_buf(buf, 2 * bus->sprom_size);
>
>> bus->sprom_size = SSB_SPROMSIZE_WORDS_R4;
>> sprom_do_read(bus, buf);
>> + htol16_buf(buf, 2 * bus->sprom_size);
>> err = sprom_check_crc(buf, bus->sprom_size);
>
>> + /* restore endianess */
>> + ltoh16_buf(buf, 2 * bus->sprom_size);
>> err = sprom_extract(bus, sprom, buf, bus->sprom_size);
>
> This endianness stuff is _really_ ugly.
> Does this patch decrease the code size, at least? I'll almost doubt it.
> If it doesn't, why are we actually doing this?
> It doesn't even decrease the .data size. Worse, it converts a .const
> table to a .data table.
>
> Just my 2 cents.
Agree. I already tried converting bcma to use crc8:
[RFC][WORTH IT?][PATCH] bcma: make use of crc8 lib
http://lists.infradead.org/pipermail/b43-dev/2011-June/001466.html
But resigned, it was introducing some hacks or not optimal ops, I
decided it's not worth it.
Even Arend said their brcm80211 is hacky about crc8 usage:
W dniu 15 czerwca 2011 21:26 użytkownik Arend van Spriel
<arend@broadcom.com> napisał:
> Agree. In brcm80211 we convert the entire sprom, calculate, and convert it
> back. Also not perfect I think as it loops over de sprom data twice.
--
Rafał
^ permalink raw reply
* Re: [PATCH] ssb: Convert to use crc8 code in kernel library
From: Arend van Spriel @ 2011-10-09 9:50 UTC (permalink / raw)
To: Michael Büsch
Cc: Larry Finger, John W Linville, Michael Buesch, zajec5@gmail.com,
b43-dev@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <20111009005107.43a49372@milhouse>
On 10/09/2011 12:51 AM, Michael Büsch wrote:
> On Sat, 08 Oct 2011 17:28:42 -0500
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
>> The kernel now contains library routines to establish crc8 tables and
>> to calculate the appropriate sums. Use them for ssb.
>
>> +static u8 srom_crc8_table[CRC8_TABLE_SIZE];
>> +
>> +/* Polynomial: x^8 + x^7 + x^6 + x^4 + x^2 + 1 */
>> +#define SROM_CRC8_POLY 0xAB
>> +
>> +static inline void ltoh16_buf(u16 *buf, unsigned int size)
>> {
>> + size /= 2;
>> + while (size--)
>> + *(buf + size) = le16_to_cpu(*(__le16 *)(buf + size));
>> +}
>>
>> - return crc;
>> +static inline void htol16_buf(u16 *buf, unsigned int size)
>> +{
>> + size /= 2;
>> + while (size--)
>> + *(__le16 *)(buf + size) = cpu_to_le16(*(buf + size));
>> }
>
>> return -ENOMEM;
>> + crc8_populate_lsb(srom_crc8_table, SROM_CRC8_POLY);
>> bus->sprom_size = SSB_SPROMSIZE_WORDS_R123;
>> sprom_do_read(bus, buf);
>> + /* convert to le */
>> + htol16_buf(buf, 2 * bus->sprom_size);
>
>> bus->sprom_size = SSB_SPROMSIZE_WORDS_R4;
>> sprom_do_read(bus, buf);
>> + htol16_buf(buf, 2 * bus->sprom_size);
>> err = sprom_check_crc(buf, bus->sprom_size);
>
>> + /* restore endianess */
>> + ltoh16_buf(buf, 2 * bus->sprom_size);
>> err = sprom_extract(bus, sprom, buf, bus->sprom_size);
>
> This endianness stuff is _really_ ugly.
It may seem ugly, but is not new. Choosing a 8-bit crc to check a 16-bit
array is not very efficient considering host endianess. The endianess
was also dealt with in the old version:
- for (word = 0; word < size - 1; word++) {
- crc = ssb_crc8(crc, sprom[word] & 0x00FF);
- crc = ssb_crc8(crc, (sprom[word] & 0xFF00) >> 8);
- }
It is a bit easier on the eye. I guess the ugliness comes from the fact
that there are two calls to htol16_buf.
A better approach would be to read sprom as bytes and run the crc8 over
the byte array. When ok do ltoh16_buf once.
> Does this patch decrease the code size, at least? I'll almost doubt it.
> If it doesn't, why are we actually doing this?
Probably for the same reason why struct list_head and related functions
are used. Trying to use what is commonly available in the kernel.
> It doesn't even decrease the .data size. Worse, it converts a .const
> table to a .data table.
True. .code size became .data size, because of the flexibility that the
table is generated for a given polynomial. Every 'bility' comes with a
price and this seems not too pricy.
> Just my 2 cents.
>
Gr. AvS
^ permalink raw reply
* Re: [PATCH] ssb: Convert to use crc8 code in kernel library
From: Arend van Spriel @ 2011-10-09 10:33 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Michael Büsch, Larry Finger, John W Linville, Michael Buesch,
b43-dev@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <CACna6rz-0TZrwctTZR-YLDHG=xdt4Oc5ShbjCZiad7Cvmh0+hQ@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/09/2011 10:48 AM, Rafał Miłecki wrote:
> Agree. I already tried converting bcma to use crc8:
> [RFC][WORTH IT?][PATCH] bcma: make use of crc8 lib
> http://lists.infradead.org/pipermail/b43-dev/2011-June/001466.html
>
> But resigned, it was introducing some hacks or not optimal ops, I
> decided it's not worth it.
>
> Even Arend said their brcm80211 is hacky about crc8 usage:
>
> W dniu 15 czerwca 2011 21:26 użytkownik Arend van Spriel
> <arend@broadcom.com> napisał:
>> Agree. In brcm80211 we convert the entire sprom, calculate, and convert it
>> back. Also not perfect I think as it loops over de sprom data twice.
>
Hi Rafał,
"not perfect" == "hacky" ;-)
I also just replied with a less hacky approach. Reading the sprom as
bytes will read the sprom content as is (little-endian) and you can do
the crc8 check without any conversions. After the check there is only
one conversion needed to move to a word array.
Gr. AvS
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOkXheAAoJELcEx/G14aEWnHwP+wZRWLladazO/zZnuMrnEuRk
xhMzbZcIy8gJwkGs/GwuWqnHBZu+Qx/k/BC3S1CNNmLPOf7qLNbS4hgKRZn+2Tze
FHYzXb6IPXkCE6MS5BFRi2qxnzrxam7gL00SB5NuGceS4b3LQL+wNHzPx5yPlPEW
KsJnecyFTabclun2zxucZPB19w2xrS84Xcl2Db+2nV3wSn700REr5mr3+pmVXmvd
ptLuWsc5ZoAnvuTQq/PUjKvQb/tA7CpDFs9+uvCeKa93Rb3JIRwTk5tAVadLEWn7
6IWyN0VMK+pdL2LT14qc1LWJa192tn8qbmOg21lKsQFepP4egJyRGWaU7aKo9bdG
PVSXfqme0azRl6vd+G28Q/SVdt//w5HBoPgdWlORhNdo/sov07QVl8gf80QkTn/A
Ij3M1+LMlUFu7weuIwgKBIA+Bi6CxTR/3ozK+S3ItpVqt6gCnMlDYtEUM6pk2vVj
8ppl0LtGHyrogFgwOrcYbxMKJGbk8Po82T+Um7wchcHuRxGLD3NuErndMiRwemMk
zALNLYNCLLftCSypCgkM5kyfDkDf7uZMxJZbPXyIIFCP4BXm5xrgx39sYQAVx4if
bIjW0W3OmIbBcQScZ4+KRZ5YN1g45VFRQ3+4BPyusApYqzwSmjxUj8aomfD2QhEJ
Fh/5uq3JIrpQazyEsILz
=JjZ0
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Alfa AWUS036NHR with RTL8188RU chipset
From: v4mp @ 2011-10-09 14:21 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <CA+XFjio+on2rUymoSZNxOWKMX9xOn5hutA6q01r0yBeOXz0ivw@mail.gmail.com>
Sorry, but i can't get this Alfa product to work with the latest bleeding edge
compat-wireless-2011-10-08 on ubuntu 11.04, tryed with kernels 2.6.38-11,
2.6.39 rc4 and 3.0
i tryed also the 2.6.39-1 version of compat-wireless
Don't show anything in managed and monitor mode..
^ permalink raw reply
* Re: [PATCH] ssb: Convert to use crc8 code in kernel library
From: Larry Finger @ 2011-10-09 14:35 UTC (permalink / raw)
To: John W Linville
Cc: Rafał Miłecki, Michael Büsch, Michael Buesch,
b43-dev, linux-wireless
In-Reply-To: <CACna6rz-0TZrwctTZR-YLDHG=xdt4Oc5ShbjCZiad7Cvmh0+hQ@mail.gmail.com>
On 10/09/2011 03:48 AM, Rafał Miłecki wrote:
> 2011/10/9 Michael Büsch<m@bues.ch>:
>> On Sat, 08 Oct 2011 17:28:42 -0500
>> Larry Finger<Larry.Finger@lwfinger.net> wrote:
>>
>>> The kernel now contains library routines to establish crc8 tables and
>>> to calculate the appropriate sums. Use them for ssb.
>>
>>> +static u8 srom_crc8_table[CRC8_TABLE_SIZE];
>>> +
>>> +/* Polynomial: x^8 + x^7 + x^6 + x^4 + x^2 + 1 */
>>> +#define SROM_CRC8_POLY 0xAB
>>> +
>>> +static inline void ltoh16_buf(u16 *buf, unsigned int size)
>>> {
>>> + size /= 2;
>>> + while (size--)
>>> + *(buf + size) = le16_to_cpu(*(__le16 *)(buf + size));
>>> +}
>>>
>>> - return crc;
>>> +static inline void htol16_buf(u16 *buf, unsigned int size)
>>> +{
>>> + size /= 2;
>>> + while (size--)
>>> + *(__le16 *)(buf + size) = cpu_to_le16(*(buf + size));
>>> }
>>
>>> return -ENOMEM;
>>> + crc8_populate_lsb(srom_crc8_table, SROM_CRC8_POLY);
>>> bus->sprom_size = SSB_SPROMSIZE_WORDS_R123;
>>> sprom_do_read(bus, buf);
>>> + /* convert to le */
>>> + htol16_buf(buf, 2 * bus->sprom_size);
>>
>>> bus->sprom_size = SSB_SPROMSIZE_WORDS_R4;
>>> sprom_do_read(bus, buf);
>>> + htol16_buf(buf, 2 * bus->sprom_size);
>>> err = sprom_check_crc(buf, bus->sprom_size);
>>
>>> + /* restore endianess */
>>> + ltoh16_buf(buf, 2 * bus->sprom_size);
>>> err = sprom_extract(bus, sprom, buf, bus->sprom_size);
>>
>> This endianness stuff is _really_ ugly.
>> Does this patch decrease the code size, at least? I'll almost doubt it.
>> If it doesn't, why are we actually doing this?
>> It doesn't even decrease the .data size. Worse, it converts a .const
>> table to a .data table.
>>
>> Just my 2 cents.
>
> Agree. I already tried converting bcma to use crc8:
> [RFC][WORTH IT?][PATCH] bcma: make use of crc8 lib
> http://lists.infradead.org/pipermail/b43-dev/2011-June/001466.html
>
> But resigned, it was introducing some hacks or not optimal ops, I
> decided it's not worth it.
>
> Even Arend said their brcm80211 is hacky about crc8 usage:
>
> W dniu 15 czerwca 2011 21:26 użytkownik Arend van Spriel
> <arend@broadcom.com> napisał:
>> Agree. In brcm80211 we convert the entire sprom, calculate, and convert it
>> back. Also not perfect I think as it loops over de sprom data twice.
John,
Please drop this patch. The amount of code churning is not worth the 100 byte
saving in the size of the generated code.
Larry
^ permalink raw reply
* Re: Alfa AWUS036NHR with RTL8188RU chipset
From: Larry Finger @ 2011-10-09 14:47 UTC (permalink / raw)
To: v4mp; +Cc: linux-wireless
In-Reply-To: <loom.20111009T161348-133@post.gmane.org>
On 10/09/2011 09:21 AM, v4mp wrote:
>
> Sorry, but i can't get this Alfa product to work with the latest bleeding edge
> compat-wireless-2011-10-08 on ubuntu 11.04, tryed with kernels 2.6.38-11,
> 2.6.39 rc4 and 3.0
>
> i tryed also the 2.6.39-1 version of compat-wireless
>
> Don't show anything in managed and monitor mode..
I do not know about monitor mode, but the Alfa device works in managed mode with
kernel 3.1-rc9 from both wireless-testing and mainline. I use NetworkManager.
All of this current code should be in the latest bleeding edge compat-wireless
version.
Have you installed the firmware?
Larry
^ permalink raw reply
* Compat-wireless release for 2011-10-09 is baked
From: Compat-wireless cronjob account @ 2011-10-09 19:03 UTC (permalink / raw)
To: linux-wireless
compat-wireless code metrics
811845 - Total upstream lines of code being pulled
2431 - backport code changes
2113 - backport code additions
318 - backport code deletions
8588 - backport from compat module
11019 - total backport code
1.3573 - % of code consists of backport work
^ permalink raw reply
* Re: [patch] fix the definition of AR9170_PHY_REG_CURRENT_RSSI
From: Christian Lamparter @ 2011-10-09 21:02 UTC (permalink / raw)
To: Adrian Chadd; +Cc: linux-wireless, Felix
In-Reply-To: <CAJ-VmomAP-LZdVkh1snpsTOxU18yPMxXut=KzjTwP+AkN9XidQ@mail.gmail.com>
On Tuesday, October 04, 2011 02:30:51 AM Adrian Chadd wrote:
> Although it currently isn't used anywhere, I thought it'd be
> worthwhile fixing the definition of AR9170_PHY_REG_CURRENT_RSSI.
> It's at AR_PHY(271) rather than AR_PHY(263).
>
> -#define AR9170_PHY_REG_CURRENT_RSSI
> (AR9170_PHY_REG_BASE + 0x041c)
> +#define AR9170_PHY_REG_CURRENT_RSSI
> (AR9170_PHY_REG_BASE + 0x043c)
Hello again,
I had some time to check what is on 0x043c.
With AR9170 it looks like to be "0". This
wouldn't be surprising, however the old reg
0x041c seems to jumps around a lot [as
expected from the current rssi].
Adrian, are you sure the source is accurate?
Felix, do you know something about the
CURRENT_RSSI register?
Regards,
Chr
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox