* Re: Abour linux driver supports BCM4325
From: Holger Schurig @ 2009-08-24 8:06 UTC (permalink / raw)
To: Johannes Berg; +Cc: Larry Finger, feng tian, linux-wireless
In-Reply-To: <1251018830.23605.32.camel@johannes.local>
> 1) changing b43 so it knows how to talk not just to
> SSB/PCI/PCMCIA chips but also SDIO chips
Feng, for this you could use another b43 card with SDIO, which
doesn't use the LP-PHY, but the older phy. If you find such a
device, you'll be start to code this now. As the SDIO-via-SSB
code is identical to b43-with-LP-PHY and b43-without-LP-PHY, can
you transfer all of this.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: feng tian @ 2009-08-24 6:03 UTC (permalink / raw)
To: Michael Buesch; +Cc: Johannes Berg, Larry Finger, linux-wireless
In-Reply-To: <f42a38140908230830r45ef1d01l5a9c5a4d0197e81e@mail.gmail.com>
>>> 1) changing b43 so it knows how to talk not just to SSB/PCI/PCMCIA
>>> chips but also SDIO chips
>>
>> We already have working support for that and we're currently merging it mainline.
>> If you want to help, please test the spinlock removal patchset I just posted.
>>> 2) changing b43 so it knows how to talk to your specific radio/PHY
>>> chip, and LP PHY
Where can I get theses codes which supports b43 talking to SDIO chips?
Thanks very much.
BR, Feng
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Larry Finger @ 2009-08-24 1:46 UTC (permalink / raw)
To: Herton Ronaldo Krzesinski; +Cc: linux-wireless, Hin-Tak Leung
In-Reply-To: <200908220038.35564.herton@mandriva.com.br>
Herton Ronaldo Krzesinski wrote:
> This change implements rfkill support for RTL8187B and RTL8187L devices,
> using new cfg80211 rfkill API.
>
> Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
> ---
I found a problem with this patch. When I issue an 'rfkill block 1'
command, I get the following circular locking warning:
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.31-rc6-wl #201
-------------------------------------------------------
rfkill/30578 is trying to acquire lock:
(&(&priv->work)->work#2){+.+...}, at: [<ffffffff81051215>]
__cancel_work_timer+0xd9/0x222
but task is already holding lock:
(&priv->conf_mutex#2){+.+.+.}, at: [<ffffffffa064a024>]
rtl8187_stop+0x31/0x364 [rtl8187]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&priv->conf_mutex#2){+.+.+.}:
[<ffffffff81065957>] __lock_acquire+0x12d0/0x1614
[<ffffffff81065d54>] lock_acquire+0xb9/0xdd
[<ffffffff8127c32f>] mutex_lock_nested+0x56/0x2a8
[<ffffffffa064a392>] rtl8187_work+0x3b/0xf2 [rtl8187]
[<ffffffff81050758>] worker_thread+0x1fa/0x30a
[<ffffffff81054ca5>] kthread+0x8f/0x97
[<ffffffff8100cb7a>] child_rip+0xa/0x20
[<ffffffffffffffff>] 0xffffffffffffffff
-> #0 (&(&priv->work)->work#2){+.+...}:
[<ffffffff8106568c>] __lock_acquire+0x1005/0x1614
[<ffffffff81065d54>] lock_acquire+0xb9/0xdd
[<ffffffff8105124e>] __cancel_work_timer+0x112/0x222
[<ffffffff8105136b>] cancel_delayed_work_sync+0xd/0xf
[<ffffffffa064a33f>] rtl8187_stop+0x34c/0x364 [rtl8187]
[<ffffffffa0242866>] ieee80211_stop_device+0x29/0x61 [mac80211]
[<ffffffffa0239194>] ieee80211_stop+0x476/0x530 [mac80211]
[<ffffffff8120ce15>] dev_close+0x8a/0xac
[<ffffffffa01d9fa7>] cfg80211_rfkill_set_block+0x4a/0x7a [cfg80211]
[<ffffffffa01bf4f0>] rfkill_set_block+0x84/0xd9 [rfkill]
[<ffffffffa01bfc31>] rfkill_fop_write+0xda/0x124 [rfkill]
[<ffffffff810cf286>] vfs_write+0xae/0x14a
[<ffffffff810cf3e6>] sys_write+0x47/0x6e
[<ffffffff8100ba6b>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
other info that might help us debug this:
4 locks held by rfkill/30578:
#0: (rfkill_global_mutex){+.+.+.}, at: [<ffffffffa01bfbbc>]
rfkill_fop_write+0x65/0x124 [rfkill]
#1: (rtnl_mutex){+.+.+.}, at: [<ffffffff81215a60>] rtnl_lock+0x12/0x14
#2: (&rdev->devlist_mtx){+.+.+.}, at: [<ffffffffa01d9f89>]
cfg80211_rfkill_set_block+0x2c/0x7a [cfg80211]
#3: (&priv->conf_mutex#2){+.+.+.}, at: [<ffffffffa064a024>]
rtl8187_stop+0x31/0x364 [rtl8187]
stack backtrace:
Pid: 30578, comm: rfkill Not tainted 2.6.31-rc6-wl #201
Call Trace:
[<ffffffff810641ec>] print_circular_bug_tail+0xc1/0xcc
[<ffffffff8106568c>] __lock_acquire+0x1005/0x1614
[<ffffffff81065d54>] lock_acquire+0xb9/0xdd
[<ffffffff81051215>] ? __cancel_work_timer+0xd9/0x222
[<ffffffff8105124e>] __cancel_work_timer+0x112/0x222
[<ffffffff81051215>] ? __cancel_work_timer+0xd9/0x222
[<ffffffff81063791>] ? mark_held_locks+0x4d/0x6b
[<ffffffff8127db94>] ? _spin_unlock_irq+0x2b/0x30
[<ffffffff81063a04>] ? trace_hardirqs_on_caller+0x10b/0x12f
[<ffffffff81063a35>] ? trace_hardirqs_on+0xd/0xf
[<ffffffff8127db94>] ? _spin_unlock_irq+0x2b/0x30
[<ffffffffa00de2c4>] ? usb_kill_anchored_urbs+0x46/0x5c [usbcore]
[<ffffffff8105136b>] cancel_delayed_work_sync+0xd/0xf
[<ffffffffa064a33f>] rtl8187_stop+0x34c/0x364 [rtl8187]
[<ffffffffa0242866>] ieee80211_stop_device+0x29/0x61 [mac80211]
[<ffffffffa0239194>] ieee80211_stop+0x476/0x530 [mac80211]
[<ffffffffa0238d68>] ? ieee80211_stop+0x4a/0x530 [mac80211]
[<ffffffff81044a28>] ? local_bh_enable_ip+0xc8/0xcd
[<ffffffff8127db65>] ? _spin_unlock_bh+0x2f/0x33
[<ffffffff8121d116>] ? dev_deactivate+0x162/0x192
[<ffffffff8120ce15>] dev_close+0x8a/0xac
[<ffffffffa01d9fa7>] cfg80211_rfkill_set_block+0x4a/0x7a [cfg80211]
[<ffffffffa01bf4f0>] rfkill_set_block+0x84/0xd9 [rfkill]
[<ffffffffa01bfc31>] rfkill_fop_write+0xda/0x124 [rfkill]
[<ffffffff8100ba9c>] ? sysret_check+0x27/0x62
[<ffffffff810cf286>] vfs_write+0xae/0x14a
[<ffffffff810cf3e6>] sys_write+0x47/0x6e
[<ffffffff8100ba6b>] system_call_fastpath+0x16/0x1bf
Larry
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Hin-Tak Leung @ 2009-08-23 19:38 UTC (permalink / raw)
To: Herton Ronaldo Krzesinski; +Cc: linux-wireless, Larry Finger
In-Reply-To: <3ace41890908221459j70e31c20ufa5ea03973a16e0a@mail.gmail.com>
On Sat, Aug 22, 2009 at 10:59 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote:
> On Sat, Aug 22, 2009 at 4:38 AM, Herton Ronaldo
> Krzesinski<herton@mandriva.com.br> wrote:
>> This change implements rfkill support for RTL8187B and RTL8187L devices,
>> using new cfg80211 rfkill API.
>>
>> Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
>
> Tested-by: Hin-Tak Leung <htl10@users.sourceforge.net>
>
> Neat!
>
> I ran a ping to the router while flicking the switch on and off, and
> have 'ping: sendmsg: Network is unreachable' in the middle. dmesg also
> shows
It appears that I wrote prematurely - flicking the switch with the
patch seems to just do the equivalent of ifconfig down.
(before the patch, the switch has no effect). However, NetworkManager
soon notices the interface going down and ifup it again. So I have
simply got a 30s to 1 minute disruption in connectivity.
Is this intentional? I thought it is supposed to actually switch off
the hardware, or is this how the code supposed to work?
Maybe some component needs to let NM knows not to reenanble the device.
Hin-Tak
^ permalink raw reply
* [PATCH] libertas: add NULL check on return value of get_zeroed_page
From: Kiran Divekar @ 2009-08-23 16:52 UTC (permalink / raw)
To: libertas-dev; +Cc: linux-wireless
>From fb132b536facfbdc47a24afe538c50662d16b3ad Mon Sep 17 00:00:00 2001
From: Kiran Divekar <kirandivekar@gmail.com>
Date: Sun, 23 Aug 2009 22:05:21 +0530
Subject: [PATCH] add NULL check on return value of get_zeroed_page
Most of the places in debugfs.c are missing a NULL check on the return value of
get_zeroed_page API call. Added required NULL check at appropriate places.
Signed-off-by: Kiran Divekar <kirandivekar@gmail.com>
---
drivers/net/wireless/libertas/debugfs.c | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/libertas/debugfs.c
b/drivers/net/wireless/libertas/debugfs.c
index 811ffc3..893a55c 100644
--- a/drivers/net/wireless/libertas/debugfs.c
+++ b/drivers/net/wireless/libertas/debugfs.c
@@ -45,6 +45,8 @@ static ssize_t lbs_dev_info(struct file *file, char
__user *userbuf,
unsigned long addr = get_zeroed_page(GFP_KERNEL);
char *buf = (char *)addr;
ssize_t res;
+ if (!buf)
+ return -ENOMEM;
pos += snprintf(buf+pos, len-pos, "state = %s\n",
szStates[priv->connect_status]);
@@ -68,6 +70,8 @@ static ssize_t lbs_getscantable(struct file *file,
char __user *userbuf,
char *buf = (char *)addr;
DECLARE_SSID_BUF(ssid);
struct bss_descriptor * iter_bss;
+ if (!buf)
+ return -ENOMEM;
pos += snprintf(buf+pos, len-pos,
"# | ch | rssi | bssid | cap | Qual
| SSID \n");
@@ -110,6 +114,8 @@ static ssize_t lbs_sleepparams_write(struct file *file,
int p1, p2, p3, p4, p5, p6;
unsigned long addr = get_zeroed_page(GFP_KERNEL);
char *buf = (char *)addr;
+ if (!buf)
+ return -ENOMEM;
buf_size = min(count, len - 1);
if (copy_from_user(buf, user_buf, buf_size)) {
@@ -148,6 +154,8 @@ static ssize_t lbs_sleepparams_read(struct file
*file, char __user *userbuf,
struct sleep_params sp;
unsigned long addr = get_zeroed_page(GFP_KERNEL);
char *buf = (char *)addr;
+ if (!buf)
+ return -ENOMEM;
ret = lbs_cmd_802_11_sleep_params(priv, CMD_ACT_GET, &sp);
if (ret)
@@ -433,6 +441,8 @@ static ssize_t lbs_rdmac_read(struct file *file,
char __user *userbuf,
int ret;
unsigned long addr = get_zeroed_page(GFP_KERNEL);
char *buf = (char *)addr;
+ if (!buf)
+ return -ENOMEM;
offval.offset = priv->mac_offset;
offval.value = 0;
@@ -457,6 +467,8 @@ static ssize_t lbs_rdmac_write(struct file *file,
ssize_t res, buf_size;
unsigned long addr = get_zeroed_page(GFP_KERNEL);
char *buf = (char *)addr;
+ if (!buf)
+ return -ENOMEM;
buf_size = min(count, len - 1);
if (copy_from_user(buf, userbuf, buf_size)) {
@@ -481,6 +493,8 @@ static ssize_t lbs_wrmac_write(struct file *file,
struct lbs_offset_value offval;
unsigned long addr = get_zeroed_page(GFP_KERNEL);
char *buf = (char *)addr;
+ if (!buf)
+ return -ENOMEM;
buf_size = min(count, len - 1);
if (copy_from_user(buf, userbuf, buf_size)) {
@@ -515,6 +529,8 @@ static ssize_t lbs_rdbbp_read(struct file *file,
char __user *userbuf,
int ret;
unsigned long addr = get_zeroed_page(GFP_KERNEL);
char *buf = (char *)addr;
+ if (!buf)
+ return -ENOMEM;
offval.offset = priv->bbp_offset;
offval.value = 0;
@@ -540,6 +556,8 @@ static ssize_t lbs_rdbbp_write(struct file *file,
ssize_t res, buf_size;
unsigned long addr = get_zeroed_page(GFP_KERNEL);
char *buf = (char *)addr;
+ if (!buf)
+ return -ENOMEM;
buf_size = min(count, len - 1);
if (copy_from_user(buf, userbuf, buf_size)) {
@@ -564,6 +582,8 @@ static ssize_t lbs_wrbbp_write(struct file *file,
struct lbs_offset_value offval;
unsigned long addr = get_zeroed_page(GFP_KERNEL);
char *buf = (char *)addr;
+ if (!buf)
+ return -ENOMEM;
buf_size = min(count, len - 1);
if (copy_from_user(buf, userbuf, buf_size)) {
@@ -598,6 +618,8 @@ static ssize_t lbs_rdrf_read(struct file *file,
char __user *userbuf,
int ret;
unsigned long addr = get_zeroed_page(GFP_KERNEL);
char *buf = (char *)addr;
+ if (!buf)
+ return -ENOMEM;
offval.offset = priv->rf_offset;
offval.value = 0;
@@ -623,6 +645,8 @@ static ssize_t lbs_rdrf_write(struct file *file,
ssize_t res, buf_size;
unsigned long addr = get_zeroed_page(GFP_KERNEL);
char *buf = (char *)addr;
+ if (!buf)
+ return -ENOMEM;
buf_size = min(count, len - 1);
if (copy_from_user(buf, userbuf, buf_size)) {
@@ -647,6 +671,8 @@ static ssize_t lbs_wrrf_write(struct file *file,
struct lbs_offset_value offval;
unsigned long addr = get_zeroed_page(GFP_KERNEL);
char *buf = (char *)addr;
+ if (!buf)
+ return -ENOMEM;
buf_size = min(count, len - 1);
if (copy_from_user(buf, userbuf, buf_size)) {
@@ -853,6 +879,8 @@ static ssize_t lbs_debugfs_read(struct file *file,
char __user *userbuf,
struct debug_data *d;
unsigned long addr = get_zeroed_page(GFP_KERNEL);
char *buf = (char *)addr;
+ if (!buf)
+ return -ENOMEM;
p = buf;
--
1.5.3.4
-----
-Kiran Divekar.
http://www.geeksofpune.org/
http://www.geocities.com/kirandivekar/
^ permalink raw reply related
* Re: Abour linux driver supports BCM4325
From: feng tian @ 2009-08-23 15:30 UTC (permalink / raw)
To: Michael Buesch; +Cc: Johannes Berg, Larry Finger, linux-wireless
In-Reply-To: <200908231455.51140.mb@bu3sch.de>
>> You have two completely orthogonal problems:
>>
>> 1) changing b43 so it knows how to talk not just to SSB/PCI/PCMCIA
>> chips but also SDIO chips
>
> We already have working support for that and we're currently merging it mainline.
> If you want to help, please test the spinlock removal patchset I just posted.
>> 2) changing b43 so it knows how to talk to your specific radio/PHY
>> chip, and LP PHY
>
> Also almost working and in the progress of merging mainline.
>
> --
> Greetings, Michael.
>
Okay, I'll first look into it, and then do some tests.
Thanks.
BR, Feng
^ permalink raw reply
* Re: WARNING: at net/mac80211/mlme.c:2292
From: Fabio Comolli @ 2009-08-23 15:03 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <b637ec0b0908230740j284734f7t7ea0536c1fee406f@mail.gmail.com>
OK, some more info.
After the warning the system is usable but wireless doesn't work. The
hang happens when I activate the rfkill swich.
This happens even after a fresh boot. After activating the rfkill
switch the console fills with:
unregister_netdevice: waiting for device wlan0 to become free
with a line every 5 seconds or so. At this time the system is
completely unresponsive.
Regards,
Fabio
On Sun, Aug 23, 2009 at 4:40 PM, Fabio Comolli<fabio.comolli@gmail.com> wrote:
> Hi.
>
> On Sun, Aug 23, 2009 at 2:12 AM, Bob Copeland<me@bobcopeland.com> wrote:
>> On Sat, Aug 22, 2009 at 09:29:39PM +0200, Fabio Comolli wrote:
>>> Hi Bob.
>>> Unfortunately the patch doesn't apply at all with compat-wireless,
>>> there's no "flush_workqueue" before "local->suspended" there....
>>
>> Ah yes, it got moved into ieee80211_stop_device(). Can you put
>> local->suspended and the barrier() ahead of that?
>>
>
> Well, this crashed my system. Backtrace copied by hand:
>
> warning at net/wireless/core.c wdev_cleanup_work [cfg80211]
>
> warn_slowpat_common
> warn_slowpath_null
> wdev_cleanup_work [cfg80211]
> worker_thread
> wdev_cleanup_work [cfg80211]
> autoresolve_wake_function
> worker_thread
> kthread
> kthread
> kernel_thread_helper
>
>
>> Thanks!
>
> Regards,
> Fabio
>
>
>>
>> --
>> Bob Copeland %% www.bobcopeland.com
>>
>>
>
^ permalink raw reply
* Re: WARNING: at net/mac80211/mlme.c:2292
From: Fabio Comolli @ 2009-08-23 14:40 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <20090823001218.GE6762@hash.localnet>
Hi.
On Sun, Aug 23, 2009 at 2:12 AM, Bob Copeland<me@bobcopeland.com> wrote:
> On Sat, Aug 22, 2009 at 09:29:39PM +0200, Fabio Comolli wrote:
>> Hi Bob.
>> Unfortunately the patch doesn't apply at all with compat-wireless,
>> there's no "flush_workqueue" before "local->suspended" there....
>
> Ah yes, it got moved into ieee80211_stop_device(). Can you put
> local->suspended and the barrier() ahead of that?
>
Well, this crashed my system. Backtrace copied by hand:
warning at net/wireless/core.c wdev_cleanup_work [cfg80211]
warn_slowpat_common
warn_slowpath_null
wdev_cleanup_work [cfg80211]
worker_thread
wdev_cleanup_work [cfg80211]
autoresolve_wake_function
worker_thread
kthread
kthread
kernel_thread_helper
> Thanks!
Regards,
Fabio
>
> --
> Bob Copeland %% www.bobcopeland.com
>
>
^ permalink raw reply
* Re: Plans for an online meeting regarding Radiotap
From: Mike Kershaw @ 2009-08-23 14:27 UTC (permalink / raw)
To: G?bor Stefanik
Cc: Johannes Berg, Richard Farina, Sam Leffler, Rafael Laufer,
Damien Bergamini, Sepherosa Ziehau, Thomas d'Otreppe,
radiotap, linux-wireless, freebsd-mobile, misc-openbsd,
tech-openbsd, netbsd-net, wireshark-dev
In-Reply-To: <69e28c910908210804h6181aab1w4a864392239aa1ac@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 836 bytes --]
On Fri, Aug 21, 2009 at 05:04:20PM +0200, G?bor Stefanik wrote:
> > Besides,
> > you're supposed to make at least two implementations when proposing a
> > standard field.
>
> If I remember correctly, I made an implementation for the Linux kernel
> (a generator-side implementation) and one for Wireshark (a parser-side
> implementation). Or should I make two generator-side implementations
> according to the requirement (e.g. one for Linux, another for
> OpenBSD)?
Once there's a spec that's a little more stable I can add it to lorcon, so
that will give you 2 userspace implementations for tx (assuming aircrack
adopts it) with different authors.
-m
--
Mike Kershaw/Dragorn <dragorn@kismetwireless.net>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1
"A baby seal walks into a club..."
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: Gábor Stefanik @ 2009-08-23 13:33 UTC (permalink / raw)
To: Michael Buesch; +Cc: Johannes Berg, Larry Finger, feng tian, linux-wireless
In-Reply-To: <200908231530.04236.mb@bu3sch.de>
2009/8/23 Michael Buesch <mb@bu3sch.de>:
> On Sunday 23 August 2009 15:24:29 Gábor Stefanik wrote:
>> Not necessarily true in this case - an important 4325-specific routine
>> (SSB PMU recalibration) is still missing. (And I don't tink I'm
>> familiar enough with ssb to do that, unfortunately.)
>
> I can do that later. It's a fairly simple routine (to me knowing the code :).
>
> --
> Greetings, Michael.
>
Thanks!
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: Michael Buesch @ 2009-08-23 13:30 UTC (permalink / raw)
To: Gábor Stefanik
Cc: Johannes Berg, Larry Finger, feng tian, linux-wireless
In-Reply-To: <69e28c910908230624s1600a9d4k3918875551bfbf4d@mail.gmail.com>
On Sunday 23 August 2009 15:24:29 Gábor Stefanik wrote:
> On Sun, Aug 23, 2009 at 2:55 PM, Michael Buesch<mb@bu3sch.de> wrote:
> > On Sunday 23 August 2009 11:13:50 Johannes Berg wrote:
> >> On Sat, 2009-08-22 at 21:59 -0500, Larry Finger wrote:
> >> > feng tian wrote:
> >> > > Thank you for the information.
> >> > > I get your point. As for the radio and phy driver, I think it's some
> >> > > command based configurations for the chip via SDIO. And that I can
> >> > > refer to the BCM 43xx PCI driver codes.
> >> > > Wonder if it's feasible. Needs your comments.
> >> > > Thanks
> >> >
> >> > The first step is to be able to read/write the various registers via
> >> > SDIO. That will be similar to the PCI operations. The next step is
> >> > knowing what to read/write and when. We are still working that out for
> >> > PCI. It is not trivial. See the recent postings of patches for the LP
> >> > pHY in the linux-wireless mailing list. These are _NOT_ complete.
> >>
> >> Right.
> >>
> >> You have two completely orthogonal problems:
> >>
> >> 1) changing b43 so it knows how to talk not just to SSB/PCI/PCMCIA
> >> chips but also SDIO chips
> >
> > We already have working support for that and we're currently merging it mainline.
> > If you want to help, please test the spinlock removal patchset I just posted.
> >
> >> 2) changing b43 so it knows how to talk to your specific radio/PHY
> >> chip, and LP PHY
> >
> > Also almost working and in the progress of merging mainline.
>
> Not necessarily true in this case - an important 4325-specific routine
> (SSB PMU recalibration) is still missing. (And I don't tink I'm
> familiar enough with ssb to do that, unfortunately.)
I can do that later. It's a fairly simple routine (to me knowing the code :).
--
Greetings, Michael.
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: Gábor Stefanik @ 2009-08-23 13:24 UTC (permalink / raw)
To: Michael Buesch; +Cc: Johannes Berg, Larry Finger, feng tian, linux-wireless
In-Reply-To: <200908231455.51140.mb@bu3sch.de>
On Sun, Aug 23, 2009 at 2:55 PM, Michael Buesch<mb@bu3sch.de> wrote:
> On Sunday 23 August 2009 11:13:50 Johannes Berg wrote:
>> On Sat, 2009-08-22 at 21:59 -0500, Larry Finger wrote:
>> > feng tian wrote:
>> > > Thank you for the information.
>> > > I get your point. As for the radio and phy driver, I think it's some
>> > > command based configurations for the chip via SDIO. And that I can
>> > > refer to the BCM 43xx PCI driver codes.
>> > > Wonder if it's feasible. Needs your comments.
>> > > Thanks
>> >
>> > The first step is to be able to read/write the various registers via
>> > SDIO. That will be similar to the PCI operations. The next step is
>> > knowing what to read/write and when. We are still working that out for
>> > PCI. It is not trivial. See the recent postings of patches for the LP
>> > pHY in the linux-wireless mailing list. These are _NOT_ complete.
>>
>> Right.
>>
>> You have two completely orthogonal problems:
>>
>> 1) changing b43 so it knows how to talk not just to SSB/PCI/PCMCIA
>> chips but also SDIO chips
>
> We already have working support for that and we're currently merging it mainline.
> If you want to help, please test the spinlock removal patchset I just posted.
>
>> 2) changing b43 so it knows how to talk to your specific radio/PHY
>> chip, and LP PHY
>
> Also almost working and in the progress of merging mainline.
Not necessarily true in this case - an important 4325-specific routine
(SSB PMU recalibration) is still missing. (And I don't tink I'm
familiar enough with ssb to do that, unfortunately.)
>
> --
> Greetings, Michael.
> --
> 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: Abour linux driver supports BCM4325
From: Michael Buesch @ 2009-08-23 12:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: Larry Finger, feng tian, linux-wireless
In-Reply-To: <1251018830.23605.32.camel@johannes.local>
On Sunday 23 August 2009 11:13:50 Johannes Berg wrote:
> On Sat, 2009-08-22 at 21:59 -0500, Larry Finger wrote:
> > feng tian wrote:
> > > Thank you for the information.
> > > I get your point. As for the radio and phy driver, I think it's some
> > > command based configurations for the chip via SDIO. And that I can
> > > refer to the BCM 43xx PCI driver codes.
> > > Wonder if it's feasible. Needs your comments.
> > > Thanks
> >
> > The first step is to be able to read/write the various registers via
> > SDIO. That will be similar to the PCI operations. The next step is
> > knowing what to read/write and when. We are still working that out for
> > PCI. It is not trivial. See the recent postings of patches for the LP
> > pHY in the linux-wireless mailing list. These are _NOT_ complete.
>
> Right.
>
> You have two completely orthogonal problems:
>
> 1) changing b43 so it knows how to talk not just to SSB/PCI/PCMCIA
> chips but also SDIO chips
We already have working support for that and we're currently merging it mainline.
If you want to help, please test the spinlock removal patchset I just posted.
> 2) changing b43 so it knows how to talk to your specific radio/PHY
> chip, and LP PHY
Also almost working and in the progress of merging mainline.
--
Greetings, Michael.
^ permalink raw reply
* [RFT] b43: Get rid of spinlocks (version 2)
From: Michael Buesch @ 2009-08-23 12:48 UTC (permalink / raw)
To: bcm43xx-dev; +Cc: linux-wireless, Albert Herranz
Hi,
This patchset removes all spinlocks (except the LEDs lock for now) from b43.
There are no known races or bugs added by this patchset.
Please test it a lot, so we can ensure there are no regressions.
It sometimes crashes for me in the lockdep code on module unload, but I'm not
really sure whether that is a b43 or lockdep bug.
Please test test test. :)
Apply the patchset in this order to wireless-testing.git:
http://bu3sch.de/patches/wireless-testing/20090823-1442/patches/001-fix-irq-thread-wakeup.patch
http://bu3sch.de/patches/wireless-testing/20090823-1442/patches/002-b43-threaded-irq-handler.patch
http://bu3sch.de/patches/wireless-testing/20090823-1442/patches/003-b43-remove-tx-lock.patch
http://bu3sch.de/patches/wireless-testing/20090823-1442/patches/004-b43-remove-queue-locks.patch
http://bu3sch.de/patches/wireless-testing/20090823-1442/patches/005-b43-remove-pio-rx-work.patch
http://bu3sch.de/patches/wireless-testing/20090823-1442/patches/006-b43-remove-shm-lock.patch
--
Greetings, Michael.
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: Johannes Berg @ 2009-08-23 9:13 UTC (permalink / raw)
To: Larry Finger; +Cc: feng tian, linux-wireless
In-Reply-To: <4A90B086.1020503@lwfinger.net>
[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]
On Sat, 2009-08-22 at 21:59 -0500, Larry Finger wrote:
> feng tian wrote:
> > Thank you for the information.
> > I get your point. As for the radio and phy driver, I think it's some
> > command based configurations for the chip via SDIO. And that I can
> > refer to the BCM 43xx PCI driver codes.
> > Wonder if it's feasible. Needs your comments.
> > Thanks
>
> The first step is to be able to read/write the various registers via
> SDIO. That will be similar to the PCI operations. The next step is
> knowing what to read/write and when. We are still working that out for
> PCI. It is not trivial. See the recent postings of patches for the LP
> pHY in the linux-wireless mailing list. These are _NOT_ complete.
Right.
You have two completely orthogonal problems:
1) changing b43 so it knows how to talk not just to SSB/PCI/PCMCIA
chips but also SDIO chips
2) changing b43 so it knows how to talk to your specific radio/PHY
chip, and LP PHY
However, 1) is being solved for you by somebody on the IRC channel with
whom Michael is in contact, and 2) is (hopefully) being solved for you
by Larry and Gabor.
Thus, the best thing you can do is familiarise yourself with the
existing efforts and eventually try to put them together and test with
your chip.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] Implementation of the IEEE80211_RADIOTAP_RATE option
From: Johannes Berg @ 2009-08-23 9:11 UTC (permalink / raw)
To: Rafael Laufer; +Cc: Gábor Stefanik, linux-wireless
In-Reply-To: <4A906B4C.6010208@cs.ucla.edu>
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]
On Sat, 2009-08-22 at 15:03 -0700, Rafael Laufer wrote:
> >> + * @IEEE80211_TX_CTL_RATE_RADIOTAP: completely internal to mac80211,
> >> + * used to indicate that the rate was defined in the received radiotap
> >> + * header and therefore the rate control algorithm should not change it.
> >>
> >
> > This should be an internal flag, the driver doesn't care.
> >
>
> right, and where are those set?
It's just a naming thing really. Look at the other flags.
> >> + /* Get the rate parameter from the radiotap header,
> >> + * allowing rate selection on a per-packet basis
> >> + */
> >>
> >
> > coding style
> >
>
> I am a newbie, I am gonna look into the coding style, but I assume you
> are talking about the missing blank line in the beginning
What Kalle said. Sorry to be a bit terse at times.
> This is a good point and now I see that Gábor pointed this out as well.
> There are other fields in the radiotap header that define the RTS and
> DATA retries. However, if those fields are not set, there must be a
> default value in this case. Are there any?
Well there's the short and long retry counts, that could be used I
guess. It would make some sense to do that. And the RTS/CTS-to-self
determination should probably be made by the network in absence of
explicit configuration, but the tx_h_rate_ctrl function should do that
already I think, even if you skip the rate control algorithm. Same with
short preamble or not. If you want to support only the rate, I suspect
that leaving the flags and setting just the rate index/count will be
sufficient. Unfortunately, you'll have to take a closer look at the code
to determine it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] Implementation of the IEEE80211_RADIOTAP_RATE option
From: Kalle Valo @ 2009-08-23 8:06 UTC (permalink / raw)
To: Rafael Laufer; +Cc: Johannes Berg, Gábor Stefanik, linux-wireless
In-Reply-To: <4A906B4C.6010208@cs.ucla.edu>
Rafael Laufer <rlaufer@CS.UCLA.EDU> writes:
>>> + /* Get the rate parameter from the radiotap header, +
>>> * allowing rate selection on a per-packet basis + */
>>>
>>
>> coding style
>>
>
> I am a newbie, I am gonna look into the coding style,
In case you didn't know, Documentation/CodingStyle is the file you want
to need.
> but I assume you are talking about the missing blank line in the
> beginning
I think Johannes' means the comment style:
/*
* The prefer multiline comments to look like this. blah blah blah blah
* blah blah blah blah blah blah blah blah blah blah blah blah
*/
--
Kalle Valo
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: Larry Finger @ 2009-08-23 2:59 UTC (permalink / raw)
To: feng tian; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <f42a38140908221927qabc3f25t60f348f7c4a446c9@mail.gmail.com>
feng tian wrote:
> Thank you for the information.
> I get your point. As for the radio and phy driver, I think it's some
> command based configurations for the chip via SDIO. And that I can
> refer to the BCM 43xx PCI driver codes.
> Wonder if it's feasible. Needs your comments.
> Thanks
The first step is to be able to read/write the various registers via
SDIO. That will be similar to the PCI operations. The next step is
knowing what to read/write and when. We are still working that out for
PCI. It is not trivial. See the recent postings of patches for the LP
pHY in the linux-wireless mailing list. These are _NOT_ complete.
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: feng tian @ 2009-08-23 2:27 UTC (permalink / raw)
To: Johannes Berg; +Cc: Larry Finger, linux-wireless
In-Reply-To: <1250964823.23605.22.camel@johannes.local>
Thank you for the information.
I get your point. As for the radio and phy driver, I think it's some
command based configurations for the chip via SDIO. And that I can
refer to the BCM 43xx PCI driver codes.
Wonder if it's feasible. Needs your comments.
Thanks
BR
Feng
2009/8/23 Johannes Berg <johannes@sipsolutions.net>:
> On Sat, 2009-08-22 at 09:27 -0500, Larry Finger wrote:
>> feng tian wrote:
>> > Instead of waiting for the codes, we decide to do someting on
>> > supporting the BCM 4325 running in linux via SDIO.
>> > The linux wireless dirver supports another chip (marvel 8686) with
>> > SDIO interface, the sources codes locate in
>> > drivers/net/wireless/libertas.
>> > We are wondering to develop the BCM4325 driver in the reference to the
>> > marvel 8686 SDIO driver.
>> > Please give comments on this, thanks.
>>
>> The SDIO routines might be transferable; however, the radio and PHY
>> code will be completely different.
>
> Very few of them will be, afaict the SDIO bus access is vastly
> different. Learning how to write an SDIO driver might be possible, but I
> suspect transferring code won't make much sense.
>
> Either way, isobel has some b43 sdio code already.
>
> johannes
>
^ permalink raw reply
* Re: WARNING: at net/mac80211/mlme.c:2292
From: Bob Copeland @ 2009-08-23 0:12 UTC (permalink / raw)
To: Fabio Comolli; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <b637ec0b0908221229k5a738f8dgc0aa9e58337c743e@mail.gmail.com>
On Sat, Aug 22, 2009 at 09:29:39PM +0200, Fabio Comolli wrote:
> Hi Bob.
> Unfortunately the patch doesn't apply at all with compat-wireless,
> there's no "flush_workqueue" before "local->suspended" there....
Ah yes, it got moved into ieee80211_stop_device(). Can you put
local->suspended and the barrier() ahead of that?
Thanks!
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH] Implementation of the IEEE80211_RADIOTAP_RATE option
From: Rafael Laufer @ 2009-08-22 22:05 UTC (permalink / raw)
To: Johannes Berg; +Cc: Gábor Stefanik, linux-wireless
In-Reply-To: <1250927425.23605.8.camel@johannes.local>
Johannes Berg wrote:
> On Fri, 2009-08-21 at 13:21 -0700, Rafael Laufer wrote:
>
>
>> It is strange that a function called "get_rate" would also change other
>> fields which are at first sight do not look related to rate. Why not
>> call other functions for that? What is the reasoning behind this?
>> Different rates have different retry counts or RTS/CTS usage?
>>
> I can't tell if you're kidding or not. This also doesn't get a single
> rate, but the entire rate control setup.
>
>> As far as I could tell from a quick look in the code,
>> rate_control_get_rate only sets the fields of info->control.rates,
>> except for this driver-specific function.
>>
> Right. And now look again what's in control.rates[].
>
ok, I get it now. The flags and count also need to be set. Anything else?
>
>> If this function really does other stuff, then a simple solution is to
>> check if the IEEE80211_TX_CTL_RATE_RADIOTAP flag is set and, in that
>> case, store the value of info->control.rates[0].idx before calling
>> rate_control_get_rate, and restoring it afterwards. Make sense?
>>
> Ick, no.
>
though so, it's so ugly
Rafael
^ permalink raw reply
* Re: [PATCH] Implementation of the IEEE80211_RADIOTAP_RATE option
From: Rafael Laufer @ 2009-08-22 22:03 UTC (permalink / raw)
To: Johannes Berg; +Cc: Gábor Stefanik, linux-wireless
In-Reply-To: <1250927308.23605.6.camel@johannes.local>
Johannes Berg wrote:
> On Fri, 2009-08-21 at 11:03 -0700, Rafael Laufer wrote:
>
>
>> + * @IEEE80211_TX_CTL_RATE_RADIOTAP: completely internal to mac80211,
>> + * used to indicate that the rate was defined in the received radiotap
>> + * header and therefore the rate control algorithm should not change it.
>>
>
> This should be an internal flag, the driver doesn't care.
>
right, and where are those set?
>
>> + /* In monitor mode, if the IEEE80211_RADIOTAP_RATE option is set in
>> + * the received radiotap header, do not call the rate control algorithm.
>> + */
>>
>
> coding style
>
>
>> + /* Get the rate parameter from the radiotap header,
>> + * allowing rate selection on a per-packet basis
>> + */
>>
>
> coding style
>
I am a newbie, I am gonna look into the coding style, but I assume you
are talking about the missing blank line in the beginning
>
>> + case IEEE80211_RADIOTAP_RATE:
>> + bitrate = (*iterator.this_arg) * 5;
>> + for (i = 0; i < sband->n_bitrates; i++) {
>> + if (sband->bitrates[i].bitrate == bitrate)
>> + break;
>> + }
>> + if (i != sband->n_bitrates) {
>> + info->control.rates[0].idx = i;
>> + info->flags |= IEEE80211_TX_CTL_RATE_RADIOTAP;
>> + }
>>
>
> You never set the counter, or any other fields.
>
This is a good point and now I see that Gábor pointed this out as well.
There are other fields in the radiotap header that define the RTS and
DATA retries. However, if those fields are not set, there must be a
default value in this case. Are there any?
>
>> /*
>> * Please update the file
>> * Documentation/networking/mac80211-injection.txt
>>
>
> And you even quote the instructions.
>
come on...
Rafael
^ permalink raw reply
* Re: [PATCH] rtl8187: always set MSR_LINK_ENEDCA flag with RTL8187B
From: Hin-Tak Leung @ 2009-08-22 22:06 UTC (permalink / raw)
To: Larry Finger
Cc: Herton Ronaldo Krzesinski, linux-wireless, John W. Linville,
Hin-Tak Leung, Rafael J. Wysocki
In-Reply-To: <4A8E9315.3000709@lwfinger.net>
On Fri, Aug 21, 2009 at 1:29 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
> Hin-Tak Leung wrote:
>>
> This problem was quite strange. My system would fail when the RTL8187B
> was inserted when the system booted. Unloading the driver did not
> help, but removing/reinstalling the card fixed the problem. As all my
> testing had been to install the card after booting, I never saw the
> failure.
Removing/reinstalling the card also reset the usb hub driver, I think,
and does more than unloading the driver. I don't have that ability
(rtl8187 built-in), but suspend/resume on my system also works around
the 'can't load 2nd time' problem.
Anyway, the 'can't load compat-wireless 2nd time' problem seems to
have gone away - I just loaded it a 2nd time testing the rkfill patch.
Hin-Tak
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Hin-Tak Leung @ 2009-08-22 21:59 UTC (permalink / raw)
To: Herton Ronaldo Krzesinski; +Cc: linux-wireless, Larry Finger, Hin-Tak Leung
In-Reply-To: <200908220038.35564.herton@mandriva.com.br>
On Sat, Aug 22, 2009 at 4:38 AM, Herton Ronaldo
Krzesinski<herton@mandriva.com.br> wrote:
> This change implements rfkill support for RTL8187B and RTL8187L devices,
> using new cfg80211 rfkill API.
>
> Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Tested-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Neat!
I ran a ping to the router while flicking the switch on and off, and
have 'ping: sendmsg: Network is unreachable' in the middle. dmesg also
shows
rtl8187: wireless radio switch turned off
wlan2: deauthenticating by local choice (reason=3)
rtl8187: wireless radio switch turned on
etc. Work as advertised.
Well done!
Hin-Tak
^ permalink raw reply
* Re: [RFT] ar9170: use eeprom's frequency calibration values
From: Christian Lamparter @ 2009-08-22 21:43 UTC (permalink / raw)
To: Joerg Albert; +Cc: linux-wireless, John Linville, Johannes Berg
In-Reply-To: <4A905D2B.9090405@gmx.de>
On Saturday 22 August 2009 23:03:39 Joerg Albert wrote:
> On 08/22/2009 01:51 AM, Christian Lamparter wrote:
> > On Saturday 22 August 2009 01:36:17 Joerg Albert wrote:
> >> On 08/21/2009 10:52 PM, Christian Lamparter wrote:
> >>> This patch adds some more bits from the vendor driver, which
> >>> are supposed to help users with the one-stage/openfw firmwares.
> >> The otus driver sets phy registers 672-703 only for the one-stage firmware -
> >> hal/hpmain.c, line 3445:
> >>
> >> #ifndef ZM_OTUS_LINUX_PHASE_2
> >> reg_write(regAddr + i, val); /* CR672 */
> >> #endif
> >>
> >> Are you sure it doesn't hurt with the two-stage firmware?
> > no idea, that's why I ask requested input, instead of posting a patch +
> > sob right away.
> >
> > so far, I haven't heard of or experienced any regressions or anomalies.
> > Do you already have comments or complains? :)
>
> Your patch works fine here with a WNDA3100, using the two-stage firmware, against
> a 802.11g AP. After "iwconfig wlan1 rate 54M" I get approx. 22 MBit/s throughput
> with iperf, same as without the patch.
same here... and not really surprising.
According to my sources, the two-stage firmware is
capable of doing calibration without extra help from
the host.
> > Unfortunately, my device (WNDA3100) still doesn't work properly
> > with either version at phy-rates beyond the magic 18MBit barrier.
>
> Strange, same device here (or another hw version? FCC ID: PY307300073)
> and I see packets @ 54M from the dev in the sniffer. But it also has the
> invalid regdomain 0x8000 in the eeprom ...
that comment about "18mbit barrier" is only true for the one-stage fw.
I've no problem getting up and slightly above 80mbits with the original
two-stage fw.
Regards,
Chr
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox