* [PATCH 0/4] mwl8k: three bug fixes, and a cosmetic fix
From: Lennert Buytenhek @ 2009-08-24 13:42 UTC (permalink / raw)
To: linville, linux-wireless
Some more patches for wireless-testing:
- A bug fix to fix an inverted error test in mwl8k_bss_info_changed().
This was accidentally introduced in the last batch of changes.
- Two minor bug fixes for issues that exist in 2.6.31 as well, but
aren't really important enough to justify applying there.
- A cosmetic fix to clarify the difference between driver and device
info during probe.
^ permalink raw reply
* [PATCH 1/4] mwl8k: fix inverted error test in mwl8k_bss_info_changed()
From: Lennert Buytenhek @ 2009-08-24 13:42 UTC (permalink / raw)
To: linville, linux-wireless
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
---
drivers/net/wireless/mwl8k.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index 41a708c..4d3353c 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -2617,7 +2617,7 @@ static void mwl8k_bss_info_changed(struct ieee80211_hw *hw,
priv->capture_beacon = false;
rc = mwl8k_fw_lock(hw);
- if (!rc)
+ if (rc)
return;
if (info->assoc) {
--
1.5.6.4
^ permalink raw reply related
* [PATCH 2/4] mwl8k: fix pci dma mapping leak in mwl8k_post_cmd() error path
From: Lennert Buytenhek @ 2009-08-24 13:42 UTC (permalink / raw)
To: linville, linux-wireless
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
---
drivers/net/wireless/mwl8k.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index 4d3353c..a4336f4 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -1439,8 +1439,11 @@ static int mwl8k_post_cmd(struct ieee80211_hw *hw, struct mwl8k_cmd_pkt *cmd)
return -ENOMEM;
rc = mwl8k_fw_lock(hw);
- if (rc)
+ if (rc) {
+ pci_unmap_single(priv->pdev, dma_addr, dma_size,
+ PCI_DMA_BIDIRECTIONAL);
return rc;
+ }
priv->hostcmd_wait = &cmd_wait;
iowrite32(dma_addr, regs + MWL8K_HIU_GEN_PTR);
--
1.5.6.4
^ permalink raw reply related
* [PATCH 3/4] mwl8k: missing endian conversion when printing firmware command result
From: Lennert Buytenhek @ 2009-08-24 13:42 UTC (permalink / raw)
To: linville, linux-wireless
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
---
drivers/net/wireless/mwl8k.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index a4336f4..6e017db 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -1474,7 +1474,7 @@ static int mwl8k_post_cmd(struct ieee80211_hw *hw, struct mwl8k_cmd_pkt *cmd)
printk(KERN_ERR "%s: Command %s error 0x%x\n",
priv->name,
mwl8k_cmd_name(cmd->code, buf, sizeof(buf)),
- cmd->result);
+ le16_to_cpu(cmd->result));
}
return rc;
--
1.5.6.4
^ permalink raw reply related
* [PATCH 4/4] mwl8k: separate driver and device info reporting during probe
From: Lennert Buytenhek @ 2009-08-24 13:48 UTC (permalink / raw)
To: linville, linux-wireless
Only print the driver version once, and condense all per-PHY
information to a single line.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
---
drivers/net/wireless/mwl8k.c | 21 ++++++++++++---------
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index 6e017db..746532e 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -164,7 +164,7 @@ struct mwl8k_priv {
u16 num_mcaddrs;
u8 hw_rev;
- __le32 fw_rev;
+ u32 fw_rev;
/*
* Running count of TX packets in flight, to avoid
@@ -2825,11 +2825,16 @@ static void mwl8k_finalize_join_worker(struct work_struct *work)
static int __devinit mwl8k_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
+ static int printed_version = 0;
struct ieee80211_hw *hw;
struct mwl8k_priv *priv;
int rc;
int i;
- u8 *fw;
+
+ if (!printed_version) {
+ printk(KERN_INFO "%s version %s\n", MWL8K_DESC, MWL8K_VERSION);
+ printed_version = 1;
+ }
rc = pci_enable_device(pdev);
if (rc) {
@@ -3004,13 +3009,11 @@ static int __devinit mwl8k_probe(struct pci_dev *pdev,
goto err_stop_firmware;
}
- fw = (u8 *)&priv->fw_rev;
- printk(KERN_INFO "%s: 88W%u %s\n", priv->name, priv->part_num,
- MWL8K_DESC);
- printk(KERN_INFO "%s: Driver Ver:%s Firmware Ver:%u.%u.%u.%u\n",
- priv->name, MWL8K_VERSION, fw[3], fw[2], fw[1], fw[0]);
- printk(KERN_INFO "%s: MAC Address: %pM\n", priv->name,
- hw->wiphy->perm_addr);
+ printk(KERN_INFO "%s: 88w%u v%d, %pM, firmware version %u.%u.%u.%u\n",
+ wiphy_name(hw->wiphy), priv->part_num, priv->hw_rev,
+ hw->wiphy->perm_addr,
+ (priv->fw_rev >> 24) & 0xff, (priv->fw_rev >> 16) & 0xff,
+ (priv->fw_rev >> 8) & 0xff, priv->fw_rev & 0xff);
return 0;
--
1.5.6.4
^ permalink raw reply related
* Re: [PATCHv4] b43 add harware tkip
From: John W. Linville @ 2009-08-24 14:20 UTC (permalink / raw)
To: gregor kowski; +Cc: Kalle Valo, linux-wireless, bcm43xx-dev, Michael Buesch
In-Reply-To: <83a869cd0908211443s1d366f70o202ae768a93b20dc@mail.gmail.com>
On Fri, Aug 21, 2009 at 11:43:55PM +0200, gregor kowski wrote:
> This add hardware tkip for b43. This can help to reduce the load a low
> powered router and make higher throughput. To enable it, you need to
> set "hwtkip" module param.
>
> Signed-off-by: Gregor Kowski <gregor.kowski@gmail.com>
> Acked-by: Michael Buesch <mb@bu3sch.de>
An earlier version was already merged. What is different here?
Please submit a new patch with just the differences.
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
* [davem@davemloft.net: consider 2.6.31 a done deal...]
From: John W. Linville @ 2009-08-24 14:36 UTC (permalink / raw)
To: linux-wireless
FYI...obviously, this goes for wireless fixes for 2.6.31 as well...
----- Forwarded message from David Miller <davem@davemloft.net> -----
> Date: Sun, 23 Aug 2009 23:21:11 -0700 (PDT)
> From: David Miller <davem@davemloft.net>
> To: netdev@vger.kernel.org
> Subject: consider 2.6.31 a done deal...
> X-Mailer: Mew version 6.2.51 on Emacs 22.1 / Mule 5.0 (SAKAKI)
>
>
> At least that should be your mindset when you submit changes
> at this point. With the net-2.6 pull request I just sent to
> Linus, I really don't want to see anything submitted for
> net-2.6 unless it is EARTH SHATTERING.
>
> And chances are, the "super important" bug fix you might have for your
> driver is absolutely not EARTH SHATTERING.
>
> So don't even try to slip it by me. Ok? :-)
>
> net-next-2.6 submissions, on the other hand, are very highly
> encouraged :-)
>
> Thanks!
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
----- End forwarded message -----
--
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
* Re: [davem@davemloft.net: consider 2.6.31 a done deal...]
From: Bob Copeland @ 2009-08-24 15:18 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20090824143622.GC8998@tuxdriver.com>
On Mon, Aug 24, 2009 at 10:36 AM, John W.
Linville<linville@tuxdriver.com> wrote:
> FYI...obviously, this goes for wireless fixes for 2.6.31 as well...
>
Right-o, then I withdraw the request about that ath5k fix, we'll
just plan to send it @stable.
>> At least that should be your mindset when you submit changes
>> at this point. With the net-2.6 pull request I just sent to
>> Linus, I really don't want to see anything submitted for
>> net-2.6 unless it is EARTH SHATTERING.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: driver_nl80211 broken again
From: Johannes Berg @ 2009-08-24 14:08 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: linux-wireless
In-Reply-To: <1251117161.22951.4.camel@maxim-laptop>
[-- Attachment #1: Type: text/plain, Size: 643 bytes --]
On Mon, 2009-08-24 at 15:32 +0300, Maxim Levitsky wrote:
> First connection works fine, but all following connections hang
> wpa_supplicant hard, and more than that, this is first time,
> NetworkManager confused that much that it refuses flat to connect to my
> network, even if I reload the wireless stack.
>
> Only way to connect again, is to reload wireless stack, restart
> wpa_supplicant, and restart NM, and this helps, only for one more shot.
>
> My network is WPA2 protected, I use iwl3945, this is quite recent
> regression (of course I use tip of wireless-testing)
Need more info, works ok here (hwsim).
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [Fwd: [Bug 13725] p54 gets a "tx refused but queue active" WARNING from mac80211]
From: Larry Finger @ 2009-08-24 16:40 UTC (permalink / raw)
To: Chr; +Cc: wireless
Christian and Johannes,
A dongle running p54usb gets a "tx refused but queue active" WARNING
when used as an AP using hostapd and running 2.6.31-rc6 from Linus's
tree, even with my patch that fixed this problem in STA mode.
Christian, have you tested this configuration? Johannes - any thoughts?
I'm trying to reproduce the problem.
Larry
======================================================================
-------- Original Message --------
Subject: [Bug 13725] p54 gets a "tx refused but queue active" WARNING
from mac80211
Date: Mon, 24 Aug 2009 15:22:34 GMT
From: bugzilla-daemon@bugzilla.kernel.org
To: Larry.Finger@lwfinger.net
References: <bug-13725-734@http.bugzilla.kernel.org/>
http://bugzilla.kernel.org/show_bug.cgi?id=13725
--- Comment #3 from cortez8591@gmail.com 2009-08-24 15:22:33 ---
I'm using p54usb dongle with hostapd to share my Internet connection.
After
client connects with station and start browsing/downloading it takes
0.5 - 1min
and suddenly network sharing stops working. The only error message
comes from
dmesg and it is the error mentioned before. System load was from 0.10
to 0.30
max.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug.
^ permalink raw reply
* Re: [Fwd: [Bug 13725] p54 gets a "tx refused but queue active" WARNING from mac80211]
From: Chunkeey @ 2009-08-24 17:24 UTC (permalink / raw)
To: Larry Finger; +Cc: Max Filippov, wireless
> Christian and Johannes,
>
> A dongle running p54usb gets a "tx refused but queue active" WARNING
> when used as an AP using hostapd and running 2.6.31-rc6 from Linus's
> tree, even with my patch that fixed this problem in STA mode.
> Christian, have you tested this configuration? Johannes - any thoughts?
well, this particular WARN_ON can probably be fixed by reverting the following patch:
"p54: call p54_wake_free_queues on every p54_free_skb and p54_rx_frame_sent"
however, based on Max commit description this patch is necessary for p54spi to
work properly. So, I'm not going to touch it...
The best thing he can do now is to use compat-wireless.
(Or since he uses a -rc kernel anyway, why not wireless-testing?)
wireless-testing/cw does not only have a newer driver,
but also mac80211 improvements for power-saving clients.
________________________________________________________________
Neu: WEB.DE Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://produkte.web.de/go/02/
^ permalink raw reply
* [PATCH] mac80211: Fix output of minstrels rc_stats
From: Arnd Hannemann @ 2009-08-24 17:42 UTC (permalink / raw)
To: linux-wireless; +Cc: Arnd Hannemann
An integer overflow in the minstrel debug code prevented the
throughput to be displayed correctly. This patch fixes that,
by swaping the division and multiplication.
Signed-off-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
---
net/mac80211/rc80211_minstrel_debugfs.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel_debugfs.c b/net/mac80211/rc80211_minstrel_debugfs.c
index 98f4807..caf9453 100644
--- a/net/mac80211/rc80211_minstrel_debugfs.c
+++ b/net/mac80211/rc80211_minstrel_debugfs.c
@@ -83,7 +83,7 @@ minstrel_stats_open(struct inode *inode, struct file *file)
p += sprintf(p, "%3u%s", mr->bitrate / 2,
(mr->bitrate & 1 ? ".5" : " "));
- tp = ((mr->cur_tp * 96) / 18000) >> 10;
+ tp = ((mr->cur_tp / 18000) * 96) >> 10;
prob = mr->cur_prob / 18;
eprob = mr->probability / 18;
--
1.6.4.1
^ permalink raw reply related
* Re: [PATCH] mac80211: Fix output of minstrels rc_stats
From: Joe Perches @ 2009-08-24 17:57 UTC (permalink / raw)
To: Arnd Hannemann; +Cc: linux-wireless
In-Reply-To: <1251135778-27288-1-git-send-email-hannemann@nets.rwth-aachen.de>
On Mon, 2009-08-24 at 19:42 +0200, Arnd Hannemann wrote:
> An integer overflow in the minstrel debug code prevented the
> throughput to be displayed correctly. This patch fixes that,
> by swaping the division and multiplication.
>
> Signed-off-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
> ---
> net/mac80211/rc80211_minstrel_debugfs.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/mac80211/rc80211_minstrel_debugfs.c b/net/mac80211/rc80211_minstrel_debugfs.c
> index 98f4807..caf9453 100644
> --- a/net/mac80211/rc80211_minstrel_debugfs.c
> +++ b/net/mac80211/rc80211_minstrel_debugfs.c
> @@ -83,7 +83,7 @@ minstrel_stats_open(struct inode *inode, struct file *file)
> p += sprintf(p, "%3u%s", mr->bitrate / 2,
> (mr->bitrate & 1 ? ".5" : " "));
>
> - tp = ((mr->cur_tp * 96) / 18000) >> 10;
> + tp = ((mr->cur_tp / 18000) * 96) >> 10;
Maybe do_div instead?
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Herton Ronaldo Krzesinski @ 2009-08-24 18:03 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Hin-Tak Leung
In-Reply-To: <4A91F100.9040804@lwfinger.net>
Em Dom 23 Ago 2009, às 22:46:40, Larry Finger escreveu:
> 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:
Hmm, this is a issue that was already present before the rfkill patch, but
seems with it, it became more likely to happen. Please try this patch:
[PATCH] rtl8187: fix circular locking (rtl8187_stop/rtl8187_work)
Larry Finger reports following lockdep 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
The problem here is that rtl8187_stop, while helding priv->conf_mutex,
runs cancel_delayed_work_sync on an workqueue that runs rtl8187_work,
which also takes priv->conf_mutex lock. Move cancel_delayed_work_sync
out of rtl8187_stop priv->conf_mutex locking region.
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
---
drivers/net/wireless/rtl818x/rtl8187_dev.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8187_dev.c b/drivers/net/wireless/rtl818x/rtl8187_dev.c
index b6e9fbd..2017ccc 100644
--- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c
@@ -1018,9 +1018,10 @@ static void rtl8187_stop(struct ieee80211_hw *dev)
dev_kfree_skb_any(skb);
usb_kill_anchored_urbs(&priv->anchored);
+ mutex_unlock(&priv->conf_mutex);
+
if (!priv->is_rtl8187b)
cancel_delayed_work_sync(&priv->work);
- mutex_unlock(&priv->conf_mutex);
}
static int rtl8187_add_interface(struct ieee80211_hw *dev,
--
1.6.4.1
>
>
> =======================================================
> [ 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
--
[]'s
Herton
^ permalink raw reply related
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Herton Ronaldo Krzesinski @ 2009-08-24 18:10 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: linux-wireless, Larry Finger
In-Reply-To: <3ace41890908231238h32b85839qe74bce2852103402@mail.gmail.com>
Em Dom 23 Ago 2009, às 16:38:43, Hin-Tak Leung escreveu:
> 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.
Yes, the equivalent of ifconfig down is what cfg80211 rfkill does in this case.
> (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.
This is strange, may be NetworkManager does something extra and for some reason
manages to wake up the interface again? I thought it would be unable to "if up"
the interface since -ERFKILL should be returned to it when switch is off...
>
> 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.
About taking interface down, thats expected, but I don't know about
NetworkManager, I was expecting it to be unable to "if up" the interface again.
>
> Hin-Tak
>
--
[]'s
Herton
^ permalink raw reply
* Re: [PATCH] mac80211: Fix output of minstrels rc_stats
From: Pavel Roskin @ 2009-08-24 18:20 UTC (permalink / raw)
To: Joe Perches; +Cc: Arnd Hannemann, linux-wireless
In-Reply-To: <1251136676.3873.28.camel@Joe-Laptop.home>
On Mon, 2009-08-24 at 10:57 -0700, Joe Perches wrote:
> On Mon, 2009-08-24 at 19:42 +0200, Arnd Hannemann wrote:
> > An integer overflow in the minstrel debug code prevented the
> > throughput to be displayed correctly. This patch fixes that,
> > by swaping the division and multiplication.
> >
> > Signed-off-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
> > ---
> > net/mac80211/rc80211_minstrel_debugfs.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/net/mac80211/rc80211_minstrel_debugfs.c b/net/mac80211/rc80211_minstrel_debugfs.c
> > index 98f4807..caf9453 100644
> > --- a/net/mac80211/rc80211_minstrel_debugfs.c
> > +++ b/net/mac80211/rc80211_minstrel_debugfs.c
> > @@ -83,7 +83,7 @@ minstrel_stats_open(struct inode *inode, struct file *file)
> > p += sprintf(p, "%3u%s", mr->bitrate / 2,
> > (mr->bitrate & 1 ? ".5" : " "));
> >
> > - tp = ((mr->cur_tp * 96) / 18000) >> 10;
> > + tp = ((mr->cur_tp / 18000) * 96) >> 10;
>
> Maybe do_div instead?
How about this?
tp = mr->cur_tp / ((18000 << 10) / 96);
((18000 << 10) / 96) is exactly 192000.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] mac80211: Fix output of minstrels rc_stats
From: Arnd Hannemann @ 2009-08-24 18:19 UTC (permalink / raw)
To: Joe Perches; +Cc: Arnd Hannemann, linux-wireless@vger.kernel.org
In-Reply-To: <1251136676.3873.28.camel@Joe-Laptop.home>
Joe Perches schrieb:
> On Mon, 2009-08-24 at 19:42 +0200, Arnd Hannemann wrote:
>> An integer overflow in the minstrel debug code prevented the
>> throughput to be displayed correctly. This patch fixes that,
>> by swaping the division and multiplication.
>>
>> Signed-off-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
>> ---
>> net/mac80211/rc80211_minstrel_debugfs.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/mac80211/rc80211_minstrel_debugfs.c b/net/mac80211/rc80211_minstrel_debugfs.c
>> index 98f4807..caf9453 100644
>> --- a/net/mac80211/rc80211_minstrel_debugfs.c
>> +++ b/net/mac80211/rc80211_minstrel_debugfs.c
>> @@ -83,7 +83,7 @@ minstrel_stats_open(struct inode *inode, struct file *file)
>> p += sprintf(p, "%3u%s", mr->bitrate / 2,
>> (mr->bitrate & 1 ? ".5" : " "));
>>
>> - tp = ((mr->cur_tp * 96) / 18000) >> 10;
>> + tp = ((mr->cur_tp / 18000) * 96) >> 10;
>
> Maybe do_div instead?
Do you mean the do_div from asm/div64h ?
It seems overly complicated to me. It would result in something like:
tp = mr->cur_tp;
do_div(tp, 18000);
tp = (tp * 96) >> 10;
Or am I missing something?
Probably
tp = mr->cur_tp * 96;
would not work..., as it would already overflow. Not sure if
do_div(tp * 96, 18000);
would work?
Best regards,
Arnd
^ permalink raw reply
* Re: Few warnings from master-2009-08-17
From: Luis R. Rodriguez @ 2009-08-24 18:21 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1250847779.17888.5.camel@johannes.local>
On Fri, Aug 21, 2009 at 2:42 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Mon, 2009-08-17 at 18:04 -0700, Luis R. Rodriguez wrote:
>
>> Aug 17 17:45:50 tux kernel: [ 424.812910] ------------[ cut here ]------------
>> Aug 17 17:45:50 tux kernel: [ 424.812928] WARNING: at
>> net/wireless/sme.c:610 __cfg80211_disconnected+0x1fb/0x260
>> [cfg80211]()
>> Aug 17 17:45:50 tux kernel: [ 424.812931] Hardware name: 7660A14
>> Aug 17 17:45:50 tux kernel: [ 424.812933] deauth failed: -67
>
> what was before that?
[ 1058.261102] No probe response from AP <AP-mac-address> after 500ms, try 1
[ 1058.761100] No probe response from AP <AP-mac-address> after 500ms, try 2
[ 1059.261122] No probe response from AP <AP-mac-address> after 500ms, try 3
[ 1059.761105] No probe response from AP <AP-mac-address> after 500ms, try 4
[ 1060.261105] No probe response from AP <AP-mac-address> after 500ms,
disconnecting.
[ 1060.264257] phy1: device now idle
[ 1060.268293] phy1: Removed STA <AP-mac-address>
[ 1060.290788] phy1: Destroyed STA <AP-mac-address>
[ 1060.290961] wlan6: deauthenticating by local choice (reason=3)
Luis
^ permalink raw reply
* Re: [PATCH] mac80211: Fix output of minstrels rc_stats
From: Arnd Hannemann @ 2009-08-24 18:36 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Joe Perches, Arnd Hannemann, linux-wireless@vger.kernel.org
In-Reply-To: <1251138015.13464.2.camel@mj>
Pavel Roskin schrieb:
> On Mon, 2009-08-24 at 10:57 -0700, Joe Perches wrote:
>> On Mon, 2009-08-24 at 19:42 +0200, Arnd Hannemann wrote:
>>> An integer overflow in the minstrel debug code prevented the
>>> throughput to be displayed correctly. This patch fixes that,
>>> by swaping the division and multiplication.
>>>
>>> Signed-off-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
>>> ---
>>> net/mac80211/rc80211_minstrel_debugfs.c | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/net/mac80211/rc80211_minstrel_debugfs.c b/net/mac80211/rc80211_minstrel_debugfs.c
>>> index 98f4807..caf9453 100644
>>> --- a/net/mac80211/rc80211_minstrel_debugfs.c
>>> +++ b/net/mac80211/rc80211_minstrel_debugfs.c
>>> @@ -83,7 +83,7 @@ minstrel_stats_open(struct inode *inode, struct file *file)
>>> p += sprintf(p, "%3u%s", mr->bitrate / 2,
>>> (mr->bitrate & 1 ? ".5" : " "));
>>>
>>> - tp = ((mr->cur_tp * 96) / 18000) >> 10;
>>> + tp = ((mr->cur_tp / 18000) * 96) >> 10;
>> Maybe do_div instead?
>
> How about this?
>
> tp = mr->cur_tp / ((18000 << 10) / 96);
>
> ((18000 << 10) / 96) is exactly 192000.
>
Hmm don't seems to be equivalent with the original statement:
a = 61027734;
b = ((a * 96) / 18000) >> 10;
c = a / ((18000 << 10) / 96);
printf("%u %u\n", b, c);
Outputs:
84 317
Best regards,
Arnd
^ permalink raw reply
* Re: [PATCH] mac80211: Fix output of minstrels rc_stats
From: Arnd Hannemann @ 2009-08-24 18:38 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Joe Perches, Arnd Hannemann, linux-wireless@vger.kernel.org
In-Reply-To: <4A92DDAB.6040503@nets.rwth-aachen.de>
Arnd Hannemann schrieb:
> Pavel Roskin schrieb:
>> On Mon, 2009-08-24 at 10:57 -0700, Joe Perches wrote:
>>> On Mon, 2009-08-24 at 19:42 +0200, Arnd Hannemann wrote:
>>>> An integer overflow in the minstrel debug code prevented the
>>>> throughput to be displayed correctly. This patch fixes that,
>>>> by swaping the division and multiplication.
>>>>
>>>> Signed-off-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
>>>> ---
>>>> net/mac80211/rc80211_minstrel_debugfs.c | 2 +-
>>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/net/mac80211/rc80211_minstrel_debugfs.c b/net/mac80211/rc80211_minstrel_debugfs.c
>>>> index 98f4807..caf9453 100644
>>>> --- a/net/mac80211/rc80211_minstrel_debugfs.c
>>>> +++ b/net/mac80211/rc80211_minstrel_debugfs.c
>>>> @@ -83,7 +83,7 @@ minstrel_stats_open(struct inode *inode, struct file *file)
>>>> p += sprintf(p, "%3u%s", mr->bitrate / 2,
>>>> (mr->bitrate & 1 ? ".5" : " "));
>>>>
>>>> - tp = ((mr->cur_tp * 96) / 18000) >> 10;
>>>> + tp = ((mr->cur_tp / 18000) * 96) >> 10;
>>> Maybe do_div instead?
>> How about this?
>>
>> tp = mr->cur_tp / ((18000 << 10) / 96);
>>
>> ((18000 << 10) / 96) is exactly 192000.
>>
>
> Hmm don't seems to be equivalent with the original statement:
>
> a = 61027734;
> b = ((a * 96) / 18000) >> 10;
> c = a / ((18000 << 10) / 96);
> printf("%u %u\n", b, c);
>
> Outputs:
> 84 317
Outch, sorry I took the overflowing formula not the fixed one!
Best regards,
Arnd
^ permalink raw reply
* [PATCH v2] mac80211: Fix output of minstrels rc_stats
From: Arnd Hannemann @ 2009-08-24 18:51 UTC (permalink / raw)
To: linux-wireless; +Cc: joe, proski, Arnd Hannemann
In-Reply-To: <1251138015.13464.2.camel@mj>
An integer overflow in the minstrel debug code prevented the
throughput to be displayed correctly. This patch fixes that,
by permutating operations like proposed by Pavel Roskin.
Signed-off-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
---
net/mac80211/rc80211_minstrel_debugfs.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel_debugfs.c b/net/mac80211/rc80211_minstrel_debugfs.c
index 98f4807..3d72ec5 100644
--- a/net/mac80211/rc80211_minstrel_debugfs.c
+++ b/net/mac80211/rc80211_minstrel_debugfs.c
@@ -83,7 +83,7 @@ minstrel_stats_open(struct inode *inode, struct file *file)
p += sprintf(p, "%3u%s", mr->bitrate / 2,
(mr->bitrate & 1 ? ".5" : " "));
- tp = ((mr->cur_tp * 96) / 18000) >> 10;
+ tp = mr->cur_tp / ((18000 << 10) / 96);
prob = mr->cur_prob / 18;
eprob = mr->probability / 18;
--
1.6.4.1
^ permalink raw reply related
* Re: Few warnings from master-2009-08-17
From: Johannes Berg @ 2009-08-24 19:37 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <43e72e890908241121j43683b75x38ef7c2ef3a71463@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 751 bytes --]
On Mon, 2009-08-24 at 11:21 -0700, Luis R. Rodriguez wrote:
> [ 1058.261102] No probe response from AP <AP-mac-address> after 500ms, try 1
> [ 1058.761100] No probe response from AP <AP-mac-address> after 500ms, try 2
> [ 1059.261122] No probe response from AP <AP-mac-address> after 500ms, try 3
> [ 1059.761105] No probe response from AP <AP-mac-address> after 500ms, try 4
> [ 1060.261105] No probe response from AP <AP-mac-address> after 500ms,
> disconnecting.
> [ 1060.264257] phy1: device now idle
> [ 1060.268293] phy1: Removed STA <AP-mac-address>
> [ 1060.290788] phy1: Destroyed STA <AP-mac-address>
> [ 1060.290961] wlan6: deauthenticating by local choice (reason=3)
Ok, but I don't see the warning after that.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Few warnings from master-2009-08-17
From: Luis R. Rodriguez @ 2009-08-24 19:43 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1251142659.12661.0.camel@johannes.local>
On Mon, Aug 24, 2009 at 12:37 PM, Johannes
Berg<johannes@sipsolutions.net> wrote:
> On Mon, 2009-08-24 at 11:21 -0700, Luis R. Rodriguez wrote:
>
>> [ 1058.261102] No probe response from AP <AP-mac-address> after 500ms, try 1
>> [ 1058.761100] No probe response from AP <AP-mac-address> after 500ms, try 2
>> [ 1059.261122] No probe response from AP <AP-mac-address> after 500ms, try 3
>> [ 1059.761105] No probe response from AP <AP-mac-address> after 500ms, try 4
>> [ 1060.261105] No probe response from AP <AP-mac-address> after 500ms,
>> disconnecting.
>> [ 1060.264257] phy1: device now idle
>> [ 1060.268293] phy1: Removed STA <AP-mac-address>
>> [ 1060.290788] phy1: Destroyed STA <AP-mac-address>
>> [ 1060.290961] wlan6: deauthenticating by local choice (reason=3)
>
> Ok, but I don't see the warning after that.
Well it was in the e-mail. Here is some log, not sure if it was the
exact same one from that day but it does seem the capture the entire
thing:
[ 1058.261102] No probe response from AP <AP-mac-address> after 500ms, try 1
[ 1058.761100] No probe response from AP <AP-mac-address> after 500ms, try 2
[ 1059.261122] No probe response from AP <AP-mac-address> after 500ms, try 3
[ 1059.761105] No probe response from AP <AP-mac-address> after 500ms, try 4
[ 1060.261105] No probe response from AP <AP-mac-address> after
500ms, disconnecting.
[ 1060.264257] phy1: device now idle
[ 1060.268293] phy1: Removed STA <AP-mac-address>
[ 1060.290788] phy1: Destroyed STA <AP-mac-address>
[ 1060.290961] wlan6: deauthenticating by local choice (reason=3)
[ 1060.291025] ------------[ cut here ]------------
[ 1060.291057] WARNING: at net/wireless/sme.c:610
__cfg80211_disconnected+0x1fb/0x260 [cfg80211]()
[ 1060.291064] Hardware name: 7660A14
[ 1060.291069] deauth failed: -67
[ 1060.291073] Modules linked in: ar9170usb mac80211 ath cfg80211
<bleh> [last unloaded: ar9170usb]
[ 1060.291230] Pid: 5525, comm: phy1 Tainted: G W 2.6.31-rc6-wl #139
[ 1060.291237] Call Trace:
[ 1060.291252] [<ffffffff810585a8>] warn_slowpath_common+0x78/0xb0
[ 1060.291262] [<ffffffff8105863c>] warn_slowpath_fmt+0x3c/0x40
[ 1060.291287] [<ffffffffa018682b>]
__cfg80211_disconnected+0x1fb/0x260 [cfg80211]
[ 1060.291312] [<ffffffffa01849f2>] ? cfg80211_send_deauth+0x62/0x80 [cfg80211]
[ 1060.291336] [<ffffffffa0184918>]
__cfg80211_send_deauth+0x228/0x2a0 [cfg80211]
[ 1060.291359] [<ffffffffa0184a01>] cfg80211_send_deauth+0x71/0x80 [cfg80211]
[ 1060.291394] [<ffffffffa03d9c1f>]
ieee80211_send_deauth_disassoc+0x14f/0x170 [mac80211]
[ 1060.291425] [<ffffffffa03dd52b>] ieee80211_sta_work+0xceb/0x1100 [mac80211]
[ 1060.291456] [<ffffffffa03dc840>] ? ieee80211_sta_work+0x0/0x1100 [mac80211]
[ 1060.291466] [<ffffffff8106de80>] worker_thread+0x1d0/0x380
[ 1060.291475] [<ffffffff8106de2e>] ? worker_thread+0x17e/0x380
[ 1060.291487] [<ffffffff8152977b>] ? _spin_unlock_irqrestore+0x3b/0x70
[ 1060.291499] [<ffffffff81073630>] ? autoremove_wake_function+0x0/0x40
[ 1060.291509] [<ffffffff8106dcb0>] ? worker_thread+0x0/0x380
[ 1060.291518] [<ffffffff81073266>] kthread+0xa6/0xb0
[ 1060.291529] [<ffffffff810130ca>] child_rip+0xa/0x20
[ 1060.291540] [<ffffffff81012a50>] ? restore_args+0x0/0x30
[ 1060.291549] [<ffffffff810731c0>] ? kthread+0x0/0xb0
[ 1060.291557] [<ffffffff810130c0>] ? child_rip+0x0/0x20
[ 1060.291564] ---[ end trace 7ef91a8a6ee731a3 ]---
[ 1060.428931] phy1: device no longer idle - scanning
[ 1068.424002] phy1: device now idle
[ 1073.259516] phy1: device no longer idle - scanning
[ 1081.234199] phy1: device now idle
[ 1086.357427] phy1: device no longer idle - scanning
[ 1094.366167] phy1: device now idle
Let me know if this helps or if you need something more recent.
Luis
^ permalink raw reply
* Re: Few warnings from master-2009-08-17
From: Johannes Berg @ 2009-08-24 19:50 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <43e72e890908241243w6b6de4d9o6e2fc22e5c814f5e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]
On Mon, 2009-08-24 at 12:43 -0700, Luis R. Rodriguez wrote:
> > Ok, but I don't see the warning after that.
>
> Well it was in the e-mail. Here is some log, not sure if it was the
> exact same one from that day but it does seem the capture the entire
> thing:
>
> [ 1058.261102] No probe response from AP <AP-mac-address> after 500ms, try 1
> [ 1058.761100] No probe response from AP <AP-mac-address> after 500ms, try 2
> [ 1059.261122] No probe response from AP <AP-mac-address> after 500ms, try 3
> [ 1059.761105] No probe response from AP <AP-mac-address> after 500ms, try 4
> [ 1060.261105] No probe response from AP <AP-mac-address> after
> 500ms, disconnecting.
> [ 1060.264257] phy1: device now idle
> [ 1060.268293] phy1: Removed STA <AP-mac-address>
> [ 1060.290788] phy1: Destroyed STA <AP-mac-address>
> [ 1060.290961] wlan6: deauthenticating by local choice (reason=3)
> [ 1060.291025] ------------[ cut here ]------------
> [ 1060.291057] WARNING: at net/wireless/sme.c:610
> __cfg80211_disconnected+0x1fb/0x260 [cfg80211]()
Well, yes, I just can't reproduce the warning. Need better instructions
how you do that.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] compal-laptop: Replace sysfs support with rfkill support
From: Mario Limonciello @ 2009-08-24 19:50 UTC (permalink / raw)
To: cezary.jackiewicz
Cc: linux-wireless, linux-acpi, linux-kernel, Mario Limonciello
In-Reply-To: <9b2b86520908220420p282c862fn9c44697db010a08d@mail.gmail.com>
This drops the support for manually groking the files in sysfs
to turn on and off the WLAN and BT for Compal laptops in favor
of platform rfkill support.
It has been combined into a single patch to not introduce regressions
in the process of simply adding rfkill support
Signed-off-by: Mario Limonciello <Mario_Limonciello@Dell.com>
Reviewed-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
---
drivers/platform/x86/compal-laptop.c | 201 +++++++++++-----------------------
1 files changed, 63 insertions(+), 138 deletions(-)
diff --git a/drivers/platform/x86/compal-laptop.c b/drivers/platform/x86/compal-laptop.c
index c1c8c03..9b1cc45 100644
--- a/drivers/platform/x86/compal-laptop.c
+++ b/drivers/platform/x86/compal-laptop.c
@@ -26,17 +26,8 @@
/*
* comapl-laptop.c - Compal laptop support.
*
- * This driver exports a few files in /sys/devices/platform/compal-laptop/:
- *
- * wlan - wlan subsystem state: contains 0 or 1 (rw)
- *
- * bluetooth - Bluetooth subsystem state: contains 0 or 1 (rw)
- *
- * raw - raw value taken from embedded controller register (ro)
- *
- * In addition to these platform device attributes the driver
- * registers itself in the Linux backlight control subsystem and is
- * available to userspace under /sys/class/backlight/compal-laptop/.
+ * The driver registers itself with the rfkill subsystem and
+ * the Linux backlight control subsystem.
*
* This driver might work on other laptops produced by Compal. If you
* want to try it you can pass force=1 as argument to the module which
@@ -52,6 +43,7 @@
#include <linux/backlight.h>
#include <linux/platform_device.h>
#include <linux/autoconf.h>
+#include <linux/rfkill.h>
#define COMPAL_DRIVER_VERSION "0.2.6"
@@ -64,6 +56,10 @@
#define WLAN_MASK 0x01
#define BT_MASK 0x02
+static struct rfkill *wifi_rfkill;
+static struct rfkill *bt_rfkill;
+static struct platform_device *compal_device;
+
static int force;
module_param(force, bool, 0);
MODULE_PARM_DESC(force, "Force driver load, ignore DMI data");
@@ -89,65 +85,75 @@ static int get_lcd_level(void)
return (int) result;
}
-static int set_wlan_state(int state)
+static int compal_rfkill_set(void *data, bool blocked)
{
+ unsigned long radio = (unsigned long) data;
u8 result, value;
ec_read(COMPAL_EC_COMMAND_WIRELESS, &result);
- if ((result & KILLSWITCH_MASK) == 0)
- return -EINVAL;
- else {
- if (state)
- value = (u8) (result | WLAN_MASK);
- else
- value = (u8) (result & ~WLAN_MASK);
- ec_write(COMPAL_EC_COMMAND_WIRELESS, value);
- }
+ if (!blocked)
+ value = (u8) (result | radio);
+ else
+ value = (u8) (result & ~radio);
+ ec_write(COMPAL_EC_COMMAND_WIRELESS, value);
return 0;
}
-static int set_bluetooth_state(int state)
+static void compal_rfkill_poll(struct rfkill *rfkill, void *data)
{
- u8 result, value;
+ u8 result;
+ bool hw_blocked;
ec_read(COMPAL_EC_COMMAND_WIRELESS, &result);
- if ((result & KILLSWITCH_MASK) == 0)
- return -EINVAL;
- else {
- if (state)
- value = (u8) (result | BT_MASK);
- else
- value = (u8) (result & ~BT_MASK);
- ec_write(COMPAL_EC_COMMAND_WIRELESS, value);
- }
-
- return 0;
+ hw_blocked = !(result & KILLSWITCH_MASK);
+ rfkill_set_hw_state(rfkill, hw_blocked);
}
-static int get_wireless_state(int *wlan, int *bluetooth)
+static const struct rfkill_ops compal_rfkill_ops = {
+ .poll = compal_rfkill_poll,
+ .set_block = compal_rfkill_set,
+};
+
+static int setup_rfkill(void)
{
- u8 result;
+ int ret;
- ec_read(COMPAL_EC_COMMAND_WIRELESS, &result);
+ wifi_rfkill = rfkill_alloc("compal-wifi", &compal_device->dev,
+ RFKILL_TYPE_WLAN, &compal_rfkill_ops,
+ (void *) WLAN_MASK);
+ if (!wifi_rfkill)
+ return -ENOMEM;
- if (wlan) {
- if ((result & KILLSWITCH_MASK) == 0)
- *wlan = 0;
- else
- *wlan = result & WLAN_MASK;
- }
+ ret = rfkill_register(wifi_rfkill);
+ if (ret)
+ goto err_wifi;
- if (bluetooth) {
- if ((result & KILLSWITCH_MASK) == 0)
- *bluetooth = 0;
- else
- *bluetooth = (result & BT_MASK) >> 1;
+ bt_rfkill = rfkill_alloc("compal-bluetooth", &compal_device->dev,
+ RFKILL_TYPE_BLUETOOTH, &compal_rfkill_ops,
+ (void *) BT_MASK);
+ if (!bt_rfkill) {
+ ret = -ENOMEM;
+ goto err_allocate_bt;
}
+ ret = rfkill_register(bt_rfkill);
+ if (ret)
+ goto err_register_bt;
return 0;
+
+err_register_bt:
+ rfkill_destroy(bt_rfkill);
+
+err_allocate_bt:
+ rfkill_unregister(wifi_rfkill);
+
+err_wifi:
+ rfkill_destroy(wifi_rfkill);
+
+ return ret;
}
/* Backlight device stuff */
@@ -170,86 +176,6 @@ static struct backlight_ops compalbl_ops = {
static struct backlight_device *compalbl_device;
-/* Platform device */
-
-static ssize_t show_wlan(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- int ret, enabled;
-
- ret = get_wireless_state(&enabled, NULL);
- if (ret < 0)
- return ret;
-
- return sprintf(buf, "%i\n", enabled);
-}
-
-static ssize_t show_raw(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- u8 result;
-
- ec_read(COMPAL_EC_COMMAND_WIRELESS, &result);
-
- return sprintf(buf, "%i\n", result);
-}
-
-static ssize_t show_bluetooth(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- int ret, enabled;
-
- ret = get_wireless_state(NULL, &enabled);
- if (ret < 0)
- return ret;
-
- return sprintf(buf, "%i\n", enabled);
-}
-
-static ssize_t store_wlan_state(struct device *dev,
- struct device_attribute *attr, const char *buf, size_t count)
-{
- int state, ret;
-
- if (sscanf(buf, "%i", &state) != 1 || (state < 0 || state > 1))
- return -EINVAL;
-
- ret = set_wlan_state(state);
- if (ret < 0)
- return ret;
-
- return count;
-}
-
-static ssize_t store_bluetooth_state(struct device *dev,
- struct device_attribute *attr, const char *buf, size_t count)
-{
- int state, ret;
-
- if (sscanf(buf, "%i", &state) != 1 || (state < 0 || state > 1))
- return -EINVAL;
-
- ret = set_bluetooth_state(state);
- if (ret < 0)
- return ret;
-
- return count;
-}
-
-static DEVICE_ATTR(bluetooth, 0644, show_bluetooth, store_bluetooth_state);
-static DEVICE_ATTR(wlan, 0644, show_wlan, store_wlan_state);
-static DEVICE_ATTR(raw, 0444, show_raw, NULL);
-
-static struct attribute *compal_attributes[] = {
- &dev_attr_bluetooth.attr,
- &dev_attr_wlan.attr,
- &dev_attr_raw.attr,
- NULL
-};
-
-static struct attribute_group compal_attribute_group = {
- .attrs = compal_attributes
-};
static struct platform_driver compal_driver = {
.driver = {
@@ -258,8 +184,6 @@ static struct platform_driver compal_driver = {
}
};
-static struct platform_device *compal_device;
-
/* Initialization */
static int dmi_check_cb(const struct dmi_system_id *id)
@@ -390,23 +314,21 @@ static int __init compal_init(void)
ret = platform_device_add(compal_device);
if (ret)
- goto fail_platform_device1;
+ goto fail_platform_device;
- ret = sysfs_create_group(&compal_device->dev.kobj,
- &compal_attribute_group);
+ ret = setup_rfkill();
if (ret)
- goto fail_platform_device2;
+ goto fail_rfkill;
printk(KERN_INFO "compal-laptop: driver "COMPAL_DRIVER_VERSION
" successfully loaded.\n");
return 0;
-fail_platform_device2:
-
+fail_rfkill:
platform_device_del(compal_device);
-fail_platform_device1:
+fail_platform_device:
platform_device_put(compal_device);
@@ -424,10 +346,13 @@ fail_backlight:
static void __exit compal_cleanup(void)
{
- sysfs_remove_group(&compal_device->dev.kobj, &compal_attribute_group);
platform_device_unregister(compal_device);
platform_driver_unregister(&compal_driver);
backlight_device_unregister(compalbl_device);
+ rfkill_unregister(wifi_rfkill);
+ rfkill_destroy(wifi_rfkill);
+ rfkill_unregister(bt_rfkill);
+ rfkill_destroy(bt_rfkill);
printk(KERN_INFO "compal-laptop: driver unloaded.\n");
}
--
1.6.3.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox