* [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
* driver_nl80211 broken again
From: Maxim Levitsky @ 2009-08-24 12:32 UTC (permalink / raw)
To: linux-wireless
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)
Best regards,
Maxim Levitsky
^ permalink raw reply
* [PATCH] mac80211: fix RX skb leaks
From: Johannes Berg @ 2009-08-24 9:46 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In mac80211's RX path some of the warnings that
warn about drivers passing invalid status values
leak the skb, fix that by refactoring the code.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/mac80211/rx.c | 34 +++++++++++++++-------------------
1 file changed, 15 insertions(+), 19 deletions(-)
--- wireless-testing.orig/net/mac80211/rx.c 2009-08-24 11:42:11.000000000 +0200
+++ wireless-testing/net/mac80211/rx.c 2009-08-24 11:43:32.000000000 +0200
@@ -2447,17 +2447,13 @@ void ieee80211_rx(struct ieee80211_hw *h
struct ieee80211_supported_band *sband;
struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(skb);
- if (status->band < 0 ||
- status->band >= IEEE80211_NUM_BANDS) {
- WARN_ON(1);
- return;
- }
+ if (WARN_ON(status->band < 0 ||
+ status->band >= IEEE80211_NUM_BANDS))
+ goto drop;
sband = local->hw.wiphy->bands[status->band];
- if (!sband) {
- WARN_ON(1);
- return;
- }
+ if (WARN_ON(!sband))
+ goto drop;
/*
* If we're suspending, it is possible although not too likely
@@ -2466,25 +2462,21 @@ void ieee80211_rx(struct ieee80211_hw *h
* that might, for example, cause stations to be added or other
* driver callbacks be invoked.
*/
- if (unlikely(local->quiescing || local->suspended)) {
- kfree_skb(skb);
- return;
- }
+ if (unlikely(local->quiescing || local->suspended))
+ goto drop;
/*
* The same happens when we're not even started,
* but that's worth a warning.
*/
- if (WARN_ON(!local->started)) {
- kfree_skb(skb);
- return;
- }
+ if (WARN_ON(!local->started))
+ goto drop;
if (status->flag & RX_FLAG_HT) {
/* rate_idx is MCS index */
if (WARN_ON(status->rate_idx < 0 ||
status->rate_idx >= 76))
- return;
+ goto drop;
/* HT rates are not in the table - use the highest legacy rate
* for now since other parts of mac80211 may not yet be fully
* MCS aware. */
@@ -2492,7 +2484,7 @@ void ieee80211_rx(struct ieee80211_hw *h
} else {
if (WARN_ON(status->rate_idx < 0 ||
status->rate_idx >= sband->n_bitrates))
- return;
+ goto drop;
rate = &sband->bitrates[status->rate_idx];
}
@@ -2531,6 +2523,10 @@ void ieee80211_rx(struct ieee80211_hw *h
__ieee80211_rx_handle_packet(hw, skb, rate);
rcu_read_unlock();
+
+ return;
+ drop:
+ kfree_skb(skb);
}
EXPORT_SYMBOL(ieee80211_rx);
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: feng tian @ 2009-08-24 9:35 UTC (permalink / raw)
To: Michael Buesch; +Cc: Johannes Berg, Larry Finger, linux-wireless
In-Reply-To: <200908241108.43943.mb@bu3sch.de>
Wow, that's really cool.
We wonder if you can send these codes to us a little earlier, then we
can start to integrate and test them on our platform.
That'll save us some time.
Thanks very much.
BR, Feng.
>> Where can I get theses codes which supports b43 talking to SDIO chips?
>> Thanks very much.
>
> They are not ready for public review, yet. We're working on merging them mainline.
> But it does basically work and we (Albert Herranz) got the SDIO chip on the Nintendo Wii running.
>
>
> --
> Greetings, Michael.
>
^ permalink raw reply
* [IW] don't emit usage to stderr
From: Holger Schurig @ 2009-08-24 9:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
Only write error output to stderr, not help und usage information.
This allows now
./iw | less
Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
Index: iw/iw.c
===================================================================
--- iw.orig/iw.c 2009-08-24 10:00:08.000000000 +0200
+++ iw/iw.c 2009-08-24 10:01:08.000000000 +0200
@@ -103,24 +103,24 @@ static void __usage_cmd(struct cmd *cmd,
{
const char *start, *lend, *end;
- fprintf(stderr, "%s", indent);
+ printf("%s", indent);
switch (cmd->idby) {
case CIB_NONE:
break;
case CIB_PHY:
- fprintf(stderr, "phy <phyname> ");
+ printf("phy <phyname> ");
break;
case CIB_NETDEV:
- fprintf(stderr, "dev <devname> ");
+ printf("dev <devname> ");
break;
}
if (cmd->section)
- fprintf(stderr, "%s ", cmd->section);
- fprintf(stderr, "%s", cmd->name);
+ printf("%s ", cmd->section);
+ printf("%s", cmd->name);
if (cmd->args)
- fprintf(stderr, " %s", cmd->args);
- fprintf(stderr, "\n");
+ printf(" %s", cmd->args);
+ printf("\n");
if (!full || !cmd->help)
return;
@@ -129,7 +129,7 @@ static void __usage_cmd(struct cmd *cmd,
if (strlen(indent))
indent = "\t\t";
else
- fprintf(stderr, "\n");
+ printf("\n");
/* print line by line */
start = cmd->help;
@@ -138,18 +138,18 @@ static void __usage_cmd(struct cmd *cmd,
lend = strchr(start, '\n');
if (!lend)
lend = end;
- fprintf(stderr, "%s", indent);
- fprintf(stderr, "%.*s\n", (int)(lend - start), start);
+ printf("%s", indent);
+ printf("%.*s\n", (int)(lend - start), start);
start = lend + 1;
} while (end != lend);
- fprintf(stderr, "\n");
+ printf("\n");
}
static void usage_options(void)
{
- fprintf(stderr, "Options:\n");
- fprintf(stderr, "\t--debug\t\tenable netlink debugging\n");
+ printf("Options:\n");
+ printf("\t--debug\t\tenable netlink debugging\n");
}
static const char *argv0;
@@ -158,17 +158,17 @@ static void usage(bool full)
{
struct cmd *cmd;
- fprintf(stderr, "Usage:\t%s [options] command\n", argv0);
+ printf("Usage:\t%s [options] command\n", argv0);
usage_options();
- fprintf(stderr, "\t--version\tshow version (%s)\n", iw_version);
- fprintf(stderr, "Commands:\n");
+ printf("\t--version\tshow version (%s)\n", iw_version);
+ printf("Commands:\n");
for (cmd = &__start___cmd; cmd < &__stop___cmd;
cmd = (struct cmd *)((char *)cmd + cmd_size)) {
if (!cmd->handler || cmd->hidden)
continue;
__usage_cmd(cmd, "\t", full);
}
- fprintf(stderr, "\nYou can omit the 'phy' or 'dev' if "
+ printf("\nYou can omit the 'phy' or 'dev' if "
"the identification is unique,\n"
"e.g. \"iw wlan0 info\" or \"iw phy0 info\". "
"(Don't when scripting.)\n\n"
@@ -188,7 +188,7 @@ TOPLEVEL(help, NULL, 0, 0, CIB_NONE, pri
static void usage_cmd(struct cmd *cmd)
{
- fprintf(stderr, "Usage:\t%s [options] ", argv0);
+ printf("Usage:\t%s [options] ", argv0);
__usage_cmd(cmd, "", true);
usage_options();
}
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: Michael Buesch @ 2009-08-24 9:08 UTC (permalink / raw)
To: feng tian; +Cc: Johannes Berg, Larry Finger, linux-wireless
In-Reply-To: <f42a38140908232303j320f858cw5c0e45cc98a1e440@mail.gmail.com>
On Monday 24 August 2009 08:03:12 feng tian wrote:
> >>> 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.
They are not ready for public review, yet. We're working on merging them mainline.
But it does basically work and we (Albert Herranz) got the SDIO chip on the Nintendo Wii running.
--
Greetings, Michael.
^ permalink raw reply
* Re: Implementing wireless testbed on Linux
From: Holger Schurig @ 2009-08-24 8:18 UTC (permalink / raw)
To: Jinsung Lee; +Cc: linux-wireless
In-Reply-To: <029301ca2239$0ac9ad70$205d0850$@kaist.ac.kr>
> In the case of using 802.11n chipset, which card and device
> driver should I choose? At the same time, which version of
> Linux kernel should be appropriate?
I'd go with Atheros based PCI cards. The cards are good, and the
support is outstanding (Atheros people work together with Linux
community on this mailing list!).
> Is there any difference between pci and usb interfaces?
Sure. Please read http://www.pcisig.com/specifications and
http://www.usb.org/developers/docs/. The busses are VERY
different in case of hierarchy, latency, max transfer rates and
so on.
I fear, however, that this mailing list isn't the right channel
to transfer this knowledge.
> Definitely, all device and software should be stable and
> up-to-date.
That's a contradicion. Especially wireless is quite evolving in
the Linux kernel.
There's the possibility that you use a vendor-kernel (e.g. Debian
kernel, Fedora kernel, or whatever distro you use). I personally
won't do this, but I'd use a more "vanilla" kernel. The vendors
usually put a huge amount on patches into their kernels, that
will make results not as easy to compare. Also, if you have a
specific questions, chances are way higher that the people in
the mailing list know about the "vanilla" kernel or
wireless-testing kernel than some random vendor kernel.
If you absolutely need something stable, you should go with the
least recent stable linux kernel (see http://www.kernel.org/).
If you want to be more up-to-date, you should use
wireless-testing. Expect new functionality, fixed bugs, but also
new bugs there :-) However, If you ever have to change some
driver code, you definitely want wireless-testing. You cannot
(usually) use the source from the stable kernel when submitting
patches. More info at
http://wireless.kernel.org/en/developers/Documentation
^ permalink raw reply
* WARNING: at include/net/mac80211.h:2104 minstrel_get_rate
From: Arnd Hannemann @ 2009-08-24 8:08 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Hi,
I managed to trigger the following warning (for the first time)
on 2.6.31-rc6. Never seen this in rc3,4,5 but maybe I was
just lucky this time.
[854748.332641] wlan0: associated
[854756.240475] ------------[ cut here ]------------
[854756.254840] WARNING: at include/net/mac80211.h:2104 minstrel_get_rate+0x78/0x48a [mac80211]()
[854756.280793] Modules linked in: xt_state ipt_MASQUERADE aes_generic ipt_LOG iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 arc4 ecb ath5k mac80211 ehci_hcd ath ohci_hcd
[854756.331887] Pid: 2554, comm: wpa_supplicant Not tainted 2.6.31-rc6-ah0 #8
[854756.352601] Call Trace:
[854756.360408] [<d08873e0>] ? minstrel_get_rate+0x78/0x48a [mac80211]
[854756.379597] [<c1012746>] warn_slowpath_common+0x60/0x77
[854756.395887] [<c101276a>] warn_slowpath_null+0xd/0x10
[854756.411487] [<d08873e0>] minstrel_get_rate+0x78/0x48a [mac80211]
[854756.430129] [<c113b665>] ? vsnprintf+0xceb/0xd62
[854756.444692] [<d087ba06>] rate_control_get_rate+0x82/0xc9 [mac80211]
[854756.464190] [<d0880fd3>] invoke_tx_handlers+0x4f9/0xb37 [mac80211]
[854756.483347] [<c1058d12>] ? pollwake+0x0/0x59
[854756.496872] [<d0880849>] ? __ieee80211_tx_prepare+0x2a5/0x2fc [mac80211]
[854756.517656] [<d08819da>] ieee80211_tx+0xa9/0x199 [mac80211]
[854756.535056] [<d08820b6>] ieee80211_master_start_xmit+0x280/0x290 [mac80211]
[854756.556562] [<c119f641>] dev_hard_start_xmit+0x1c2/0x24a
[854756.573136] [<c11acf67>] __qdisc_run+0xb4/0x172
[854756.587352] [<c11a1c79>] dev_queue_xmit+0x1b9/0x2a8
[854756.602611] [<c124d7c3>] ? nl80211_send_deauth+0xd/0x11
[854756.618976] [<d0883582>] ieee80211_tx_skb+0x4e/0x51 [mac80211]
[854756.637185] [<d0877739>] ieee80211_send_deauth_disassoc+0xfc/0x104 [mac80211]
[854756.659283] [<d087788a>] ieee80211_set_disassoc+0xf5/0x1f9 [mac80211]
[854756.679303] [<d087a571>] ieee80211_sta_req_auth+0x5b/0x9a [mac80211]
[854756.699039] [<d0872a51>] ieee80211_ioctl_siwfreq+0x10b/0x13e [mac80211]
[854756.719498] [<c1247209>] ioctl_standard_call+0x4b/0x26c
[854756.735791] [<c1259159>] ? __mutex_lock_slowpath+0x17e/0x186
[854756.753398] [<c1246f57>] wext_handle_ioctl+0xe2/0x179
[854756.769228] [<d0872946>] ? ieee80211_ioctl_siwfreq+0x0/0x13e [mac80211]
[854756.789710] [<c11a0e76>] dev_ioctl+0x554/0x57e
[854756.803693] [<c11947d2>] ? sys_sendto+0xa1/0xc0
[854756.817911] [<c1194f45>] ? sys_recvfrom+0x96/0xb7
[854756.832652] [<c122882a>] ? packet_bind+0x50/0x66
[854756.847117] [<c11954b8>] ? sock_ioctl+0x0/0x1ee
[854756.861333] [<c119569a>] sock_ioctl+0x1e2/0x1ee
[854756.875555] [<c11954b8>] ? sock_ioctl+0x0/0x1ee
[854756.889781] [<c1056e99>] vfs_ioctl+0x19/0x50
[854756.903235] [<c10576eb>] do_vfs_ioctl+0x446/0x47a
[854756.917974] [<c1194809>] ? sys_send+0x18/0x1a
[854756.931677] [<c1195280>] ? sys_socketcall+0xbb/0x165
[854756.947179] [<c105774b>] sys_ioctl+0x2c/0x45
[854756.960605] [<c1002715>] syscall_call+0x7/0xb
[854756.974302] ---[ end trace cd3397cce4cc2497 ]---
[854764.311238] wlan0: authenticate with AP XX:XX:XX:XX:XX:XX
Best regards,
Arnd
^ permalink raw reply
* Re: [PATCH 2/2] wl1271: remove print_mac usage
From: Luciano Coelho @ 2009-08-24 8:08 UTC (permalink / raw)
To: ext John W. Linville; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1250607301-24944-1-git-send-email-linville@tuxdriver.com>
ext John W. Linville wrote:
> CC [M] drivers/net/wireless/wl12xx/wl1271_main.o
> drivers/net/wireless/wl12xx/wl1271_main.c: In function ‘wl1271_op_add_interface’:
> drivers/net/wireless/wl12xx/wl1271_main.c:611: warning: ‘print_mac’ is deprecated (declared at include/linux/if_ether.h:142)
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
>
Thanks John.
Acked-by: Luciano Coelho <luciano.coelho@nokia.com>
--
Cheers,
Luca.
^ permalink raw reply
* 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
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