* Re: Path for fixed channel issue in aircrack-ng suite [V2]
From: Richard Farina @ 2010-06-01 18:36 UTC (permalink / raw)
To: Maxim Levitsky
Cc: Johannes Berg, Gábor Stefanik, Joker Joker, linux-wireless,
mister_x
In-Reply-To: <1275416907.3778.11.camel@maxim-laptop>
Maxim Levitsky wrote:
> While debugging recent wireless problems, I gave the aircrack suite a
> shot, and found this thread.
>
>
Thanks Maxim!
> How about this patch to fix this issue:
>
>
I will definitely find some testers, the problem is that I have been
unable to reliably reproduce the "channel -1". Since I don't know the
exact conditions this happens under the best I can do is have a few
people test it and make sure no one sees the error.
Mister_X, how does this look to you? I assume you are familiar with the
issue.
Thanks,
Rick Farina
> commit fffd6e63ea75850dafbf2ccfb38a4189f43c0282
> Author: Maxim Levitsky <maximlevitsky@gmail.com>
> Date: Tue Jun 1 15:43:21 2010 +0300
>
> wireless: allow to retrieve the channel set on monitor interface
>
> This will allow to preserve compatibility with userspace
>
> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
>
> diff --git a/net/wireless/chan.c b/net/wireless/chan.c
> index b01a6f6..09d979b 100644
> --- a/net/wireless/chan.c
> +++ b/net/wireless/chan.c
> @@ -49,9 +49,12 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
> {
> struct ieee80211_channel *chan;
> int result;
> + struct wireless_dev *mon_dev = NULL;
>
> - if (wdev && wdev->iftype == NL80211_IFTYPE_MONITOR)
> + if (wdev && wdev->iftype == NL80211_IFTYPE_MONITOR) {
> + mon_dev = wdev;
> wdev = NULL;
> + }
>
> if (wdev) {
> ASSERT_WDEV_LOCK(wdev);
> @@ -76,5 +79,8 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
> if (wdev)
> wdev->channel = chan;
>
> + if (mon_dev)
> + mon_dev->channel = chan;
> +
> return 0;
> }
>
>
>
>
^ permalink raw reply
* Re: IWL3945 problems in 2.6.35-rc1
From: Abhijeet Kolekar @ 2010-06-01 19:03 UTC (permalink / raw)
To: sedat.dilek@gmail.com; +Cc: Maxim Levitsky, linux-wireless, iwlwifi maling list
In-Reply-To: <AANLkTinmjlukRABwWWVuO6VRHrULcqB7Zk_HQZSDicKr@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 9385 bytes --]
Hello,
Please check the following version of the patch.
Abhijeet
On Tue, 2010-06-01 at 08:21 -0700, Sedat Dilek wrote:
> Hi Maxim,
>
> that's a known issue... and there were several mails to LKML and here
> on the ML (as I see you are very active on both lists :-)).
> Unfortunately, the patch in [1] didnt go into any (GIT) reposoitory. I know.
>
> I am attaching the original patch and give it a meaningfull name, so
> people see it on patchwork.kernel.org (linux-wireless).
>
> Kind Regards,
> - Sedat -
>
> [1] http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2208
>
> On Tue, Jun 1, 2010 at 4:57 PM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> > On Tue, 2010-06-01 at 15:25 +0300, Maxim Levitsky wrote:
> >> Hi,
> >>
> >> in 2.6.35-rc1 the wireless became just unusable.
> >>
> >> These are problems that I have:
> >>
> >> 1. very frequent oopses.This appears to be mention on the list already,
> >> but patches I tried don't help.
> >>
> >> I currently use this bandaid patch, and I still get some crashes:
> >
> >
> > The crash happens here:
> >
> > 0xec3d is in iwl3945_request_scan (/home/maxim/software/kernel/linux-2.6/drivers/net/wireless/iwlwifi/iwl3945-base.c:1878).
> > 1873 if (chan->band != band)
> > 1874 continue;
> > 1875
> > 1876 scan_ch->channel = chan->hw_value;
> > 1877
> > 1878 ch_info = iwl_get_channel_info(priv, band, scan_ch->channel);
> > 1879 if (!is_channel_valid(ch_info)) {
> > 1880 IWL_DEBUG_SCAN(priv, "Channel %d is INVALID for this band.\n",
> > 1881 scan_ch->channel);
> > 1882 continue;
> >
> >
> > The backtrace:
> >
> > <1>[14212.708840] BUG: unable to handle kernel paging request at 00000002ffffffb1
> > <1>[14212.709870] IP: [<ffffffffa0305c0d>] iwl3945_request_scan+0x61d/0xf90 [iwl3945]
> > <4>[14212.710763] PGD 0
> > <0>[14212.711636] Oops: 0000 [#1] PREEMPT SMP
> > <0>[14212.712519] last sysfs file: /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/hwmon/hwmon1/temp1_input
> > <4>[14212.713416] CPU 0
> > <4>[14212.713432] Modules linked in: tg3 libphy iwl3945 iwlcore mac80211 cfg80211 ntfs vfat msdos fat lirc_ene0100 lirc_dev af_packet nfsd exportfs nfs lockd nfs_acl auth_rpcgss usb_storage usb_libusual cpufreq_powersave cpufreq_conservative r852 snd_hda_codec_realtek uvcvideo sm_common cpufreq_userspace acpi_cpufreq snd_hda_intel videodev mperf nand snd_hda_codec nand_ids sdhci_pci iTCO_wdt v4l2_compat_ioctl32 joydev snd_hwdep nand_ecc uhci_hcd sunrpc iTCO_vendor_support sdhci ehci_hcd psmouse snd_pcm mmc_core mtd usbcore coretemp ac sg battery evdev serio_raw snd_page_alloc video nouveau ttm drm_kms_helper drm i2c_algo_bit [last unloaded: cfg80211]
> > <4>[14212.718797]
> > <4>[14212.718797] Pid: 4263, comm: iwl3945 Not tainted 2.6.35-rc1 #30 Nettiling/Aspire 5720
> > <4>[14212.718797] RIP: 0010:[<ffffffffa0305c0d>] [<ffffffffa0305c0d>] iwl3945_request_scan+0x61d/0xf90 [iwl3945]
> > <4>[14212.718797] RSP: 0018:ffff88006ce91c80 EFLAGS: 00010297
> > <4>[14212.718797] RAX: ffff880066e74100 RBX: ffff88001b2c1dc0 RCX: 00000002ffffffb1
> > <4>[14212.718797] RDX: 0000000000000000 RSI: 00000000ffff8800 RDI: ffff88001b2c1dc0
> > <4>[14212.718797] RBP: ffff88006ce91d70 R08: 000000000000030e R09: 00000000ffffffff
> > <4>[14212.718797] R10: 0000000000000058 R11: 0000000000000001 R12: 0000000000000000
> > <4>[14212.718797] R13: ffff88001b295800 R14: 0000000000000000 R15: ffff88001b2958f2
> > <4>[14212.718797] FS: 0000000000000000(0000) GS:ffff880002400000(0000) knlGS:0000000000000000
> > <4>[14212.718797] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > <4>[14212.718797] CR2: 00000002ffffffb1 CR3: 000000000155b000 CR4: 00000000000006f0
> > <4>[14212.718797] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > <4>[14212.718797] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > <4>[14212.718797] Process iwl3945 (pid: 4263, threadinfo ffff88006ce90000, task ffff88006d04a280)
> > <0>[14212.718797] Stack:
> > <4>[14212.718797] ffffffffa02c3810 ffff88006d04a2f0 ffff88006ce91cb0 ffffffff81036911
> > <4>[14212.718797] <0> 0000000000000000 0000000000000001 ffff88006ce91cd0 ffffffff00000000
> > <4>[14212.718797] <0> 0057000000000246 0000005800000021 ffff88006ce91fd8 0058ffff813a07bf
> > <0>[14212.718797] Call Trace:
> > <4>[14212.718797] [<ffffffffa02c3810>] ? iwl_bg_start_internal_scan+0x0/0x3d0 [iwlcore]
> > <4>[14212.718797] [<ffffffff81036911>] ? get_parent_ip+0x11/0x50
> > <4>[14212.718797] [<ffffffffa02c3810>] ? iwl_bg_start_internal_scan+0x0/0x3d0 [iwlcore]
> > <4>[14212.718797] [<ffffffffa02c3b2a>] iwl_bg_start_internal_scan+0x31a/0x3d0 [iwlcore]
> > <4>[14212.718797] [<ffffffff81056dfe>] ? worker_thread+0x1ce/0x390
> > <4>[14212.718797] [<ffffffff81056e50>] worker_thread+0x220/0x390
> > <4>[14212.718797] [<ffffffff81056dfe>] ? worker_thread+0x1ce/0x390
> > <4>[14212.718797] [<ffffffff8105bc80>] ? autoremove_wake_function+0x0/0x40
> > <4>[14212.718797] [<ffffffff81056c30>] ? worker_thread+0x0/0x390
> > <4>[14212.718797] [<ffffffff8105b7fe>] kthread+0xae/0xc0
> > <4>[14212.718797] [<ffffffff81003b94>] kernel_thread_helper+0x4/0x10
> > <4>[14212.718797] [<ffffffff8105b750>] ? kthread+0x0/0xc0
> > <4>[14212.718797] [<ffffffff81003b90>] ? kernel_thread_helper+0x0/0x10
> > <0>[14212.718797] Code: ff ff 41 8d 52 ff 66 89 95 56 ff ff ff eb 14 0f 1f 80 00 00 00 00 41 ff c4 44 3b 60 0c 0f 83 eb 00 00 00 49 63 d4 48 8b 4c d0 38 <44> 3b 31 75 e6 0f b7 41 06 44 89 f6 41 88 47 01 0f b6 d0 48 89
> > <1>[14212.718797] RIP [<ffffffffa0305c0d>] iwl3945_request_scan+0x61d/0xf90 [iwl3945]
> > <4>[14212.718797] RSP <ffff88006ce91c80>
> > <0>[14212.718797] CR2: 00000002ffffffb1
> > <4>[14212.760163] ---[ end trace 7075fd19298c88a3 ]---
> > <0>[14212.761267] Kernel panic - not syncing: Fatal exception
> > <4>[14212.762226] Pid: 4263, comm: iwl3945 Tainted: G D 2.6.35-rc1 #30
> > <4>[14212.763193] Call Trace:
> > <4>[14212.764143] [<ffffffff8139e487>] panic+0x90/0x10a
> > <4>[14212.765084] [<ffffffff8100737c>] oops_end+0xcc/0xe0
> > <4>[14212.765095] [<ffffffff81027c13>] no_context+0xf3/0x260
> > <4>[14212.765106] [<ffffffff810622e5>] ? sched_clock_local+0x25/0x90
> > <4>[14212.765116] [<ffffffff81027e95>] __bad_area_nosemaphore+0x115/0x1d0
> > <4>[14212.765128] [<ffffffff81027f5e>] bad_area_nosemaphore+0xe/0x10
> > <4>[14212.765138] [<ffffffff810283c6>] do_page_fault+0x2e6/0x390
> > <4>[14212.765148] [<ffffffff810622e5>] ? sched_clock_local+0x25/0x90
> > <4>[14212.765158] [<ffffffff81062410>] ? sched_clock_cpu+0xc0/0x110
> > <4>[14212.765169] [<ffffffff8100add7>] ? native_sched_clock+0x27/0x80
> > <4>[14212.765179] [<ffffffff810622e5>] ? sched_clock_local+0x25/0x90
> > <4>[14212.765191] [<ffffffff813a309f>] page_fault+0x1f/0x30
> > <4>[14212.765207] [<ffffffffa0305c0d>] ? iwl3945_request_scan+0x61d/0xf90 [iwl3945]
> > <4>[14212.765232] [<ffffffffa02c3810>] ? iwl_bg_start_internal_scan+0x0/0x3d0 [iwlcore]
> > <4>[14212.765246] [<ffffffff81036911>] ? get_parent_ip+0x11/0x50
> > <4>[14212.765266] [<ffffffffa02c3810>] ? iwl_bg_start_internal_scan+0x0/0x3d0 [iwlcore]
> > <4>[14212.765286] [<ffffffffa02c3b2a>] iwl_bg_start_internal_scan+0x31a/0x3d0 [iwlcore]
> > <4>[14212.765299] [<ffffffff81056dfe>] ? worker_thread+0x1ce/0x390
> > <4>[14212.765310] [<ffffffff81056e50>] worker_thread+0x220/0x390
> > <4>[14212.765320] [<ffffffff81056dfe>] ? worker_thread+0x1ce/0x390
> > <4>[14212.765333] [<ffffffff8105bc80>] ? autoremove_wake_function+0x0/0x40
> > <4>[14212.765344] [<ffffffff81056c30>] ? worker_thread+0x0/0x390
> > <4>[14212.765353] [<ffffffff8105b7fe>] kthread+0xae/0xc0
> > <4>[14212.765365] [<ffffffff81003b94>] kernel_thread_helper+0x4/0x10
> > <4>[14212.765376] [<ffffffff8105b750>] ? kthread+0x0/0xc0
> > <4>[14212.765386] [<ffffffff81003b90>] ? kernel_thread_helper+0x0/0x10
> > <3>[14212.765402] [drm:drm_fb_helper_panic] *ERROR* panic occurred, switching back to text console
> >>
> >> diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> >> index 3e5bffb..1aef988 100644
> >> --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
> >> +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> >> @@ -1861,6 +1861,11 @@ static int iwl3945_get_channels_for_scan(struct iwl_priv *priv,
> >> if (!sband)
> >> return 0;
> >>
> >> + if(!priv->scan_request) {
> >> + WARN_ON(1);
> >> + return 0;
> >> + }
> >> +
> >> active_dwell = iwl_get_active_dwell_time(priv, band, n_probes);
> >> passive_dwell = iwl_get_passive_dwell_time(priv, band, vif);
> >>
> >>
> >> 2. mulicast/broadcast is broken.
> >> this results in DHCP non working on open access point.
> >> It seems that DHCP does work on my home wireless, but avahi-autoipd doesn't see any neighbours, and this is annoying.
> >> It can be worked around by doing (sudo ifconfig wlan0 promisc)
> >>
> >>
> > Best regards,
> > Maxim Levitsky
> >
> > --
> > 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
> >
[-- Attachment #2: 0001-iwl3945-fix-internal-scan.patch --]
[-- Type: text/x-patch, Size: 7288 bytes --]
>From 9b6e4d25dd20941d20dae102096c4b2fb7626af6 Mon Sep 17 00:00:00 2001
From: Abhijeet Kolekar <abhijeet.kolekar@intel.com>
Date: Wed, 26 May 2010 10:49:22 -0700
Subject: [PATCH V2] iwl3945: fix internal scan
Port of internal scan to iwl3945 missed introduction
of iwl3945_get_single_channel_for_scan.
Fix the following bug by introducing the iwl3945_get_single_channel_for_scan
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2208
Signed-off-by: Abhijeet Kolekar <abhijeet.kolekar@intel.com>
---
v2: rearrange code. Put duplicate code in single function.
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 30 +-------------
drivers/net/wireless/iwlwifi/iwl-core.c | 39 ++++++++++++++++++
drivers/net/wireless/iwlwifi/iwl-core.h | 2 +
drivers/net/wireless/iwlwifi/iwl3945-base.c | 56 +++++++++++++++++++++++++-
4 files changed, 96 insertions(+), 31 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
index 1176a64..c7d5251 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
@@ -992,10 +992,9 @@ static int iwl_get_single_channel_for_scan(struct iwl_priv *priv,
struct iwl_scan_channel *scan_ch)
{
const struct ieee80211_supported_band *sband;
- const struct iwl_channel_info *ch_info;
u16 passive_dwell = 0;
u16 active_dwell = 0;
- int i, added = 0;
+ int added = 0;
u16 channel = 0;
sband = iwl_get_hw_mode(priv, band);
@@ -1010,32 +1009,7 @@ static int iwl_get_single_channel_for_scan(struct iwl_priv *priv,
if (passive_dwell <= active_dwell)
passive_dwell = active_dwell + 1;
- /* only scan single channel, good enough to reset the RF */
- /* pick the first valid not in-use channel */
- if (band == IEEE80211_BAND_5GHZ) {
- for (i = 14; i < priv->channel_count; i++) {
- if (priv->channel_info[i].channel !=
- le16_to_cpu(priv->staging_rxon.channel)) {
- channel = priv->channel_info[i].channel;
- ch_info = iwl_get_channel_info(priv,
- band, channel);
- if (is_channel_valid(ch_info))
- break;
- }
- }
- } else {
- for (i = 0; i < 14; i++) {
- if (priv->channel_info[i].channel !=
- le16_to_cpu(priv->staging_rxon.channel)) {
- channel =
- priv->channel_info[i].channel;
- ch_info = iwl_get_channel_info(priv,
- band, channel);
- if (is_channel_valid(ch_info))
- break;
- }
- }
- }
+ channel = iwl_get_single_channel_number(priv, band);
if (channel) {
scan_ch->channel = cpu_to_le16(channel);
scan_ch->type = SCAN_CHANNEL_TYPE_PASSIVE;
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index 9d4010e..0dc8b9c 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -856,6 +856,45 @@ void iwl_set_rxon_chain(struct iwl_priv *priv)
}
EXPORT_SYMBOL(iwl_set_rxon_chain);
+/* Return valid channel */
+u16 iwl_get_single_channel_number(struct iwl_priv *priv,
+ enum ieee80211_band band)
+{
+ const struct iwl_channel_info *ch_info;
+ int i;
+ u16 channel = 0;
+
+ /* only scan single channel, good enough to reset the RF */
+ /* pick the first valid not in-use channel */
+ if (band == IEEE80211_BAND_5GHZ) {
+ for (i = 14; i < priv->channel_count; i++) {
+ if (priv->channel_info[i].channel !=
+ le16_to_cpu(priv->staging_rxon.channel)) {
+ channel = priv->channel_info[i].channel;
+ ch_info = iwl_get_channel_info(priv,
+ band, channel);
+ if (is_channel_valid(ch_info))
+ break;
+ }
+ }
+ } else {
+ for (i = 0; i < 14; i++) {
+ if (priv->channel_info[i].channel !=
+ le16_to_cpu(priv->staging_rxon.channel)) {
+ channel =
+ priv->channel_info[i].channel;
+ ch_info = iwl_get_channel_info(priv,
+ band, channel);
+ if (is_channel_valid(ch_info))
+ break;
+ }
+ }
+ }
+
+ return channel;
+}
+EXPORT_SYMBOL(iwl_get_single_channel_number);
+
/**
* iwl_set_rxon_channel - Set the phymode and channel values in staging RXON
* @phymode: MODE_IEEE80211A sets to 5.2GHz; all else set to 2.4GHz
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.h b/drivers/net/wireless/iwlwifi/iwl-core.h
index 87dd573..007e104 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.h
+++ b/drivers/net/wireless/iwlwifi/iwl-core.h
@@ -347,6 +347,8 @@ int iwl_check_rxon_cmd(struct iwl_priv *priv);
int iwl_full_rxon_required(struct iwl_priv *priv);
void iwl_set_rxon_chain(struct iwl_priv *priv);
int iwl_set_rxon_channel(struct iwl_priv *priv, struct ieee80211_channel *ch);
+u16 iwl_get_single_channel_number(struct iwl_priv *priv,
+ enum ieee80211_band band);
void iwl_set_flags_for_band(struct iwl_priv *priv,
enum ieee80211_band band,
struct ieee80211_vif *vif);
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 71aebbb..67ebda5 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -1783,6 +1783,49 @@ static void iwl3945_irq_tasklet(struct iwl_priv *priv)
#endif
}
+static int iwl3945_get_single_channel_for_scan(struct iwl_priv *priv,
+ struct ieee80211_vif *vif,
+ enum ieee80211_band band,
+ struct iwl3945_scan_channel *scan_ch)
+{
+ const struct ieee80211_supported_band *sband;
+ u16 passive_dwell = 0;
+ u16 active_dwell = 0;
+ int added = 0;
+ u16 channel = 0;
+
+ sband = iwl_get_hw_mode(priv, band);
+ if (!sband) {
+ IWL_ERR(priv, "invalid band\n");
+ return added;
+ }
+
+ active_dwell = iwl_get_active_dwell_time(priv, band, 0);
+ passive_dwell = iwl_get_passive_dwell_time(priv, band, vif);
+
+ if (passive_dwell <= active_dwell)
+ passive_dwell = active_dwell + 1;
+
+
+ channel = iwl_get_single_channel_number(priv, band);
+
+ if (channel) {
+ scan_ch->channel = cpu_to_le16(channel);
+ scan_ch->type = SCAN_CHANNEL_TYPE_PASSIVE;
+ scan_ch->active_dwell = cpu_to_le16(active_dwell);
+ scan_ch->passive_dwell = cpu_to_le16(passive_dwell);
+ /* Set txpower levels to defaults */
+ scan_ch->tpc.dsp_atten = 110;
+ if (band == IEEE80211_BAND_5GHZ)
+ scan_ch->tpc.tx_gain = ((1 << 5) | (3 << 3)) | 3;
+ else
+ scan_ch->tpc.tx_gain = ((1 << 5) | (5 << 3));
+ added++;
+ } else
+ IWL_ERR(priv, "no valid channel found\n");
+ return added;
+}
+
static int iwl3945_get_channels_for_scan(struct iwl_priv *priv,
enum ieee80211_band band,
u8 is_active, u8 n_probes,
@@ -2933,9 +2976,16 @@ void iwl3945_request_scan(struct iwl_priv *priv, struct ieee80211_vif *vif)
/* select Rx antennas */
scan->flags |= iwl3945_get_antenna_flags(priv);
- scan->channel_count =
- iwl3945_get_channels_for_scan(priv, band, is_active, n_probes,
- (void *)&scan->data[le16_to_cpu(scan->tx_cmd.len)], vif);
+ if (priv->is_internal_short_scan) {
+ scan->channel_count =
+ iwl3945_get_single_channel_for_scan(priv, vif, band,
+ (void *)&scan->data[le16_to_cpu(
+ scan->tx_cmd.len)]);
+ } else {
+ scan->channel_count =
+ iwl3945_get_channels_for_scan(priv, band, is_active, n_probes,
+ (void *)&scan->data[le16_to_cpu(scan->tx_cmd.len)], vif);
+ }
if (scan->channel_count == 0) {
IWL_DEBUG_SCAN(priv, "channel count %d\n", scan->channel_count);
--
1.6.3.3
^ permalink raw reply related
* Re: Path for fixed channel issue in aircrack-ng suite [V2]
From: Johannes Berg @ 2010-06-01 19:19 UTC (permalink / raw)
To: Maxim Levitsky
Cc: Richard Farina, Gábor Stefanik, Joker Joker, linux-wireless
In-Reply-To: <1275416907.3778.11.camel@maxim-laptop>
On Tue, 2010-06-01 at 21:28 +0300, Maxim Levitsky wrote:
> wireless: allow to retrieve the channel set on monitor interface
>
> This will allow to preserve compatibility with userspace
>
> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
>
> diff --git a/net/wireless/chan.c b/net/wireless/chan.c
> index b01a6f6..09d979b 100644
> --- a/net/wireless/chan.c
> +++ b/net/wireless/chan.c
> @@ -49,9 +49,12 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
> {
> struct ieee80211_channel *chan;
> int result;
> + struct wireless_dev *mon_dev = NULL;
>
> - if (wdev && wdev->iftype == NL80211_IFTYPE_MONITOR)
> + if (wdev && wdev->iftype == NL80211_IFTYPE_MONITOR) {
> + mon_dev = wdev;
> wdev = NULL;
> + }
>
> if (wdev) {
> ASSERT_WDEV_LOCK(wdev);
> @@ -76,5 +79,8 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
> if (wdev)
> wdev->channel = chan;
>
> + if (mon_dev)
> + mon_dev->channel = chan;
> +
This won't quite work. monitor interfaces are always slaves in the sense
that their channel setting never takes precedence over anything, so if
you add another interface and do something there, the hardware will
happily channel switch away from the monitor channel, but it will still
report the old channel here that you set.
I have no idea how to _properly_ fix this though, since eventually we'll
have a situation where you can have multiple interfaces active on
different channels, so that monitors don't have a fixed channel anyway.
Maybe this patch is sufficient since it works in the case people care
about when they _only_ have a monitor interface, but I think it'd be
nicer if it wouldn't report anything in the other cases.
johannes
^ permalink raw reply
* [PATCH v2] ath9k: fix queue stop/start based on the number of pending frames
From: Felix Fietkau @ 2010-06-01 19:33 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville, Luis R. Rodriguez
Because there is a limited number of tx buffers available, once the
queue has been filled to a certain point, ath9k needs to stop accepting
new frames from mac80211. In order to prevent a full WMM queue from
stopping another queue with fewer frames, this patch limits the number
of queued frames to a quarter of the total available tx buffers, minus
some reserved frames to be used for other purposes (e.g. beacons).
Because tx buffers are reserved for frames when they're staged in
software queues as well, the actual queue depth cannot be used for
this, so this patch stores a reference to the tx queue in the ath_buf
struct and keeps track of the total number of pending frames.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
v2: ath_wake_mac80211_queue() needs to be fixed as well (thanks, vasanth)
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -137,6 +137,8 @@ void ath_descdma_cleanup(struct ath_soft
#define ATH_MAX_ANTENNA 3
#define ATH_RXBUF 512
#define ATH_TXBUF 512
+#define ATH_TXBUF_RESERVE 5
+#define ATH_MAX_QDEPTH (ATH_TXBUF / 4 - ATH_TXBUF_RESERVE)
#define ATH_TXMAXTRY 13
#define ATH_MGT_TXMAXTRY 4
@@ -205,6 +207,7 @@ struct ath_txq {
struct list_head txq_fifo_pending;
u8 txq_headidx;
u8 txq_tailidx;
+ int pending_frames;
};
struct ath_atx_ac {
@@ -242,6 +245,7 @@ struct ath_buf {
struct ath_buf_state bf_state;
dma_addr_t bf_dmacontext;
struct ath_wiphy *aphy;
+ struct ath_txq *txq;
};
struct ath_atx_tid {
@@ -331,7 +335,6 @@ void ath_tx_node_cleanup(struct ath_soft
void ath_txq_schedule(struct ath_softc *sc, struct ath_txq *txq);
int ath_tx_init(struct ath_softc *sc, int nbufs);
void ath_tx_cleanup(struct ath_softc *sc);
-struct ath_txq *ath_test_get_txq(struct ath_softc *sc, struct sk_buff *skb);
int ath_txq_update(struct ath_softc *sc, int qnum,
struct ath9k_tx_queue_info *q);
int ath_tx_start(struct ieee80211_hw *hw, struct sk_buff *skb,
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -986,32 +986,6 @@ int ath_tx_get_qnum(struct ath_softc *sc
return qnum;
}
-struct ath_txq *ath_test_get_txq(struct ath_softc *sc, struct sk_buff *skb)
-{
- struct ath_txq *txq = NULL;
- u16 skb_queue = skb_get_queue_mapping(skb);
- int qnum;
-
- qnum = ath_get_hal_qnum(skb_queue, sc);
- txq = &sc->tx.txq[qnum];
-
- spin_lock_bh(&txq->axq_lock);
-
- if (txq->axq_depth >= (ATH_TXBUF - 20)) {
- ath_print(ath9k_hw_common(sc->sc_ah), ATH_DBG_XMIT,
- "TX queue: %d is full, depth: %d\n",
- qnum, txq->axq_depth);
- ath_mac80211_stop_queue(sc, skb_queue);
- txq->stopped = 1;
- spin_unlock_bh(&txq->axq_lock);
- return NULL;
- }
-
- spin_unlock_bh(&txq->axq_lock);
-
- return txq;
-}
-
int ath_txq_update(struct ath_softc *sc, int qnum,
struct ath9k_tx_queue_info *qinfo)
{
@@ -1811,6 +1785,7 @@ int ath_tx_start(struct ieee80211_hw *hw
struct ath_wiphy *aphy = hw->priv;
struct ath_softc *sc = aphy->sc;
struct ath_common *common = ath9k_hw_common(sc->sc_ah);
+ struct ath_txq *txq = txctl->txq;
struct ath_buf *bf;
int r;
@@ -1820,10 +1795,16 @@ int ath_tx_start(struct ieee80211_hw *hw
return -1;
}
+ bf->txq = txctl->txq;
+ spin_lock_bh(&bf->txq->axq_lock);
+ if (++bf->txq->pending_frames > ATH_MAX_QDEPTH && !txq->stopped) {
+ ath_mac80211_stop_queue(sc, skb_get_queue_mapping(skb));
+ txq->stopped = 1;
+ }
+ spin_unlock_bh(&bf->txq->axq_lock);
+
r = ath_tx_setup_buffer(hw, bf, skb, txctl);
if (unlikely(r)) {
- struct ath_txq *txq = txctl->txq;
-
ath_print(common, ATH_DBG_FATAL, "TX mem alloc failure\n");
/* upon ath_tx_processq() this TX queue will be resumed, we
@@ -1831,7 +1812,7 @@ int ath_tx_start(struct ieee80211_hw *hw
* we will at least have to run TX completionon one buffer
* on the queue */
spin_lock_bh(&txq->axq_lock);
- if (sc->tx.txq[txq->axq_qnum].axq_depth > 1) {
+ if (!txq->stopped && txq->axq_depth > 1) {
ath_mac80211_stop_queue(sc, skb_get_queue_mapping(skb));
txq->stopped = 1;
}
@@ -1972,6 +1953,13 @@ static void ath_tx_complete_buf(struct a
tx_flags |= ATH_TX_XRETRY;
}
+ if (bf->txq) {
+ spin_lock_bh(&bf->txq->axq_lock);
+ bf->txq->pending_frames--;
+ spin_unlock_bh(&bf->txq->axq_lock);
+ bf->txq = NULL;
+ }
+
dma_unmap_single(sc->dev, bf->bf_dmacontext, skb->len, DMA_TO_DEVICE);
ath_tx_complete(sc, skb, bf->aphy, tx_flags);
ath_debug_stat_tx(sc, txq, bf, ts);
@@ -2060,8 +2048,7 @@ static void ath_wake_mac80211_queue(stru
int qnum;
spin_lock_bh(&txq->axq_lock);
- if (txq->stopped &&
- sc->tx.txq[txq->axq_qnum].axq_depth <= (ATH_TXBUF - 20)) {
+ if (txq->stopped && txq->pending_frames < ATH_MAX_QDEPTH) {
qnum = ath_get_mac80211_qnum(txq->axq_qnum, sc);
if (qnum != -1) {
ath_mac80211_start_queue(sc, qnum);
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1026,6 +1026,7 @@ static int ath9k_tx(struct ieee80211_hw
struct ath_tx_control txctl;
int padpos, padsize;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
+ int qnum;
if (aphy->state != ATH_WIPHY_ACTIVE && aphy->state != ATH_WIPHY_SCAN) {
ath_print(common, ATH_DBG_XMIT,
@@ -1098,11 +1099,8 @@ static int ath9k_tx(struct ieee80211_hw
memmove(skb->data, skb->data + padsize, padpos);
}
- /* Check if a tx queue is available */
-
- txctl.txq = ath_test_get_txq(sc, skb);
- if (!txctl.txq)
- goto exit;
+ qnum = ath_get_hal_qnum(skb_get_queue_mapping(skb), sc);
+ txctl.txq = &sc->tx.txq[qnum];
ath_print(common, ATH_DBG_XMIT, "transmitting packet, skb: %p\n", skb);
^ permalink raw reply
* Re: Path for fixed channel issue in aircrack-ng suite [V2]
From: Richard Farina @ 2010-06-01 19:50 UTC (permalink / raw)
To: Johannes Berg
Cc: Maxim Levitsky, Gábor Stefanik, Joker Joker, linux-wireless
In-Reply-To: <1275419973.3634.7.camel@jlt3.sipsolutions.net>
Johannes Berg wrote:
> On Tue, 2010-06-01 at 21:28 +0300, Maxim Levitsky wrote:
>
>
>> wireless: allow to retrieve the channel set on monitor interface
>>
>> This will allow to preserve compatibility with userspace
>>
>> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
>>
>> diff --git a/net/wireless/chan.c b/net/wireless/chan.c
>> index b01a6f6..09d979b 100644
>> --- a/net/wireless/chan.c
>> +++ b/net/wireless/chan.c
>> @@ -49,9 +49,12 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
>> {
>> struct ieee80211_channel *chan;
>> int result;
>> + struct wireless_dev *mon_dev = NULL;
>>
>> - if (wdev && wdev->iftype == NL80211_IFTYPE_MONITOR)
>> + if (wdev && wdev->iftype == NL80211_IFTYPE_MONITOR) {
>> + mon_dev = wdev;
>> wdev = NULL;
>> + }
>>
>> if (wdev) {
>> ASSERT_WDEV_LOCK(wdev);
>> @@ -76,5 +79,8 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
>> if (wdev)
>> wdev->channel = chan;
>>
>> + if (mon_dev)
>> + mon_dev->channel = chan;
>> +
>>
>
> This won't quite work. monitor interfaces are always slaves in the sense
> that their channel setting never takes precedence over anything, so if
> you add another interface and do something there, the hardware will
> happily channel switch away from the monitor channel, but it will still
> report the old channel here that you set.
>
> I have no idea how to _properly_ fix this though, since eventually we'll
> have a situation where you can have multiple interfaces active on
> different channels, so that monitors don't have a fixed channel anyway.
>
> Maybe this patch is sufficient since it works in the case people care
> about when they _only_ have a monitor interface, but I think it'd be
> nicer if it wouldn't report anything in the other cases.
>
>
Is this a NACK or a "I wish there was a better way to do this but I'll
allow it until a better way if found"?
-Rick
> johannes
>
>
>
^ permalink raw reply
* Re: Path for fixed channel issue in aircrack-ng suite [V2]
From: Maxim Levitsky @ 2010-06-01 19:53 UTC (permalink / raw)
To: Johannes Berg
Cc: Richard Farina, Gábor Stefanik, Joker Joker, linux-wireless
In-Reply-To: <1275419973.3634.7.camel@jlt3.sipsolutions.net>
On Tue, 2010-06-01 at 21:19 +0200, Johannes Berg wrote:
> On Tue, 2010-06-01 at 21:28 +0300, Maxim Levitsky wrote:
>
> > wireless: allow to retrieve the channel set on monitor interface
> >
> > This will allow to preserve compatibility with userspace
> >
> > Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
> >
> > diff --git a/net/wireless/chan.c b/net/wireless/chan.c
> > index b01a6f6..09d979b 100644
> > --- a/net/wireless/chan.c
> > +++ b/net/wireless/chan.c
> > @@ -49,9 +49,12 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
> > {
> > struct ieee80211_channel *chan;
> > int result;
> > + struct wireless_dev *mon_dev = NULL;
> >
> > - if (wdev && wdev->iftype == NL80211_IFTYPE_MONITOR)
> > + if (wdev && wdev->iftype == NL80211_IFTYPE_MONITOR) {
> > + mon_dev = wdev;
> > wdev = NULL;
> > + }
> >
> > if (wdev) {
> > ASSERT_WDEV_LOCK(wdev);
> > @@ -76,5 +79,8 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
> > if (wdev)
> > wdev->channel = chan;
> >
> > + if (mon_dev)
> > + mon_dev->channel = chan;
> > +
>
> This won't quite work. monitor interfaces are always slaves in the sense
> that their channel setting never takes precedence over anything, so if
> you add another interface and do something there, the hardware will
> happily channel switch away from the monitor channel, but it will still
> report the old channel here that you set.
>
> I have no idea how to _properly_ fix this though, since eventually we'll
> have a situation where you can have multiple interfaces active on
> different channels, so that monitors don't have a fixed channel anyway.
>
> Maybe this patch is sufficient since it works in the case people care
> about when they _only_ have a monitor interface, but I think it'd be
> nicer if it wouldn't report anything in the other cases.
Why?
We don't have any wireless devices that actually support using 2
channels independently.
Therefore user should be aware that if he sets channel on one interface,
and then on other, the last setting matters.
Of course the right fix would to make channel a global property of card
rather that of interface.
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: Association problems - again - comment
From: Jaroslav Fojtik @ 2010-06-01 19:29 UTC (permalink / raw)
To: Bob Copeland, linux-wireless; +Cc: johannes.berg
In-Reply-To: <AANLkTimRxjfvS_6cR7ZN3yim3TO9GcPwJ59L3HZzpVmy@mail.gmail.com>
[-- Attachment #1: Mail message body --]
[-- Type: text/plain, Size: 1855 bytes --]
Dear Bob,
I have found a solution for my problem.
Patch from "Johannes Berg <johannes.berg@intel.com>" fixes a problem.
#Processing an association response could take a bit
#of time while we set up the hardware etc. During that
#time, the AP might already send a blockack request.
#If this happens very quickly on a fairly slow machine,
#we can end up processing the blockack request before
#the association processing has finished. Since the
#blockack processing cannot sleep right now, we also
#cannot make it wait in the driver.
> > I have found that ATH5k has severe problems during association to AP.
> > Sometimes it needs more than 100 attempts to association, before it connects
> > to AP.
> Did it work in previous kernels?
The association has beed bad - 2 to 5 attempts needed,
but not 150. So previous kernels did not behave so wrong.
> You said you reverted 6b5d117eddc09cd976ad8030d715f4 and still have the
> problem, right? Are you sure you booted the kernel with the revert?
Yes, because I have ATH5k inside modules. And when I type:
make KLIB=/usr/src/linux-2.6.32.11 KLIB_BUILD=/usr/src/linux-2.6.32.11
make KLIB=/usr/src/linux-2.6.32.11 KLIB_BUILD=/usr/src/linux-2.6.32.11 KMODPATH_ARG='INSTALL_MOD_PATH=' install
Modules in /lib/modules are updated.
> > [ 149.926717] wlan1: direct probe to 00:15:6d:d6:2a:9d (try 1)
> > [ 150.013353] eth3: no IPv6 routers present
> > [ 150.126699] wlan1: direct probe to 00:15:6d:d6:2a:9d (try 2)
> > [ 150.326707] wlan1: direct probe to 00:15:6d:d6:2a:9d (try 3)
> > [ 150.526696] wlan1: direct probe to 00:15:6d:d6:2a:9d timed out
>
> Probably traffic is not being sent or received from one side.
But when association is done (after 150 attempts), the client runs without any packetloss
without any problems.
regards
Jara
> --
> Bob Copeland %% www.bobcopeland.com
[-- Attachment #2: patch_wireless.txt --]
[-- Type: Application/Octet-stream, Size: 2655 bytes --]
---
net/mac80211/mlme.c | 52 +++++++++++++++++++++++++++++++++++++++++++++-------
net/mac80211/rx.c | 3 +++
2 files changed, 48 insertions(+), 7 deletions(-)
--- wireless-testing.orig/net/mac80211/mlme.c 2010-05-28 15:10:29.000000000 +0200
+++ wireless-testing/net/mac80211/mlme.c 2010-05-28 15:12:04.000000000 +0200
@@ -1692,14 +1692,52 @@ static void ieee80211_sta_rx_queued_mgmt
rma = ieee80211_rx_mgmt_disassoc(sdata, mgmt, skb->len);
break;
case IEEE80211_STYPE_ACTION:
- if (mgmt->u.action.category != WLAN_CATEGORY_SPECTRUM_MGMT)
- break;
+ switch (mgmt->u.action.category) {
+ case WLAN_CATEGORY_BACK: {
+ struct ieee80211_local *local = sdata->local;
+ int len = skb->len;
+ struct sta_info *sta;
- ieee80211_sta_process_chanswitch(sdata,
- &mgmt->u.action.u.chan_switch.sw_elem,
- (void *)ifmgd->associated->priv,
- rx_status->mactime);
- break;
+ rcu_read_lock();
+ sta = sta_info_get(sdata, mgmt->sa);
+ if (!sta) {
+ rcu_read_unlock();
+ break;
+ }
+
+ local_bh_disable();
+
+ switch (mgmt->u.action.u.addba_req.action_code) {
+ case WLAN_ACTION_ADDBA_REQ:
+ if (len < (IEEE80211_MIN_ACTION_SIZE +
+ sizeof(mgmt->u.action.u.addba_req)))
+ break;
+ ieee80211_process_addba_request(local, sta, mgmt, len);
+ break;
+ case WLAN_ACTION_ADDBA_RESP:
+ if (len < (IEEE80211_MIN_ACTION_SIZE +
+ sizeof(mgmt->u.action.u.addba_resp)))
+ break;
+ ieee80211_process_addba_resp(local, sta, mgmt, len);
+ break;
+ case WLAN_ACTION_DELBA:
+ if (len < (IEEE80211_MIN_ACTION_SIZE +
+ sizeof(mgmt->u.action.u.delba)))
+ break;
+ ieee80211_process_delba(sdata, sta, mgmt, len);
+ break;
+ }
+ local_bh_enable();
+ rcu_read_unlock();
+ break;
+ }
+ case WLAN_CATEGORY_SPECTRUM_MGMT:
+ ieee80211_sta_process_chanswitch(sdata,
+ &mgmt->u.action.u.chan_switch.sw_elem,
+ (void *)ifmgd->associated->priv,
+ rx_status->mactime);
+ break;
+ }
}
mutex_unlock(&ifmgd->mtx);
--- wireless-testing.orig/net/mac80211/rx.c 2010-05-28 14:22:59.000000000 +0200
+++ wireless-testing/net/mac80211/rx.c 2010-05-28 15:11:47.000000000 +0200
@@ -1936,6 +1936,9 @@ ieee80211_rx_h_action(struct ieee80211_r
if (len < IEEE80211_MIN_ACTION_SIZE + 1)
break;
+ if (sdata->vif.type == NL80211_IFTYPE_STATION)
+ return ieee80211_sta_rx_mgmt(sdata, rx->skb);
+
switch (mgmt->u.action.u.addba_req.action_code) {
case WLAN_ACTION_ADDBA_REQ:
if (len < (IEEE80211_MIN_ACTION_SIZE +
^ permalink raw reply
* Re: IWL3945 problems in 2.6.35-rc1
From: Maxim Levitsky @ 2010-06-01 19:59 UTC (permalink / raw)
To: Abhijeet Kolekar
Cc: sedat.dilek@gmail.com, linux-wireless, iwlwifi maling list
In-Reply-To: <1275419000.5225.0.camel@abhi-desktop>
On Tue, 2010-06-01 at 12:03 -0700, Abhijeet Kolekar wrote:
> Hello,
> Please check the following version of the patch.
>
> Abhijeet
> On Tue, 2010-06-01 at 08:21 -0700, Sedat Dilek wrote:
> > Hi Maxim,
> >
> > that's a known issue... and there were several mails to LKML and here
> > on the ML (as I see you are very active on both lists :-)).
> > Unfortunately, the patch in [1] didnt go into any (GIT) reposoitory. I know.
> >
> > I am attaching the original patch and give it a meaningfull name, so
> > people see it on patchwork.kernel.org (linux-wireless).
> >
> > Kind Regards,
> > - Sedat -
> >
> > [1] http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2208
> >
> > On Tue, Jun 1, 2010 at 4:57 PM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> > > On Tue, 2010-06-01 at 15:25 +0300, Maxim Levitsky wrote:
> > >> Hi,
> > >>
> > >> in 2.6.35-rc1 the wireless became just unusable.
> > >>
> > >> These are problems that I have:
> > >>
> > >> 1. very frequent oopses.This appears to be mention on the list already,
> > >> but patches I tried don't help.
> > >>
> > >> I currently use this bandaid patch, and I still get some crashes:
> > >
> > >
> > > The crash happens here:
> > >
> > > 0xec3d is in iwl3945_request_scan (/home/maxim/software/kernel/linux-2.6/drivers/net/wireless/iwlwifi/iwl3945-base.c:1878).
> > > 1873 if (chan->band != band)
> > > 1874 continue;
> > > 1875
> > > 1876 scan_ch->channel = chan->hw_value;
> > > 1877
> > > 1878 ch_info = iwl_get_channel_info(priv, band, scan_ch->channel);
> > > 1879 if (!is_channel_valid(ch_info)) {
> > > 1880 IWL_DEBUG_SCAN(priv, "Channel %d is INVALID for this band.\n",
> > > 1881 scan_ch->channel);
> > > 1882 continue;
> > >
> > >
> > > The backtrace:
> > >
> > > <1>[14212.708840] BUG: unable to handle kernel paging request at 00000002ffffffb1
> > > <1>[14212.709870] IP: [<ffffffffa0305c0d>] iwl3945_request_scan+0x61d/0xf90 [iwl3945]
> > > <4>[14212.710763] PGD 0
> > > <0>[14212.711636] Oops: 0000 [#1] PREEMPT SMP
> > > <0>[14212.712519] last sysfs file: /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/hwmon/hwmon1/temp1_input
> > > <4>[14212.713416] CPU 0
> > > <4>[14212.713432] Modules linked in: tg3 libphy iwl3945 iwlcore mac80211 cfg80211 ntfs vfat msdos fat lirc_ene0100 lirc_dev af_packet nfsd exportfs nfs lockd nfs_acl auth_rpcgss usb_storage usb_libusual cpufreq_powersave cpufreq_conservative r852 snd_hda_codec_realtek uvcvideo sm_common cpufreq_userspace acpi_cpufreq snd_hda_intel videodev mperf nand snd_hda_codec nand_ids sdhci_pci iTCO_wdt v4l2_compat_ioctl32 joydev snd_hwdep nand_ecc uhci_hcd sunrpc iTCO_vendor_support sdhci ehci_hcd psmouse snd_pcm mmc_core mtd usbcore coretemp ac sg battery evdev serio_raw snd_page_alloc video nouveau ttm drm_kms_helper drm i2c_algo_bit [last unloaded: cfg80211]
> > > <4>[14212.718797]
> > > <4>[14212.718797] Pid: 4263, comm: iwl3945 Not tainted 2.6.35-rc1 #30 Nettiling/Aspire 5720
> > > <4>[14212.718797] RIP: 0010:[<ffffffffa0305c0d>] [<ffffffffa0305c0d>] iwl3945_request_scan+0x61d/0xf90 [iwl3945]
> > > <4>[14212.718797] RSP: 0018:ffff88006ce91c80 EFLAGS: 00010297
> > > <4>[14212.718797] RAX: ffff880066e74100 RBX: ffff88001b2c1dc0 RCX: 00000002ffffffb1
> > > <4>[14212.718797] RDX: 0000000000000000 RSI: 00000000ffff8800 RDI: ffff88001b2c1dc0
> > > <4>[14212.718797] RBP: ffff88006ce91d70 R08: 000000000000030e R09: 00000000ffffffff
> > > <4>[14212.718797] R10: 0000000000000058 R11: 0000000000000001 R12: 0000000000000000
> > > <4>[14212.718797] R13: ffff88001b295800 R14: 0000000000000000 R15: ffff88001b2958f2
> > > <4>[14212.718797] FS: 0000000000000000(0000) GS:ffff880002400000(0000) knlGS:0000000000000000
> > > <4>[14212.718797] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> > > <4>[14212.718797] CR2: 00000002ffffffb1 CR3: 000000000155b000 CR4: 00000000000006f0
> > > <4>[14212.718797] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > > <4>[14212.718797] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > > <4>[14212.718797] Process iwl3945 (pid: 4263, threadinfo ffff88006ce90000, task ffff88006d04a280)
> > > <0>[14212.718797] Stack:
> > > <4>[14212.718797] ffffffffa02c3810 ffff88006d04a2f0 ffff88006ce91cb0 ffffffff81036911
> > > <4>[14212.718797] <0> 0000000000000000 0000000000000001 ffff88006ce91cd0 ffffffff00000000
> > > <4>[14212.718797] <0> 0057000000000246 0000005800000021 ffff88006ce91fd8 0058ffff813a07bf
> > > <0>[14212.718797] Call Trace:
> > > <4>[14212.718797] [<ffffffffa02c3810>] ? iwl_bg_start_internal_scan+0x0/0x3d0 [iwlcore]
> > > <4>[14212.718797] [<ffffffff81036911>] ? get_parent_ip+0x11/0x50
> > > <4>[14212.718797] [<ffffffffa02c3810>] ? iwl_bg_start_internal_scan+0x0/0x3d0 [iwlcore]
> > > <4>[14212.718797] [<ffffffffa02c3b2a>] iwl_bg_start_internal_scan+0x31a/0x3d0 [iwlcore]
> > > <4>[14212.718797] [<ffffffff81056dfe>] ? worker_thread+0x1ce/0x390
> > > <4>[14212.718797] [<ffffffff81056e50>] worker_thread+0x220/0x390
> > > <4>[14212.718797] [<ffffffff81056dfe>] ? worker_thread+0x1ce/0x390
> > > <4>[14212.718797] [<ffffffff8105bc80>] ? autoremove_wake_function+0x0/0x40
> > > <4>[14212.718797] [<ffffffff81056c30>] ? worker_thread+0x0/0x390
> > > <4>[14212.718797] [<ffffffff8105b7fe>] kthread+0xae/0xc0
> > > <4>[14212.718797] [<ffffffff81003b94>] kernel_thread_helper+0x4/0x10
> > > <4>[14212.718797] [<ffffffff8105b750>] ? kthread+0x0/0xc0
> > > <4>[14212.718797] [<ffffffff81003b90>] ? kernel_thread_helper+0x0/0x10
> > > <0>[14212.718797] Code: ff ff 41 8d 52 ff 66 89 95 56 ff ff ff eb 14 0f 1f 80 00 00 00 00 41 ff c4 44 3b 60 0c 0f 83 eb 00 00 00 49 63 d4 48 8b 4c d0 38 <44> 3b 31 75 e6 0f b7 41 06 44 89 f6 41 88 47 01 0f b6 d0 48 89
> > > <1>[14212.718797] RIP [<ffffffffa0305c0d>] iwl3945_request_scan+0x61d/0xf90 [iwl3945]
> > > <4>[14212.718797] RSP <ffff88006ce91c80>
> > > <0>[14212.718797] CR2: 00000002ffffffb1
> > > <4>[14212.760163] ---[ end trace 7075fd19298c88a3 ]---
> > > <0>[14212.761267] Kernel panic - not syncing: Fatal exception
> > > <4>[14212.762226] Pid: 4263, comm: iwl3945 Tainted: G D 2.6.35-rc1 #30
> > > <4>[14212.763193] Call Trace:
> > > <4>[14212.764143] [<ffffffff8139e487>] panic+0x90/0x10a
> > > <4>[14212.765084] [<ffffffff8100737c>] oops_end+0xcc/0xe0
> > > <4>[14212.765095] [<ffffffff81027c13>] no_context+0xf3/0x260
> > > <4>[14212.765106] [<ffffffff810622e5>] ? sched_clock_local+0x25/0x90
> > > <4>[14212.765116] [<ffffffff81027e95>] __bad_area_nosemaphore+0x115/0x1d0
> > > <4>[14212.765128] [<ffffffff81027f5e>] bad_area_nosemaphore+0xe/0x10
> > > <4>[14212.765138] [<ffffffff810283c6>] do_page_fault+0x2e6/0x390
> > > <4>[14212.765148] [<ffffffff810622e5>] ? sched_clock_local+0x25/0x90
> > > <4>[14212.765158] [<ffffffff81062410>] ? sched_clock_cpu+0xc0/0x110
> > > <4>[14212.765169] [<ffffffff8100add7>] ? native_sched_clock+0x27/0x80
> > > <4>[14212.765179] [<ffffffff810622e5>] ? sched_clock_local+0x25/0x90
> > > <4>[14212.765191] [<ffffffff813a309f>] page_fault+0x1f/0x30
> > > <4>[14212.765207] [<ffffffffa0305c0d>] ? iwl3945_request_scan+0x61d/0xf90 [iwl3945]
> > > <4>[14212.765232] [<ffffffffa02c3810>] ? iwl_bg_start_internal_scan+0x0/0x3d0 [iwlcore]
> > > <4>[14212.765246] [<ffffffff81036911>] ? get_parent_ip+0x11/0x50
> > > <4>[14212.765266] [<ffffffffa02c3810>] ? iwl_bg_start_internal_scan+0x0/0x3d0 [iwlcore]
> > > <4>[14212.765286] [<ffffffffa02c3b2a>] iwl_bg_start_internal_scan+0x31a/0x3d0 [iwlcore]
> > > <4>[14212.765299] [<ffffffff81056dfe>] ? worker_thread+0x1ce/0x390
> > > <4>[14212.765310] [<ffffffff81056e50>] worker_thread+0x220/0x390
> > > <4>[14212.765320] [<ffffffff81056dfe>] ? worker_thread+0x1ce/0x390
> > > <4>[14212.765333] [<ffffffff8105bc80>] ? autoremove_wake_function+0x0/0x40
> > > <4>[14212.765344] [<ffffffff81056c30>] ? worker_thread+0x0/0x390
> > > <4>[14212.765353] [<ffffffff8105b7fe>] kthread+0xae/0xc0
> > > <4>[14212.765365] [<ffffffff81003b94>] kernel_thread_helper+0x4/0x10
> > > <4>[14212.765376] [<ffffffff8105b750>] ? kthread+0x0/0xc0
> > > <4>[14212.765386] [<ffffffff81003b90>] ? kernel_thread_helper+0x0/0x10
> > > <3>[14212.765402] [drm:drm_fb_helper_panic] *ERROR* panic occurred, switching back to text console
> > >>
> > >> diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> > >> index 3e5bffb..1aef988 100644
> > >> --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
> > >> +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> > >> @@ -1861,6 +1861,11 @@ static int iwl3945_get_channels_for_scan(struct iwl_priv *priv,
> > >> if (!sband)
> > >> return 0;
> > >>
> > >> + if(!priv->scan_request) {
> > >> + WARN_ON(1);
> > >> + return 0;
> > >> + }
> > >> +
> > >> active_dwell = iwl_get_active_dwell_time(priv, band, n_probes);
> > >> passive_dwell = iwl_get_passive_dwell_time(priv, band, vif);
> > >>
> > >>
> > >> 2. mulicast/broadcast is broken.
> > >> this results in DHCP non working on open access point.
> > >> It seems that DHCP does work on my home wireless, but avahi-autoipd doesn't see any neighbours, and this is annoying.
> > >> It can be worked around by doing (sudo ifconfig wlan0 promisc)
> > >>
> > >>
> > > Best regards,
> > > Maxim Levitsky
> > >
> > > --
> > > 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
> > >
>
Doesn't apply.
maxim@maxim-laptop:~/software/kernel/linux-2.6$ patch -p1 --dry-run < ../0001-iwl3945-fix-internal-scan.patch
patching file drivers/net/wireless/iwlwifi/iwl-agn-lib.c
Hunk #1 succeeded at 1119 (offset 127 lines).
Hunk #2 succeeded at 1136 (offset 127 lines).
patching file drivers/net/wireless/iwlwifi/iwl-core.c
Hunk #1 succeeded at 854 (offset -2 lines).
patching file drivers/net/wireless/iwlwifi/iwl-core.h
Hunk #1 FAILED at 347.
1 out of 1 hunk FAILED -- saving rejects to file drivers/net/wireless/iwlwifi/iwl-core.h.rej
patching file drivers/net/wireless/iwlwifi/iwl3945-base.c
Hunk #1 succeeded at 1844 (offset 61 lines).
Hunk #2 succeeded at 3035 (offset 59 lines).
The other patch I received today does work.
Best regards.
Maxim Levitsky
^ permalink raw reply
* Re: Path for fixed channel issue in aircrack-ng suite [V2]
From: Johannes Berg @ 2010-06-01 20:06 UTC (permalink / raw)
To: Maxim Levitsky
Cc: Richard Farina, Gábor Stefanik, Joker Joker, linux-wireless
In-Reply-To: <1275421989.2574.12.camel@maxim-laptop>
On Tue, 2010-06-01 at 22:53 +0300, Maxim Levitsky wrote:
> > This won't quite work. monitor interfaces are always slaves in the sense
> > that their channel setting never takes precedence over anything, so if
> > you add another interface and do something there, the hardware will
> > happily channel switch away from the monitor channel, but it will still
> > report the old channel here that you set.
> >
> > I have no idea how to _properly_ fix this though, since eventually we'll
> > have a situation where you can have multiple interfaces active on
> > different channels, so that monitors don't have a fixed channel anyway.
> >
> > Maybe this patch is sufficient since it works in the case people care
> > about when they _only_ have a monitor interface, but I think it'd be
> > nicer if it wouldn't report anything in the other cases.
>
> Why?
>
> We don't have any wireless devices that actually support using 2
> channels independently.
ath9k already supports this with its virtual wiphy concept, and that
will be moved in the medium term to do channel switching between
multiple virtual interfaces. It's perfectly possible to do this with two
station interfaces, for instance, since you can pretend to be in
powersave while you go to the other channel. So we actually _do_ have
devices that support multiple channels independently, just not the way
you think of it.
> Therefore user should be aware that if he sets channel on one interface,
> and then on other, the last setting matters.
Like I said, this is not true.
> Of course the right fix would to make channel a global property of card
> rather that of interface.
No, see above ... my recent patches have moved exactly in the other
direction for this reason!
However, This obviously only works for certain special cases like 2
stations. Monitor interfaces are sort of a second class citizen, if you
have two stations on different channels and add a monitor interface, its
channel setting won't matter at all.
However, in that case, when you set a channel on the monitor interface,
with this patch it will report that channel, irregardless of what
channel it is currently on. And if you have 2 channel switching station
mode interfaces, there's no sensible channel to report at all.
Again however though, very likely you don't care about that situation.
But I still think we shouldn't report a bogus channel then. So maybe in
that situation we should just fall back to reporting nothing, i.e.
return -EINVAL?
johannes
^ permalink raw reply
* Re: Association problems - again - comment
From: Johannes Berg @ 2010-06-01 20:09 UTC (permalink / raw)
To: Jaroslav Fojtik; +Cc: Bob Copeland, linux-wireless
In-Reply-To: <4C055FA2.23990.223BFA@jafojtik.seznam.cz>
On Tue, 2010-06-01 at 21:29 +0200, Jaroslav Fojtik wrote:
> Dear Bob,
>
> I have found a solution for my problem.
>
> Patch from "Johannes Berg <johannes.berg@intel.com>" fixes a problem.
>
> #Processing an association response could take a bit
> #of time while we set up the hardware etc. During that
> #time, the AP might already send a blockack request.
That makes no sense at all -- ath5k doesn't do aggregation. I guess it
probably just means that your problem is timing related.
johannes
^ permalink raw reply
* Re: Path for fixed channel issue in aircrack-ng suite [V2]
From: Johannes Berg @ 2010-06-01 20:19 UTC (permalink / raw)
To: Richard Farina
Cc: Maxim Levitsky, Gábor Stefanik, Joker Joker, linux-wireless
In-Reply-To: <4C056476.9090905@gmail.com>
On Tue, 2010-06-01 at 15:50 -0400, Richard Farina wrote:
> > This won't quite work. monitor interfaces are always slaves in the sense
> > that their channel setting never takes precedence over anything, so if
> > you add another interface and do something there, the hardware will
> > happily channel switch away from the monitor channel, but it will still
> > report the old channel here that you set.
> >
> > I have no idea how to _properly_ fix this though, since eventually we'll
> > have a situation where you can have multiple interfaces active on
> > different channels, so that monitors don't have a fixed channel anyway.
> >
> > Maybe this patch is sufficient since it works in the case people care
> > about when they _only_ have a monitor interface, but I think it'd be
> > nicer if it wouldn't report anything in the other cases.
> >
> >
> Is this a NACK or a "I wish there was a better way to do this but I'll
> allow it until a better way if found"?
I haven't really made up my mind. I really dislike the reporting of
wrong information though, see my other email.
johannes
^ permalink raw reply
* [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Dmytro Milinevskyy @ 2010-04-07 18:58 UTC (permalink / raw)
To: ath5k-devel
Cc: Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez, Bob Copeland,
John W. Linville, GeunSik Lim, Greg Kroah-Hartman, Lukas Turek,
Mark Hindley, Johannes Berg, Jiri Kosina, Kalle Valo, Keng-Yu Lin,
Luca Verdesca, Shahar Or, linux-wireless, netdev, linux-kernel,
Dmytro Milinevskyy
Hello!
Here is the patch to disable ath5k leds support on build stage.
However if the leds support was enabled do not force selection of 802.11 leds layer.
I've applied suggestion given by Pavel Roskin.
Best regards,
--Dima
---
drivers/net/wireless/ath/ath5k/Kconfig | 10 +++++++---
drivers/net/wireless/ath/ath5k/Makefile | 2 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 16 +++++++++++-----
drivers/net/wireless/ath/ath5k/base.h | 17 ++++++++++++-----
drivers/net/wireless/ath/ath5k/gpio.c | 2 ++
drivers/net/wireless/ath/ath5k/led.c | 9 +++++++++
6 files changed, 42 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/Kconfig b/drivers/net/wireless/ath/ath5k/Kconfig
index eb83b7b..6b5677e 100644
--- a/drivers/net/wireless/ath/ath5k/Kconfig
+++ b/drivers/net/wireless/ath/ath5k/Kconfig
@@ -1,9 +1,6 @@
config ATH5K
tristate "Atheros 5xxx wireless cards support"
depends on PCI && MAC80211
- select MAC80211_LEDS
- select LEDS_CLASS
- select NEW_LEDS
---help---
This module adds support for wireless adapters based on
Atheros 5xxx chipset.
@@ -18,6 +15,13 @@ config ATH5K
If you choose to build a module, it'll be called ath5k. Say M if
unsure.
+
+config ATH5K_LEDS
+ tristate "Atheros 5xxx wireless cards LEDs support"
+ depends on ATH5K
+ ---help---
+ Atheros 5xxx LED support.
+
config ATH5K_DEBUG
bool "Atheros 5xxx debugging"
depends on ATH5K
diff --git a/drivers/net/wireless/ath/ath5k/Makefile b/drivers/net/wireless/ath/ath5k/Makefile
index cc09595..6d552dd 100644
--- a/drivers/net/wireless/ath/ath5k/Makefile
+++ b/drivers/net/wireless/ath/ath5k/Makefile
@@ -10,8 +10,8 @@ ath5k-y += phy.o
ath5k-y += reset.o
ath5k-y += attach.o
ath5k-y += base.o
-ath5k-y += led.o
ath5k-y += rfkill.o
ath5k-y += ani.o
ath5k-$(CONFIG_ATH5K_DEBUG) += debug.o
+ath5k-$(CONFIG_ATH5K_LEDS) += led.o
obj-$(CONFIG_ATH5K) += ath5k.o
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index 2785946..615b9ca 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -920,11 +920,6 @@ enum ath5k_power_mode {
#define AR5K_LED_ASSOC 3 /*IEEE80211_S_ASSOC*/
#define AR5K_LED_RUN 4 /*IEEE80211_S_RUN*/
-/* GPIO-controlled software LED */
-#define AR5K_SOFTLED_PIN 0
-#define AR5K_SOFTLED_ON 0
-#define AR5K_SOFTLED_OFF 1
-
/*
* Chipset capabilities -see ath5k_hw_get_capability-
* get_capability function is not yet fully implemented
@@ -1148,11 +1143,18 @@ struct ath5k_hw {
int ath5k_hw_attach(struct ath5k_softc *sc);
void ath5k_hw_detach(struct ath5k_hw *ah);
+#ifdef CONFIG_ATH5K_LEDS
/* LED functions */
int ath5k_init_leds(struct ath5k_softc *sc);
void ath5k_led_enable(struct ath5k_softc *sc);
void ath5k_led_off(struct ath5k_softc *sc);
void ath5k_unregister_leds(struct ath5k_softc *sc);
+#else
+#define ath5k_init_leds(sc) do {} while (0)
+#define ath5k_led_enable(sc) do {} while (0)
+#define ath5k_led_off(sc) do {} while (0)
+#define ath5k_unregister_leds(sc) do {} while (0)
+#endif
/* Reset Functions */
int ath5k_hw_nic_wakeup(struct ath5k_hw *ah, int flags, bool initial);
@@ -1233,7 +1235,11 @@ int ath5k_hw_set_slot_time(struct ath5k_hw *ah, unsigned int slot_time);
int ath5k_hw_init_desc_functions(struct ath5k_hw *ah);
/* GPIO Functions */
+#ifdef CONFIG_ATH5K_LEDS
void ath5k_hw_set_ledstate(struct ath5k_hw *ah, unsigned int state);
+#else
+#define ath5k_hw_set_ledstate(ah, state) do {} while (0)
+#endif
int ath5k_hw_set_gpio_input(struct ath5k_hw *ah, u32 gpio);
int ath5k_hw_set_gpio_output(struct ath5k_hw *ah, u32 gpio);
u32 ath5k_hw_get_gpio(struct ath5k_hw *ah, u32 gpio);
diff --git a/drivers/net/wireless/ath/ath5k/base.h b/drivers/net/wireless/ath/ath5k/base.h
index 56221bc..e493d34 100644
--- a/drivers/net/wireless/ath/ath5k/base.h
+++ b/drivers/net/wireless/ath/ath5k/base.h
@@ -86,15 +86,19 @@ struct ath5k_txq {
#define ATH5K_LED_MAX_NAME_LEN 31
+#ifdef CONFIG_ATH5K_LEDS
/*
* State for LED triggers
*/
struct ath5k_led
{
- char name[ATH5K_LED_MAX_NAME_LEN + 1]; /* name of the LED in sysfs */
struct ath5k_softc *sc; /* driver state */
+#ifdef CONFIG_LEDS_CLASS
+ char name[ATH5K_LED_MAX_NAME_LEN + 1]; /* name of the LED in sysfs */
struct led_classdev led_dev; /* led classdev */
+#endif
};
+#endif
/* Rfkill */
struct ath5k_rfkill {
@@ -186,9 +190,6 @@ struct ath5k_softc {
u8 bssidmask[ETH_ALEN];
- unsigned int led_pin, /* GPIO pin for driving LED */
- led_on; /* pin setting for LED on */
-
struct tasklet_struct restq; /* reset tasklet */
unsigned int rxbufsize; /* rx size based on mtu */
@@ -196,7 +197,6 @@ struct ath5k_softc {
spinlock_t rxbuflock;
u32 *rxlink; /* link ptr in last RX desc */
struct tasklet_struct rxtq; /* rx intr tasklet */
- struct ath5k_led rx_led; /* rx led */
struct list_head txbuf; /* transmit buffer */
spinlock_t txbuflock;
@@ -204,7 +204,14 @@ struct ath5k_softc {
struct ath5k_txq txqs[AR5K_NUM_TX_QUEUES]; /* tx queues */
struct ath5k_txq *txq; /* main tx queue */
struct tasklet_struct txtq; /* tx intr tasklet */
+
+
+#ifdef CONFIG_ATH5K_LEDS
+ unsigned int led_pin, /* GPIO pin for driving LED */
+ led_on; /* pin setting for LED on */
+ struct ath5k_led rx_led; /* rx led */
struct ath5k_led tx_led; /* tx led */
+#endif
struct ath5k_rfkill rf_kill;
diff --git a/drivers/net/wireless/ath/ath5k/gpio.c b/drivers/net/wireless/ath/ath5k/gpio.c
index 64a27e7..9e757b3 100644
--- a/drivers/net/wireless/ath/ath5k/gpio.c
+++ b/drivers/net/wireless/ath/ath5k/gpio.c
@@ -25,6 +25,7 @@
#include "debug.h"
#include "base.h"
+#ifdef CONFIG_ATH5K_LEDS
/*
* Set led state
*/
@@ -76,6 +77,7 @@ void ath5k_hw_set_ledstate(struct ath5k_hw *ah, unsigned int state)
else
AR5K_REG_ENABLE_BITS(ah, AR5K_PCICFG, led_5210);
}
+#endif
/*
* Set GPIO inputs
diff --git a/drivers/net/wireless/ath/ath5k/led.c b/drivers/net/wireless/ath/ath5k/led.c
index 67aa52e..df8e8d2 100644
--- a/drivers/net/wireless/ath/ath5k/led.c
+++ b/drivers/net/wireless/ath/ath5k/led.c
@@ -121,6 +121,7 @@ ath5k_led_brightness_set(struct led_classdev *led_dev,
ath5k_led_on(led->sc);
}
+#ifdef CONFIG_LEDS_CLASS
static int
ath5k_register_led(struct ath5k_softc *sc, struct ath5k_led *led,
const char *name, char *trigger)
@@ -140,13 +141,16 @@ ath5k_register_led(struct ath5k_softc *sc, struct ath5k_led *led,
}
return err;
}
+#endif
static void
ath5k_unregister_led(struct ath5k_led *led)
{
if (!led->sc)
return;
+#ifdef CONFIG_LEDS_CLASS
led_classdev_unregister(&led->led_dev);
+#endif
ath5k_led_off(led->sc);
led->sc = NULL;
}
@@ -177,6 +181,7 @@ int ath5k_init_leds(struct ath5k_softc *sc)
ath5k_led_enable(sc);
+#ifdef CONFIG_LEDS_CLASS
snprintf(name, sizeof(name), "ath5k-%s::rx", wiphy_name(hw->wiphy));
ret = ath5k_register_led(sc, &sc->rx_led, name,
ieee80211_get_rx_led_name(hw));
@@ -186,6 +191,10 @@ int ath5k_init_leds(struct ath5k_softc *sc)
snprintf(name, sizeof(name), "ath5k-%s::tx", wiphy_name(hw->wiphy));
ret = ath5k_register_led(sc, &sc->tx_led, name,
ieee80211_get_tx_led_name(hw));
+#else
+ sc->rx_led.sc = sc;
+ sc->tx_led.sc = sc;
+#endif
out:
return ret;
}
--
1.7.1
^ permalink raw reply related
* Re: Association problems - again - comment
From: Jaroslav Fojtik @ 2010-06-01 20:24 UTC (permalink / raw)
To: Johannes Berg, Bob Copeland, linux-wireless
In-Reply-To: <1275422985.3634.22.camel@jlt3.sipsolutions.net>
Dear Johannes Berg,
> > I have found a solution for my problem.
> >
> > Patch from "Johannes Berg <johannes.berg@intel.com>" fixes a problem.
> >
> > #Processing an association response could take a bit
> > #of time while we set up the hardware etc. During that
> > #time, the AP might already send a blockack request.
>
> That makes no sense at all -- ath5k doesn't do aggregation. I guess it
> probably just means that your problem is timing related.
But it works ;)
May be, I do not know ATH5k internals.
I could test something, when you generate some release.
Anyway, the "workable" code still has reverted patch:
> You said you reverted 6b5d117eddc09cd976ad8030d715f4 and still have the
> problem, right? Are you sure you booted the kernel with the revert?
So 2 changes against "compat-wireless-2010-05-30" has been done.
regards
Jara
^ permalink raw reply
* Re: [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Bob Copeland @ 2010-06-01 20:34 UTC (permalink / raw)
To: Dmytro Milinevskyy
Cc: ath5k-devel, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
John W. Linville, GeunSik Lim, Greg Kroah-Hartman, Lukas Turek,
Mark Hindley, Johannes Berg, Jiri Kosina, Kalle Valo, Keng-Yu Lin,
Luca Verdesca, Shahar Or, linux-wireless, netdev, linux-kernel
In-Reply-To: <4c056b50.0c3fdf0a.500b.44af@mx.google.com>
On Wed, Apr 7, 2010 at 2:58 PM, Dmytro Milinevskyy
<milinevskyy@gmail.com> wrote:
> Hello!
Thanks, comments inline.
> +config ATH5K_LEDS
> + tristate "Atheros 5xxx wireless cards LEDs support"
> + depends on ATH5K
> + ---help---
> + Atheros 5xxx LED support.
> +
This can select the proper LED classes? Then you can get rid of another
ifdef check later.
> -/* GPIO-controlled software LED */
> -#define AR5K_SOFTLED_PIN 0
> -#define AR5K_SOFTLED_ON 0
> -#define AR5K_SOFTLED_OFF 1
> -
Please drop this hunk, no problem keeping it around.
> +#ifdef CONFIG_ATH5K_LEDS
> /* LED functions */
> int ath5k_init_leds(struct ath5k_softc *sc);
> void ath5k_led_enable(struct ath5k_softc *sc);
> void ath5k_led_off(struct ath5k_softc *sc);
> void ath5k_unregister_leds(struct ath5k_softc *sc);
> +#else
> +#define ath5k_init_leds(sc) do {} while (0)
> +#define ath5k_led_enable(sc) do {} while (0)
> +#define ath5k_led_off(sc) do {} while (0)
> +#define ath5k_unregister_leds(sc) do {} while (0)
> +#endif
I prefer:
#ifdef
...
#else
static inline int ath5k_init_leds(struct ath5k_softc *sc)
{
return 0;
}
...
#endif
so you get type-checking. Also this doesn't quite work in your version:
int foo = ath5k_init_leds(sc);
> +#ifdef CONFIG_ATH5K_LEDS
> /*
> * State for LED triggers
> */
> struct ath5k_led
> {
> - char name[ATH5K_LED_MAX_NAME_LEN + 1]; /* name of the LED in sysfs */
> struct ath5k_softc *sc; /* driver state */
> +#ifdef CONFIG_LEDS_CLASS
> + char name[ATH5K_LED_MAX_NAME_LEN + 1]; /* name of the LED in sysfs */
> struct led_classdev led_dev; /* led classdev */
> +#endif
> };
> +#endif
Why move name?
> /* Rfkill */
> struct ath5k_rfkill {
> @@ -186,9 +190,6 @@ struct ath5k_softc {
>
> u8 bssidmask[ETH_ALEN];
>
> - unsigned int led_pin, /* GPIO pin for driving LED */
> - led_on; /* pin setting for LED on */
> -
> struct tasklet_struct restq; /* reset tasklet */
>
> unsigned int rxbufsize; /* rx size based on mtu */
> @@ -196,7 +197,6 @@ struct ath5k_softc {
> spinlock_t rxbuflock;
> u32 *rxlink; /* link ptr in last RX desc */
> struct tasklet_struct rxtq; /* rx intr tasklet */
> - struct ath5k_led rx_led; /* rx led */
>
> struct list_head txbuf; /* transmit buffer */
> spinlock_t txbuflock;
> @@ -204,7 +204,14 @@ struct ath5k_softc {
> struct ath5k_txq txqs[AR5K_NUM_TX_QUEUES]; /* tx queues */
> struct ath5k_txq *txq; /* main tx queue */
> struct tasklet_struct txtq; /* tx intr tasklet */
> +
> +
> +#ifdef CONFIG_ATH5K_LEDS
> + unsigned int led_pin, /* GPIO pin for driving LED */
> + led_on; /* pin setting for LED on */
> + struct ath5k_led rx_led; /* rx led */
> struct ath5k_led tx_led; /* tx led */
> +#endif
You might want to do this in two stages: move the led-dependent things
together in the structure (or into a separate structure) and then only
have one #ifdef section.
Still too many ifdefs in general.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [ath5k-devel] [PATCH] ath5k: disable ASPM
From: Luis R. Rodriguez @ 2010-06-01 20:43 UTC (permalink / raw)
To: Bruno Randolf
Cc: ath5k-devel, Pavel Roskin, Jussi Kivilinna, linux-wireless,
Stephen Hemminger, Alan Cox, bkuhn, linux-kernel, BrianK.Lee
In-Reply-To: <201005311006.15282.br1@einfach.org>
Note: this e-mail thread is on a public mailing list.
Adding a few folks just for their information or in case they have
anything to add and It is also good to remind ourselves about best
practices for this stuff.
On Sun, May 30, 2010 at 6:06 PM, Bruno Randolf <br1@einfach.org> wrote:
> On Saturday 29 May 2010 05:27:56 Pavel Roskin wrote:
>> If we need to add GPL code to ath5k, it could go to a separate file.
>> But if that separation becomes inconvenient, we could drop BSD
>> compatibility from ath5k. I don't see any benefit from dual licensing,
>> unless some existing ath5k contributors are BSD developers who would
>> stop working on the code in case of relicensing, but I don't think it's
>> the case.
>
> afaik, one of the reasons for the dual license is that *BSDs (our ancestors
> from a ath5k point of view) should be able to benefit from improvements we
> make.
Some clarifications on this.
Dual licensing GPL/BSD is typically done for the purpose of sharing
code between GPL codebases and permissive licensed codebases but I
should note that dual licensing GPL/BSD with this intention is legally
equivalent to just licensing under the BSD license. Also the
"Alternative" or "or" language used in dual licensing can sometimes be
left up to interpretation and confusion and for this same reason
SFLC's guidelines advise against this practice and instead recommend a
simple clear permissive license [1].
In ath9k's case all files are permissive licensed on purpose,
following SFLC's latest advice on this matter [1]. In ath5k only the
hardware files were *only* permissive licensed since those were the
files under review for sharing with OpenBSD. The other core driver
files have the dual license just because of historical purposes but
with the same intentions.
I should note though that when sharing permissive licensed files on a
larger GPL project it is also important to have in process a tag
mechanism to annotate when contributions made to a permissive licensed
file are indeed being kept under that same permissive licensed file.
In Linux this is accomplished by the Signed-off-by tag, which has as a
purpose stated under the 'Developer's Certificate of Origin 1.1':
------------------------------------------------------------------------------------------
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
------------------------------------------------------------------------------------------
For ath5k initially we used to use a more implicit
Changes-licensed-under tag but after a while this practice faded off
in favor for educating more on the meaning behind the Singed-off-by
tag, as stated above. There are more subsystems where this code
sharing happens with permissive licensed code bases and sticking to
the simple SOB makes it easier.
> this applies mostly to atheros chipset related things, and is irrelevant
> for linux-only implementation specifics.
Actually the Linux kernel has other places where we care to share with
the other BSD families, another example I am aware of is ACPI code.
There may be others, but I am not too sure.
> also we can mix BSD and GPL in one file - see debug.c
No, once you have GPL a file the entire driver becomes GPL as a whole,
the final binary that is. The ath5k/debug.c file is GPL, and future
contributions would be made only as GPL then. If you want to separate
permissive licensed changes from GPL changes that technically is
possible but its just a pain in the ass and silly. For this reason I
recommend to keep GPL files separate from permissive files. But yes,
it is also possible to keep some GPL files and some permissive
licensed files for a driver and ath5k is good example of such a case:
* GPL files (debug.c)
* Dual licensing for historical purposes (core driver)
* Clean simple permissive license (ISC license, on hardware code)
[1] http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
Luis
^ permalink raw reply
* Re: [PATCH] mac80211: process station blockack action frames from work
From: reinette chatre @ 2010-06-01 21:10 UTC (permalink / raw)
To: Johannes Berg, John W. Linville; +Cc: linux-wireless, John Linville, Zhu, Yi
In-Reply-To: <1275052978.3909.105.camel@jlt3.sipsolutions.net>
Hi John,
On Fri, 2010-05-28 at 06:22 -0700, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> Processing an association response could take a bit
> of time while we set up the hardware etc. During that
> time, the AP might already send a blockack request.
> If this happens very quickly on a fairly slow machine,
> we can end up processing the blockack request before
> the association processing has finished. Since the
> blockack processing cannot sleep right now, we also
> cannot make it wait in the driver.
>
> As a result, sometimes on slow machines the iwlagn
> driver gets totally confused, and no traffic can pass
> when the aggregation setup was done before the assoc
> setup completed.
>
> I'm working on a proper fix for this, which involves
> queuing all blockack category action frames from a
> work struct, and also allowing the ampdu_action driver
> callback to sleep, which will generally clean up the
> code and make things easier.
>
> However, this is a very involved and complex change.
> To fix the problem at hand in a way that can also be
> backported to stable, I've come up with this patch.
> Here, I simply process all aggregation action frames
> from the managed interface skb queue, which means
> their processing will be serialized with processing
> the association response, thereby fixing the problem.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> Cc: stable@kernel.org
> ---
Could you please consider this patch for wireless-2.6/2.6.34 ? Without
this patch no data transfer is possible on some slow machines.
Thank you
Reinette
^ permalink raw reply
* Re: Path for fixed channel issue in aircrack-ng suite [V2]
From: Thomas d'Otreppe @ 2010-06-01 21:53 UTC (permalink / raw)
To: Johannes Berg
Cc: Richard Farina, Maxim Levitsky, Gábor Stefanik, Joker Joker,
linux-wireless
In-Reply-To: <1275423555.3634.23.camel@jlt3.sipsolutions.net>
On Tue, Jun 1, 2010 at 9:19 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2010-06-01 at 15:50 -0400, Richard Farina wrote:
>
>> > This won't quite work. monitor interfaces are always slaves in the sense
>> > that their channel setting never takes precedence over anything, so if
>> > you add another interface and do something there, the hardware will
>> > happily channel switch away from the monitor channel, but it will still
>> > report the old channel here that you set.
>> >
>> > I have no idea how to _properly_ fix this though, since eventually we'll
>> > have a situation where you can have multiple interfaces active on
>> > different channels, so that monitors don't have a fixed channel anyway.
>> >
>> > Maybe this patch is sufficient since it works in the case people care
>> > about when they _only_ have a monitor interface, but I think it'd be
>> > nicer if it wouldn't report anything in the other cases.
>> >
>> >
>> Is this a NACK or a "I wish there was a better way to do this but I'll
>> allow it until a better way if found"?
>
> I haven't really made up my mind. I really dislike the reporting of
> wrong information though, see my other email.
>
> johannes
>
> --
> 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
>
Reporting wrong information doesn't make sense to me and thus I also
think returning -EINVAL is a good idea in such case.
Thomas (Mister_X)
^ permalink raw reply
* Re: [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Dmytro Milinevskyy @ 2010-06-01 23:01 UTC (permalink / raw)
To: Bob Copeland
Cc: ath5k-devel, Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez,
John W. Linville, GeunSik Lim, Greg Kroah-Hartman, Lukas Turek,
Mark Hindley, Johannes Berg, Jiri Kosina, Kalle Valo, Keng-Yu Lin,
Luca Verdesca, Shahar Or, linux-wireless, netdev, linux-kernel
In-Reply-To: <AANLkTinFCuqgvnEGFmssL5R1J9-Yx7JB8mO9yKdXuYUj@mail.gmail.com>
Bob, thanks for the response.
I will rework the patch.
>> -/* GPIO-controlled software LED */
>> -#define AR5K_SOFTLED_PIN 0
>> -#define AR5K_SOFTLED_ON 0
>> -#define AR5K_SOFTLED_OFF 1
>> -
>
> Please drop this hunk, no problem keeping it around.
I suppose this should go away with another patch to keep current
clean. These dfinitions are not related to the subject.
Regards,
-- Dima
On Tue, Jun 1, 2010 at 11:34 PM, Bob Copeland <me@bobcopeland.com> wrote:
> On Wed, Apr 7, 2010 at 2:58 PM, Dmytro Milinevskyy
> <milinevskyy@gmail.com> wrote:
>> Hello!
>
> Thanks, comments inline.
>
>
>> +config ATH5K_LEDS
>> + tristate "Atheros 5xxx wireless cards LEDs support"
>> + depends on ATH5K
>> + ---help---
>> + Atheros 5xxx LED support.
>> +
>
> This can select the proper LED classes? Then you can get rid of another
> ifdef check later.
>
>> -/* GPIO-controlled software LED */
>> -#define AR5K_SOFTLED_PIN 0
>> -#define AR5K_SOFTLED_ON 0
>> -#define AR5K_SOFTLED_OFF 1
>> -
>
> Please drop this hunk, no problem keeping it around.
>
>> +#ifdef CONFIG_ATH5K_LEDS
>> /* LED functions */
>> int ath5k_init_leds(struct ath5k_softc *sc);
>> void ath5k_led_enable(struct ath5k_softc *sc);
>> void ath5k_led_off(struct ath5k_softc *sc);
>> void ath5k_unregister_leds(struct ath5k_softc *sc);
>> +#else
>> +#define ath5k_init_leds(sc) do {} while (0)
>> +#define ath5k_led_enable(sc) do {} while (0)
>> +#define ath5k_led_off(sc) do {} while (0)
>> +#define ath5k_unregister_leds(sc) do {} while (0)
>> +#endif
>
> I prefer:
>
> #ifdef
> ...
> #else
> static inline int ath5k_init_leds(struct ath5k_softc *sc)
> {
> return 0;
> }
> ...
> #endif
>
> so you get type-checking. Also this doesn't quite work in your version:
>
> int foo = ath5k_init_leds(sc);
>
>> +#ifdef CONFIG_ATH5K_LEDS
>> /*
>> * State for LED triggers
>> */
>> struct ath5k_led
>> {
>> - char name[ATH5K_LED_MAX_NAME_LEN + 1]; /* name of the LED in sysfs */
>> struct ath5k_softc *sc; /* driver state */
>> +#ifdef CONFIG_LEDS_CLASS
>> + char name[ATH5K_LED_MAX_NAME_LEN + 1]; /* name of the LED in sysfs */
>> struct led_classdev led_dev; /* led classdev */
>> +#endif
>> };
>> +#endif
>
> Why move name?
>
>> /* Rfkill */
>> struct ath5k_rfkill {
>> @@ -186,9 +190,6 @@ struct ath5k_softc {
>>
>> u8 bssidmask[ETH_ALEN];
>>
>> - unsigned int led_pin, /* GPIO pin for driving LED */
>> - led_on; /* pin setting for LED on */
>> -
>> struct tasklet_struct restq; /* reset tasklet */
>>
>> unsigned int rxbufsize; /* rx size based on mtu */
>> @@ -196,7 +197,6 @@ struct ath5k_softc {
>> spinlock_t rxbuflock;
>> u32 *rxlink; /* link ptr in last RX desc */
>> struct tasklet_struct rxtq; /* rx intr tasklet */
>> - struct ath5k_led rx_led; /* rx led */
>>
>> struct list_head txbuf; /* transmit buffer */
>> spinlock_t txbuflock;
>> @@ -204,7 +204,14 @@ struct ath5k_softc {
>> struct ath5k_txq txqs[AR5K_NUM_TX_QUEUES]; /* tx queues */
>> struct ath5k_txq *txq; /* main tx queue */
>> struct tasklet_struct txtq; /* tx intr tasklet */
>> +
>> +
>> +#ifdef CONFIG_ATH5K_LEDS
>> + unsigned int led_pin, /* GPIO pin for driving LED */
>> + led_on; /* pin setting for LED on */
>> + struct ath5k_led rx_led; /* rx led */
>> struct ath5k_led tx_led; /* tx led */
>> +#endif
>
> You might want to do this in two stages: move the led-dependent things
> together in the structure (or into a separate structure) and then only
> have one #ifdef section.
>
> Still too many ifdefs in general.
>
> --
> Bob Copeland %% www.bobcopeland.com
>
^ permalink raw reply
* [PATCH] mac80211: reduce debugfs code size
From: Felix Fietkau @ 2010-06-02 0:57 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville, Johannes Berg
This patch reduces the binary size by around 25k (measured on MIPS,
with CONFIG_MAC80211_DEBUG_COUNTERS enabled).
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -307,9 +307,6 @@ static const struct file_operations queu
/* statistics stuff */
-#define DEBUGFS_STATS_FILE(name, buflen, fmt, value...) \
- DEBUGFS_READONLY_FILE(stats_ ##name, buflen, fmt, ##value)
-
static ssize_t format_devstat_counter(struct ieee80211_local *local,
char __user *userbuf,
size_t count, loff_t *ppos,
@@ -351,75 +348,16 @@ static const struct file_operations stat
.open = mac80211_open_file_generic, \
};
-#define DEBUGFS_STATS_ADD(name) \
+#define DEBUGFS_STATS_ADD(name, field) \
+ debugfs_create_u32(#name, 0400, statsd, (u32 *) &field);
+#define DEBUGFS_DEVSTATS_ADD(name) \
debugfs_create_file(#name, 0400, statsd, local, &stats_ ##name## _ops);
-DEBUGFS_STATS_FILE(transmitted_fragment_count, 20, "%u",
- local->dot11TransmittedFragmentCount);
-DEBUGFS_STATS_FILE(multicast_transmitted_frame_count, 20, "%u",
- local->dot11MulticastTransmittedFrameCount);
-DEBUGFS_STATS_FILE(failed_count, 20, "%u",
- local->dot11FailedCount);
-DEBUGFS_STATS_FILE(retry_count, 20, "%u",
- local->dot11RetryCount);
-DEBUGFS_STATS_FILE(multiple_retry_count, 20, "%u",
- local->dot11MultipleRetryCount);
-DEBUGFS_STATS_FILE(frame_duplicate_count, 20, "%u",
- local->dot11FrameDuplicateCount);
-DEBUGFS_STATS_FILE(received_fragment_count, 20, "%u",
- local->dot11ReceivedFragmentCount);
-DEBUGFS_STATS_FILE(multicast_received_frame_count, 20, "%u",
- local->dot11MulticastReceivedFrameCount);
-DEBUGFS_STATS_FILE(transmitted_frame_count, 20, "%u",
- local->dot11TransmittedFrameCount);
-#ifdef CONFIG_MAC80211_DEBUG_COUNTERS
-DEBUGFS_STATS_FILE(tx_handlers_drop, 20, "%u",
- local->tx_handlers_drop);
-DEBUGFS_STATS_FILE(tx_handlers_queued, 20, "%u",
- local->tx_handlers_queued);
-DEBUGFS_STATS_FILE(tx_handlers_drop_unencrypted, 20, "%u",
- local->tx_handlers_drop_unencrypted);
-DEBUGFS_STATS_FILE(tx_handlers_drop_fragment, 20, "%u",
- local->tx_handlers_drop_fragment);
-DEBUGFS_STATS_FILE(tx_handlers_drop_wep, 20, "%u",
- local->tx_handlers_drop_wep);
-DEBUGFS_STATS_FILE(tx_handlers_drop_not_assoc, 20, "%u",
- local->tx_handlers_drop_not_assoc);
-DEBUGFS_STATS_FILE(tx_handlers_drop_unauth_port, 20, "%u",
- local->tx_handlers_drop_unauth_port);
-DEBUGFS_STATS_FILE(rx_handlers_drop, 20, "%u",
- local->rx_handlers_drop);
-DEBUGFS_STATS_FILE(rx_handlers_queued, 20, "%u",
- local->rx_handlers_queued);
-DEBUGFS_STATS_FILE(rx_handlers_drop_nullfunc, 20, "%u",
- local->rx_handlers_drop_nullfunc);
-DEBUGFS_STATS_FILE(rx_handlers_drop_defrag, 20, "%u",
- local->rx_handlers_drop_defrag);
-DEBUGFS_STATS_FILE(rx_handlers_drop_short, 20, "%u",
- local->rx_handlers_drop_short);
-DEBUGFS_STATS_FILE(rx_handlers_drop_passive_scan, 20, "%u",
- local->rx_handlers_drop_passive_scan);
-DEBUGFS_STATS_FILE(tx_expand_skb_head, 20, "%u",
- local->tx_expand_skb_head);
-DEBUGFS_STATS_FILE(tx_expand_skb_head_cloned, 20, "%u",
- local->tx_expand_skb_head_cloned);
-DEBUGFS_STATS_FILE(rx_expand_skb_head, 20, "%u",
- local->rx_expand_skb_head);
-DEBUGFS_STATS_FILE(rx_expand_skb_head2, 20, "%u",
- local->rx_expand_skb_head2);
-DEBUGFS_STATS_FILE(rx_handlers_fragments, 20, "%u",
- local->rx_handlers_fragments);
-DEBUGFS_STATS_FILE(tx_status_drop, 20, "%u",
- local->tx_status_drop);
-
-#endif
-
DEBUGFS_DEVSTATS_FILE(dot11ACKFailureCount);
DEBUGFS_DEVSTATS_FILE(dot11RTSFailureCount);
DEBUGFS_DEVSTATS_FILE(dot11FCSErrorCount);
DEBUGFS_DEVSTATS_FILE(dot11RTSSuccessCount);
-
void debugfs_hw_add(struct ieee80211_local *local)
{
struct dentry *phyd = local->hw.wiphy->debugfsdir;
@@ -448,38 +386,60 @@ void debugfs_hw_add(struct ieee80211_loc
if (!statsd)
return;
- DEBUGFS_STATS_ADD(transmitted_fragment_count);
- DEBUGFS_STATS_ADD(multicast_transmitted_frame_count);
- DEBUGFS_STATS_ADD(failed_count);
- DEBUGFS_STATS_ADD(retry_count);
- DEBUGFS_STATS_ADD(multiple_retry_count);
- DEBUGFS_STATS_ADD(frame_duplicate_count);
- DEBUGFS_STATS_ADD(received_fragment_count);
- DEBUGFS_STATS_ADD(multicast_received_frame_count);
- DEBUGFS_STATS_ADD(transmitted_frame_count);
+ DEBUGFS_STATS_ADD(transmitted_fragment_count,
+ local->dot11TransmittedFragmentCount);
+ DEBUGFS_STATS_ADD(multicast_transmitted_frame_count,
+ local->dot11MulticastTransmittedFrameCount);
+ DEBUGFS_STATS_ADD(failed_count, local->dot11FailedCount);
+ DEBUGFS_STATS_ADD(retry_count, local->dot11RetryCount);
+ DEBUGFS_STATS_ADD(multiple_retry_count,
+ local->dot11MultipleRetryCount);
+ DEBUGFS_STATS_ADD(frame_duplicate_count,
+ local->dot11FrameDuplicateCount);
+ DEBUGFS_STATS_ADD(received_fragment_count,
+ local->dot11ReceivedFragmentCount);
+ DEBUGFS_STATS_ADD(multicast_received_frame_count,
+ local->dot11MulticastReceivedFrameCount);
+ DEBUGFS_STATS_ADD(transmitted_frame_count,
+ local->dot11TransmittedFrameCount);
#ifdef CONFIG_MAC80211_DEBUG_COUNTERS
- DEBUGFS_STATS_ADD(tx_handlers_drop);
- DEBUGFS_STATS_ADD(tx_handlers_queued);
- DEBUGFS_STATS_ADD(tx_handlers_drop_unencrypted);
- DEBUGFS_STATS_ADD(tx_handlers_drop_fragment);
- DEBUGFS_STATS_ADD(tx_handlers_drop_wep);
- DEBUGFS_STATS_ADD(tx_handlers_drop_not_assoc);
- DEBUGFS_STATS_ADD(tx_handlers_drop_unauth_port);
- DEBUGFS_STATS_ADD(rx_handlers_drop);
- DEBUGFS_STATS_ADD(rx_handlers_queued);
- DEBUGFS_STATS_ADD(rx_handlers_drop_nullfunc);
- DEBUGFS_STATS_ADD(rx_handlers_drop_defrag);
- DEBUGFS_STATS_ADD(rx_handlers_drop_short);
- DEBUGFS_STATS_ADD(rx_handlers_drop_passive_scan);
- DEBUGFS_STATS_ADD(tx_expand_skb_head);
- DEBUGFS_STATS_ADD(tx_expand_skb_head_cloned);
- DEBUGFS_STATS_ADD(rx_expand_skb_head);
- DEBUGFS_STATS_ADD(rx_expand_skb_head2);
- DEBUGFS_STATS_ADD(rx_handlers_fragments);
- DEBUGFS_STATS_ADD(tx_status_drop);
+ DEBUGFS_STATS_ADD(tx_handlers_drop, local->tx_handlers_drop);
+ DEBUGFS_STATS_ADD(tx_handlers_queued, local->tx_handlers_queued);
+ DEBUGFS_STATS_ADD(tx_handlers_drop_unencrypted,
+ local->tx_handlers_drop_unencrypted);
+ DEBUGFS_STATS_ADD(tx_handlers_drop_fragment,
+ local->tx_handlers_drop_fragment);
+ DEBUGFS_STATS_ADD(tx_handlers_drop_wep,
+ local->tx_handlers_drop_wep);
+ DEBUGFS_STATS_ADD(tx_handlers_drop_not_assoc,
+ local->tx_handlers_drop_not_assoc);
+ DEBUGFS_STATS_ADD(tx_handlers_drop_unauth_port,
+ local->tx_handlers_drop_unauth_port);
+ DEBUGFS_STATS_ADD(rx_handlers_drop, local->rx_handlers_drop);
+ DEBUGFS_STATS_ADD(rx_handlers_queued, local->rx_handlers_queued);
+ DEBUGFS_STATS_ADD(rx_handlers_drop_nullfunc,
+ local->rx_handlers_drop_nullfunc);
+ DEBUGFS_STATS_ADD(rx_handlers_drop_defrag,
+ local->rx_handlers_drop_defrag);
+ DEBUGFS_STATS_ADD(rx_handlers_drop_short,
+ local->rx_handlers_drop_short);
+ DEBUGFS_STATS_ADD(rx_handlers_drop_passive_scan,
+ local->rx_handlers_drop_passive_scan);
+ DEBUGFS_STATS_ADD(tx_expand_skb_head,
+ local->tx_expand_skb_head);
+ DEBUGFS_STATS_ADD(tx_expand_skb_head_cloned,
+ local->tx_expand_skb_head_cloned);
+ DEBUGFS_STATS_ADD(rx_expand_skb_head,
+ local->rx_expand_skb_head);
+ DEBUGFS_STATS_ADD(rx_expand_skb_head2,
+ local->rx_expand_skb_head2);
+ DEBUGFS_STATS_ADD(rx_handlers_fragments,
+ local->rx_handlers_fragments);
+ DEBUGFS_STATS_ADD(tx_status_drop,
+ local->tx_status_drop);
#endif
- DEBUGFS_STATS_ADD(dot11ACKFailureCount);
- DEBUGFS_STATS_ADD(dot11RTSFailureCount);
- DEBUGFS_STATS_ADD(dot11FCSErrorCount);
- DEBUGFS_STATS_ADD(dot11RTSSuccessCount);
+ DEBUGFS_DEVSTATS_ADD(dot11ACKFailureCount);
+ DEBUGFS_DEVSTATS_ADD(dot11RTSFailureCount);
+ DEBUGFS_DEVSTATS_ADD(dot11FCSErrorCount);
+ DEBUGFS_DEVSTATS_ADD(dot11RTSSuccessCount);
}
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -30,7 +30,6 @@ static ssize_t sta_ ##name## _read(struc
}
#define STA_READ_D(name, field) STA_READ(name, 20, field, "%d\n")
#define STA_READ_U(name, field) STA_READ(name, 20, field, "%u\n")
-#define STA_READ_LU(name, field) STA_READ(name, 20, field, "%lu\n")
#define STA_READ_S(name, field) STA_READ(name, 20, field, "%s\n")
#define STA_OPS(name) \
@@ -52,19 +51,7 @@ static const struct file_operations sta_
STA_FILE(aid, sta.aid, D);
STA_FILE(dev, sdata->name, S);
-STA_FILE(rx_packets, rx_packets, LU);
-STA_FILE(tx_packets, tx_packets, LU);
-STA_FILE(rx_bytes, rx_bytes, LU);
-STA_FILE(tx_bytes, tx_bytes, LU);
-STA_FILE(rx_duplicates, num_duplicates, LU);
-STA_FILE(rx_fragments, rx_fragments, LU);
-STA_FILE(rx_dropped, rx_dropped, LU);
-STA_FILE(tx_fragments, tx_fragments, LU);
-STA_FILE(tx_filtered, tx_filtered_count, LU);
-STA_FILE(tx_retry_failed, tx_retry_failed, LU);
-STA_FILE(tx_retry_count, tx_retry_count, LU);
STA_FILE(last_signal, last_signal, D);
-STA_FILE(wep_weak_iv_count, wep_weak_iv_count, LU);
static ssize_t sta_flags_read(struct file *file, char __user *userbuf,
size_t count, loff_t *ppos)
@@ -307,6 +294,13 @@ STA_OPS(ht_capa);
debugfs_create_file(#name, 0400, \
sta->debugfs.dir, sta, &sta_ ##name## _ops);
+#define DEBUGFS_ADD_COUNTER(name, field) \
+ if (sizeof(sta->field) == sizeof(u32)) \
+ debugfs_create_u32(#name, 0400, sta->debugfs.dir, \
+ (u32 *) &sta->field); \
+ else \
+ debugfs_create_u64(#name, 0400, sta->debugfs.dir, \
+ (u64 *) &sta->field);
void ieee80211_sta_debugfs_add(struct sta_info *sta)
{
@@ -339,20 +333,21 @@ void ieee80211_sta_debugfs_add(struct st
DEBUGFS_ADD(last_seq_ctrl);
DEBUGFS_ADD(agg_status);
DEBUGFS_ADD(dev);
- DEBUGFS_ADD(rx_packets);
- DEBUGFS_ADD(tx_packets);
- DEBUGFS_ADD(rx_bytes);
- DEBUGFS_ADD(tx_bytes);
- DEBUGFS_ADD(rx_duplicates);
- DEBUGFS_ADD(rx_fragments);
- DEBUGFS_ADD(rx_dropped);
- DEBUGFS_ADD(tx_fragments);
- DEBUGFS_ADD(tx_filtered);
- DEBUGFS_ADD(tx_retry_failed);
- DEBUGFS_ADD(tx_retry_count);
DEBUGFS_ADD(last_signal);
- DEBUGFS_ADD(wep_weak_iv_count);
DEBUGFS_ADD(ht_capa);
+
+ DEBUGFS_ADD_COUNTER(rx_packets, rx_packets);
+ DEBUGFS_ADD_COUNTER(tx_packets, tx_packets);
+ DEBUGFS_ADD_COUNTER(rx_bytes, rx_bytes);
+ DEBUGFS_ADD_COUNTER(tx_bytes, tx_bytes);
+ DEBUGFS_ADD_COUNTER(rx_duplicates, num_duplicates);
+ DEBUGFS_ADD_COUNTER(rx_fragments, rx_fragments);
+ DEBUGFS_ADD_COUNTER(rx_dropped, rx_dropped);
+ DEBUGFS_ADD_COUNTER(tx_fragments, tx_fragments);
+ DEBUGFS_ADD_COUNTER(tx_filtered, tx_filtered_count);
+ DEBUGFS_ADD_COUNTER(tx_retry_failed, tx_retry_failed);
+ DEBUGFS_ADD_COUNTER(tx_retry_count, tx_retry_count);
+ DEBUGFS_ADD_COUNTER(wep_weak_iv_count, wep_weak_iv_count);
}
void ieee80211_sta_debugfs_remove(struct sta_info *sta)
^ permalink raw reply
* Sheep on Meth is out with wings (?) - compat-wireless for linux-2.6.35-rc1
From: Luis R. Rodriguez @ 2010-06-02 1:52 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth; +Cc: linux-kernel
The sheep (Linus?) got on meth (Red Bull?) this weekend with a 2.6.35
release (huge guess on the meaning :)) so we get to give it wings with
a respective compat-wireless stable release [1] tarball based on it
[2]. This gives us the 2.6.35 802.11 subsystem, bluetooth subsystem
and new 802.11/bluetooth drivers (and a few Ethernet drivers [atlc1,
atl1e, atl1, atl2, b44]) compilable and installable on older kernels.
Please report any issues ASAP. For details on changes you can refer to
the ChangeLog-2.6.35-wireless [3].
While at it I went ahead and updated the older compat-wireless releases from:
compat-wireless-2.6.32.11.tar.bz2 --> compat-wireless-2.6.32.15.tar.bz2
compat-wireless-2.6.33.5.tar.bz2 --> compat-wireless-2.6.33.5.tar.bz2
The 2.6.34 kernel has not received a new extra version update yet so
that remains the same.
The $(git shortlog linux-2.6.34.y..linux-2.6.35.y) for the generic
kernel compatibility module [4] is:
Hauke Mehrtens (3):
compat: backport eth_change_mtu and eth_validate_addr
compat: move kparam_{block,unblock}_sysfs_write
compat: move usb_{alloc,free}_coherent
Luis R. Rodriguez (11):
compat: add new way to backport the usage of net_device_ops
compat: add the rest of the missing netdev_attach_ops()
compat: add the ndo_select_queue for netdev_attach_ops()
compat: add compat_version read-only module parameter
Modify the compat print
Add the COMPAT_BASE_TREE and COMPAT_BASE_TREE_VERSION
Add a COMPAT_PROJECT tag
Fix the syntax for the defines passed for compat
Remove the stupid SET_NETDEVOP
compat: create the udev directories for compat_firmware file
compat: backport USHRT_MAX, SHRT_MAX and SHRT_MIN
The $(git shortlog linux-2.6.34.y..linux-2.6.35.y) for compat-wireless
for this release so far is:
Bruno Randolf (1):
compat-wireless: fix 07-change-default-rate-alg.patch
Hauke Mehrtens (22):
compat-wireless: rename {free,alloc}_ieee80211 to {free,alloc}_libipw
compat-wireless: fix building of iwmc3200wifi
compat-wireless: remove some uneeded header files
compat-wireless: update config symbols
compat-wireless: add orinoco to compat-wireless
compat-wireless: remove rename {free,alloc}_ieee80211 patch
compat-wireless: refresh patch to apply again
compat-wireless: Backport changes in pcmcia system
compat-wireless: fix use of device_create
compat-wireless: use wireless_handlers for wext functions.
compat-wireless: backport convert multicast list to list_head.
compat-wireless: Remove use of sdio quirks attribute
compat-wireless: include net and trace includes form compat.
compat-wireless: refresh patches
compat-wireless: updates for orinoco
compat-wireless: backport pm_qos_{add,remove,update}_request
compat-wireless: make patches apply again
Revert "compat-wireless: fix 07-change-default-rate-alg.patch"
compat-wireless: Update Readme to reflect changes
compat-wireless: update clean scripts
compat-wireless: use /etc/init.d/ and not sudo service
compat-wireless: run refresh only on last applied directory
Luis R. Rodriguez (71):
./scripts/admin-update.sh refresh
./scripts/admin-update.sh refres
admin-update refresh the patches
driver-select: enable listing of ath9k_htc
driver-select: fix selecting ath9k_htc
admin-update refresh
Fix patches/06-header-changes.patch
Fix patches/13-trace.patch
admin-update refresh
admin-update refresh
admin-update refresh
Update USB makefile for new driver ipheth.o
./scripts/admin-update.sh refresh
compat-wireless: make use of new netdev_attach_ops() for orinoco
scripts/admin-update.sh refresh
Make rndis_host use netdev_attach_ops()
usbnet: use netdev_attach_ops()
rndis_wlan: fix backport of netdev_attach_ops() usage
rndis_wlan: use netdev_attach_ops()
mac80211: use netdev_attach_ops()
admin-update refresh
b44: use netdev_attach_ops()
ipw2100: use netdev_attach_ops()
ipw2200: use netdev_attach_ops()
libertas: use netdev_attach_ops()
mac80211_hwsim: use netdevice_attach_ops()
bnep, atl1e, atl1c: use netdev_attach_ops()
atl1: use netdev_attach_ops()
atl2: use netdev_attach_ops()
./scripts/admin-update.sh refresh
./scripts/admin-update.sh refresh
Change admin-update.sh to use system version files
Remove double line on admin-update.sh
Split up the NOSTDINC_FLAGS into a few lines
Use the defines to tag the compat module
Fix dependency on on WEXT
Fix the CREL compat-wireless release name on top level Makefile
Fix gen-compat-autoconf.sh for new version name changes
Fix scripts/driver-select due to new version changes
Add the compat to the unload of the modules
compat-wireless: add linux-next-pending, crap patch dirs and nagometer
rm -rf drivers when running scripts/admin-update.sh
compat-wireless: add a set of pending patches for linux-wireless
compat-wireless: add the Kconfig for drivers
compat-wireless: add some Atheros crap patches
compat-wireless: run ./scripts/compat_firmware_install
compat-wireless: remove some new files upon make clean
compat-wireless: add the new versioning files to .gitignore
Revert "compat-wireless: run ./scripts/compat_firmware_install"
compat-wireless: remove pending patches as of next-20100525
compat-wireless: ./scripts/admin-update.sh refresh
compat-wireless: fix backport code calculation
compat-wireless: only copy existing Kconfig files
compat-wireless: ./scripts/admin-update.sh -p refresh
compat-wireless: fix typo for used color for nagometer
compat-wireless: add new set of pending patches for 2010-05-25
compat-wireless: update the atheros crap patches
compat-wireless: clarify usage of linux-next-cherry-pick for bleeding edge
compat-wireless: remove two pending patches now upstream
compat-wireless: add pending fix patch for ath9k
compat-wireless: fixes offsets for
07-change-default-rate-alg.patch for 2.6.35-rc1
./scripts/admin-update.sh refresh
compat-wireless: fix hunks for crap/0002-ath9k-Add-pktlog-support.patch
compat-wireless: accept extra arguments for scripts/gen-stable-release.sh
Remove sucked in patch post 2.6.35-rc1
compat-wireless: add -n -p -c support for gen-stable-release.sh
compat-wireless: optimize branch selection on gen-stable-release.sh
compat-wireless: update the usage() print for gen-stable-release.sh
compat-wireless: fix target kernel expecations on gen-stable-release.sh
compat-wireless: Drop all the linux-next-pending patches
compat-wireless: remove the crap patches
Paul Fertser (1):
compat-wireless: driver-select: add b43 to the list
Pavel Roskin (9):
compat-wireless: disable rt2800 if crc_ccitt is not available
compat-wireless: disable wl1251 SPI and wl1271 if crc7 is not available
compat-wireless: add support for ath9k_htc
compat-wireless: update 22-multiqueue.patch for the current linux-next
compat-wireless: remove patch part dealing with net/net_namespace.h
compat-wireless: remove 13-trace.patch, it's handled in compat now
compat-wireless: remove 25-device_create.patch, it's handled by compat
compat-wireless: find the actual remote URL
compat-wireless: fix fallbacks for unknown branch, remote or remote URL
Walter Goldens (2):
compat-wireless, unload rt2800usb
compat-wireless: rt2x00 added to driver-select
If there are any questions please let me know, I'll push new updates
out as we move along with the rcs for 2.6.35.
[1] http://wireless.kernel.org/en/users/Download/stable
[2] http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.35/compat-wireless-2.6.35-rc1.tar.bz2
[3] http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.35/ChangeLog-2.6.35-rc1-wireless
[4] http://git.kernel.org/?p=linux/kernel/git/mcgrof/compat.git;a=summary
Luis
^ permalink raw reply
* compat-wireless branch for wireless-testing, "wl"
From: Luis R. Rodriguez @ 2010-06-02 2:20 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth; +Cc: Senthil Balasubramanian, Felix Fietkau
Some developers or users may not have linux-next.git or the
linux-2.6-allstable.git trees around and only keep a local
wireless-testing.git tree around. For those there is a branch now on
compat-wireless called "wl" (I got it from the localversion-wireless
file) which you can use to generate tarballs based on only the latest
wireless-testing updates. I've kept the pending and crap patches on it
for now but those will likely be removed once John starts merging
stuff back in.
I would prefer if people who do contribute on compat-wireless work
more on the master branch of compat-wireless and linux-next.git
instead though as this allows us to start backporting the next kernel
release headaches early on and not at cram time during or right after
the merge window. The "wl" branch is there to aid developers who do
not have the linux-next.git tree around or for Linux distributions who
currently may not care about updates on the kernel development cycle
on the other subsystems since wireless-testing only gets only 802.11
updates. An example is openwrt which uses only wireless-testing.git.
If you send me patches I will assume they are for the master branch of
compat-wireless unless otherwise specified. I will try to keep it the
wireless-testing branch updated but patches for it are always
welcomed. I will try to follow the upstream model though so would
first want the patches on the master branch of compat-wireless and
only then trickle them down for the "wl" branch. Since there is a time
delay between patches getting in wireless-next.git and linux-next.git
there may be an inherent delay between propagating patches down to the
"wl" branch. Not sure, we'll see. If you have a better idea of how to
handle this please let me know.
Luis
^ permalink raw reply
* [PATCH] p54spi: replace internal "cx3110x" name with "p54spi"
From: Luke-Jr @ 2010-06-02 2:16 UTC (permalink / raw)
To: linux-wireless; +Cc: linux-kernel, torvalds
While the comment removed in this patch claims board_n800.c uses "cx3110x", it was never merged to mainline like
this.
Mainlined board files for Nokia N8x0 devices are expected "p54spi", and thus don't work because the modalias is
"cx3110x".
To my knowledge, these devices are the only real-world use of p54spi, and will not work without this change.
Tested against my Nokia N810.
Signed-off-by: Luke Dashjr <luke-jr+git@utopios.org>
---
drivers/net/wireless/p54/p54spi.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index c8f09da..087bf06 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -697,9 +697,7 @@ static int __devexit p54spi_remove(struct spi_device *spi)
static struct spi_driver p54spi_driver = {
.driver = {
- /* use cx3110x name because board-n800.c uses that for the
- * SPI port */
- .name = "cx3110x",
+ .name = "p54spi",
.bus = &spi_bus_type,
.owner = THIS_MODULE,
},
@@ -733,3 +731,4 @@ module_exit(p54spi_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Christian Lamparter <chunkeey@web.de>");
MODULE_ALIAS("spi:cx3110x");
+MODULE_ALIAS("spi:p54spi");
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH]: libertas: fix uninitialized variable warning
From: Dan Williams @ 2010-06-02 5:29 UTC (permalink / raw)
To: Prarit Bhargava; +Cc: linux-wireless, linville
In-Reply-To: <20100527183717.24368.49914.sendpatchset@prarit.bos.redhat.com>
On Thu, 2010-05-27 at 14:41 -0400, Prarit Bhargava wrote:
> Fixes:
>
> drivers/net/wireless/libertas/rx.c: In function ‘process_rxed_802_11_packet’:
> drivers/net/wireless/libertas/rx.c:354: error: ‘radiotap_hdr.flags’ may be used uninitialized in this function
>
> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Acked-by: Dan Williams <dcbw@redhat.com>
>
> diff --git a/drivers/net/wireless/libertas/rx.c b/drivers/net/wireless/libertas/rx.c
> index e2b8d88..2319bde 100644
> --- a/drivers/net/wireless/libertas/rx.c
> +++ b/drivers/net/wireless/libertas/rx.c
> @@ -330,9 +330,8 @@ static int process_rxed_802_11_packet(struct lbs_private *priv,
> /* create the exported radio header */
>
> /* radiotap header */
> - radiotap_hdr.hdr.it_version = 0;
> - /* XXX must check this value for pad */
> - radiotap_hdr.hdr.it_pad = 0;
> + memset(&radiotap_hdr, 0, sizeof(radiotap_hdr));
> + /* XXX must check radiotap_hdr.hdr.it_pad for pad */
> radiotap_hdr.hdr.it_len = cpu_to_le16 (sizeof(struct rx_radiotap_hdr));
> radiotap_hdr.hdr.it_present = cpu_to_le32 (RX_RADIOTAP_PRESENT);
> radiotap_hdr.rate = convert_mv_rate_to_radiotap(prxpd->rx_rate);
> --
> 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
^ permalink raw reply
* Re: [PATCH] libertas: Fix ethtool reporting no WOL options supported if WOL is not already active
From: Dan Williams @ 2010-06-02 5:36 UTC (permalink / raw)
To: Sascha Silbe; +Cc: linux-wireless
In-Reply-To: <1274806808-24185-1-git-send-email-sascha-pgp@silbe.org>
On Sun, 2010-05-23 at 10:03 +0200, Sascha Silbe wrote:
> This patch fixes the libertas driver incorrectly reporting that Wake-on-LAN
> is not supported if Wake-on-LAN is currently disabled.
Acked-by: Dan Williams <dcbw@redhat.com>
but note that this patch submission isn't correctly formatted, you'll
need to add your Signed-off-by tag as described here:
http://lxr.linux.no/#linux+v2.6.34/Documentation/SubmittingPatches
around line 286 or so. I doubt John will pick the patch up until you've
done that.
> ---
> drivers/net/wireless/libertas/ethtool.c | 9 +++------
> 1 files changed, 3 insertions(+), 6 deletions(-)
>
> Without patch:
>
> root@xo15-minimal:~# ethtool wlan0
> Settings for wlan0:
> Supports Wake-on: d
> Wake-on: d
> root@xo15-minimal:~# ethtool -s wlan0 wol pum
> root@xo15-minimal:~# ethtool wlan0
> Settings for wlan0:
> Supports Wake-on: pumb
> Wake-on: pum
> root@xo15-minimal:~# ethtool -s wlan0 wol d
> root@xo15-minimal:~# ethtool wlan0
> Settings for wlan0:
> Supports Wake-on: d
> Wake-on: d
> root@xo15-minimal:~#
>
>
> With patch:
>
> xo-sascha:~# ethtool eth0
> Settings for eth0:
> Supports Wake-on: pumb
> Wake-on: d
> xo-sascha:~# ethtool -s eth0 wol pum
> xo-sascha:~# ethtool eth0
> Settings for eth0:
> Supports Wake-on: pumb
> Wake-on: pum
> xo-sascha:~# ethtool -s eth0 wol d
> xo-sascha:~# ethtool eth0
> Settings for eth0:
> Supports Wake-on: pumb
> Wake-on: d
>
> diff --git a/drivers/net/wireless/libertas/ethtool.c b/drivers/net/wireless/libertas/ethtool.c
> index 6eb9a88..4a337b7 100644
> --- a/drivers/net/wireless/libertas/ethtool.c
> +++ b/drivers/net/wireless/libertas/ethtool.c
> @@ -145,14 +145,11 @@ static void lbs_ethtool_get_wol(struct net_device *dev,
> {
> struct lbs_private *priv = dev->ml_priv;
>
> - if (priv->wol_criteria == 0xffffffff) {
> - /* Interface driver didn't configure wake */
> - wol->supported = wol->wolopts = 0;
> - return;
> - }
> -
> wol->supported = WAKE_UCAST|WAKE_MCAST|WAKE_BCAST|WAKE_PHY;
>
> + if (priv->wol_criteria == EHS_REMOVE_WAKEUP)
> + return;
> +
> if (priv->wol_criteria & EHS_WAKE_ON_UNICAST_DATA)
> wol->wolopts |= WAKE_UCAST;
> if (priv->wol_criteria & EHS_WAKE_ON_MULTICAST_DATA)
^ permalink raw reply
* Re: [PATCH] p54spi: replace internal "cx3110x" name with "p54spi"
From: Johannes Berg @ 2010-06-02 7:54 UTC (permalink / raw)
To: Luke-Jr; +Cc: linux-wireless, linux-kernel, torvalds
In-Reply-To: <201006012117.00432.luke@dashjr.org>
On Tue, 2010-06-01 at 21:16 -0500, Luke-Jr wrote:
> static struct spi_driver p54spi_driver = {
> .driver = {
> - /* use cx3110x name because board-n800.c uses that for the
> - * SPI port */
> - .name = "cx3110x",
> + .name = "p54spi",
> .bus = &spi_bus_type,
maybe that comment wasn't clear enough ... it needs to be that way to be
properly linked up against SPI.
johannes
^ 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