* Re: pull request: wireless 2013-06-06
From: Sujith Manoharan @ 2013-06-12 7:24 UTC (permalink / raw)
To: David Miller; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <20130612.002103.916991474696226731.davem@davemloft.net>
David Miller wrote:
> John, I also don't like the ATK9K Kconfig option name change added in
> this pull request, this is exactly the kind of thing that drives
> Linus insane.
>
> Change the default, fine, but changing the name is unnecssary churn
> and adds a new config prompt that people are going to respond to
> incorrectly when they type "make oldconfig"
This was Linus' suggestion: https://patchwork.kernel.org/patch/2676971/
The RH bugzilla appears to be down at the moment, but more background
for the bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=927191
Sujith
^ permalink raw reply
* Re: pull request: wireless 2013-06-06
From: David Miller @ 2013-06-12 7:21 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20130611.222706.1492583255605214982.davem@davemloft.net>
John, I also don't like the ATK9K Kconfig option name change added in
this pull request, this is exactly the kind of thing that drives
Linus insane.
Change the default, fine, but changing the name is unnecssary churn
and adds a new config prompt that people are going to respond to
incorrectly when they type "make oldconfig"
^ permalink raw reply
* Re: [PATCH] mwifiex: Add module parameter for regdomain
From: Kalle Valo @ 2013-06-12 7:15 UTC (permalink / raw)
To: Bing Zhao
Cc: linux-wireless, John W. Linville, Amitkumar Karwar, Avinash Patil,
Yogesh Ashok Powar, Nishant Sarmukadam, Frank Huang, Paul Stewart
In-Reply-To: <1370904007-10959-1-git-send-email-bzhao@marvell.com>
Bing Zhao <bzhao@marvell.com> writes:
> From: Avinash Patil <patila@marvell.com>
>
> Allow a regulatory domain country code to be specified at boot
> using a module argument. This overrides the firmware regulatory
> mode.
>
> This patch also enables uAP to operate in 11a mode with hostapd.
>
> Signed-off-by: Avinash Patil <patila@marvell.com>
> Signed-off-by: Paul Stewart <pstew@chromium.org>
> Signed-off-by: Bing Zhao <bzhao@marvell.com>
This looks ugly. Why can't you use the proper nl80211 interface and
instead want to add a driver specific hack?
--
Kalle Valo
^ permalink raw reply
* Re: pull-request: mac80211 2013-06-12
From: Johannes Berg @ 2013-06-12 7:14 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <1371019363.8601.6.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]
Let's try that again :-)
Following davem's complaint about my patch, here's a new pull request
w/o the patch he was complaining about, but instead with the const fix
rolled into the fix.
I have a fix for radar detection, one for rate control and a workaround
for broken HT APs which is a regression fix because we didn't rely on
them to be correct before.
johannes
The following changes since commit ac20976dcaeea3e77e40e9aac8f3799d2a22ea2b:
mac80211: Allow single vif mac address change with addr_mask (2013-05-27 11:26:48 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git for-john
for you to fetch changes up to 795d855d56c6d172f50a974f603ba923ac93ee76:
mac80211: Fix rate control mask matching call (2013-06-12 09:12:43 +0200)
----------------------------------------------------------------
Johannes Berg (1):
mac80211: work around broken APs not including HT info
Simon Wunderlich (2):
mac80211: abort CAC in stop_ap()
mac80211: Fix rate control mask matching call
net/mac80211/cfg.c | 6 ++++
net/mac80211/ieee80211_i.h | 5 +--
net/mac80211/mlme.c | 87 ++++++++++++++++++++++++++++++++++++++++++----
net/mac80211/rate.c | 2 +-
net/mac80211/util.c | 4 +--
5 files changed, 92 insertions(+), 12 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: pull request: wireless 2013-06-06
From: Johannes Berg @ 2013-06-12 7:09 UTC (permalink / raw)
To: David Miller; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <20130612.000711.759531077550828193.davem@davemloft.net>
On Wed, 2013-06-12 at 00:07 -0700, David Miller wrote:
> From: Johannes Berg <johannes@sipsolutions.net>
> Date: Wed, 12 Jun 2013 08:26:49 +0200
>
> > On Tue, 2013-06-11 at 22:27 -0700, David Miller wrote:
> >> From: "John W. Linville" <linville@tuxdriver.com>
> >> Date: Thu, 6 Jun 2013 15:09:30 -0400
> >>
> >> > Johannes Berg (2):
> >> > mac80211: constify ieee802_11_parse_elems() argument
> >>
> >> Such cleanups are absolutely, positively, not appropriate at this
> >> time.
> >
> > My other fix depends on this to not have a const warning. I can add a
> > cast to pretend the input isn't const at this point, but that seemed
> > like a bad idea as well.
>
> I would combine the two changes into one commit, because then this
> necessity is clear and you can even explain this in the commit message
> so that there is no argument about the justification.
Sure, I can do that too.
johannes
^ permalink raw reply
* Re: pull request: wireless 2013-06-06
From: David Miller @ 2013-06-12 7:07 UTC (permalink / raw)
To: johannes; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <1371018409.8601.2.camel@jlt4.sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Wed, 12 Jun 2013 08:26:49 +0200
> On Tue, 2013-06-11 at 22:27 -0700, David Miller wrote:
>> From: "John W. Linville" <linville@tuxdriver.com>
>> Date: Thu, 6 Jun 2013 15:09:30 -0400
>>
>> > Johannes Berg (2):
>> > mac80211: constify ieee802_11_parse_elems() argument
>>
>> Such cleanups are absolutely, positively, not appropriate at this
>> time.
>
> My other fix depends on this to not have a const warning. I can add a
> cast to pretend the input isn't const at this point, but that seemed
> like a bad idea as well.
I would combine the two changes into one commit, because then this
necessity is clear and you can even explain this in the commit message
so that there is no argument about the justification.
Thanks.
^ permalink raw reply
* pull-request: mac80211 2013-06-12
From: Johannes Berg @ 2013-06-12 6:42 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]
John,
Following davem's complaint about my patch, here's a new pull request
w/o the patch he was complaining about, but instead with an ugly void*
cast to suppress the compiler warning.
I have a fix for radar detection, one for rate control and a workaround
for broken HT APs which is a regression fix because we didn't rely on
them to be correct before.
johannes
The following changes since commit ac20976dcaeea3e77e40e9aac8f3799d2a22ea2b:
mac80211: Allow single vif mac address change with addr_mask (2013-05-27 11:26:48 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git for-john
for you to fetch changes up to be0d678f67ce75ad7099d067e0de6c72f61db27f:
mac80211: Fix rate control mask matching call (2013-06-12 08:37:36 +0200)
----------------------------------------------------------------
Johannes Berg (1):
mac80211: work around broken APs not including HT info
Simon Wunderlich (2):
mac80211: abort CAC in stop_ap()
mac80211: Fix rate control mask matching call
net/mac80211/cfg.c | 6 ++++
net/mac80211/mlme.c | 87 ++++++++++++++++++++++++++++++++++++++++++++++++-----
net/mac80211/rate.c | 2 +-
3 files changed, 87 insertions(+), 8 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] mac80211: ath9k: Use RCU protection calling ieee80211_get_tx_rates
From: Kalle Valo @ 2013-06-12 6:37 UTC (permalink / raw)
To: Johannes Berg
Cc: Calvin Owens, Luis R. Rodriguez, John W. Linville, Felix Fietkau,
linux-wireless, linux-kernel, ath9k-devel, netdev
In-Reply-To: <1370980523.8356.70.camel@jlt4.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> Now the subject should no longer say "mac80211:" :)
It did have a change to mac80211.h as well, but IMHO that should be in a
separate patch.
--
Kalle Valo
^ permalink raw reply
* Re: pull request: wireless 2013-06-06
From: Johannes Berg @ 2013-06-12 6:26 UTC (permalink / raw)
To: David Miller; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <20130611.222706.1492583255605214982.davem@davemloft.net>
On Tue, 2013-06-11 at 22:27 -0700, David Miller wrote:
> From: "John W. Linville" <linville@tuxdriver.com>
> Date: Thu, 6 Jun 2013 15:09:30 -0400
>
> > Johannes Berg (2):
> > mac80211: constify ieee802_11_parse_elems() argument
>
> Such cleanups are absolutely, positively, not appropriate at this
> time.
My other fix depends on this to not have a const warning. I can add a
cast to pretend the input isn't const at this point, but that seemed
like a bad idea as well.
johannes
^ permalink raw reply
* Re: pull request: wireless 2013-06-06
From: David Miller @ 2013-06-12 5:27 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20130606190929.GB18827@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 6 Jun 2013 15:09:30 -0400
> Johannes Berg (2):
> mac80211: constify ieee802_11_parse_elems() argument
Such cleanups are absolutely, positively, not appropriate at this
time.
Sorry.
I still can't pull this.
^ permalink raw reply
* Re: Intel Centrino Wireless-N 2200 Tech Support
From: Edward Seyler @ 2013-06-12 4:04 UTC (permalink / raw)
To: Emmanuel Grumbach; +Cc: linux-wireless
In-Reply-To: <CANUX_P0ddkfEY+hxir8=PGH1ocS5FQRFwvrm2otj3eTUkwJ+Gw@mail.gmail.com>
>
> This is really weird...
> Can you compile with CONFIG_IWLWIFI_DEBUG?
> I will then need a few debug prints.
> I recently changed this flow to speed up the fw loading process on
> platform that can afford a bit amount of DMA, but I just tested it
> (again) and it works even if there is not big DMA chunk available.
I compiled with CONFIG_IWLWIFI_DEBUG. I also absent mindedly enabled CONFIG_IWLWIFI_DEBUG_EXPERIMENTAL_UCODE--please let me know if you do not want this. I can provide other debugging output, but I am sending this now in case I cannot respond promptly.
# echo 0xFFFFFFFF > /sys/module/iwlwifi/parameters/debug
# dmesg | grep iwl
[ 10.116748] iwlwifi 0000:03:00.0: irq 43 for MSI/MSI-X
[ 10.234866] iwlwifi 0000:03:00.0: loaded firmware version 18.168.6.1
[ 10.362940] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG enabled
[ 10.362952] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
[ 10.362957] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING enabled
[ 10.362963] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TESTMODE disabled
[ 10.362967] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_P2P disabled
[ 10.362974] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R) Wireless-N 2200 BGN, REV=0x104
[ 10.363003] iwlwifi 0000:03:00.0: L1 Disabled; Enabling L0S
[ 10.377474] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[ 1180.920142] iwlwifi 0000:03:00.0: U iwlagn_mac_start enter
[ 1180.920152] iwlwifi 0000:03:00.0: I iwl_prep_station Add STA to driver ID 15: ff:ff:ff:ff:ff:ff
[ 1180.920158] iwlwifi 0000:03:00.0: I iwl_prep_station Add STA to driver ID 14: ff:ff:ff:ff:ff:ff
[ 1180.920163] iwlwifi 0000:03:00.0: U iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
[ 1180.920171] iwlwifi 0000:03:00.0: U iwl_pcie_set_hw_ready hardware ready
[ 1180.920173] iwlwifi 0000:03:00.0: U iwl_enable_rfkill_int Enabling rfkill interrupt
[ 1180.920180] iwlwifi 0000:03:00.0: U iwl_pcie_apm_init Init card's basic functions
[ 1180.920196] iwlwifi 0000:03:00.0: L1 Disabled; Enabling L0S
[ 1180.928171] iwlwifi 0000:03:00.0: Radio type=0x2-0x0-0x0
[ 1180.929423] iwlwifi 0000:03:00.0: U iwl_enable_interrupts Enabling interrupts
[ 1180.929431] iwlwifi 0000:03:00.0: U iwl_pcie_load_section [0] uCode section being loaded...
[ 1185.926627] iwlwifi 0000:03:00.0: Failed to load firmware chunk!
[ 1185.926967] iwlwifi 0000:03:00.0: Could not load the [0] uCode section
[ 1185.927256] iwlwifi 0000:03:00.0: U iwl_disable_interrupts Disabled interrupts
[ 1185.927442] iwlwifi 0000:03:00.0: U iwl_pcie_apm_stop Stop card, put in low power state
[ 1185.927449] iwlwifi 0000:03:00.0: U iwl_pcie_apm_stop_master stop master
[ 1185.927465] iwlwifi 0000:03:00.0: U iwl_disable_interrupts Disabled interrupts
[ 1185.927467] iwlwifi 0000:03:00.0: U iwl_enable_rfkill_int Enabling rfkill interrupt
[ 1185.927470] iwlwifi 0000:03:00.0: Failed to run INIT ucode: -110
[ 1185.927712] iwlwifi 0000:03:00.0: U iwl_down iwlwifi is going down
[ 1185.927715] iwlwifi 0000:03:00.0: U iwl_scan_cancel_timeout Scan cancel timeout
[ 1185.927718] iwlwifi 0000:03:00.0: U iwl_do_scan_abort Not performing scan to abort
[ 1185.927721] iwlwifi 0000:03:00.0: U iwl_clear_ucode_stations Clearing ucode stations in driver
[ 1185.927725] iwlwifi 0000:03:00.0: U iwl_clear_ucode_stations No active stations found to be cleared
[ 1185.927733] iwlwifi 0000:03:00.0: U iwl_disable_interrupts Disabled interrupts
[ 1185.927738] iwlwifi 0000:03:00.0: U iwl_pcie_apm_stop Stop card, put in low power state
[ 1185.927744] iwlwifi 0000:03:00.0: U iwl_pcie_apm_stop_master stop master
[ 1185.927759] iwlwifi 0000:03:00.0: U iwl_disable_interrupts Disabled interrupts
[ 1185.927761] iwlwifi 0000:03:00.0: U iwl_enable_rfkill_int Enabling rfkill interrupt
[ 1185.927763] iwlwifi 0000:03:00.0: Unable to initialize device.
^ permalink raw reply
* Re: kmemleak report in 3.9.5+, related to cfg80211_inform_bss_frame
From: Ben Greear @ 2013-06-12 0:36 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
In-Reply-To: <51B77594.20000@candelatech.com>
On 06/11/2013 12:08 PM, Ben Greear wrote:
> On 06/11/2013 12:00 PM, Ben Greear wrote:
>> I see several reports similar to the one below while doing some
>> kmemleak testing on my 3.9.5+ tree (with local patches applied):
>>
>> http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.9.dev.y/.git;a=summary
>> The kmemleak report is below:
>>
>>
>> unreferenced object 0xffff8801c8e41e78 (size 192):
>> comm "kworker/u:2", pid 157, jiffies 4295509873 (age 86582.869s)
>> hex dump (first 32 bytes):
>> 41 0d 00 30 02 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b A..0....kkkkkkkk
>> 6b 6b 6b 6b 6b 6b 6b 6b 69 00 00 00 00 0c 2e 32 kkkkkkkki......2
>> backtrace:
>> [<ffffffff815de7bf>] kmemleak_alloc+0x73/0x98
>> [<ffffffff8118b4d4>] slab_post_alloc_hook+0x28/0x2a
>> [<ffffffff8118d605>] __kmalloc+0xf9/0x122
>> [<ffffffffa027cb27>] cfg80211_inform_bss_frame+0x114/0x1f8 [cfg80211]
>> [<ffffffffa03d6865>] ieee80211_bss_info_update+0x66/0x21f [mac80211]
>> [<ffffffffa040aec6>] ieee80211_rx_bss_info+0x12f/0x1ca [mac80211]
>> [<ffffffffa040b017>] ieee80211_rx_mgmt_probe_resp+0xb6/0x197 [mac80211]
>> [<ffffffffa040e8a3>] ieee80211_sta_rx_queued_mgmt+0xdd/0x60e [mac80211]
>> [<ffffffffa03df0ee>] ieee80211_iface_work+0x238/0x2cc [mac80211]
>> [<ffffffff810b0cd3>] process_one_work+0x292/0x42e
>> [<ffffffff810b36af>] worker_thread+0x14f/0x264
>> [<ffffffff810b7bea>] kthread+0xc7/0xcf
>> [<ffffffff815f64ec>] ret_from_fork+0x7c/0xb0
>> [<ffffffffffffffff>] 0xffffffffffffffff
Something else came to mind on this.
To determine if we should delete an old pointer to memory,
we do an rcu_access_pointer to read the old value, and
we are assigning with rcu_assign_pointer.
Could this be racing so that rcu_access_pointer returns NULL
when looking for the old pointer, but other threads manage
to set the pointer more than once, leaking all but the last
to be set?
For instance, this code:
if (found) {
/* Update IEs */
if (rcu_access_pointer(tmp->pub.proberesp_ies)) {
const struct cfg80211_bss_ies *old;
old = rcu_access_pointer(found->pub.proberesp_ies);
rcu_assign_pointer(found->pub.proberesp_ies,
tmp->pub.proberesp_ies);
/* Override possible earlier Beacon frame IEs */
rcu_assign_pointer(found->pub.ies,
tmp->pub.proberesp_ies);
if (old)
kfree_rcu((struct cfg80211_bss_ies *)old,
rcu_head);
I don't see a huge number of leaks..but they are definitely
accumulating if kmemleak is to be believed...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Ironic kernel panic when changing STATION channel type (b/t HT20 and HT40)
From: wen @ 2013-06-11 23:44 UTC (permalink / raw)
To: linux-wireless
Hello developers!
I am new to linux wireless driver coding, and is trying to implement
Notify Channel Width Action frame.
Along with sending the action frame to request AP send data using
specified bandwidth (20MHZ or 40MHZ), STATION also need to change its
channel type accordingly (b/t HT20 and HT40).
For now, my implementation on action frame and updating sending rate b/t
HT20 rates and HT40 rates works fine, but not for channel type change.
One way I tried to change channel type is calling
ieee80211_set_channel_type() primitive. This can change channel type as
wish on AP side, but ironically, it causes kernel panic (inside
ieee80211_set_channel_type() function) when called exactly on STATION,
even the same way as it is called on AP.
Another way I tried is through calling drv_config(), which causes kernel
panic on both AP and STATION side also.
I truly appreciate it if you could help me with your rich experience!
Thanks in advance!
Wen
^ permalink raw reply
* Re: where is ath9k debugfs?
From: Pat Erley @ 2013-06-11 22:51 UTC (permalink / raw)
To: George Nychis; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CA+7oyge=p5uTgCc+Veq-fZrH2Dd6Ew7OR8m0mz+e7+Ze+LNcYQ@mail.gmail.com>
On 06/11/2013 12:40 PM, George Nychis wrote:
> I have configured my kernel to use ath9k debugfs:
> $ grep ATH9K_DEBUGFS /boot/config-`uname -r`
> CONFIG_ATH9K_DEBUGFS=y
>
> The location of these debugfs files should be in
> /sys/kernel/debug/ath9k according to:
> http://wireless.kernel.org/en/users/Drivers/ath9k/debug#Debugfs_files_for_ath9k
>
> However, when I load the modules and plug in an ath9k device, I do not
> get any ath9k debugfs files:
> root@parallels:/sys# find /sys -name ath9k
> root@parallels:/sys# find /sys -name rx_chainmask
> root@parallels:/sys# find /sys -name disable_ani
> root@parallels:/sys#
>
> I do get the ieee80211 debug, though:
> # ls -l /sys/kernel/debug/ieee80211/
> total 0
> drwxr-xr-x 6 root root 0 Jun 11 12:30 phy0
>
> Do I need to pass some parameter to the kernel module on load to get
> the ath9k debugfs? Am I missing something else?
>
> Thanks!
> George
Hi George,
When you say 'plug in an ath9k device' I assume you mean you plug it in
before you boot? There aren't any ath9k devices that I know of that use
USB. I believe they're all handled by ath9k_htc.
Aside from that, you found the right spot
(/sys/kernel/debug/ieee80211/phyN) for it to live. What does dmesg say
when you plug in/boot with the device?
Pat
^ permalink raw reply
* Re: [PATCH] rtlwifi: initialize local array and set value.
From: John W. Linville @ 2013-06-11 20:59 UTC (permalink / raw)
To: Yunlian Jiang; +Cc: linux-wireless, Larry.Finger, chaoming_li, davem
In-Reply-To: <CAMsPy2ufj3TjdWbpPKq7QqS_ELAmqhA_Djo6dwcevLym2PCkDQ@mail.gmail.com>
It's in wireless-next...
commit ec71997eff2231098212a99934c0fb987a9e6b04
Author: Yunlian Jiang <yunlian@google.com>
Date: Fri May 31 14:45:21 2013 -0700
rtlwifi: initialize local array and set value.
GCC 4.8 is spitting out uninitialized-variable warnings against
"drivers/net/wireless/rtlwifi/rtl8192de/dm.c".
drivers/net/wireless/rtlwifi/rtl8192de/dm.c:941:31:
error: 'ofdm_index_old[1]' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
rtlpriv->dm.ofdm_index[i] = ofdm_index_old[i];
This patch adds initialization to the variable and properly sets its value.
Signed-off-by: Yunlian Jiang <yunlian@google.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
On Tue, Jun 11, 2013 at 01:00:00PM -0700, Yunlian Jiang wrote:
> John,
> Any update for this patch?
> Thanks
>
>
> On Mon, Jun 3, 2013 at 2:17 PM, Yunlian Jiang <yunlian@google.com> wrote:
>
> > John,
> > Yes, I intended for it to be there and please add it.
> >
> > Thanks
> >
> >
> > On Mon, Jun 3, 2013 at 2:07 PM, John W. Linville <linville@tuxdriver.com>wrote:
> >
> >> That would be perfectly fine. Or, you can just acknowledge that you
> >> intended for it to be there and I can add it myself.
> >>
> >> John
> >>
> >> On Mon, Jun 03, 2013 at 12:48:31PM -0700, Yunlian Jiang wrote:
> >> > Sorry, can I re-upload the patch and set Signed-off-by me?
> >> >
> >> > Thanks
> >> >
> >> >
> >> > On Mon, Jun 3, 2013 at 12:39 PM, John W. Linville <
> >> linville@tuxdriver.com>wrote:
> >> >
> >> > > This patch is missing a Signed-off-by line...
> >> > >
> >> > > On Fri, May 31, 2013 at 02:45:21PM -0700, Yunlian Jiang wrote:
> >> > > > GCC 4.8 is spitting out uninitialized-variable warnings against
> >> > > > "drivers/net/wireless/rtlwifi/rtl8192de/dm.c".
> >> > > >
> >> > > > drivers/net/wireless/rtlwifi/rtl8192de/dm.c:941:31:
> >> > > > error: 'ofdm_index_old[1]' may be used uninitialized in this
> >> > > > function [-Werror=maybe-uninitialized]
> >> > > > rtlpriv->dm.ofdm_index[i] = ofdm_index_old[i];
> >> > > >
> >> > > > This patch adds initialization to the variable and properly sets its
> >> > > value.
> >> > > > ---
> >> > > > drivers/net/wireless/rtlwifi/rtl8192de/dm.c | 2 +-
> >> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> >> > > >
> >> > > > diff --git a/drivers/net/wireless/rtlwifi/rtl8192de/dm.c
> >> > > b/drivers/net/wireless/rtlwifi/rtl8192de/dm.c
> >> > > > index 19a7655..47875ba 100644
> >> > > > --- a/drivers/net/wireless/rtlwifi/rtl8192de/dm.c
> >> > > > +++ b/drivers/net/wireless/rtlwifi/rtl8192de/dm.c
> >> > > > @@ -842,7 +842,7 @@ static void
> >> > > rtl92d_dm_txpower_tracking_callback_thermalmeter(
> >> > > > long val_y, ele_c = 0;
> >> > > > u8 ofdm_index[2];
> >> > > > s8 cck_index = 0;
> >> > > > - u8 ofdm_index_old[2];
> >> > > > + u8 ofdm_index_old[2] = {0, 0};
> >> > > > s8 cck_index_old = 0;
> >> > > > u8 index;
> >> > > > int i;
> >> > > > --
> >> > > > 1.8.2.1
> >> > > >
> >> > > > --
> >> > > > 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
> >> > > >
> >> > >
> >> > > --
> >> > > John W. Linville Someday the world will need a hero,
> >> and you
> >> > > linville@tuxdriver.com might be all we have. Be
> >> ready.
> >> > >
> >>
> >> --
> >> John W. Linville Someday the world will need a hero, and
> >> you
> >> linville@tuxdriver.com might be all we have. Be ready.
> >>
> >
> >
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 00/22] brcmfmac: firmware-signalling fixes and cleanup
From: John W. Linville @ 2013-06-11 20:59 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <51B7881B.9000408@broadcom.com>
On Tue, Jun 11, 2013 at 10:27:07PM +0200, Arend van Spriel wrote:
> On 06/06/2013 01:17 PM, Arend van Spriel wrote:
> >This series is intended for v3.11 and resolves a number of issues observed
> >testing firmware-signalling feature with power-save stations and P2P scenarios
> >as well as several patches for code cleanup.
> >
> >The series applies to the master branch of the wireless-next repository.
>
> Hi John,
>
> Did this series for 3.11 get lost somewhere or is it still on your queue?
>
> Regards,
> Arend
I have it...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH v2 2/2] mac80211: update mesh beacon on workqueue
From: Thomas Pedersen @ 2013-06-11 20:32 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, open80211s, Bob Copeland
In-Reply-To: <1370950216.8356.10.camel@jlt4.sipsolutions.net>
On Tue, Jun 11, 2013 at 4:30 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2013-06-10 at 13:17 -0700, Thomas Pedersen wrote:
>
>> + struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
>> + u32 bit;
>> +
>> + /* if we race with running work, worst case this work becomes a noop */
>> + for_each_set_bit(bit, (unsigned long *)&changed,
>> + sizeof(changed) * BITS_PER_BYTE)
>
> This isn't valid, it happens to work on little endian platforms but will
> fail on big endian 64-bit ones, because you have this in memory (0 is
> the lowest order nibble):
>
> 76 54 32 10 -- -- -- --
> and now you point an unsigned long pointer to it, so you interpret the
> "--" as the lowest bits.
OK I was just trying to make the compiler happy, but that makes sense.
Assigning changed (u32) to an unsigned long then getting the address
of that should move the u32 into the lower half of an unsigned long on
a 64-bit BE system?
Thanks for explaining this.
> More generally, I'd argue that mesh is being a bit odd here, flushing
> stations turing mesh stop can and will actually cause a BSS info update
> after the mesh interface has already been stopped (beaconing has been
> disabled in the driver.) This seems rather odd. Maybe it would be better
> to move the beacon update out of mesh_sta_cleanup() and into
> ieee80211_mesh_housekeeping() in some way? Although it'd also have to be
> done in the station handling in cfg.c but that shouldn't be a problem?
Yes it is odd to queue a bss info update but never do so. I don't know
if it really matters though. The problem is mesh_sta_cleanup() is
called from several paths: mac80211 mesh runtime, stop_mesh(), and
cfg80211. I think this is a fairly clean way of satisfying all the
users (mesh work queued from stop_mesh() is a noop if we check
ifmsh->mesh_id_len instead of the wdev->mesh_id_len).
It sounds like you'd like beacon updates to be asynchronous, which
this patch already accomplishes :)
> Note also that the way you did this is rather odd, ieee80211_stop_mesh()
> could cause to schedule out to the workqueue for the update, but then
> the update won't happen. It's a bit racy though, because you could stop
> and restart the mesh and then the workqueue runs or something? Overall
> this approach seems a bit brittle?
I guess if you clear the ifmsh->wrkq_flags at the end of stop_mesh()
this wouldn't happen. Also as long as the check to ensure no mesh work
is performed while not joined is in place, we should be ok.
--
Thomas
^ permalink raw reply
* Re: [PATCH 00/22] brcmfmac: firmware-signalling fixes and cleanup
From: Arend van Spriel @ 2013-06-11 20:27 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <1370517487-14395-1-git-send-email-arend@broadcom.com>
On 06/06/2013 01:17 PM, Arend van Spriel wrote:
> This series is intended for v3.11 and resolves a number of issues observed
> testing firmware-signalling feature with power-save stations and P2P scenarios
> as well as several patches for code cleanup.
>
> The series applies to the master branch of the wireless-next repository.
Hi John,
Did this series for 3.11 get lost somewhere or is it still on your queue?
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] mac80211: ath9k: Use RCU protection calling ieee80211_get_tx_rates
From: Johannes Berg @ 2013-06-11 19:55 UTC (permalink / raw)
To: Calvin Owens
Cc: Luis R. Rodriguez, John W. Linville, Felix Fietkau,
linux-wireless, linux-kernel, ath9k-devel, netdev
In-Reply-To: <20130611171304.GA2189@gmail.com>
Now the subject should no longer say "mac80211:" :)
However... given that ieee80211_get_tx_rates() actually *copies* the
rates into the parameter, I guess it should do the rcu_read_lock()
internally. I guess I wasn't paying attention previously. Felix?
johannes
^ permalink raw reply
* Re: [PATCH] carl9170: make use of the new rate control API
From: Johannes Berg @ 2013-06-11 19:53 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linville, Thomas Hühn, linux-wireless, nbd
In-Reply-To: <201306112149.09768.chunkeey@googlemail.com>
On Tue, 2013-06-11 at 21:49 +0200, Christian Lamparter wrote:
> > > As I just saw an ath9k patch for rcu protection when ieee80211_get_tx_rates() is called.
> > > Should this be done in carl9170 as well ?
> >
> > I think that patch is wrong actually, probably should just do the rcu
> > protection inside the function. However the patch is completely wrong
> > anyway (C isn't python) so ...
> Uh, that's confusing. We are now talking about the patch from Thomas, right?
> If so: the previous "new rate control api" feature patch for carl9170 should
> be fine in this regard.
No, Calvin Owens's patch.
johannes
^ permalink raw reply
* Re: [PATCH] carl9170: make use of the new rate control API
From: Christian Lamparter @ 2013-06-11 19:49 UTC (permalink / raw)
To: linville; +Cc: Johannes Berg, Thomas Hühn, linux-wireless, nbd
In-Reply-To: <1370978668.8356.67.camel@jlt4.sipsolutions.net>
On Tuesday, June 11, 2013 09:24:28 PM Johannes Berg wrote:
> On Tue, 2013-06-11 at 21:17 +0200, Thomas Hühn wrote:
> > Hi Christian,
> >
> > I have not seen that patch in wireless-next, that's why I overlooked it... sorry.
You are right and it's not in wireless-testing.git either. That's a bit odd.
John,
was this patch overlooked/lost or was there a problem with it?
(Or: can you please put it into wireless-next)
> > > carl9170 already supports the new rate control API (Patch from 2013-04-23).
> > > <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/107657>
> > >
> > > Can you please tell me what you think is missing?
> > >
> >
> > You patch looks good to me.
> > As I just saw an ath9k patch for rcu protection when ieee80211_get_tx_rates() is called.
> > Should this be done in carl9170 as well ?
>
> I think that patch is wrong actually, probably should just do the rcu
> protection inside the function. However the patch is completely wrong
> anyway (C isn't python) so ...
Uh, that's confusing. We are now talking about the patch from Thomas, right?
If so: the previous "new rate control api" feature patch for carl9170 should
be fine in this regard.
Regards,
Chr
^ permalink raw reply
* Re: [PATCH] carl9170: make use of the new rate control API
From: Johannes Berg @ 2013-06-11 19:24 UTC (permalink / raw)
To: Thomas Hühn; +Cc: Christian Lamparter, linville, linux-wireless, nbd
In-Reply-To: <1E3747D2-BD9C-4136-B17F-9227E24136D5@net.t-labs.tu-berlin.de>
On Tue, 2013-06-11 at 21:17 +0200, Thomas Hühn wrote:
> Hi Christian,
>
> I have not seen that patch in wireless-next, that's why I overlooked it… sorry.
>
> >
> > ???
> >
> > carl9170 already supports the new rate control API (Patch from 2013-04-23).
> > <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/107657>
> >
> > Can you please tell me what you think is missing?
> >
>
> You patch looks good to me.
> As I just saw an ath9k patch for rcu protection when ieee80211_get_tx_rates() is called.
> Should this be done in carl9170 as well ?
I think that patch is wrong actually, probably should just do the rcu
protection inside the function. However the patch is completely wrong
anyway (C isn't python) so ...
johannes
^ permalink raw reply
* Re: [PATCH] carl9170: make use of the new rate control API
From: Thomas Hühn @ 2013-06-11 19:17 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linville, linux-wireless, nbd, johannes
In-Reply-To: <201306111946.22682.chunkeey@googlemail.com>
Hi Christian,
I have not seen that patch in wireless-next, that's why I overlooked it… sorry.
>
> ???
>
> carl9170 already supports the new rate control API (Patch from 2013-04-23).
> <http://permalink.gmane.org/gmane.linux.kernel.wireless.general/107657>
>
> Can you please tell me what you think is missing?
>
You patch looks good to me.
As I just saw an ath9k patch for rcu protection when ieee80211_get_tx_rates() is called.
Should this be done in carl9170 as well ?
Greetinsg,
Thomas
> Regards,
> Chr
>
> --
> 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: [RFT/RFC 0/4] iwlegacy: workaround for firmware frame tx rejection
From: Jake Edge @ 2013-06-11 19:17 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <20130611160949.GA1696@redhat.com>
On Tue, 11 Jun 2013 18:09:50 +0200 Stanislaw Gruszka wrote:
> I found a bug in one patch, perhaps it is a reason of failure.
> Please apply patch 5/4 from here:
> http://marc.info/?l=linux-wireless&m=136947199729148&q=raw
> and patch from the end of this email, which fix the bug.
>
> Could you also recheck that "mac80211: fix direct probe auth" patch
> is applied, note that it is included in 3.10-rc5 as commit
> 6211dd12da609bc6893b9c3182630b494737ec4b
yes, that mac80211 patch was applied to both 3.9 and 3.10-rc4 ... but I
just built 3.10-rc5 (and confirmed that it does have that patch) with
the 4 previous patches plus the new one above and my system connected
just fine ... i switched back and forth a few times and all seems
well ...
looks like a good a set of patches for 3.11, though I imagine stable
will stick with the other workaround ...
thanks!
jake
--
Jake Edge - LWN - jake@lwn.net - http://lwn.net
^ permalink raw reply
* Re: [RFC 4/5] mac80211: enforce address verification on monitors
From: Jakub Kiciński @ 2013-06-11 19:13 UTC (permalink / raw)
To: Johannes Berg
Cc: Felix Fietkau, linux-wireless, Helmut Schaa,
nietrywialneprzejscie
In-Reply-To: <1370963652.8356.51.camel@jlt4.sipsolutions.net>
On Tue, 11 Jun 2013 17:14:12 +0200, Johannes Berg wrote:
>
>>> I think we should "just" move ieee80211_verify_mac() into do_open().
>>> Semantically anyway, I'm clearly handwaving a bit. But I would argue
>>> that you can set any MAC address that you like, as long as you don't
>>> bring the interface up, hence the verification really shouldn't be done
>>> when you assign the address but when you bring it up.
>>
>> I've considered this initially. Two reasons that made me
>> think the current approach is cleaner are:
>> - it's nice when user gets the error during the action that
>> puts system in inconsistent state not some time later. I
>> personally hate to get vague EBUSY and have to figure out
>> what's wrong.
>> - suppose there are two interfaces, both down with
>> incompatible addresses. User adds third ifc, what address
>> should we assign to it?
>
> Right now you can assign the same addresses to multiple interfaces and
> then you can't bring them up. This happens for example if there are no
> more addresses to assign.
I didn't realise that. I will move the check into do_open() path as
suggested then.
-- kuba
^ 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