* [PATCH 2/6] ath5k: remove own (wrong) IEEE80211_MAX_LEN
From: Bob Copeland @ 2010-08-15 17:03 UTC (permalink / raw)
To: linville, jirislaby, mickflemm, lrodriguez
Cc: linux-wireless, ath5k-devel, Bob Copeland
In-Reply-To: <1281891795-14718-1-git-send-email-me@bobcopeland.com>
From: Nick Kossifidis <mickflemm@gmail.com>
Use the version already supplied in include/linux/ieee80211.h.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
drivers/net/wireless/ath/ath5k/ath5k.h | 5 +----
drivers/net/wireless/ath/ath5k/base.c | 2 +-
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index 9129e51..f399c4d 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -175,7 +175,7 @@
#define AR5K_TUNE_ADDITIONAL_SWBA_BACKOFF 0
#define AR5K_TUNE_RADAR_ALERT false
#define AR5K_TUNE_MIN_TX_FIFO_THRES 1
-#define AR5K_TUNE_MAX_TX_FIFO_THRES ((IEEE80211_MAX_LEN / 64) + 1)
+#define AR5K_TUNE_MAX_TX_FIFO_THRES ((IEEE80211_MAX_FRAME_LEN / 64) + 1)
#define AR5K_TUNE_REGISTER_TIMEOUT 20000
/* Register for RSSI threshold has a mask of 0xff, so 255 seems to
* be the max value. */
@@ -343,9 +343,6 @@ struct ath5k_srev_name {
#define AR5K_SREV_PHY_5413 0x61
#define AR5K_SREV_PHY_2425 0x70
-/* IEEE defs */
-#define IEEE80211_MAX_LEN 2500
-
/* TODO add support to mac80211 for vendor-specific rates and modes */
/*
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index cc080d0..efd9350 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1709,7 +1709,7 @@ ath5k_rx_start(struct ath5k_softc *sc)
struct ath5k_buf *bf;
int ret;
- common->rx_bufsize = roundup(IEEE80211_MAX_LEN, common->cachelsz);
+ common->rx_bufsize = roundup(IEEE80211_MAX_FRAME_LEN, common->cachelsz);
ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "cachelsz %u rx_bufsize %u\n",
common->cachelsz, common->rx_bufsize);
--
1.7.1.1
^ permalink raw reply related
* [PATCH 6/6] ath5k: don't enable probe request rx for STAs
From: Bob Copeland @ 2010-08-15 17:03 UTC (permalink / raw)
To: linville, jirislaby, mickflemm, lrodriguez
Cc: linux-wireless, ath5k-devel, Bob Copeland
In-Reply-To: <1281891795-14718-1-git-send-email-me@bobcopeland.com>
AR5K_RX_FILTER_PROBEREQ enables reception of probe requests,
but the filter flag FIF_BCN_PRBRESP_PROMISC is actually about
receiving beacons and probe _responses_, so we shouldn't
turn on the filter when scanning.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
drivers/net/wireless/ath/ath5k/base.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index e60b148..6d46ae7 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -3227,9 +3227,9 @@ static void ath5k_configure_filter(struct ieee80211_hw *hw,
rfilt |= AR5K_RX_FILTER_PHYERR;
/* FIF_BCN_PRBRESP_PROMISC really means to enable beacons
- * and probes for any BSSID, this needs testing */
+ * and probes for any BSSID */
if (*new_flags & FIF_BCN_PRBRESP_PROMISC)
- rfilt |= AR5K_RX_FILTER_BEACON | AR5K_RX_FILTER_PROBEREQ;
+ rfilt |= AR5K_RX_FILTER_BEACON;
/* FIF_CONTROL doc says that if FIF_PROMISC_IN_BSS is not
* set we should only pass on control frames for this
--
1.7.1.1
^ permalink raw reply related
* [PATCH 4/6] ath5k: remove monitor check in receive_frame_ok filter
From: Bob Copeland @ 2010-08-15 17:03 UTC (permalink / raw)
To: linville, jirislaby, mickflemm, lrodriguez
Cc: linux-wireless, ath5k-devel, Bob Copeland
In-Reply-To: <1281891795-14718-1-git-send-email-me@bobcopeland.com>
Monitor interfaces are never seen by the driver, so tests based on
that opmode don't make sense. Also, we already pass all mic
failure packets.
Consequently this code is actually accepting any frames with just
crypto errors and rejecting those with CRC, FIFO, and PHY errors for
all interface types. Adjust the code and comment accordingly.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
drivers/net/wireless/ath/ath5k/base.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 9c49b8d..03808b8 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -2035,9 +2035,8 @@ ath5k_receive_frame_ok(struct ath5k_softc *sc, struct ath5k_rx_status *rs)
return true;
}
- /* let crypto-error packets fall through in MNTR */
- if ((rs->rs_status & ~(AR5K_RXERR_DECRYPT|AR5K_RXERR_MIC)) ||
- sc->opmode != NL80211_IFTYPE_MONITOR)
+ /* reject any frames with non-crypto errors */
+ if (rs->rs_status & ~(AR5K_RXERR_DECRYPT))
return false;
}
--
1.7.1.1
^ permalink raw reply related
* [PATCH 1/6] ath5k: rename ath5k_hw_set_associd to _set_bssid
From: Bob Copeland @ 2010-08-15 17:03 UTC (permalink / raw)
To: linville, jirislaby, mickflemm, lrodriguez
Cc: linux-wireless, ath5k-devel, Bob Copeland
In-Reply-To: <1281891795-14718-1-git-send-email-me@bobcopeland.com>
From: Nick Kossifidis <mickflemm@gmail.com>
Although the named function also sets the aid, its main
purpose is configuring the bssid and we use that
everywhere else.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
drivers/net/wireless/ath/ath5k/ath5k.h | 2 +-
drivers/net/wireless/ath/ath5k/attach.c | 2 +-
drivers/net/wireless/ath/ath5k/base.c | 4 ++--
drivers/net/wireless/ath/ath5k/pcu.c | 13 ++++++-------
drivers/net/wireless/ath/ath5k/reset.c | 2 +-
5 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index ea6362a..9129e51 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -1190,7 +1190,7 @@ extern int ath5k_hw_set_opmode(struct ath5k_hw *ah, enum nl80211_iftype opmode);
void ath5k_hw_set_coverage_class(struct ath5k_hw *ah, u8 coverage_class);
/* BSSID Functions */
int ath5k_hw_set_lladdr(struct ath5k_hw *ah, const u8 *mac);
-void ath5k_hw_set_associd(struct ath5k_hw *ah);
+void ath5k_hw_set_bssid(struct ath5k_hw *ah);
void ath5k_hw_set_bssid_mask(struct ath5k_hw *ah, const u8 *mask);
/* Receive start/stop functions */
void ath5k_hw_start_rx_pcu(struct ath5k_hw *ah);
diff --git a/drivers/net/wireless/ath/ath5k/attach.c b/drivers/net/wireless/ath/ath5k/attach.c
index b32e28c..e72a1e5 100644
--- a/drivers/net/wireless/ath/ath5k/attach.c
+++ b/drivers/net/wireless/ath/ath5k/attach.c
@@ -329,7 +329,7 @@ int ath5k_hw_attach(struct ath5k_softc *sc)
/* Set BSSID to bcast address: ff:ff:ff:ff:ff:ff for now */
memcpy(common->curbssid, ath_bcast_mac, ETH_ALEN);
- ath5k_hw_set_associd(ah);
+ ath5k_hw_set_bssid(ah);
ath5k_hw_set_opmode(ah, sc->opmode);
ath5k_hw_rfgain_opt_init(ah);
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 373dcfe..cc080d0 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -3475,7 +3475,7 @@ static void ath5k_bss_info_changed(struct ieee80211_hw *hw,
/* Cache for later use during resets */
memcpy(common->curbssid, bss_conf->bssid, ETH_ALEN);
common->curaid = 0;
- ath5k_hw_set_associd(ah);
+ ath5k_hw_set_bssid(ah);
mmiowb();
}
@@ -3493,7 +3493,7 @@ static void ath5k_bss_info_changed(struct ieee80211_hw *hw,
"Bss Info ASSOC %d, bssid: %pM\n",
bss_conf->aid, common->curbssid);
common->curaid = bss_conf->aid;
- ath5k_hw_set_associd(ah);
+ ath5k_hw_set_bssid(ah);
/* Once ANI is available you would start it here */
}
}
diff --git a/drivers/net/wireless/ath/ath5k/pcu.c b/drivers/net/wireless/ath/ath5k/pcu.c
index 86fdb6d..efde8df 100644
--- a/drivers/net/wireless/ath/ath5k/pcu.c
+++ b/drivers/net/wireless/ath/ath5k/pcu.c
@@ -308,27 +308,26 @@ int ath5k_hw_set_lladdr(struct ath5k_hw *ah, const u8 *mac)
}
/**
- * ath5k_hw_set_associd - Set BSSID for association
+ * ath5k_hw_set_bssid - Set current BSSID on hw
*
* @ah: The &struct ath5k_hw
- * @bssid: BSSID
- * @assoc_id: Assoc id
*
- * Sets the BSSID which trigers the "SME Join" operation
+ * Sets the current BSSID and BSSID mask we have from the
+ * common struct into the hardware
*/
-void ath5k_hw_set_associd(struct ath5k_hw *ah)
+void ath5k_hw_set_bssid(struct ath5k_hw *ah)
{
struct ath_common *common = ath5k_hw_common(ah);
u16 tim_offset = 0;
/*
- * Set simple BSSID mask on 5212
+ * Set BSSID mask on 5212
*/
if (ah->ah_version == AR5K_AR5212)
ath_hw_setbssidmask(common);
/*
- * Set BSSID which triggers the "SME Join" operation
+ * Set BSSID
*/
ath5k_hw_reg_write(ah,
get_unaligned_le32(common->curbssid),
diff --git a/drivers/net/wireless/ath/ath5k/reset.c b/drivers/net/wireless/ath/ath5k/reset.c
index 498aa28..f5434eb 100644
--- a/drivers/net/wireless/ath/ath5k/reset.c
+++ b/drivers/net/wireless/ath/ath5k/reset.c
@@ -1160,7 +1160,7 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum nl80211_iftype op_mode,
*/
/* Restore bssid and bssid mask */
- ath5k_hw_set_associd(ah);
+ ath5k_hw_set_bssid(ah);
/* Set PCU config */
ath5k_hw_set_opmode(ah, op_mode);
--
1.7.1.1
^ permalink raw reply related
* Re: Odd BUG on wireless-testing master-2010-08-05
From: Kalle Valo @ 2010-08-15 17:39 UTC (permalink / raw)
To: Johannes Berg
Cc: Christian Lamparter, Luis R. Rodriguez, John W. Linville,
linux-wireless
In-Reply-To: <1281256404.3697.2.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
>> I have similar warnings with ath9k, using commit
>> 0ca923bdb96b1fee4d1db90b3094a0cf36120056:
>>
>> Aug 6 21:02:08 tukki kernel: [ 71.172707] =============================================================================
>> Aug 6 21:02:08 tukki kernel: [ 71.172715] BUG kmalloc-4096: Object already free
>> Aug 6 21:02:08 tukki kernel: [ 71.172718] -----------------------------------------------------------------------------
>> Aug 6 21:02:08 tukki kernel: [ 71.172720]
>> Aug 6 21:02:08 tukki kernel: [ 71.172732] INFO: Allocated in wireless_send_event+0x1f2/0x410 age=0 cpu=1 pid=3056
>
> I wonder if this is in any way related to
> commit 1235f504aaba2ebeabc863fdb3ceac764a317d47
> Author: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Mon Jul 26 13:09:16 2010 -0700
>
> netlink: netlink_recvmsg() fix
Thanks, that was a good tip. I run a revert of this commit for few
days and didn't see any warnings. Yesterday I again dropped the revert
and started to see warnings again. I can't be 100% certain (yet) that
this commit is the culprit, but it really looks like it.
--
Kalle Valo
^ permalink raw reply
* [PATCH]: b43: is there such a thing as radio 0x2062 rev 2?
From: dimitri.gorokhovik @ 2010-08-15 18:27 UTC (permalink / raw)
To: linville, stefano.brivio; +Cc: linux-wireless
In-Reply-To: <1682961998.136221281896329090.JavaMail.root@zimbra3-e1.priv.proxad.net>
Hi,
On a DELL D630 with BCM4312 (low-power PHY 4e4:4315 rev 01), I was able to fix the problem:
Aug 15 17:14:45 dimitri kernel: b43-phy0 debug: RC calib: Failed to switch to channel 7, error = -5
by bumping the radio's version (0x2062 rev 2) to 0x2063 (kept rev 2).
Before the fix, the hardware detected as:
Aug 15 17:14:45 dimitri kernel: b43-phy0: Broadcom 4312 WLAN found (core revision 15)
Aug 15 17:14:45 dimitri kernel: b43-phy0 debug: Found PHY: Analog 6, Type 5, Revision 1
Aug 15 17:14:45 dimitri kernel: b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2062, Revision 2
The problem manifested itself (permanently) as:
Aug 15 18:18:10 dimitri kernel: b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
Aug 15 18:18:10 dimitri kernel: b43-phy0 debug: b2062: Using crystal tab entry 19200 kHz.
Aug 15 18:18:10 dimitri kernel: b43-phy0 debug: RC calib: Failed to switch to channel 7, error = -5
The patch follows, tested on 2.6.32.18 and 2.6.35.2, both built for x86_64.
---
b43: Bump the radio version 0x2063-rev-2 to 0x2063.
Signed-off-by: <dimitri.gorokhovik@free.fr>
---
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index 7965b70..d245a23 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -4084,6 +4084,7 @@ static int b43_phy_versioning(struct b43_wldev *dev)
case B43_PHYTYPE_LP:
if (radio_ver != 0x2062 && radio_ver != 0x2063)
unsupported = 1;
+ radio_ver += radio_rev > 1;
break;
default:
B43_WARN_ON(1);
^ permalink raw reply related
* Re: [PATCH]: b43: is there such a thing as radio 0x2062 rev 2?
From: Gábor Stefanik @ 2010-08-15 18:52 UTC (permalink / raw)
To: dimitri.gorokhovik; +Cc: linville, stefano.brivio, linux-wireless
In-Reply-To: <1944322236.136661281896820874.JavaMail.root@zimbra3-e1.priv.proxad.net>
Does the card actually work if you make b43 believe that it has a BCM2063 radio?
BTW, all BCM2062 radios seen so far are rev.2, and none have shown
this error. Maybe your card actually has a BCM2063 radio, but for some
reason b43 detects it as a BCM2062?
Also, does the Broadcom hybrid driver handle your card?
Thanks,
Gábor.
On Sun, Aug 15, 2010 at 8:27 PM, <dimitri.gorokhovik@free.fr> wrote:
> Hi,
>
> On a DELL D630 with BCM4312 (low-power PHY 4e4:4315 rev 01), I was able to fix the problem:
>
> Aug 15 17:14:45 dimitri kernel: b43-phy0 debug: RC calib: Failed to switch to channel 7, error = -5
>
> by bumping the radio's version (0x2062 rev 2) to 0x2063 (kept rev 2).
>
> Before the fix, the hardware detected as:
>
> Aug 15 17:14:45 dimitri kernel: b43-phy0: Broadcom 4312 WLAN found (core revision 15)
> Aug 15 17:14:45 dimitri kernel: b43-phy0 debug: Found PHY: Analog 6, Type 5, Revision 1
> Aug 15 17:14:45 dimitri kernel: b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2062, Revision 2
>
> The problem manifested itself (permanently) as:
>
> Aug 15 18:18:10 dimitri kernel: b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
> Aug 15 18:18:10 dimitri kernel: b43-phy0 debug: b2062: Using crystal tab entry 19200 kHz.
> Aug 15 18:18:10 dimitri kernel: b43-phy0 debug: RC calib: Failed to switch to channel 7, error = -5
>
>
> The patch follows, tested on 2.6.32.18 and 2.6.35.2, both built for x86_64.
>
> ---
> b43: Bump the radio version 0x2063-rev-2 to 0x2063.
>
> Signed-off-by: <dimitri.gorokhovik@free.fr>
> ---
> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
> index 7965b70..d245a23 100644
> --- a/drivers/net/wireless/b43/main.c
> +++ b/drivers/net/wireless/b43/main.c
> @@ -4084,6 +4084,7 @@ static int b43_phy_versioning(struct b43_wldev *dev)
> case B43_PHYTYPE_LP:
> if (radio_ver != 0x2062 && radio_ver != 0x2063)
> unsupported = 1;
> + radio_ver += radio_rev > 1;
> break;
> default:
> B43_WARN_ON(1);
> --
> 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
* Compat-wireless release for 2010-08-15 is baked
From: Compat-wireless cronjob account @ 2010-08-15 19:02 UTC (permalink / raw)
To: linux-wireless
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
cat: compat_base_tree: No such file or directory
cat: compat_base_tree_version: No such file or directory
cat: compat_version: No such file or directory
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
scripts/Makefile.clean:17: /var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile: No such file or directory
make[4]: *** No rule to make target `/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile'. Stop.
make[3]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap] Error 2
make[2]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless] Error 2
make[1]: *** [_clean_/var/opt/compat/compat-wireless-2.6] Error 2
make: *** [clean] Error 2
compat-wireless code metrics
494644 - Total upstream lines of code being pulled
^ permalink raw reply
* Re: [PATCH]: b43: is there such a thing as radio 0x2062 rev 2?
From: dimitri.gorokhovik @ 2010-08-15 19:21 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: linville, stefano brivio, linux-wireless
In-Reply-To: <1689108175.140731281899456474.JavaMail.root@zimbra3-e1.priv.proxad.net>
----- "Gábor Stefanik" <netrolller.3d@gmail.com> a écrit :
> Does the card actually work if you make b43 believe that it has a
> BCM2063 radio?
The interface stays on (the WiFi LED lit), and I can scan and see
the networks (Quality info seems OK as well with 2.6.35). However,
I am still unable to connect to either an open or a protected
network:
Aug 15 19:04:11 dimitri kernel: wlan0: authenticate with 00:17:33:1e:13:70 (try 1)
Aug 15 19:04:11 dimitri kernel: wlan0: authenticated
Aug 15 19:04:11 dimitri kernel: wlan0: associate with 00:17:33:1e:13:70 (try 1)
Aug 15 19:04:11 dimitri kernel: wlan0: RX AssocResp from 00:17:33:1e:13:70 (capab=0x411 status=0 aid=2)
Aug 15 19:04:11 dimitri kernel: wlan0: associated
Aug 15 19:04:16 dimitri kernel: No probe response from AP 00:17:33:1e:13:70 after 500ms, disconnecting.
> BTW, all BCM2062 radios seen so far are rev.2, and none have shown
> this error. Maybe your card actually has a BCM2063 radio, but for
> some reason b43 detects it as a BCM2062?
Sure, this is of course possible (I don't really believe my patch
fixes the problem). The MAC address of the WiFi card is
00:22:68:ba:e2:ef (maybe somebody knows know the manufacturing
series).
For the record, I was able, only once, to run the unmodified driver
(2.6.32 x86+_64 debian kernel), but was never able to get it ever
again after that. That time, the HDMI res negotiated on both my
screens (though a dock) was rather unusual (something like
11xx X 9xx) so I think my problem might be some sort of CEM
problem.
>
> Also, does the Broadcom hybrid driver handle your card?
Last time I tried (more than a year ago), from memory, I believe,
I was able to scan, but I had the problems with Network Manager
support and didn't go for manual config.
Thanks,
Dimitri
>
> Thanks,
> Gábor.
>
> On Sun, Aug 15, 2010 at 8:27 PM, <dimitri.gorokhovik@free.fr> wrote:
> > Hi,
> >
> > On a DELL D630 with BCM4312 (low-power PHY 4e4:4315 rev 01), I was
> able to fix the problem:
> >
> > Aug 15 17:14:45 dimitri kernel: b43-phy0 debug: RC calib: Failed to
> switch to channel 7, error = -5
> >
> > by bumping the radio's version (0x2062 rev 2) to 0x2063 (kept rev
> 2).
> >
> > Before the fix, the hardware detected as:
> >
> > Aug 15 17:14:45 dimitri kernel: b43-phy0: Broadcom 4312 WLAN found
> (core revision 15)
> > Aug 15 17:14:45 dimitri kernel: b43-phy0 debug: Found PHY: Analog 6,
> Type 5, Revision 1
> > Aug 15 17:14:45 dimitri kernel: b43-phy0 debug: Found Radio: Manuf
> 0x17F, Version 0x2062, Revision 2
> >
> > The problem manifested itself (permanently) as:
> >
> > Aug 15 18:18:10 dimitri kernel: b43-phy0: Loading firmware version
> 478.104 (2008-07-01 00:50:23)
> > Aug 15 18:18:10 dimitri kernel: b43-phy0 debug: b2062: Using crystal
> tab entry 19200 kHz.
> > Aug 15 18:18:10 dimitri kernel: b43-phy0 debug: RC calib: Failed to
> switch to channel 7, error = -5
> >
> >
> > The patch follows, tested on 2.6.32.18 and 2.6.35.2, both built for
> x86_64.
> >
> > ---
> > b43: Bump the radio version 0x2063-rev-2 to 0x2063.
> >
> > Signed-off-by: <dimitri.gorokhovik@free.fr>
> > ---
> > diff --git a/drivers/net/wireless/b43/main.c
> b/drivers/net/wireless/b43/main.c
> > index 7965b70..d245a23 100644
> > --- a/drivers/net/wireless/b43/main.c
> > +++ b/drivers/net/wireless/b43/main.c
> > @@ -4084,6 +4084,7 @@ static int b43_phy_versioning(struct b43_wldev
> *dev)
> > case B43_PHYTYPE_LP:
> > if (radio_ver != 0x2062 && radio_ver != 0x2063)
> > unsupported = 1;
> > + radio_ver += radio_rev > 1;
> > break;
> > default:
> > B43_WARN_ON(1);
> > --
> > 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]: b43: is there such a thing as radio 0x2062 rev 2?
From: Larry Finger @ 2010-08-15 20:17 UTC (permalink / raw)
To: dimitri.gorokhovik
Cc: Gábor Stefanik, linville, stefano brivio, linux-wireless
In-Reply-To: <1123777895.142301281900112563.JavaMail.root@zimbra3-e1.priv.proxad.net>
On 08/15/2010 02:21 PM, dimitri.gorokhovik@free.fr wrote:
>
> ----- "Gábor Stefanik" <netrolller.3d@gmail.com> a écrit :
>
>> Does the card actually work if you make b43 believe that it has a
>> BCM2063 radio?
> The interface stays on (the WiFi LED lit), and I can scan and see
> the networks (Quality info seems OK as well with 2.6.35). However,
> I am still unable to connect to either an open or a protected
> network:
>
> Aug 15 19:04:11 dimitri kernel: wlan0: authenticate with 00:17:33:1e:13:70 (try 1)
> Aug 15 19:04:11 dimitri kernel: wlan0: authenticated
> Aug 15 19:04:11 dimitri kernel: wlan0: associate with 00:17:33:1e:13:70 (try 1)
> Aug 15 19:04:11 dimitri kernel: wlan0: RX AssocResp from 00:17:33:1e:13:70 (capab=0x411 status=0 aid=2)
> Aug 15 19:04:11 dimitri kernel: wlan0: associated
> Aug 15 19:04:16 dimitri kernel: No probe response from AP 00:17:33:1e:13:70 after 500ms, disconnecting.
>
>> BTW, all BCM2062 radios seen so far are rev.2, and none have shown
>> this error. Maybe your card actually has a BCM2063 radio, but for
>> some reason b43 detects it as a BCM2062?
> Sure, this is of course possible (I don't really believe my patch
> fixes the problem). The MAC address of the WiFi card is
> 00:22:68:ba:e2:ef (maybe somebody knows know the manufacturing
> series).
>
> For the record, I was able, only once, to run the unmodified driver
> (2.6.32 x86+_64 debian kernel), but was never able to get it ever
> again after that. That time, the HDMI res negotiated on both my
> screens (though a dock) was rather unusual (something like
> 11xx X 9xx) so I think my problem might be some sort of CEM
> problem.
>
>>
>> Also, does the Broadcom hybrid driver handle your card?
> Last time I tried (more than a year ago), from memory, I believe,
> I was able to scan, but I had the problems with Network Manager
> support and didn't go for manual config.
>From a quick look at the latest Broadcom driver that we have for RE, for PHY rev
<= 2, there are times when a 2063 radio is treated as a 2062, but there are
others where it is a 2063.
When I get time, I'll try to sort it out and update the specs. In the meantime,
NACK on the patch. It is certainly incomplete, and does not appear to help.
Larry
^ permalink raw reply
* RE: [PATCH v4 3/8] wireless: wl1271: add platform driver to get board data
From: DebBarma, Tarun Kanti @ 2010-08-16 4:21 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: felipe.balbi@nokia.com, Ohad Ben-Cohen, Kalle Valo,
Pandita, Vikram, akpm@linux-foundation.org,
Quadros Roger (Nokia-MS/Helsinki), Tony Lindgren,
linux-wireless@vger.kernel.org, Mark Brown,
linux-mmc@vger.kernel.org, Nicolas Pitre, San Mehat,
Chikkature Rajashekar, Madhusudhan,
Coelho Luciano (Nokia-MS/Helsinki), linux-omap@vger.kernel.org,
Ido Yariv, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20100811212513.GC827@n2100.arm.linux.org.uk>
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Thursday, August 12, 2010 2:55 AM
> To: DebBarma, Tarun Kanti
> Cc: felipe.balbi@nokia.com; Ohad Ben-Cohen; Kalle Valo; Pandita, Vikram;
> akpm@linux-foundation.org; Quadros Roger (Nokia-MS/Helsinki); Tony
> Lindgren; linux-wireless@vger.kernel.org; Mark Brown; linux-
> mmc@vger.kernel.org; Nicolas Pitre; San Mehat; Chikkature Rajashekar,
> Madhusudhan; Coelho Luciano (Nokia-MS/Helsinki); linux-
> omap@vger.kernel.org; Ido Yariv; linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH v4 3/8] wireless: wl1271: add platform driver to get
> board data
>
> On Thu, Aug 12, 2010 at 12:57:18AM +0530, DebBarma, Tarun Kanti wrote:
> >
> > > -----Original Message-----
> > > From: Felipe Balbi [mailto:felipe.balbi@nokia.com]
> > > Sent: Thursday, August 12, 2010 12:27 AM
> > > To: DebBarma, Tarun Kanti
> > > Cc: Balbi Felipe (Nokia-MS/Helsinki); Ohad Ben-Cohen; linux-
> > > wireless@vger.kernel.org; linux-mmc@vger.kernel.org; linux-
> > > omap@vger.kernel.org; Ido Yariv; Mark Brown; linux-arm-
> > > kernel@lists.infradead.org; Chikkature Rajashekar, Madhusudhan; Coelho
> > > Luciano (Nokia-MS/Helsinki); akpm@linux-foundation.org; San Mehat;
> Quadros
> > > Roger (Nokia-MS/Helsinki); Tony Lindgren; Nicolas Pitre; Pandita,
> Vikram;
> > > Kalle Valo
> > > Subject: Re: [PATCH v4 3/8] wireless: wl1271: add platform driver to
> get
> > > board data
> > >
> > > Hi,
> > >
> > > On Wed, Aug 11, 2010 at 08:52:54PM +0200, ext DebBarma, Tarun Kanti
> wrote:
> > > >True; however if we go by that argument than we can also assume pdata
> > > >is valid, so that we would not need the below check.
> > >
> > > of course not. You can have devices that just play well with default
> > > values or devices where you don't need the flexibility of platform
> data.
> > > That's why we check.
> > >
> > > platform_device pointers on the other hand, are guaranteed to be
> always
> > > true, if it isn't then you should oops, you deserve to oops because
> > > something is really really wrong.
> > >
> > Sounds perfect!
> > What that means is _probe() function makes sense only for cases where we
> > have valid platform data because we are returning right at the top if
> > pdata is not valid. If this is the case I was curious to know why not
> > framework make another check for valid pdata before calling _probe()
> > instead of coming all the way to _probe() and then returning!
>
> Platform devices are not for passing platform data around - they're for
> declaring platform hardware devices that we want drivers to handle -
> and it depends on the driver whether having platform data is appropriate
> or not.
>
> This proposal is, IMHO, abusing the platform device/driver support to
> achieve its own goals. I've outlined a far simpler and easiler solution
> which avoids this kind of abuse, and given suggestions on how to extend
> it to support multiple instances.
I guess I have not put my question in the right perspective. As you have said, platform devices are not meant for passing data around, it appeared to me contradictory when in the probe() we are just checking the pdata and proceeding/returning based upon its value, as if platform device has no other functions. So, the question should have been what else we could do in probe() with platform device other than manipulation of pdata, other than modification of the framework in the real sense.
Anyways, I will go through the suggestions you mentioned. Thanks for the clarifications.
^ permalink raw reply
* Re: [PATCH v2] cfg80211: fix race between sysfs and cfg80211
From: Johannes Berg @ 2010-08-16 9:06 UTC (permalink / raw)
To: mbizon; +Cc: linux-wireless
In-Reply-To: <1281767472.12446.551.camel@sakura.staff.proxad.net>
On Sat, 2010-08-14 at 08:31 +0200, Maxime Bizon wrote:
> The driver is still inside ieee80211_register_hw(), but the userspace is
> able to create the AP interface before the call is over. Once
> wiphy_register() is done, no lock seems to prevent this from happening.
>
> ieee80211_init_rate_ctrl_alg() then fails with EBUSY, and
> ieee80211_register_hw() starts unregistering the phy.
>
> Is that expected ?
Oops. No, not really, but I think the problem is that we do
wiphy_register far too early. I think we should see if we can reorder
the code in register_hw(). It won't be perfect wrt. debugfs, but I don't
think that is a problem.
johannes
^ permalink raw reply
* Re: iwlwifi connection problems
From: Johannes Berg @ 2010-08-16 13:16 UTC (permalink / raw)
To: Alex Romosan; +Cc: Guy, Wey-Yi, linux-wireless@vger.kernel.org
In-Reply-To: <8762zq76p3.fsf@sycorax.lbl.gov>
On Wed, 2010-08-04 at 08:12 -0700, Alex Romosan wrote:
> Johannes Berg <johannes@sipsolutions.net> writes:
>
> > On Wed, 2010-08-04 at 08:08 -0700, Alex Romosan wrote:
> >
> >> > Thanks. The down/up is fine, I'll be able to identify that in the
> >> > traces. Except the "working" trace looks like it only starts after you
> >> > connected already?
> >>
> >> the driver connects automatically on boot, so, yes, it was after i was
> >> connected. i can bring down the interface and try again if you want.
> >
> > Yes, please do that.
>
> http://caliban.lbl.gov/iwlwifi/trace.dat-working.before.ifup.gz
Alex, thanks. I apologise for the delay. I should've asked you much
earlier to do this -- could you open a bug report on
bugzilla.intellinuxwireless.org and attach all the information you
gathered? That way, hopefully we can find somebody more familiar with
3945 to help you with this. I only joined the team long after it, so I'm
not familiar with the device at all. When you do this, feel free to
paste this link to the thread:
http://thread.gmane.org/gmane.linux.kernel.wireless.general/53539
Also, have you tried the released 2.6.35.2?
johannes
^ permalink raw reply
* Re: iwlwifi connection problems
From: Alex Romosan @ 2010-08-16 13:44 UTC (permalink / raw)
To: Johannes Berg; +Cc: Guy, Wey-Yi, linux-wireless@vger.kernel.org
In-Reply-To: <1281964617.3683.23.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> Alex, thanks. I apologise for the delay. I should've asked you much
> earlier to do this -- could you open a bug report on
> bugzilla.intellinuxwireless.org and attach all the information you
> gathered?
okay, i'll do that.
> Also, have you tried the released 2.6.35.2?
i haven't, tried 2.6.36-rc1 last night but got a series of oopses while
booting so i didn't get a chance to test it. i'll give 2.6.35.2 a try at
some point soon. thanks for all the help.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
^ permalink raw reply
* Re: iwl3945 not associating on 2.6.35
From: John W. Linville @ 2010-08-16 14:52 UTC (permalink / raw)
To: Marcus Better; +Cc: linux-wireless
In-Reply-To: <i485ou$qmb$1@dough.gmane.org>
On Sun, Aug 15, 2010 at 09:42:15AM +0200, Marcus Better wrote:
> Hi,
>
> after upgrading from 2.6.34 to either 2.6.35 or 2.6.35.1, wpasupplicant will
> no longer associate to my WPA2 access point. The log is full of "Failed to
> initiate AP scan" messages.
>
> Is this a known issue? I couldn't quite find out by sifting through the
> archives... The system is a Thinkpad T61, x86_64, Debian sid, network-
> manager and wpasupplicant 0.6.10-2.
>
> Cheers,
>
> Marcus
I'm not aware of this issue. Please open a bug at bugzilla.kernel.org.
Please include dmesg output for starters.
Thanks,
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH 3/16] drivers/net/wireless/wl12xx: Use available error codes
From: Julia Lawall @ 2010-08-16 16:25 UTC (permalink / raw)
To: Kalle Valo, John W. Linville, linux-wireless, netdev,
linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
In each case, error codes are stored in ret, but the return value is always
0. Return ret instead.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@r@
local idexpression x;
constant C;
@@
if (...) { ...
x = -C
... when != x
(
return <+...x...+>;
|
return NULL;
|
return;
|
* return ...;
)
}
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
This changes the semantics and has not been tested.
drivers/net/wireless/wl12xx/wl1251_acx.c | 2 +-
drivers/net/wireless/wl12xx/wl1251_cmd.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1251_acx.c b/drivers/net/wireless/wl12xx/wl1251_acx.c
index 91891f9..2f8a2ba 100644
--- a/drivers/net/wireless/wl12xx/wl1251_acx.c
+++ b/drivers/net/wireless/wl12xx/wl1251_acx.c
@@ -380,7 +380,7 @@ int wl1251_acx_pd_threshold(struct wl1251 *wl)
out:
kfree(pd);
- return 0;
+ return ret;
}
int wl1251_acx_slot(struct wl1251 *wl, enum acx_slot_type slot_time)
diff --git a/drivers/net/wireless/wl12xx/wl1251_cmd.c b/drivers/net/wireless/wl12xx/wl1251_cmd.c
index a37b30c..949b6a3 100644
--- a/drivers/net/wireless/wl12xx/wl1251_cmd.c
+++ b/drivers/net/wireless/wl12xx/wl1251_cmd.c
@@ -200,7 +200,7 @@ int wl1251_cmd_vbm(struct wl1251 *wl, u8 identity,
out:
kfree(vbm);
- return 0;
+ return ret;
}
int wl1251_cmd_data_path(struct wl1251 *wl, u8 channel, bool enable)
^ permalink raw reply related
* [PATCH 10/16] drivers/net/wireless/wl12xx: Use available error codes
From: Julia Lawall @ 2010-08-16 16:27 UTC (permalink / raw)
To: Luciano Coelho, John W. Linville, linux-wireless, netdev,
linux-kernel, kernel-janitors
From: Julia Lawall <julia@diku.dk>
Error codes are stored in ret, but the return value is always 0. Return
ret instead.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@r@
local idexpression x;
constant C;
@@
if (...) { ...
x = -C
... when != x
(
return <+...x...+>;
|
return NULL;
|
return;
|
* return ...;
)
}
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
This changes the semantics and has not been tested.
drivers/net/wireless/wl12xx/wl1271_acx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_acx.c b/drivers/net/wireless/wl12xx/wl1271_acx.c
index bb245f0..f03ad08 100644
--- a/drivers/net/wireless/wl12xx/wl1271_acx.c
+++ b/drivers/net/wireless/wl12xx/wl1271_acx.c
@@ -269,7 +269,7 @@ int wl1271_acx_pd_threshold(struct wl1271 *wl)
out:
kfree(pd);
- return 0;
+ return ret;
}
int wl1271_acx_slot(struct wl1271 *wl, enum acx_slot_type slot_time)
^ permalink raw reply related
* Re: iwlwifi connection problems
From: Alex Romosan @ 2010-08-16 16:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: Guy, Wey-Yi, linux-wireless@vger.kernel.org
In-Reply-To: <1281964617.3683.23.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> Also, have you tried the released 2.6.35.2?
just tried it with 2.6.36-rc1 (after applying a reiserfs patch) and i
still need to comment out the call to iwlcore_commit_rxon(priv); on line
1361 of iwl-core.c. i'll file the bug, but if nobody steps forward,
wouldn't it make sense just to remove that call? thanks.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
^ permalink raw reply
* Re: [PATCH 3/16] drivers/net/wireless/wl12xx: Use available error codes
From: Kalle Valo @ 2010-08-16 17:47 UTC (permalink / raw)
To: Julia Lawall
Cc: John W. Linville, linux-wireless, netdev, linux-kernel,
kernel-janitors
In-Reply-To: <Pine.LNX.4.64.1008161825010.19313@ask.diku.dk>
On 08/16/2010 07:25 PM, Julia Lawall wrote:
> From: Julia Lawall <julia@diku.dk>
>
> In each case, error codes are stored in ret, but the return value is always
> 0. Return ret instead.
Thanks, looks correct to me.
Acked-by: Kalle Valo <kvalo@adurom.com>
Kalle
^ permalink raw reply
* [RFT] BCM4312 users with DMA errors, please test!
From: Gábor Stefanik @ 2010-08-16 17:59 UTC (permalink / raw)
To: b43-dev, linux-wireless
[-- Attachment #1: Type: text/plain, Size: 456 bytes --]
Hello Everyone!
If you are experiencing DMA errors on a BCM4312, please test the
attached patch. It implements the PCI-E SERDES workaround, which the
hybrid driver is applying during early init to LP-PHY cards, and which
is a good candidate for the cause of the DMA error.
Note that this is not a final patch & it may cause collateral damage
for non-4312 cards; if it helps the 4312 problem, I will submit a
cleaned-up version.
Thanks,
Gábor
[-- Attachment #2: pcie_serdes_workaround.diff --]
[-- Type: application/octet-stream, Size: 3421 bytes --]
diff --git a/drivers/ssb/driver_pcicore.c b/drivers/ssb/driver_pcicore.c
index 0e8d352..9f5c5e2 100644
--- a/drivers/ssb/driver_pcicore.c
+++ b/drivers/ssb/driver_pcicore.c
@@ -446,13 +446,71 @@ static void ssb_pcie_write(struct ssb_pcicore *pc, u32 address, u32 data)
pcicore_write32(pc, 0x134, data);
}
+static bool ssb_pcie_mdio_set_block(struct ssb_pcicore *pc, u8 device)
+{
+ const u16 mdio_control = 0x128;
+ const u16 mdio_data = 0x12C;
+
+ pcicore_write32(pc, mdio_data, 0x57C20000 | (device << 4));
+ udelay(10);
+
+ for (i = 0; i < 200; i++) {
+ if (pcicore_read32(pc, mdio_control) & 0x100)
+ return true;
+ msleep(1);
+ }
+
+ return false;
+}
+
+static u16 ssb_pcie_mdio_read(struct ssb_pcicore *pc, u8 device,
+ u8 address)
+{
+ const u16 mdio_control = 0x128;
+ const u16 mdio_data = 0x12C;
+ u32 v;
+ int i, imax;
+ u16 data;
+
+ v = 0x80; /* Enable Preamble Sequence */
+ v |= 0x2; /* MDIO Clock Divisor */
+ pcicore_write32(pc, mdio_control, v);
+
+ v = (1 << 30); /* Start of Transaction */
+ v |= (1 << 29); /* Read Transaction */
+ v |= (1 << 17); /* Turnaround */
+
+ if (pc->dev->id.revision >= 10) {
+ if (!ssb_pcie_mdio_set_block(pc, device))
+ return 0;
+ imax = 200;
+ } else {
+ v |= (u32)device << 22;
+ imax = 10;
+ }
+ v |= (u32)address << 18;
+ pcicore_write32(pc, mdio_data, v);
+ /* Wait for the device to complete the transaction */
+ udelay(10);
+ for (i = 0; i < imax; i++) {
+ v = pcicore_read32(pc, mdio_control);
+ if (v & 0x100 /* Trans complete */)
+ break;
+ msleep(1);
+ }
+ udelay(10);
+ data = pcicore_read32(pc, mdio_data) & 0xFFFF
+ pcicore_write32(pc, mdio_control, 0);
+ return data;
+}
+
static void ssb_pcie_mdio_write(struct ssb_pcicore *pc, u8 device,
u8 address, u16 data)
{
const u16 mdio_control = 0x128;
const u16 mdio_data = 0x12C;
u32 v;
- int i;
+ int i, imax;
v = 0x80; /* Enable Preamble Sequence */
v |= 0x2; /* MDIO Clock Divisor */
@@ -461,13 +519,21 @@ static void ssb_pcie_mdio_write(struct ssb_pcicore *pc, u8 device,
v = (1 << 30); /* Start of Transaction */
v |= (1 << 28); /* Write Transaction */
v |= (1 << 17); /* Turnaround */
- v |= (u32)device << 22;
+
+ if (pc->dev->id.revision >= 10) {
+ if (!ssb_pcie_mdio_set_block(pc, device))
+ return;
+ imax = 200;
+ } else {
+ v |= (u32)device << 22;
+ imax = 10;
+ }
v |= (u32)address << 18;
v |= data;
pcicore_write32(pc, mdio_data, v);
/* Wait for the device to complete the transaction */
udelay(10);
- for (i = 0; i < 10; i++) {
+ for (i = 0; i < imax; i++) {
v = pcicore_read32(pc, mdio_control);
if (v & 0x100 /* Trans complete */)
break;
@@ -591,6 +657,20 @@ int ssb_pcicore_dev_irqvecs_enable(struct ssb_pcicore *pc,
tmp = ssb_pcie_read(pc, 0x100);
tmp |= 0x40;
ssb_pcie_write(pc, 0x100, tmp);
+ } else {
+ const u8 serdes_pll_device = 0x1D;
+ const u8 serdes_rx_device = 0x1F;
+
+ /* PCI-E PHY Status register */
+ if (ssb_pcie_read(pc, 0x204) & 0x10)
+ ssb_pcie_mdio_write(pc, serdes_rx_device,
+ 1 /* Control */, 0xC0);
+ else
+ ssb_pcie_mdio_write(pc, serdes_rx_device,
+ 1 /* Control */, 0x80);
+ ssb_pcie_mdio_write(pc, serdes_pll_device, 1,
+ ssb_pcie_mdio_read(pc, serdes_pll_device, 1) &
+ ~0x4000);
}
}
pc->setup_done = 1;
^ permalink raw reply related
* Re: [RFT] BCM4312 users with DMA errors, please test!
From: Gábor Stefanik @ 2010-08-16 18:15 UTC (permalink / raw)
To: Arthur Moreira, b43-dev, linux-wireless
In-Reply-To: <AANLkTin0R6k0_GoSEN8aJ8t_fTJw9h_N_0etcxAokv6N@mail.gmail.com>
2010/8/16 Arthur Moreira <arthur.moreira@gmail.com>:
> Hi,
> I have a BCM4353 card, with the hybrid module wl work fine to find
> and conect to networks.
> But, a want to put the card in monitor mode.
>
> (my card is a 802.11bgN mini card, in a dell vostro)
>
> this path will help me? and.. how to aply the path? the comand path $#
> < file ???
> tks
>
>
> Arthur Moreira
>
No, this patch is only for BCM4312 devices, not the BCM43224 that you
have (there is no such thing as a "BCM4353" AFAIK - PCI device IDs
don't map directly to chip IDs!). Your card is an N-PHY, probably
revision 4 or 5 (you can see the revision by adding 14e4:4353 to the
list of PCI IDs in ssb, then looking for the "FOUND UNSUPPORTED PHY"
line in dmesg). We are working on N-PHYs, revisions <=2 will likely be
usable soon; rev.3 and newer will take longer, however. (It is
possible that this patch will also be needed for N-PHYs if they show
similar DMA errors to the 4312, but it is certainly not enough to get
N-PHYs to work.)
>
>
>
> 2010/8/16 Gábor Stefanik <netrolller.3d@gmail.com>:
>> Hello Everyone!
>>
>> If you are experiencing DMA errors on a BCM4312, please test the
>> attached patch. It implements the PCI-E SERDES workaround, which the
>> hybrid driver is applying during early init to LP-PHY cards, and which
>> is a good candidate for the cause of the DMA error.
>> Note that this is not a final patch & it may cause collateral damage
>> for non-4312 cards; if it helps the 4312 problem, I will submit a
>> cleaned-up version.
>>
>> Thanks,
>> Gábor
>>
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [RFT] BCM4312 users with DMA errors, please test!
From: Gábor Stefanik @ 2010-08-16 18:45 UTC (permalink / raw)
To: Arthur Moreira, b43-dev, linux-wireless
In-Reply-To: <AANLkTinkx+FjrAR48dziDR2kX48JRcjm3SF7jhhi4_oM@mail.gmail.com>
2010/8/16 Arthur Moreira <arthur.moreira@gmail.com>:
> Ok, tks Gábor
>
> i will wait, i need much of this card working in monitor mode for
> tests and demonstration and my organization. i work with security in
> my city. and i dont want to plug another card, like usb ou pciexpreess
> card than a original embedded.
>
> if you need a help to tests and beta version of driver or modules
> call me
>
>
> Arthur Moreira
Well, I post any testing requests on the list, so you will probably
see them here.
Also, please use the Reply to All button when replying to a list!
>
> 2010/8/16 Gábor Stefanik <netrolller.3d@gmail.com>:
>> 2010/8/16 Arthur Moreira <arthur.moreira@gmail.com>:
>>> Hi,
>>> I have a BCM4353 card, with the hybrid module wl work fine to find
>>> and conect to networks.
>>> But, a want to put the card in monitor mode.
>>>
>>> (my card is a 802.11bgN mini card, in a dell vostro)
>>>
>>> this path will help me? and.. how to aply the path? the comand path $#
>>> < file ???
>>> tks
>>>
>>>
>>> Arthur Moreira
>>>
>>
>> No, this patch is only for BCM4312 devices, not the BCM43224 that you
>> have (there is no such thing as a "BCM4353" AFAIK - PCI device IDs
>> don't map directly to chip IDs!). Your card is an N-PHY, probably
>> revision 4 or 5 (you can see the revision by adding 14e4:4353 to the
>> list of PCI IDs in ssb, then looking for the "FOUND UNSUPPORTED PHY"
>> line in dmesg). We are working on N-PHYs, revisions <=2 will likely be
>> usable soon; rev.3 and newer will take longer, however. (It is
>> possible that this patch will also be needed for N-PHYs if they show
>> similar DMA errors to the 4312, but it is certainly not enough to get
>> N-PHYs to work.)
>>
>>>
>>>
>>>
>>> 2010/8/16 Gábor Stefanik <netrolller.3d@gmail.com>:
>>>> Hello Everyone!
>>>>
>>>> If you are experiencing DMA errors on a BCM4312, please test the
>>>> attached patch. It implements the PCI-E SERDES workaround, which the
>>>> hybrid driver is applying during early init to LP-PHY cards, and which
>>>> is a good candidate for the cause of the DMA error.
>>>> Note that this is not a final patch & it may cause collateral damage
>>>> for non-4312 cards; if it helps the 4312 problem, I will submit a
>>>> cleaned-up version.
>>>>
>>>> Thanks,
>>>> Gábor
>>>>
>>>
>>
>>
>>
>> --
>> Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
>>
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Compat-wireless release for 2010-08-16 is baked
From: Compat-wireless cronjob account @ 2010-08-16 19:03 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
16383b1..3639a89 history -> origin/history
+ f55f020...f74eac3 master -> origin/master (forced update)
ad41a1e..da5cabf stable -> origin/stable
* [new tag] next-20100816 -> next-20100816
* [new tag] v2.6.36-rc1 -> v2.6.36-rc1
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
cat: compat_base_tree: No such file or directory
cat: compat_base_tree_version: No such file or directory
cat: compat_version: No such file or directory
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
scripts/Makefile.clean:17: /var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile: No such file or directory
make[4]: *** No rule to make target `/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile'. Stop.
make[3]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap] Error 2
make[2]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless] Error 2
make[1]: *** [_clean_/var/opt/compat/compat-wireless-2.6] Error 2
make: *** [clean] Error 2
compat-wireless code metrics
494670 - Total upstream lines of code being pulled
^ permalink raw reply
* Re: [RFT] BCM4312 users with DMA errors, please test!
From: Larry Finger @ 2010-08-16 19:06 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: b43-dev, linux-wireless
In-Reply-To: <AANLkTimMhW7OX3DT7A3EDNaOnr577KmTv5w9C_mz19TG@mail.gmail.com>
On 08/16/2010 12:59 PM, Gábor Stefanik wrote:
> Hello Everyone!
>
> If you are experiencing DMA errors on a BCM4312, please test the
> attached patch. It implements the PCI-E SERDES workaround, which the
> hybrid driver is applying during early init to LP-PHY cards, and which
> is a good candidate for the cause of the DMA error.
> Note that this is not a final patch & it may cause collateral damage
> for non-4312 cards; if it helps the 4312 problem, I will submit a
> cleaned-up version.
The patch that you distributed had a couple of errors in compiling, namely:
CC [M] drivers/ssb/driver_pcicore.o
drivers/ssb/driver_pcicore.c: In function ‘ssb_pcie_mdio_set_block’:
drivers/ssb/driver_pcicore.c:457:7: error: ‘i’ undeclared (first use in this
function)
drivers/ssb/driver_pcicore.c:457:7: note: each undeclared identifier is reported
only once for each function it appears in
drivers/ssb/driver_pcicore.c: In function ‘ssb_pcie_mdio_read’:
drivers/ssb/driver_pcicore.c:503:2: error: expected ‘;’ before ‘pcicore_write32’
make[2]: *** [drivers/ssb/driver_pcicore.o] Error 1
make[1]: *** [drivers/ssb] Error 2
make[1]: *** Waiting for unfinished jobs....
Did you forget a quilt refresh?
My machine does not have the DMA error, but I will be testing.
Larry
^ permalink raw reply
* nl80211 scanning from userspace
From: Christopher Piggott @ 2010-08-16 19:06 UTC (permalink / raw)
To: linux-wireless
Hi,
I'm trying to figure out how to use nl80211 to scan. The "iw" example
has been somewhat helpful, though the userspace header file nl80211
and /usr/include/netlink/*.h have been helpful. I'm on an ubuntu
system, and I'm sorry to say that the libnl1-doc package has some
doxygen files in it that don't agree with the actual headers (function
prototypes differ, etc.) but it's enough to get at least some picture
of what's going on.
Here's what I have put together so far, in snippets:
Register callbacks for all messages:
callbacks = nl_cb_alloc(NL_CB_DEFAULT);
nl_cb_set_all(callbacks, NL_CB_CUSTOM, rx, NULL);
Create a socket, allocate a cache. I do error checking on each of
these calls to make sure they succeed, but I'm eliminating that here
for brevity:
genl_connect(sock);
cache = genl_ctrl_alloc_cache(sock);
nl80211 = genl_ctrl_search_by_name(cache, cacheName); /*
cacheName is "nl80211" */
Start building the message. First build an SSID list with one entry
in it (empty string)
struct nl_msg *ssids = nlmsg_alloc();
nla_put_string(ssids, 0, "");
Next build the scan request message:
struct nl_msg *msg = nlmsg_alloc();
int flags = 0;
int cmd = NL80211_CMD_TRIGGER_SCAN;
genlmsg_put(msg, 0, 0, genl_family_get_id(nl80211), 0, flags, cmd, 0);
/* append our ssid list to this message as a nested message */
nla_put_nested(msg, NL80211_ATTR_SCAN_SSIDS, ssids)
Finally I send the request:
int rc = nl_send_auto_complete(sock, msg);
>From this I found out that 32 bytes were sent (seems reasonable).
Unfortunately, what I get back is this:
[HEADER] 16 octets
.nlmsg_len = 52
.nlmsg_type = 2 <ERROR>
.nlmsg_flags = 0 <>
.nlmsg_seq = 1282012377
.nlmsg_pid = 30415
[ERRORMSG] 20 octets
.error = -22 "Invalid argument"
[ORIGINAL MESSAGE] 16 octets
.nlmsg_len = 16
.nlmsg_type = 23 <0x17>
.nlmsg_flags = 5 <REQUEST,ACK>
.nlmsg_seq = 1282012377
.nlmsg_pid = 30415
so, even following what iw's "scan.c" does I have somehow pieced the
request together incorrectly.
Questions:
1. Am I doing something obviously wrong?
2. Is this even the interface I should be using to do this? (I need
to scan for all access points on a specific "hidden" SSID to retrieve
some information about their SNR. It's a type of "site survey"
application for building contour maps of coverage).
I'm not sure what I'm doing next makes sense, either. After I send
the scan request I wait 3 seconds then start reading like this:
while(nl_recvmsgs(sock, callbacks) != 0)
{
printf("processed a result\n");
}
I have registered my callback earlier; this seems to work because I
get the message (above) plus later an "Operation Not Supported"
message. The operation is indeed supported, as it works with the
iwlist and iw command line tools.
--Chris
^ 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