* Re: RTL8187B wireless driver issue
From: Hin-Tak Leung @ 2009-09-15 1:24 UTC (permalink / raw)
To: Vignette consultant; +Cc: Larry Finger, linux-wireless
In-Reply-To: <3b0e19890909141434t758a9b3dk2799623dfb19c6a6@mail.gmail.com>
On Mon, Sep 14, 2009 at 10:34 PM, Vignette consultant
<vignette75@gmail.com> wrote:
> Hi
>
> I get timed out errors consistently as per attached log file.
> I tried several Live Cds from fedora, sidux - but i get the same dhcp
> error. I used to be able to connect before.
>
> Please check attached log and see if you can point me towards the solution.
Your log do not add anything new - I already asked you to do 3 things,
and there is no indication you have done any of them; there is no
point writing me the same things you had wrote to Larry or
linux-wireless, and try to get a private answer - Your won't. (please
do not remove the CC:'s and please do not write privately on general
help matters).
1) make sure that wpa_supplicant is *not* running - newer liveCDs can
have wpa_supplicant working (compare to older which does not use it).
2) make sure your authentication credentials - essid, passphases - are
in the network config files and agree with what you are trying to set
on the command line, just in case udev wants to unset your credentials
you are setting manually on the comamnd line.
3) switch from kernel-modules-backport to a different version of
compat-wireless and/or vice versa. There were some transient bugs a
while ago.
>
> thanks
> sam
>
> On 9/14/09, Hin-Tak Leung <hintak.leung@gmail.com> wrote:
>> On Mon, Sep 14, 2009 at 6:56 PM, Vignette consultant
>> <vignette75@gmail.com> wrote:
>>> Larry,
>>>
>>> I got the same error even after adding wlan0 in
>>> /etc/network/interfaces file. I set the essid using "sudo iwconfig
>>> wlan0 essid linksys" command and restarted network. I tried other
>>> essids, but it gives same error.
>>>
>>> Attached files contain log files. Please advise about solution.
>>>
>>> How do I disable usb monitoring log, so I can see wlan0 interface log
>>> from dmesg?
>>>
>>> Thanks
>>> Sam
>>>
>>> On 9/14/09, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>>> Vignette consultant wrote:
>>>>> Hi
>>>>>
>>>>> Attached files contain several logs of various commands. The log-1
>>>>> file is before running command and log-2 file is after running
>>>>> specific command.
>>>>>
>>>>> Here are commands that I give as soon as I log in. It's server
>>>>> edition.
>>>>>
>>>>> $ sudo ifconfig wlan0 up
>>>>> $ sudo iwconfig wlan0 ESSID linksys
>>>>> $ sudo dhclient wlan0 - results in no IP addr leased
>>>>
>>>> Your wireless has not associated and has no communication, which is
>>>> why it cannot get an IP using DHCP.
>>>>
>>>> A quick check with Google indicates that Ubuntu uses
>>>> /etc/network/interfaces to control the devices. Once that is correct,
>>>> you should be able to 'sudo /etc/init.d/networking restart' to start
>>>> the network. If the server is properly configured, the network should
>>>> start on boot.
>>>>
>>>> BTW, the dmesg buffer is circular. All that usb monitoring output has
>>>> completely filled the buffer, and it contains no useful information.
>>>>
>>>
>>
>> scanning works, so there doesn't seem to be anything wrong with the
>> device or the driver itself. However, even for static configuration,
>> sometimes wpa_supplicant can still be involved and interfere, so you
>> probably want to make sure you put all the relevant config in
>> wpa_supplicant.conf , as well as manually; or make sure no other
>> network tools are running. (udev can launch wpa_supplicant/dhcp on
>> ifconfig up automatically - the 'not ready' messages are from udev
>> hooks). Lastly, I think the Ubuntu/Debian family packages
>> compat-wireless as 'kernel-modules-backport' or something; try that or
>> even compat-wireless. ( a while back there was a bug with
>> associattion).
>>
>
^ permalink raw reply
* Re: zd1211rw on ppc (iBook G4) -- Solved, somewhat)
From: Hin-Tak Leung @ 2009-09-15 1:08 UTC (permalink / raw)
To: Leonardo Hamada; +Cc: linux-wireless
In-Reply-To: <8ea57b3c57061154c0d312925100c827.squirrel@webmail.ufra.edu.br>
(I'd prefer *not* to have one-on-one exchanges, so where appropriate
please CC: the list)
On Tue, Sep 15, 2009 at 12:30 AM, Leonardo Hamada
<leonardo.hamada@ufra.edu.br> wrote:
>
> Em Seg, Setembro 14, 2009 18:11, Hin-Tak Leung escreveu:
>> On Mon, Sep 14, 2009 at 5:47 PM, Leonardo H. Souza Hamada
>> <leonardo.hamada@ufra.edu.br> wrote:
>>
>>> <<<Disabling original zd1211rw in kernel configuration, recompiled
>>> kernel as instructed above, installed new kernel, reboot, many times
>>> until I got it right>>>
>>
>> The patch isn't particularly version-specific - may have applied to
>> the kernel source itself...
>
>
> No, the patch was applied to compat package. The script install what is
> necessary.
I meant the patch should have applied to the vanilla kernel source as
well, if you have gone to the trouble of recompiling the kernel to get
mac80211 as module. (i.e. don't bother with compat-wireless).
>
>
>>
>>> Results:
>>>
>>> dmesg seems ok. no errors.
>>
>> No, I want to see dmesg - there should be something similiar to this?
>>
>> cfg80211: Calling CRDA for country: GB
>> cfg80211: Regulatory domain changed to country: GB
>> (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
>> (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
>> (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
>> (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
>> (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
>
>
> I'm sure saw the first line as: cfg80211: Calling CRDA for country: JP
>
> There wasn't the rest (frequency stuff), I think. So this is suspicious.
That's strange. Do you have the crda package installed? You need the
regulatory database userland stuff for crda to work.
http://www.linuxwireless.org/en/developers/Regulatory/CRDA
>>> can do iwlist wlan0
>>>
>>> iwconfig wlan0 shows:
>>> IEEE 802.11bg Mode:Managed Access Point: Not-Associated
>>> Tx-Power=20 dBm
>>> Retry long limit:7 RTS thr:off Fragment thr:off
>>> Encryption key:off
>>> Power Management:off
>>>
>>>
>>> I do not seem to be able to connect to a given access point so far. LED
>>> does not blink.
>>
>> stay dark or stay lit?
>>
>
>
> Before ifconfig wlan0 up it stays lit. After it, always dark.
Hmm, I am not familiar with the LED code in zd1211rw - somebody else
please comment.
^ permalink raw reply
* Re: [PATCH v2] genetlink: fix netns vs. netlink table locking
From: David Miller @ 2009-09-15 0:07 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <1252760595.23427.20.camel@johannes.local>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Sat, 12 Sep 2009 07:03:15 -0600
> Since my commits introducing netns awareness into
> genetlink we can get this problem:
>
> BUG: scheduling while atomic: modprobe/1178/0x00000002
> 2 locks held by modprobe/1178:
> #0: (genl_mutex){+.+.+.}, at: [<ffffffff8135ee1a>] genl_register_mc_grou
> #1: (rcu_read_lock){.+.+..}, at: [<ffffffff8135eeb5>] genl_register_mc_g
> Pid: 1178, comm: modprobe Not tainted 2.6.31-rc8-wl-34789-g95cb731-dirty #
> Call Trace:
> [<ffffffff8103e285>] __schedule_bug+0x85/0x90
> [<ffffffff81403138>] schedule+0x108/0x588
> [<ffffffff8135b131>] netlink_table_grab+0xa1/0xf0
> [<ffffffff8135c3a7>] netlink_change_ngroups+0x47/0x100
> [<ffffffff8135ef0f>] genl_register_mc_group+0x12f/0x290
>
> because I overlooked that netlink_table_grab() will
> schedule, thinking it was just the rwlock. However,
> in the contention case, that isn't actually true.
>
> Fix this by letting the code grab the netlink table
> lock first and then the RCU for netns protection.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Applied, thanks.
^ permalink raw reply
* RE: [RFC] ar9170usb: add ar9170 usbid
From: Stephen Chen @ 2009-09-14 23:39 UTC (permalink / raw)
To: Christian Lamparter, Fabian Lenz
Cc: linux-wireless@vger.kernel.org, Luis Rodriguez
In-Reply-To: <200909142308.19569.chunkeey@googlemail.com>
Hi Christian,
I could not find this VID/PID in INF file in Windows release.
This ID combination could be obsolete.
Thank you!
Stephen
-----Original Message-----
From: Christian Lamparter [mailto:chunkeey@googlemail.com]
Sent: Tuesday, September 15, 2009 5:08 AM
To: Fabian Lenz
Cc: linux-wireless@vger.kernel.org; Luis Rodriguez; Stephen Chen
Subject: [RFC] ar9170usb: add ar9170 usbid
Reported-by: Fabian Lenz <lenz_fabian@yahoo.de>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
Stephen,
- since 0x0cf3 is Atheros' vendor id - can you please lookup the real product
code name for 0x0cf3:0x1002.
I will take care of the re-spin and update the wiki.
Thanks,
Chr
---
diff --git a/drivers/net/wireless/ath/ar9170/usb.c b/drivers/net/wireless/ath/ar9170/usb.c
index e0138ac..68b0bda 100644
--- a/drivers/net/wireless/ath/ar9170/usb.c
+++ b/drivers/net/wireless/ath/ar9170/usb.c
@@ -64,6 +64,8 @@ static struct usb_device_id ar9170_usb_ids[] = {
{ USB_DEVICE(0x0cf3, 0x9170) },
/* Atheros TG121N */
{ USB_DEVICE(0x0cf3, 0x1001) },
+ /* Atheros - Unknown Product Name - */
+ { USB_DEVICE(0x0cf3, 0x1002) },
/* Cace Airpcap NX */
{ USB_DEVICE(0xcace, 0x0300) },
/* D-Link DWA 160A */
^ permalink raw reply related
* [RFC PATCH] mac80211: Fix [re]association power saving issue on AP side
From: Igor Perminov @ 2009-09-14 23:02 UTC (permalink / raw)
To: Johannes Berg, Jouni Malinen; +Cc: linux-wireless
Consider the following step-by step:
1. A STA authenticates and associates with the AP and exchanges
traffic.
2. The STA reports to the AP that it is going to PS state.
3. Some time later the STA device goes to the stand-by mode (not only
its wi-fi card, but the device itself) and drops the association state
without sending a disassociation frame.
4. The STA device wakes up and begins authentication with an
Auth frame as it hasn't been authenticated/associated previously.
At the step 4 the AP "remembers" the STA and considers it is still in
the PS state, so the AP buffers frames, which it has to send to the STA.
But the STA isn't actually in the PS state and so it neither checks
TIM bits nor reports to the AP that it isn't power saving.
Because of that reauthentication/association fails.
To fix this issue:
1. Auth, Assoc Resp and Reassoc Resp frames are transmitted disregarding
of STA's power saving state.
2. When an application (hostapd) tries to add a STA to an AP (that
occurs when the STA has [re]associated successfully) and mac80211
already "knows" that STA, the AP resets the power saving state of the
STA and purges of frames that was previously buffered if any.
Signed-off-by: Igor Perminov <igor.perminov@inbox.ru>
---
net/mac80211/cfg.c | 15 +++++++++------
net/mac80211/sta_info.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
net/mac80211/sta_info.h | 1 +
net/mac80211/tx.c | 5 ++++-
4 files changed, 61 insertions(+), 7 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 5608f6c..20d4c12 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -704,7 +704,7 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
struct sta_info *sta;
struct ieee80211_sub_if_data *sdata;
int err;
- int layer2_update;
+ int iftype_ap;
if (params->vlan) {
sdata = IEEE80211_DEV_TO_SUB_IF(params->vlan);
@@ -731,7 +731,7 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
rate_control_rate_init(sta);
- layer2_update = sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
+ iftype_ap = sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
sdata->vif.type == NL80211_IFTYPE_AP;
rcu_read_lock();
@@ -739,17 +739,20 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
err = sta_info_insert(sta);
if (err) {
/* STA has been freed */
- if (err == -EEXIST && layer2_update) {
- /* Need to update layer 2 devices on reassociation */
+ if (err == -EEXIST && iftype_ap) {
+ /* Need to reset PS state
+ * and update layer 2 devices on reassociation */
sta = sta_info_get(local, mac);
- if (sta)
+ if (sta) {
+ sta_info_reset_ps(sta);
ieee80211_send_layer2_update(sta);
+ }
}
rcu_read_unlock();
return err;
}
- if (layer2_update)
+ if (iftype_ap)
ieee80211_send_layer2_update(sta);
rcu_read_unlock();
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index eec0014..09dc8de 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -459,6 +459,53 @@ void sta_info_clear_tim_bit(struct sta_info *sta)
spin_unlock_irqrestore(&sta->local->sta_lock, flags);
}
+void sta_info_reset_ps(struct sta_info *sta)
+{
+ struct ieee80211_sub_if_data *sdata = sta->sdata;
+ struct ieee80211_local *local = sdata->local;
+ struct ieee80211_if_ap *bss = sdata->bss;
+ unsigned long flags;
+ int filtered, buffered;
+
+ BUG_ON(!bss);
+
+ spin_lock_irqsave(&sta->local->sta_lock, flags);
+
+ if (!test_sta_flags(sta, WLAN_STA_PS)) {
+ spin_unlock_irqrestore(&sta->local->sta_lock, flags);
+ return;
+ }
+
+#ifdef CONFIG_MAC80211_VERBOSE_PS_DEBUG
+ printk(KERN_DEBUG "%s: STA %pM aid %d resets power save mode\n",
+ sdata->dev->name, sta->sta.addr, sta->sta.aid);
+#endif /* CONFIG_MAC80211_VERBOSE_PS_DEBUG */
+
+ atomic_dec(&bss->num_sta_ps);
+
+ clear_sta_flags(sta, WLAN_STA_PS);
+ drv_sta_notify(local, &sdata->vif, STA_NOTIFY_AWAKE, &sta->sta);
+
+ filtered = skb_queue_len(&sta->tx_filtered);
+ skb_queue_purge(&sta->tx_filtered);
+
+ buffered = skb_queue_len(&sta->ps_tx_buf);
+ skb_queue_purge(&sta->ps_tx_buf);
+
+ if (buffered) {
+ __sta_info_clear_tim_bit(bss, sta);
+ local->total_ps_buffered -= buffered;
+ }
+
+#ifdef CONFIG_MAC80211_VERBOSE_PS_DEBUG
+ printk(KERN_DEBUG "%s: STA %pM aid %d purged of "
+ "%d filtered/%d PS frames\n", sdata->dev->name,
+ sta->sta.addr, sta->sta.aid, filtered, buffered);
+#endif /* CONFIG_MAC80211_VERBOSE_PS_DEBUG */
+
+ spin_unlock_irqrestore(&sta->local->sta_lock, flags);
+}
+
static void __sta_info_unlink(struct sta_info **sta)
{
struct ieee80211_local *local = (*sta)->local;
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index ccc3adf..bd65d9c 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -445,6 +445,7 @@ void sta_info_unlink(struct sta_info **sta);
void sta_info_destroy(struct sta_info *sta);
void sta_info_set_tim_bit(struct sta_info *sta);
void sta_info_clear_tim_bit(struct sta_info *sta);
+void sta_info_reset_ps(struct sta_info *sta);
void sta_info_init(struct ieee80211_local *local);
int sta_info_start(struct ieee80211_local *local);
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 10a1099..4d981e7 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -367,7 +367,10 @@ ieee80211_tx_h_unicast_ps_buf(struct ieee80211_tx_data *tx)
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx->skb->data;
u32 staflags;
- if (unlikely(!sta || ieee80211_is_probe_resp(hdr->frame_control)))
+ if (unlikely(!sta || ieee80211_is_probe_resp(hdr->frame_control)
+ || ieee80211_is_auth(hdr->frame_control)
+ || ieee80211_is_assoc_resp(hdr->frame_control)
+ || ieee80211_is_reassoc_resp(hdr->frame_control)))
return TX_CONTINUE;
staflags = get_sta_flags(sta);
^ permalink raw reply related
* Re: [PATCH] b43: Don't abuse wl->current_dev in the led work
From: Larry Finger @ 2009-09-14 22:58 UTC (permalink / raw)
To: Michael Buesch; +Cc: John W. Linville, Broadcom Wireless, linux-wireless
In-Reply-To: <200909142322.09152.mb@bu3sch.de>
Michael Buesch wrote:
> Don't abuse wl->current_dev in the LED work for checking whether we're
> going down. Add an explicit variable.
> This fixes a crash on rmmod dereferencing the wl->current_dev NULL pointer
> in various other places of the driver.
>
> Signed-off-by: Michael Buesch <mb@bu3sch.de>
This patch does not apply. What other patches should I have beyond the
current state of wireless-testing?
Larry
^ permalink raw reply
* Re: A station can't reconnect after it wakes up
From: Igor Perminov @ 2009-09-14 22:55 UTC (permalink / raw)
To: Holger Schurig
Cc: Kalle Valo, Johannes Berg, linux-wireless, hostap, Jouni Malinen,
Artur Skawina
In-Reply-To: <200909141431.31091.hs4233@mail.mn-solutions.de>
On Mon, 2009-09-14 at 14:31 +0200, Holger Schurig wrote:
> > 4. The STA device wakes up and begins
> > authentication with an Auth frame as it hasn't been
> > authenticated/associated previously.
>
> What's the status of the PS bit of this Auth Frame?
The PS bit of the Auth frame indicates that the STA is under power.
And mac80211 checks the PS bit in data frames only, but not in
management ones.
> Does the station here send a NULL func packet with the "I'm under
> power again" bit? It might be necessary to do this via a
> null-func packet towards some broken APs.
No, it doesn't send. The station works under Windows Mobile 6, and I
can't change its implementation. Contrary, I'm working on making a
Linux/hostapd AP non-broken.
Igor
^ permalink raw reply
* Re: [PATCH] p54usb: add Zcomax XG-705A usbid
From: Larry Finger @ 2009-09-14 22:24 UTC (permalink / raw)
To: Christian Lamparter
Cc: Jari Jaakola, linux-wireless, John W. Linville, stable
In-Reply-To: <200909142308.43652.chunkeey@googlemail.com>
Christian Lamparter wrote:
> This patch adds a new usbid for Zcomax XG-705A to the device table.
>
> Cc: stable@kernel.org
> Reported-by: Jari Jaakola <jari.jaakola@gmail.com>
> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> ---
> diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
> index e44460f..17e1995 100644
> --- a/drivers/net/wireless/p54/p54usb.c
> +++ b/drivers/net/wireless/p54/p54usb.c
> @@ -67,6 +67,7 @@ static struct usb_device_id p54u_table[] __devinitdata = {
> {USB_DEVICE(0x0bf8, 0x1009)}, /* FUJITSU E-5400 USB D1700*/
> {USB_DEVICE(0x0cde, 0x0006)}, /* Medion MD40900 */
> {USB_DEVICE(0x0cde, 0x0008)}, /* Sagem XG703A */
> + {USB_DEVICE(0x0cde, 0x0015)}, /* Zcomax XG-705A */
> {USB_DEVICE(0x0d8e, 0x3762)}, /* DLink DWL-G120 Cohiba */
> {USB_DEVICE(0x124a, 0x4025)}, /* IOGear GWU513 (GW3887IK chip) */
> {USB_DEVICE(0x1260, 0xee22)}, /* SMC 2862W-G version 2 */
> --
ack
^ permalink raw reply
* [PATCH] b43: Don't abuse wl->current_dev in the led work
From: Michael Buesch @ 2009-09-14 21:22 UTC (permalink / raw)
To: John W. Linville; +Cc: Broadcom Wireless, linux-wireless, Larry Finger
Don't abuse wl->current_dev in the LED work for checking whether we're
going down. Add an explicit variable.
This fixes a crash on rmmod dereferencing the wl->current_dev NULL pointer
in various other places of the driver.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
---
Note to self: Don't try to safe a byte of memory :)
Index: wireless-testing/drivers/net/wireless/b43/leds.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/leds.c 2009-09-14 22:42:05.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/leds.c 2009-09-14 23:15:39.000000000 +0200
@@ -112,10 +112,7 @@ static void b43_led_brightness_set(struc
struct b43_led *led = container_of(led_dev, struct b43_led, led_dev);
struct b43_wl *wl = led->wl;
- /* The check for current_dev is only needed while unregistering,
- * so it is sequencial and does not race. But we must not dereference
- * current_dev here. */
- if (likely(wl->current_dev)) {
+ if (likely(!wl->leds.stop)) {
atomic_set(&led->state, brightness);
ieee80211_queue_work(wl->hw, &wl->leds.work);
}
@@ -314,6 +311,8 @@ void b43_leds_init(struct b43_wldev *dev
break;
}
}
+
+ dev->wl->leds.stop = 0;
}
void b43_leds_exit(struct b43_wldev *dev)
Index: wireless-testing/drivers/net/wireless/b43/leds.h
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/leds.h 2009-09-14 22:42:05.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/leds.h 2009-09-14 23:13:38.000000000 +0200
@@ -35,6 +35,7 @@ struct b43_leds {
struct b43_led led_radio;
struct b43_led led_assoc;
+ bool stop;
struct work_struct work;
};
Index: wireless-testing/drivers/net/wireless/b43/main.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/main.c 2009-09-14 23:11:17.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/main.c 2009-09-14 23:14:39.000000000 +0200
@@ -4987,7 +4987,7 @@ static void b43_remove(struct ssb_device
* might have modified it. Restoring is important, so the networking
* stack can properly free resources. */
wl->hw->queues = wl->mac80211_initially_registered_queues;
- wl->current_dev = NULL;
+ wl->leds.stop = 1;
cancel_work_sync(&wl->leds.work);
ieee80211_unregister_hw(wl->hw);
}
--
Greetings, Michael.
^ permalink raw reply
* Re: zd1211rw on ppc (iBook G4) -- Solved, somewhat)
From: Hin-Tak Leung @ 2009-09-14 21:11 UTC (permalink / raw)
To: Leonardo H. Souza Hamada; +Cc: linux-wireless
In-Reply-To: <4AAE7395.1050502@ufra.edu.br>
On Mon, Sep 14, 2009 at 5:47 PM, Leonardo H. Souza Hamada
<leonardo.hamada@ufra.edu.br> wrote:
> <<<Disabling original zd1211rw in kernel configuration, recompiled
> kernel as instructed above, installed new kernel, reboot, many times
> until I got it right>>>
The patch isn't particularly version-specific - may have applied to
the kernel source itself...
> Results:
>
> dmesg seems ok. no errors.
No, I want to see dmesg - there should be something similiar to this?
cfg80211: Calling CRDA for country: GB
cfg80211: Regulatory domain changed to country: GB
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
> can do iwlist wlan0
>
> iwconfig wlan0 shows:
> IEEE 802.11bg Mode:Managed Access Point: Not-Associated
> Tx-Power=20 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key:off
> Power Management:off
>
>
> I do not seem to be able to connect to a given access point so far. LED
> does not blink.
stay dark or stay lit?
^ permalink raw reply
* [PATCH] p54usb: add Zcomax XG-705A usbid
From: Christian Lamparter @ 2009-09-14 21:08 UTC (permalink / raw)
To: Jari Jaakola; +Cc: linux-wireless, John W. Linville, stable
In-Reply-To: <6c9000d40909141238w2331a975tdaf0952487a3c76@mail.gmail.com>
This patch adds a new usbid for Zcomax XG-705A to the device table.
Cc: stable@kernel.org
Reported-by: Jari Jaakola <jari.jaakola@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
index e44460f..17e1995 100644
--- a/drivers/net/wireless/p54/p54usb.c
+++ b/drivers/net/wireless/p54/p54usb.c
@@ -67,6 +67,7 @@ static struct usb_device_id p54u_table[] __devinitdata = {
{USB_DEVICE(0x0bf8, 0x1009)}, /* FUJITSU E-5400 USB D1700*/
{USB_DEVICE(0x0cde, 0x0006)}, /* Medion MD40900 */
{USB_DEVICE(0x0cde, 0x0008)}, /* Sagem XG703A */
+ {USB_DEVICE(0x0cde, 0x0015)}, /* Zcomax XG-705A */
{USB_DEVICE(0x0d8e, 0x3762)}, /* DLink DWL-G120 Cohiba */
{USB_DEVICE(0x124a, 0x4025)}, /* IOGear GWU513 (GW3887IK chip) */
{USB_DEVICE(0x1260, 0xee22)}, /* SMC 2862W-G version 2 */
^ permalink raw reply related
* [RFC] ar9170usb: add ar9170 usbid
From: Christian Lamparter @ 2009-09-14 21:08 UTC (permalink / raw)
To: Fabian Lenz; +Cc: linux-wireless, Luis R. Rodriguez, Stephen.Chen
In-Reply-To: <200909142046.07525.lenz_fabian@yahoo.de>
Reported-by: Fabian Lenz <lenz_fabian@yahoo.de>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
Stephen,
- since 0x0cf3 is Atheros' vendor id - can you please lookup the real product
code name for 0x0cf3:0x1002.
I will take care of the re-spin and update the wiki.
Thanks,
Chr
---
diff --git a/drivers/net/wireless/ath/ar9170/usb.c b/drivers/net/wireless/ath/ar9170/usb.c
index e0138ac..68b0bda 100644
--- a/drivers/net/wireless/ath/ar9170/usb.c
+++ b/drivers/net/wireless/ath/ar9170/usb.c
@@ -64,6 +64,8 @@ static struct usb_device_id ar9170_usb_ids[] = {
{ USB_DEVICE(0x0cf3, 0x9170) },
/* Atheros TG121N */
{ USB_DEVICE(0x0cf3, 0x1001) },
+ /* Atheros - Unknown Product Name - */
+ { USB_DEVICE(0x0cf3, 0x1002) },
/* Cace Airpcap NX */
{ USB_DEVICE(0xcace, 0x0300) },
/* D-Link DWA 160A */
^ permalink raw reply related
* Re: [PATCH] b43: Add LP PHY Analog Switch Support
From: Michael Buesch @ 2009-09-14 21:07 UTC (permalink / raw)
To: bcm43xx-dev; +Cc: Thomas Ilnseher, John Linville, linux-wireless
In-Reply-To: <1252962093.4696.45.camel@luzifer.localnet>
On Monday 14 September 2009 23:01:33 Thomas Ilnseher wrote:
> The current verison of b43 uses "b43_phyop_switch_analog_generic" for A,
> G and LP phys.
>
> According to the spec, this is the wrong behaviour for the LP PHY
> (see: http://bcm-v4.sipsolutions.net/802.11/PHY/Anacore )
>
> While no problems on the x86 plattform where seen, this leads to a crash
> on the BCM5354 SoC (MIPS 32 LE plattform).
> This patch implements the analog switch for LP PHYs according to the
> specs. It fixes the crash
>
> signed-off-by: Thomas Ilnseher <illth@gmx.de>
> ---
> diff -uNr b/drivers/net/wireless/b43/phy_lp.c
> a/drivers/net/wireless/b43/phy_lp.c
> --- b/drivers/net/wireless/b43/phy_lp.c 2009-09-14 06:14:18.000000000 +0200
> +++ a/drivers/net/wireless/b43/phy_lp.c 2009-09-14 21:03:15.158507573 +0200
> @@ -2228,6 +2228,16 @@
> return B43_TXPWR_RES_DONE;
> }
>
> +void b43_lpphy_op_switch_analog(struct b43_wldev *dev, bool on)
> +{
> + if (on) {
> + b43_phy_mask(dev, B43_LPPHY_AFE_CTL_OVR, 0xfff8);
> + } else {
> + b43_phy_set(dev, B43_LPPHY_AFE_CTL_OVRVAL, 0x0007);
> + b43_phy_set(dev, B43_LPPHY_AFE_CTL_OVR, 0x0007);
> + }
> +}
> +
> const struct b43_phy_operations b43_phyops_lp = {
> .allocate = b43_lpphy_op_allocate,
> .free = b43_lpphy_op_free,
> @@ -2239,7 +2249,7 @@
> .radio_read = b43_lpphy_op_radio_read,
> .radio_write = b43_lpphy_op_radio_write,
> .software_rfkill = b43_lpphy_op_software_rfkill,
> - .switch_analog = b43_phyop_switch_analog_generic,
> + .switch_analog = b43_lpphy_op_switch_analog,
> .switch_channel = b43_lpphy_op_switch_channel,
> .get_default_chan = b43_lpphy_op_get_default_chan,
> .set_rx_antenna = b43_lpphy_op_set_rx_antenna,
>
ack
--
Greetings, Michael.
^ permalink raw reply
* [PATCH] b43: Add LP PHY Analog Switch Support
From: Thomas Ilnseher @ 2009-09-14 21:01 UTC (permalink / raw)
To: John Linville; +Cc: Broadcom Wireless, linux-wireless
The current verison of b43 uses "b43_phyop_switch_analog_generic" for A,
G and LP phys.
According to the spec, this is the wrong behaviour for the LP PHY
(see: http://bcm-v4.sipsolutions.net/802.11/PHY/Anacore )
While no problems on the x86 plattform where seen, this leads to a crash
on the BCM5354 SoC (MIPS 32 LE plattform).
This patch implements the analog switch for LP PHYs according to the
specs. It fixes the crash
signed-off-by: Thomas Ilnseher <illth@gmx.de>
---
diff -uNr b/drivers/net/wireless/b43/phy_lp.c
a/drivers/net/wireless/b43/phy_lp.c
--- b/drivers/net/wireless/b43/phy_lp.c 2009-09-14 06:14:18.000000000 +0200
+++ a/drivers/net/wireless/b43/phy_lp.c 2009-09-14 21:03:15.158507573 +0200
@@ -2228,6 +2228,16 @@
return B43_TXPWR_RES_DONE;
}
+void b43_lpphy_op_switch_analog(struct b43_wldev *dev, bool on)
+{
+ if (on) {
+ b43_phy_mask(dev, B43_LPPHY_AFE_CTL_OVR, 0xfff8);
+ } else {
+ b43_phy_set(dev, B43_LPPHY_AFE_CTL_OVRVAL, 0x0007);
+ b43_phy_set(dev, B43_LPPHY_AFE_CTL_OVR, 0x0007);
+ }
+}
+
const struct b43_phy_operations b43_phyops_lp = {
.allocate = b43_lpphy_op_allocate,
.free = b43_lpphy_op_free,
@@ -2239,7 +2249,7 @@
.radio_read = b43_lpphy_op_radio_read,
.radio_write = b43_lpphy_op_radio_write,
.software_rfkill = b43_lpphy_op_software_rfkill,
- .switch_analog = b43_phyop_switch_analog_generic,
+ .switch_analog = b43_lpphy_op_switch_analog,
.switch_channel = b43_lpphy_op_switch_channel,
.get_default_chan = b43_lpphy_op_get_default_chan,
.set_rx_antenna = b43_lpphy_op_set_rx_antenna,
^ permalink raw reply
* Re: Kernel oops with 2.6.31-wl
From: Michael Buesch @ 2009-09-14 20:55 UTC (permalink / raw)
To: Larry Finger; +Cc: Johannes Berg, wireless
In-Reply-To: <4AAEAC90.7070205@lwfinger.net>
On Monday 14 September 2009 22:50:24 Larry Finger wrote:
> Michael Buesch wrote:
> > On Monday 14 September 2009 20:20:21 Larry Finger wrote:
> >> Johannes Berg wrote:
> >>> On Mon, 2009-09-14 at 09:05 -0500, Larry Finger wrote:
> >>>> Using the kernel v2.6.31-38241-g2d3a51e, I get the following kernel
> >>>> oops when unloading b43:
> >>>> RIP: 0010:[<ffffffffa02a3a3e>] [<ffffffffa02a3a3e>]
> >>>> b43_op_config+0x10c/0x36f [b43]
> >>> Seems like a b43 problem to me.
> >> I had pretty much reached that conclusion. I will need to swap cards
> >> to debug as the 4315 won't run on older kernels without a lot of patches.
> >
> > I can't reproduce here. What sequence of events is needed to trigger this?
>
> All I have to do is make a connection, then "sudo modprobe -rv b43"
> while the connection is live. I have not tried shutting the interface
> down before the modprobe. It gets through the "rmmod b43" and the
> "rmmod ssb" and then crashes.
Ok, works. Thanks.
I'll send a patch soon.
--
Greetings, Michael.
^ permalink raw reply
* Re: RTL8187B wireless driver issue
From: Hin-Tak Leung @ 2009-09-14 20:51 UTC (permalink / raw)
To: Vignette consultant; +Cc: Larry Finger, wireless
In-Reply-To: <3b0e19890909141056l4a01b8f9w9887af5d6219c3ff@mail.gmail.com>
On Mon, Sep 14, 2009 at 6:56 PM, Vignette consultant
<vignette75@gmail.com> wrote:
> Larry,
>
> I got the same error even after adding wlan0 in
> /etc/network/interfaces file. I set the essid using "sudo iwconfig
> wlan0 essid linksys" command and restarted network. I tried other
> essids, but it gives same error.
>
> Attached files contain log files. Please advise about solution.
>
> How do I disable usb monitoring log, so I can see wlan0 interface log
> from dmesg?
>
> Thanks
> Sam
>
> On 9/14/09, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> Vignette consultant wrote:
>>> Hi
>>>
>>> Attached files contain several logs of various commands. The log-1
>>> file is before running command and log-2 file is after running
>>> specific command.
>>>
>>> Here are commands that I give as soon as I log in. It's server edition.
>>>
>>> $ sudo ifconfig wlan0 up
>>> $ sudo iwconfig wlan0 ESSID linksys
>>> $ sudo dhclient wlan0 - results in no IP addr leased
>>
>> Your wireless has not associated and has no communication, which is
>> why it cannot get an IP using DHCP.
>>
>> A quick check with Google indicates that Ubuntu uses
>> /etc/network/interfaces to control the devices. Once that is correct,
>> you should be able to 'sudo /etc/init.d/networking restart' to start
>> the network. If the server is properly configured, the network should
>> start on boot.
>>
>> BTW, the dmesg buffer is circular. All that usb monitoring output has
>> completely filled the buffer, and it contains no useful information.
>>
>
scanning works, so there doesn't seem to be anything wrong with the
device or the driver itself. However, even for static configuration,
sometimes wpa_supplicant can still be involved and interfere, so you
probably want to make sure you put all the relevant config in
wpa_supplicant.conf , as well as manually; or make sure no other
network tools are running. (udev can launch wpa_supplicant/dhcp on
ifconfig up automatically - the 'not ready' messages are from udev
hooks). Lastly, I think the Ubuntu/Debian family packages
compat-wireless as 'kernel-modules-backport' or something; try that or
even compat-wireless. ( a while back there was a bug with
associattion).
^ permalink raw reply
* Re: Kernel oops with 2.6.31-wl
From: Larry Finger @ 2009-09-14 20:50 UTC (permalink / raw)
To: Michael Buesch; +Cc: Johannes Berg, wireless
In-Reply-To: <200909142245.52042.mb@bu3sch.de>
Michael Buesch wrote:
> On Monday 14 September 2009 20:20:21 Larry Finger wrote:
>> Johannes Berg wrote:
>>> On Mon, 2009-09-14 at 09:05 -0500, Larry Finger wrote:
>>>> Using the kernel v2.6.31-38241-g2d3a51e, I get the following kernel
>>>> oops when unloading b43:
>>>> RIP: 0010:[<ffffffffa02a3a3e>] [<ffffffffa02a3a3e>]
>>>> b43_op_config+0x10c/0x36f [b43]
>>> Seems like a b43 problem to me.
>> I had pretty much reached that conclusion. I will need to swap cards
>> to debug as the 4315 won't run on older kernels without a lot of patches.
>
> I can't reproduce here. What sequence of events is needed to trigger this?
All I have to do is make a connection, then "sudo modprobe -rv b43"
while the connection is live. I have not tried shutting the interface
down before the modprobe. It gets through the "rmmod b43" and the
"rmmod ssb" and then crashes.
Larry
^ permalink raw reply
* Re: [PATCH3]Add analog switch support
From: Michael Buesch @ 2009-09-14 20:47 UTC (permalink / raw)
To: bcm43xx-dev; +Cc: Thomas Ilnseher, John Linville, linux-wireless
In-Reply-To: <1252959777.4696.29.camel@luzifer.localnet>
On Monday 14 September 2009 22:22:57 Thomas Ilnseher wrote:
> I can now confirm that the patch below DOES compile, and even works.
So can you send a version which conforms to our patch submission standards as larry explained?
--
Greetings, Michael.
^ permalink raw reply
* Re: Kernel oops with 2.6.31-wl
From: Michael Buesch @ 2009-09-14 20:45 UTC (permalink / raw)
To: Larry Finger; +Cc: Johannes Berg, wireless
In-Reply-To: <4AAE8965.4040108@lwfinger.net>
On Monday 14 September 2009 20:20:21 Larry Finger wrote:
> Johannes Berg wrote:
> > On Mon, 2009-09-14 at 09:05 -0500, Larry Finger wrote:
> >> Using the kernel v2.6.31-38241-g2d3a51e, I get the following kernel
> >> oops when unloading b43:
> >
> >> RIP: 0010:[<ffffffffa02a3a3e>] [<ffffffffa02a3a3e>]
> >> b43_op_config+0x10c/0x36f [b43]
> >
> > Seems like a b43 problem to me.
>
> I had pretty much reached that conclusion. I will need to swap cards
> to debug as the 4315 won't run on older kernels without a lot of patches.
I can't reproduce here. What sequence of events is needed to trigger this?
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH3]Add analog switch support
From: Thomas Ilnseher @ 2009-09-14 20:22 UTC (permalink / raw)
To: John Linville; +Cc: Broadcom Wireless, linux-wireless
In-Reply-To: <1252958183.4696.25.camel@luzifer.localnet>
I can now confirm that the patch below DOES compile, and even works.
Here is the dmesg output on my router:
root@OpenWrt:/tmp# dmesg
b43-phy1: Broadcom 5354 WLAN found (core revision 13)
b43-phy1 debug: Found PHY: Analog 6, Type 5, Revision 0
b43-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2062, Revision 1
phy1: Selected rate control algorithm 'minstrel'
Broadcom 43xx driver loaded [ Features: PL, Firmware-ID: FW13 ]
b43 ssb0:3: firmware: requesting b43/ucode13.fw
b43 ssb0:3: firmware: requesting b43/lp0initvals13.fw
b43 ssb0:3: firmware: requesting b43/lp0bsinitvals13.fw
b43-phy1: Loading firmware version 410.2160 (2007-05-26 15:32:10)
b43-phy1 debug: b2062: Using crystal tab entry 19200 kHz.
b43-phy1 debug: Chip initialized
b43-phy1 debug: 64-bit DMA initialized
Registered led device: b43-phy1::tx
Registered led device: b43-phy1::rx
b43-phy1 debug: Wireless interface started
b43-phy1 debug: Adding Interface type 2
wlan0: direct probe to AP XXXXXXXX (try 1)
wlan0 direct probe responded
wlan0: authenticate with AP XXXXXXXX (try 1)
wlan0: authenticated
wlan0: associate with AP XXXXXXXX (try 1)
wlan0: RX AssocResp from XXXXXXXX (capab=0x431 status=0 aid=1)
wlan0: associated
b43-phy1 debug: Using hardware based encryption for keyidx: 0, mac: XXXXXXXX
root@OpenWrt:/tmp# iwconfig 2> /dev/null
wlan0 IEEE 802.11bg ESSID:"tommy"
Mode:Managed Frequency:2.412 GHz Access Point: XX:XX:XX:XX:XX:XX
Bit Rate=11 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=70/70 Signal level=3 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
On Mo, 2009-09-14 at 21:56 +0200, Thomas Ilnseher wrote:
> On Mo, 2009-09-14 at 21:43 +0200, Gábor Stefanik wrote:
> > Always send patches to John Linville, and CC linux-wireless.
> Ok, the last try ...
>
> As I've seen Gàbor's patch, I noticed that my previous patch was
> bullshit. This patch should work:
>
> (see: http://bcm-v4.sipsolutions.net/802.11/PHY/Anacore)
>
> Signed-off-by: Thomas Ilnseher <illth@gmx.de>
>
> diff -uNr b/drivers/net/wireless/b43/phy_lp.c
> a/drivers/net/wireless/b43/phy_lp.c
> --- b/drivers/net/wireless/b43/phy_lp.c 2009-09-14 06:14:18.000000000
> +0200
> +++ a/drivers/net/wireless/b43/phy_lp.c 2009-09-14 21:03:15.158507573
> +0200
> @@ -2228,6 +2228,16 @@
> return B43_TXPWR_RES_DONE;
> }
>
> +void b43_lpphy_op_switch_analog(struct b43_wldev *dev, bool on)
> +{
> + if (on) {
> + b43_phy_mask(dev, B43_LPPHY_AFE_CTL_OVR, 0xfff8);
> + } else {
> + b43_phy_set(dev, B43_LPPHY_AFE_CTL_OVRVAL, 0x0007);
> + b43_phy_set(dev, B43_LPPHY_AFE_CTL_OVR, 0x0007);
> + }
> +}
> +
> const struct b43_phy_operations b43_phyops_lp = {
> .allocate = b43_lpphy_op_allocate,
> .free = b43_lpphy_op_free,
> @@ -2239,7 +2249,7 @@
> .radio_read = b43_lpphy_op_radio_read,
> .radio_write = b43_lpphy_op_radio_write,
> .software_rfkill = b43_lpphy_op_software_rfkill,
> - .switch_analog = b43_phyop_switch_analog_generic,
> + .switch_analog = b43_lpphy_op_switch_analog,
> .switch_channel = b43_lpphy_op_switch_channel,
> .get_default_chan = b43_lpphy_op_get_default_chan,
> .set_rx_antenna = b43_lpphy_op_set_rx_antenna,
>
>
>
^ permalink raw reply
* Re: [PATCH3]Add analog switch support
From: Larry Finger @ 2009-09-14 20:18 UTC (permalink / raw)
To: Thomas Ilnseher; +Cc: John Linville, Broadcom Wireless, linux-wireless
In-Reply-To: <1252958183.4696.25.camel@luzifer.localnet>
Thomas Ilnseher wrote:
> On Mo, 2009-09-14 at 21:43 +0200, Gábor Stefanik wrote:
>> Always send patches to John Linville, and CC linux-wireless.
> Ok, the last try ...
>
> As I've seen Gàbor's patch, I noticed that my previous patch was
> bullshit. This patch should work:
>
> (see: http://bcm-v4.sipsolutions.net/802.11/PHY/Anacore)
>
> Signed-off-by: Thomas Ilnseher <illth@gmx.de>
>
A few points about patch formatting.
The subject of the submittal message should be of the form "[PATCH]
component: Description". For this one, something like "[PATCH] b43:
Add LP PHY analog switch support" would be appropriate. If multiple
versions are needed, indicate that a previous one is superceded by
[PATCH V2] ..., etc.
There should be a line containing --- after the last signed-off-by line.
Anything between the beginning of the e-mail and the --- line becomes
part of the permanent record if the patch is accepted. Usually quoted
material and words like bullshit are avoided. Not always, but usually.
Between the --- line and the start of the patch, you can place
instructions to Linville regarding the circumstances of the patch and
its priority. Such directions are useful to distinguish an improvement
that should wait for the next merge period from a bug fix that should
be sent upstream ASAP. In this case, the patch fixes a system crash on
some platforms and should be applied now.
Larry
^ permalink raw reply
* Re: [PATCH3]Add analog switch support
From: Thomas Ilnseher @ 2009-09-14 19:56 UTC (permalink / raw)
To: John Linville; +Cc: Broadcom Wireless, linux-wireless
In-Reply-To: <69e28c910909141243i5551c87bsfd0c9e767cfa254@mail.gmail.com>
On Mo, 2009-09-14 at 21:43 +0200, Gábor Stefanik wrote:
> Always send patches to John Linville, and CC linux-wireless.
Ok, the last try ...
As I've seen Gàbor's patch, I noticed that my previous patch was
bullshit. This patch should work:
(see: http://bcm-v4.sipsolutions.net/802.11/PHY/Anacore)
Signed-off-by: Thomas Ilnseher <illth@gmx.de>
diff -uNr b/drivers/net/wireless/b43/phy_lp.c
a/drivers/net/wireless/b43/phy_lp.c
--- b/drivers/net/wireless/b43/phy_lp.c 2009-09-14 06:14:18.000000000
+0200
+++ a/drivers/net/wireless/b43/phy_lp.c 2009-09-14 21:03:15.158507573
+0200
@@ -2228,6 +2228,16 @@
return B43_TXPWR_RES_DONE;
}
+void b43_lpphy_op_switch_analog(struct b43_wldev *dev, bool on)
+{
+ if (on) {
+ b43_phy_mask(dev, B43_LPPHY_AFE_CTL_OVR, 0xfff8);
+ } else {
+ b43_phy_set(dev, B43_LPPHY_AFE_CTL_OVRVAL, 0x0007);
+ b43_phy_set(dev, B43_LPPHY_AFE_CTL_OVR, 0x0007);
+ }
+}
+
const struct b43_phy_operations b43_phyops_lp = {
.allocate = b43_lpphy_op_allocate,
.free = b43_lpphy_op_free,
@@ -2239,7 +2249,7 @@
.radio_read = b43_lpphy_op_radio_read,
.radio_write = b43_lpphy_op_radio_write,
.software_rfkill = b43_lpphy_op_software_rfkill,
- .switch_analog = b43_phyop_switch_analog_generic,
+ .switch_analog = b43_lpphy_op_switch_analog,
.switch_channel = b43_lpphy_op_switch_channel,
.get_default_chan = b43_lpphy_op_get_default_chan,
.set_rx_antenna = b43_lpphy_op_set_rx_antenna,
^ permalink raw reply
* Re: [PATCH RFC 2/3] sdio: pass unknown cis tuples to sdio drivers
From: Pierre Ossman @ 2009-09-14 19:52 UTC (permalink / raw)
To: Michael Buesch; +Cc: Albert Herranz, bcm43xx-dev, linux-mmc, linux-wireless
In-Reply-To: <200909072056.00673.mb@bu3sch.de>
[-- Attachment #1: Type: text/plain, Size: 518 bytes --]
On Mon, 7 Sep 2009 20:55:58 +0200
Michael Buesch <mb@bu3sch.de> wrote:
> On Monday 07 September 2009 20:47:12 Albert Herranz wrote:
> >
> >
>
> Please also submit to the SDIO maintainer.
>
There isn't one anymore, so submitting to this list is the correct
method.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH3]Add analog switch support
From: Gábor Stefanik @ 2009-09-14 19:43 UTC (permalink / raw)
To: Thomas Ilnseher, John Linville; +Cc: Broadcom Wireless, linux-wireless
In-Reply-To: <1252956934.4696.23.camel@luzifer.localnet>
Always send patches to John Linville, and CC linux-wireless.
On Mon, Sep 14, 2009 at 9:35 PM, Thomas Ilnseher <illth@gmx.de> wrote:
> As I've seen Gàbor's patch, I noticed that my previous patch was
> bullshit. This patch should work:
>
> Signed-off-by: Thomas Ilnseher <illth@gmx.de>
>
> diff -uNr b/drivers/net/wireless/b43/phy_lp.c a/drivers/net/wireless/b43/phy_lp.c
> --- b/drivers/net/wireless/b43/phy_lp.c 2009-09-14 06:14:18.000000000 +0200
> +++ a/drivers/net/wireless/b43/phy_lp.c 2009-09-14 21:03:15.158507573 +0200
> @@ -2228,6 +2228,16 @@
> return B43_TXPWR_RES_DONE;
> }
>
> +void b43_lpphy_op_switch_analog(struct b43_wldev *dev, bool on)
> +{
> + if (on) {
> + b43_phy_mask(dev, B43_LPPHY_AFE_CTL_OVR, 0xfff8);
> + } else {
> + b43_phy_set(dev, B43_LPPHY_AFE_CTL_OVRVAL, 0x0007);
> + b43_phy_set(dev, B43_LPPHY_AFE_CTL_OVR, 0x0007);
> + }
> +}
> +
> const struct b43_phy_operations b43_phyops_lp = {
> .allocate = b43_lpphy_op_allocate,
> .free = b43_lpphy_op_free,
> @@ -2239,7 +2249,7 @@
> .radio_read = b43_lpphy_op_radio_read,
> .radio_write = b43_lpphy_op_radio_write,
> .software_rfkill = b43_lpphy_op_software_rfkill,
> - .switch_analog = b43_phyop_switch_analog_generic,
> + .switch_analog = b43_lpphy_op_switch_analog,
> .switch_channel = b43_lpphy_op_switch_channel,
> .get_default_chan = b43_lpphy_op_get_default_chan,
> .set_rx_antenna = b43_lpphy_op_set_rx_antenna,
>
>
> _______________________________________________
> Bcm43xx-dev mailing list
> Bcm43xx-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH] b43: LP-PHY: Fix analog core switching
From: Michael Buesch @ 2009-09-14 19:40 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Larry Finger, Broadcom Wireless, linux-wireless
In-Reply-To: <4AAE950C.2050704@gmail.com>
On Monday 14 September 2009 21:10:04 Gábor Stefanik wrote:
> The generic analog switch routine is not correct for LP-PHY according
> to the latest specs. Implement the proper analog core switch routine.
>
> Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
> ---
> diff --git a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
> index 80da9c7..b0e127a 100644
> --- a/drivers/net/wireless/b43/phy_lp.c
> +++ b/drivers/net/wireless/b43/phy_lp.c
> @@ -2160,6 +2160,16 @@ static int lpphy_b2063_tune(struct b43_w
> return 0;
> }
>
> +static void b43_lpphy_op_switch_analog(struct b43_wldev *dev, bool on)
> +{
> + if (on) {
> + b43_phy_set(dev, B43_LPPHY_AFE_CTL_OVRVAL, 0x7);
> + b43_phy_set(dev, B43_LPPHY_AFE_CTL_OVR, 0x7);
> + } else {
> + b43_phy_mask(dev, B43_LPPHY_AFE_CTL_OVR, 0xFFF8);
> + }
> +}
You have the if branches swapped. (Don't add a ! in front of the on. Swap the branches).
--
Greetings, Michael.
^ 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