* Re: ath10k inoperatable after suspend
From: Michal Kazior @ 2016-09-19 11:15 UTC (permalink / raw)
To: Steffen Arntz; +Cc: linux-wireless
In-Reply-To: <CAMHqqOC5G3w6TnuJp1MWcVpvYkjt5cgpKDwGLi5sEe3-Ud5_HA@mail.gmail.com>
On 19 September 2016 at 00:52, Steffen Arntz <winrootkit@gmail.com> wrote:
> Hi at all,
>
> I have an QCA988X based card in my laptop and have some "issues" with
> it, that I was not experiencing with my previous ath9k based card.
>
> The main issue is, that after suspend to RAM the card seems to be
> "hung up" and only reloading ath10k_core and ath10k_pci helps to fix
> the problem.
Hmm.. just a guess - maybe PCI config space isn't well preserved over
suspend and reloading modules prompts the PCI subsys to reset it.
Michal
^ permalink raw reply
* Re: ath10k mesh mode issue
From: Michal Kazior @ 2016-09-19 11:22 UTC (permalink / raw)
To: Matteo Grandi; +Cc: LinuxWireless Mailing List
In-Reply-To: <CAF3cwD2jkXTbZAw7YPE2mDyZKgEUCdWOXDAqkt6zLbXLV6uT9g@mail.gmail.com>
On 16 September 2016 at 12:56, Matteo Grandi <grn.matteo@gmail.com> wrote:
> Hello all,
[...]
> [ 8.589474] ath10k_pci 0000:07:00.0: qca988x hw2.0 (0x4100016c,
> 0x043222ff sub 0000:0000) fw 10.2.4.70.54 fwapi 5 bdapi 1 htt-ver 2.1
> wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1 features
> no-p2p,raw-mode
The "raw-mode" here only hints the firmware is capable of raw mode
operation which needs to be explicitly enabled.
> [ 8.589491] ath10k_pci 0000:07:00.0: debug 1 debugfs 1 tracing 0
> dfs 0 testmode 1
> [ 8.691670] ath: EEPROM regdomain: 0x0
> [ 8.691680] ath: EEPROM indicates default country code should be used
> [ 8.691686] ath: doing EEPROM country->regdmn map search
> [ 8.691695] ath: country maps to regdmn code: 0x3a
> [ 8.691702] ath: Country alpha2 being used: US
> [ 8.691706] ath: Regpair used: 0x3a
> [ 176.983250] ath10k_pci 0000:07:00.0: must load driver with
> rawmode=3D1 to add mesh interfaces
[...]
> - I've also tried to load the ath10k modules adding the parameter
> rowmode=3D1 but I had an error "rawmode unknown parameter"
Only ath10k_core needs to be loaded with rawmode=3D1.
You can check available module parameters with:
modinfo ath10k_core
modinfo ath10k_pci
Micha=C5=82
^ permalink raw reply
* Re: [v3 PATCH 0/2] rhashtable: rhashtable with duplicate objects
From: Johannes Berg @ 2016-09-19 11:32 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, netdev, linux-wireless, Thomas Graf, tom,
Ben Greear
In-Reply-To: <1474283023.6544.0.camel@sipsolutions.net>
On Mon, 2016-09-19 at 13:03 +0200, Johannes Berg wrote:
> On Mon, 2016-09-19 at 18:58 +0800, Herbert Xu wrote:
> >
> > v3 fixes a bug in the remove path that causes the element count
> > to decrease when it shouldn't, leading to a gigantic hash table
> > when it underflows.
> >
> Ok, with the BUG_ON() thrown in, this works in the test that was
> failing before. I'll run the entire suite again over lunch.
>
Ok, the entire test suite passed (with the BUG_ON, but hey).
Dave, let me know what you want to do (or have done, as it may be).
Thanks,
johannes
^ permalink raw reply
* staging: wilc1000: kernel Oops while opening the device
From: Nicolas Ferre @ 2016-09-19 12:06 UTC (permalink / raw)
To: linux-wireless, Aditya Shankar, Ganesh Krishna; +Cc: Greg Kroah-Hartman, luisbg
Hi all,
While using the wilc1000 driver with latest 4.8-rc7, I
have difficulties to open the device and actually use it as I have
this kernel Oops right after the loading of the firmware (wilc1003_firmware.bin).
If I revert back the driver to its b9811891a9f60ca9c314dcab3244c65930c4cf37 state,
it works okay. I did this because I tend to think that it might be related to the latest
move on this driver to "completion" or "work queues".
It seems to be a regression from 4.7.
It's on my ARM platform sama5d2 Xplained.
Here is the log:
---------------------------------------------------------------------------
root@sama5d2-xplained:~# ifup wlan0
Successfully initialized wpa_supplicant
wilc1000_sdio mmc1:0001:1: chipid (001003a0)
wilc1000_sdio mmc1:0001:1: has_thrpt_enh3 = 1...
wilc1000_sdio mmc1:0001:1 wlan0: loading firmware atmel/wilc1003_firmware.bin
Unable to handle kernel NULL pointer dereference at virtual address 00000010
pgd = d4608000
[00000010] *pgd=34671831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] ARM
Modules linked in: wilc1000_sdio(C) wilc1000(C)
CPU: 0 PID: 365 Comm: wpa_supplicant Tainted: G C 4.8.0-rc7 #231
Hardware name: Atmel SAMA5
task: d463dbc0 task.stack: d462e000
PC is at __queue_work+0x98/0x29c
LR is at __queue_work+0x60/0x29c
pc : [<c0127060>] lr : [<c0127028>] psr: 60000093
sp : d462fc68 ip : a0000093 fp : 00000014
r10: 00000000 r9 : 00000001 r8 : c0a0812c
r7 : c0a2f098 r6 : d444a900 r5 : d4663374 r4 : 00000000
r3 : 0006000a r2 : d4663374 r1 : 07ffffff r0 : 00000000
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c53c7d Table: 34608059 DAC: 00000051
Process wpa_supplicant (pid: 365, stack limit = 0xd462e208)
Stack: (0xd462fc68 to 0xd4630000)
fc60: c0a0bbc0 ffffc985 a0000013 ffffffe1 00000000 d461a460
fc80: 00000000 d444a500 00008914 c0127298 d4663200 d461a460 00000001 bf0076b4
fca0: fffffe7c bf0082b4 ffffffff 00000018 00000001 00000000 00000000 00000000
fcc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
fce0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
fd00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
fd20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
fd40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
fd60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
fd80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
fda0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
fdc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
fde0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
fe00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 d461a460
fe20: 00000000 00000000 00000000 00000000 d461a000 d461a800 00000000 bf00509c
fe40: 00000001 00000000 d461a000 bf00dde0 00000001 00001002 00000000 c04fde98
fe60: d461a000 d461a000 00000001 d461a000 00001003 c04fe128 d461a000 00000148
fe80: 00001002 00000001 00000000 c04fe204 00000000 d444a50c 00000000 00000001
fea0: 00000000 c0557d5c 00000020 00000000 bebd28f0 bebd28f0 d444a50c d461a000
fec0: 6e616c77 00000030 00000000 00000000 00001003 00000000 00000000 00000000
fee0: 00001002 00008914 bebd28f0 d0164000 bebd28f0 d43ceb40 d462e000 bebd28f0
ff00: d0164020 c04e40a0 00000005 d43ceb40 00008914 c01b16e0 d43ce008 00000020
ff20: 00000001 00000001 00000000 00000000 d4418d80 d43ce000 00000008 d4028ba8
ff40: d43ce000 00000008 bebd2950 d462ff80 00000008 c01a1a1c 00000000 00000000
ff60: d43ce000 00000000 00000000 d43ceb40 d43ceb40 00008914 bebd28f0 00000005
ff80: d462e000 00000000 000f0c70 c01b1ef0 00000000 00000005 00000001 00000036
ffa0: c01076e4 c0107520 00000000 00000005 00000005 00008914 bebd28f0 00001003
ffc0: 00000000 00000005 00000001 00000036 0011959d 001195b9 00000005 000f0c70
ffe0: 001019bc bebd28e4 000b4660 b6c761fc 600c0010 00000005 00000000 00000000
[<c0127060>] (__queue_work) from [<c0127298>] (queue_work_on+0x34/0x40)
[<c0127298>] (queue_work_on) from [<bf0076b4>] (wilc_enqueue_cmd+0x54/0x64 [wilc1000])
[<bf0076b4>] (wilc_enqueue_cmd [wilc1000]) from [<bf0082b4>] (wilc_set_wfi_drv_handler+0x48/0x70 [wilc1000])
[<bf0082b4>] (wilc_set_wfi_drv_handler [wilc1000]) from [<bf00509c>] (wilc_mac_open+0x214/0x250 [wilc1000])
[<bf00509c>] (wilc_mac_open [wilc1000]) from [<c04fde98>] (__dev_open+0xb8/0x11c)
[<c04fde98>] (__dev_open) from [<c04fe128>] (__dev_change_flags+0x94/0x158)
[<c04fe128>] (__dev_change_flags) from [<c04fe204>] (dev_change_flags+0x18/0x48)
[<c04fe204>] (dev_change_flags) from [<c0557d5c>] (devinet_ioctl+0x6b4/0x788)
[<c0557d5c>] (devinet_ioctl) from [<c04e40a0>] (sock_ioctl+0x154/0x2cc)
[<c04e40a0>] (sock_ioctl) from [<c01b16e0>] (do_vfs_ioctl+0x9c/0x878)
[<c01b16e0>] (do_vfs_ioctl) from [<c01b1ef0>] (SyS_ioctl+0x34/0x5c)
[<c01b1ef0>] (SyS_ioctl) from [<c0107520>] (ret_fast_syscall+0x0/0x3c)
Code: e5932004 e1520006 01a04003 0affffff (e5943010)
---[ end trace b612328adaa6bf20 ]---
/etc/network/if-pre-up.d/wpa-supplicant: line 83: 365 Segmentation fault start-stop-daemon --start --quiet --name $WPA_SUP_PNAME --startas $WPA_SUP_BIN --pidfile $WPA_SUP_PIDFILE -- $WPA_SUP_OPTIONS $WPA_SUP_CONF -D $IF_WPA_DRIVER
---------------------------------------------------------------------------
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [athk9] beacon.c:642 ath9k_calculate_summary_state dump
From: Vidar Haarr @ 2016-09-19 12:32 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <87mvj63b9y.fsf@purkki.adurom.net>
On Sat, Sep 17, 2016 at 3:29 PM, Kalle Valo <kvalo@codeaurora.org> wrote:
> Vidar Haarr <vidar@heidrunbryggeri.no> writes:
>> sep. 17 11:38:36 edbpc kernel: WARNING: CPU: 0 PID: 1684 at
>> /home/kernel/COD/linux/drivers/net/wireless/ath/ath9k/beacon.c:642
>> ath9k_calculate_summary_state+0x135/0x390 [ath9k]
>
> Looks like exactly the same problem, but the fix (below) is not in
> v4.8-rc6. Should be in -rc7 which Linus hopefully releases on Sunday.
> Please test that and report if the problem continues.
Indeed, I did not check to see if -rc6 included it specifically, I
just checked github.com/torvalds/linux master branch to see if the fix
was there just before I sent the email to linux-wireless.
-rc7 seems to have resolved the issue.
Thank you,
--
Vidar
^ permalink raw reply
* Re: staging: wilc1000: kernel Oops while opening the device
From: Greg Kroah-Hartman @ 2016-09-19 13:42 UTC (permalink / raw)
To: Nicolas Ferre; +Cc: linux-wireless, Aditya Shankar, Ganesh Krishna, luisbg
In-Reply-To: <c12338f5-0a50-bb55-0b83-0fa705237cf8@atmel.com>
On Mon, Sep 19, 2016 at 02:06:02PM +0200, Nicolas Ferre wrote:
> Hi all,
>
> While using the wilc1000 driver with latest 4.8-rc7, I
> have difficulties to open the device and actually use it as I have
> this kernel Oops right after the loading of the firmware (wilc1003_firmware.bin).
>
> If I revert back the driver to its b9811891a9f60ca9c314dcab3244c65930c4cf37 state,
> it works okay. I did this because I tend to think that it might be related to the latest
> move on this driver to "completion" or "work queues".
> It seems to be a regression from 4.7.
Ick, not good at all.
Any chance you can run 'git bisect' to see if you can find the offending
patch?
I thought the maintainers were testing this driver over time :(
thanks,
greg k-h
^ permalink raw reply
* Problem with 40Mhz on 2.5GHz with Intel 8260
From: Volker Mische @ 2016-09-19 14:00 UTC (permalink / raw)
To: linux-wireless
Hi,
I'm having connectivity issues with an Intel 8260 on a 2.5GHz network
when using 40Mhz. I'm getting errors like
Queue 2 stuck for 10000 ms.
I've upgrade my system to the firmware version 21 (21.373438.0) and
Kernel 4.8.0-rc6 in hope that it fixes the issue and to be able to debug
the problem.
I then found the page about platform noise [1]. I don't have any issue
for several hours now (normally I was hitting the issue every few
minutes) as I've set the cfg80211_disable_40mhz_24ghz parameter.
Now I wonder, is it worth debugging the issue with being on 40MHz or is
disabling the proper solution and I should bother.
[1]:
https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi#about_platform_noise
Cheers,
Volker
^ permalink raw reply
* Re: brcmfmac MAC address change delay and 500ms down delay
From: Dan Williams @ 2016-09-19 14:48 UTC (permalink / raw)
To: Arend Van Spriel, linux-wireless
In-Reply-To: <f1912b3a-80ce-097f-8c58-cfe246804055@broadcom.com>
On Fri, 2016-09-16 at 11:58 +0200, Arend Van Spriel wrote:
> On 15-9-2016 16:42, Dan Williams wrote:
> >
> > Hi,
> >
> > While refining NetworkManager's MAC address randomization behavior
> > we
> > came across two issues with brcmfmac:
> >
> > 1) when changing the MAC address, the driver schedules work for the
> > new
> > change and returns success, but doesn't actually change the MAC
> > until
> > the work is scheduled. Because it returns 0 from the
> > ndo_set_mac_address hook the net core will generate a
> > NETDEV_CHANGEADDR
> > event and rtnetlink will send out an RTM_NEWLINK with the old MAC
> > address. No event for the new address will be sent. So it's
> > pretty
> > hard to figure out when the address actually changed, and when its
> > safe
> > to associate, without polling the device's MAC address. Ugly.
> And apparently unnecessary. I recalled we had this as the
> ndo_set_mac_address callback could be called in atomic context. So we
> are using a worker because we are grabbing a mutex upon sending the
> control info to the device. Looking into the core network code it
> seems
> the callback is not called in atomic context so it seems we can get
> rid
> of the worker here. I made a patch
>
> >
> > 2) when closing the device (eg, set !IFF_UP) the driver
> > unconditionally
> > blocks for 500ms in __brcmf_cfg80211_down():
> >
> > if (check_vif_up(ifp->vif)) {
> > brcmf_link_down(ifp->vif, WLAN_REASON_UNSPECIFIED);
> >
> > /* Make sure WPA_Supplicant receives all the event
> > generated due to DISASSOC call to the fw to keep
> > the state fw and WPA_Supplicant state consistent
> > */
> > brcmf_delay(500);
> > }
> This is actually a bogus delay as we are under an RTNL lock here so I
> think the events will not go out until after the delay has finished.
> I
> did submit a patch long ago removing this delay, but the change was
> not
> accepted. Let me revisit that.
>
> >
> > Should I dump these into kernel bugzilla, or is there some internal
> > bug
> > tracker they could get stuffed into?
> Kernel bugzilla is fine although I check it rather infrequently.
Thanks for taking another look at these. Should I still file in
bugzilla, or are the patches going through the process already?
Dan
^ permalink raw reply
* Re: [PATCH] cfg80211: cap 20MHz VHT bitrate at MCS 8
From: Ben Greear @ 2016-09-19 16:19 UTC (permalink / raw)
To: Johannes Berg, Pedersen, Thomas; +Cc: linux-wireless
In-Reply-To: <1474275637.4469.15.camel@sipsolutions.net>
On 09/19/2016 02:00 AM, Johannes Berg wrote:
>
>> Actually, can you apply the v2 (cfg80211: add bitrate for 20MHz MCS
>> 9) of this? Systems guys confirmed they use MCS 9 @ 20MHz when LDPC
>> is enabled. Also confirmed bitrate should be ok.
>
> I don't really understand that. How can the bitrate be "OK" when the
> spec explicitly says it cannot be used?
>
> johannes
>
I think it is a moot point as far as this change goes: Regardless of whether
the NIC should or not, it _does_. So, mis-reporting it up the stack only hides
the issue and does not even give the user a clue that on-the-air encoding may be
slightly off-spec.
If the on-air encoding is an issue, then we need to hack the firmware to
disable this 'feature', but that is a completely separate issue.
Once this patch goes in, someone might consider properly reporting CCK
rx rates for 5Ghz band too: ath10k can do this 'feature' as well, at least
in some firmware. Probably can reproduce by sending off-channel mgt frames on
5Ghz when associated on 2.4, or something similar to this. I was using ath9k as
sniffer when I found this long ago, so at least ath9k needs the change....
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH V2] rtl8xxxu: Stop log spam from each successful interrupt
From: Larry Finger @ 2016-09-19 16:33 UTC (permalink / raw)
To: kvalo, Jes Sorensen; +Cc: devel, linux-wireless, Larry Finger
As soon as debugging is turned on, the logs are filled with messages
reporting the interrupt status. As this quantity is usually zero, this
output is not needed. In fact, there will be a report if the status is
not zero, thus the debug line in question could probably be deleted.
Rather than taking that action, I have changed it to only be printed
when the newly added RTL8XXXU_DEBUG_INTERRUPT bit is set in the debug
mask.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
V2 - Added new debugging flag as requested by Jes.
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 1 +
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 870c9cd..4508b6d 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -29,6 +29,7 @@
#define RTL8XXXU_DEBUG_H2C 0x800
#define RTL8XXXU_DEBUG_ACTION 0x1000
#define RTL8XXXU_DEBUG_EFUSE 0x2000
+#define RTL8XXXU_DEBUG_INTERRUPT 0x4000
#define RTW_USB_CONTROL_MSG_TIMEOUT 500
#define RTL8XXXU_MAX_REG_POLL 500
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 9f6dbb4..efba8f1 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -5260,7 +5260,8 @@ static void rtl8xxxu_int_complete(struct urb *urb)
struct device *dev = &priv->udev->dev;
int ret;
- dev_dbg(dev, "%s: status %i\n", __func__, urb->status);
+ if (rtl8xxxu_debug & RTL8XXXU_DEBUG_INTERRUPT)
+ dev_dbg(dev, "%s: status %i\n", __func__, urb->status);
if (urb->status == 0) {
usb_anchor_urb(urb, &priv->int_anchor);
ret = usb_submit_urb(urb, GFP_ATOMIC);
--
2.6.6
^ permalink raw reply related
* Re: [PATCH 0/9] brcmfmac: coverity fixes
From: Florian Fainelli @ 2016-09-19 16:42 UTC (permalink / raw)
To: Arend van Spriel, Kalle Valo; +Cc: linux-wireless
In-Reply-To: <1474283399-14385-1-git-send-email-arend.vanspriel@broadcom.com>
On 09/19/2016 04:09 AM, Arend van Spriel wrote:
> This series consist of:
> * fixes for several issues found by Coverity.
> * ignore 802.11d configuration if not supported in firmware.
> * remove worker from netdev callback.
Thanks for doing this, can you also provide the coverity id when
relevant? Something like:
Reported-by: coverity (CID #12345678)
Which can help with automated tools hooking to coverity for managing the
lifecycle of the report.
Thanks!
>
> This is intended for 4.9 and applies to the master branch of
> the wireless-drivers-next repository.
>
> Arend van Spriel (4):
> brcmfmac: rework pointer trickery in brcmf_proto_bcdc_query_dcmd()
> brcmfmac: fix memory leak in brcmf_flowring_add_tdls_peer()
> brcmfmac: initialize variable in brcmf_sdiod_regrl()
> brcmfmac: remove worker from .ndo_set_mac_address() callback
>
> Hante Meuleman (5):
> brcmfmac: ignore 11d configuration errors
> brcmfmac: remove unnecessary null pointer check
> brcmfmac: fix clearing entry IPv6 address
> brcmfmac: fix out of bound access on clearing wowl wake indicator
> brcmfmac: simplify mapping of auth type
>
> .../wireless/broadcom/brcm80211/brcmfmac/bcdc.c | 2 +-
> .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 2 +-
> .../broadcom/brcm80211/brcmfmac/cfg80211.c | 41 +++++++++---------
> .../wireless/broadcom/brcm80211/brcmfmac/core.c | 49 +++++++++-------------
> .../wireless/broadcom/brcm80211/brcmfmac/core.h | 2 -
> .../broadcom/brcm80211/brcmfmac/flowring.c | 8 +++-
> 6 files changed, 47 insertions(+), 57 deletions(-)
>
--
Florian
^ permalink raw reply
* Re: [PATCH] rsi: fix memory leak in debugfs entry and supported bands
From: Heinrich Schuchardt @ 2016-09-19 17:25 UTC (permalink / raw)
To: Prameela Rani Garnepudi, linux-wireless
Cc: kvalo, johannes.berg, hofrat, Prameela Rani Garnepudi
In-Reply-To: <1474282311-21541-1-git-send-email-prameela.j04cs@gmail.com>
On 09/19/2016 12:51 PM, Prameela Rani Garnepudi wrote:
> From: Prameela Rani Garnepudi <prameela.garnepudi@redpinesignals.com>
>
> Signed-off-by: Prameela Rani Garnepudi <prameela.garnepudi@redpinesignals.com>
> ---
> drivers/net/wireless/rsi/rsi_91x_mac80211.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
> index dbb2389..dc64532 100644
> --- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
> +++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
> @@ -194,6 +194,7 @@ static void rsi_register_rates_channels(struct rsi_hw *adapter, int band)
> void rsi_mac80211_detach(struct rsi_hw *adapter)
> {
> struct ieee80211_hw *hw = adapter->hw;
> + int i;
>
> if (hw) {
> ieee80211_stop_queues(hw);
> @@ -201,7 +202,16 @@ void rsi_mac80211_detach(struct rsi_hw *adapter)
> ieee80211_free_hw(hw);
> }
>
> + for (i = 0; i < 2; i++) {
> + struct ieee80211_supported_band *sbands = &adapter->sbands[i];
> +
> + kfree(sbands->channels);
> + }
> +
> +#ifdef CONFIG_RSI_DEBUGFS
> rsi_remove_dbgfs(adapter);
> + kfree(adapter->dfsentry);
> +#endif
> }
> EXPORT_SYMBOL_GPL(rsi_mac80211_detach);
>
>
Please, use
git format-patch -ns HEAD~1..HEAD
to create the patch message and
git send-email
to post your patch including your commit message.
Best regards
Heinrich
^ permalink raw reply
* nl80211 fine timing measurement support
From: Lior David @ 2016-09-19 17:31 UTC (permalink / raw)
To: Johannes Berg; +Cc: Maya Erez, Jouni Malinen, linux-wireless
Hi Johannes,
We are working on adding indoor location support to the wil6210 11ad driver. This includes fine timing measurement (FTM) as well as something we call angle of arrival (AOA) which measures azimuth and elevation.
Initially we implemented it internally using vendor commands but we would like to upstream it using standard nl80211 API.
I noticed a patch you sent some time ago (https://patchwork.kernel.org/patch/7790701/) for adding fine timing measurement support to nl80211, it looks like a good baseline though we do have few issues with it... However I did not see any comments or response on this patch. Can you please update if you plan on eventually submitting this patch?
Thanks,
Lior
^ permalink raw reply
* Re: brcmfmac MAC address change delay and 500ms down delay
From: Arend Van Spriel @ 2016-09-19 18:34 UTC (permalink / raw)
To: Dan Williams, linux-wireless
In-Reply-To: <1474296520.3075.7.camel@redhat.com>
On 19-9-2016 16:48, Dan Williams wrote:
> On Fri, 2016-09-16 at 11:58 +0200, Arend Van Spriel wrote:
>> On 15-9-2016 16:42, Dan Williams wrote:
>>>
>>> Hi,
>>>
>>> While refining NetworkManager's MAC address randomization behavior
>>> we
>>> came across two issues with brcmfmac:
>>>
>>> 1) when changing the MAC address, the driver schedules work for the
>>> new
>>> change and returns success, but doesn't actually change the MAC
>>> until
>>> the work is scheduled. Because it returns 0 from the
>>> ndo_set_mac_address hook the net core will generate a
>>> NETDEV_CHANGEADDR
>>> event and rtnetlink will send out an RTM_NEWLINK with the old MAC
>>> address. No event for the new address will be sent. So it's
>>> pretty
>>> hard to figure out when the address actually changed, and when its
>>> safe
>>> to associate, without polling the device's MAC address. Ugly.
>> And apparently unnecessary. I recalled we had this as the
>> ndo_set_mac_address callback could be called in atomic context. So we
>> are using a worker because we are grabbing a mutex upon sending the
>> control info to the device. Looking into the core network code it
>> seems
>> the callback is not called in atomic context so it seems we can get
>> rid
>> of the worker here. I made a patch
>>
>>>
>>> 2) when closing the device (eg, set !IFF_UP) the driver
>>> unconditionally
>>> blocks for 500ms in __brcmf_cfg80211_down():
>>>
>>> if (check_vif_up(ifp->vif)) {
>>> brcmf_link_down(ifp->vif, WLAN_REASON_UNSPECIFIED);
>>>
>>> /* Make sure WPA_Supplicant receives all the event
>>> generated due to DISASSOC call to the fw to keep
>>> the state fw and WPA_Supplicant state consistent
>>> */
>>> brcmf_delay(500);
>>> }
>> This is actually a bogus delay as we are under an RTNL lock here so I
>> think the events will not go out until after the delay has finished.
>> I
>> did submit a patch long ago removing this delay, but the change was
>> not
>> accepted. Let me revisit that.
>>
>>>
>>> Should I dump these into kernel bugzilla, or is there some internal
>>> bug
>>> tracker they could get stuffed into?
>> Kernel bugzilla is fine although I check it rather infrequently.
>
> Thanks for taking another look at these. Should I still file in
> bugzilla, or are the patches going through the process already?
For the mac address delay I let this [1] one fly today. A pity
git-send-email does not add the 'Reported-by:' email to the Cc:
The other one is a bit more tricky. The 500ms delay can be removed, but
I need to fix a related scenario. Working on it.
Regards,
Arend
[1] 1474283399-14385-6-git-send-email-arend.vanspriel@broadcom.com
^ permalink raw reply
* Re: nl80211 fine timing measurement support
From: Arend Van Spriel @ 2016-09-19 18:42 UTC (permalink / raw)
To: Lior David, Johannes Berg; +Cc: Maya Erez, Jouni Malinen, linux-wireless
In-Reply-To: <e7096bbb-ba66-e639-b86e-a483dc198b85@codeaurora.org>
On 19-9-2016 19:31, Lior David wrote:
> Hi Johannes,
>
> We are working on adding indoor location support to the wil6210 11ad driver. This includes fine timing measurement (FTM) as well as something we call angle of arrival (AOA) which measures azimuth and elevation.
> Initially we implemented it internally using vendor commands but we would like to upstream it using standard nl80211 API.
> I noticed a patch you sent some time ago (https://patchwork.kernel.org/patch/7790701/) for adding fine timing measurement support to nl80211, it looks like a good baseline though we do have few issues with it... However I did not see any comments or response on this patch. Can you please update if you plan on eventually submitting this patch?
You can find several FTM related patches in backport-iwlwifi repo on
kernel.org. See link to git log of nl80211.h there [1].
Regards,
Arend
[1]
https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwifi.git/log/include/uapi/linux/nl80211.h
^ permalink raw reply
* Re: nl80211 fine timing measurement support
From: Johannes Berg @ 2016-09-19 19:41 UTC (permalink / raw)
To: Arend Van Spriel, Lior David
Cc: Maya Erez, Jouni Malinen, linux-wireless, Luca Coelho
In-Reply-To: <45d2980c-aeb4-4faa-e73f-75747124e9eb@broadcom.com>
> > However I did not see any comments or response on this
> > patch. Can you please update if you plan on eventually submitting
> > this patch?
>
> You can find several FTM related patches in backport-iwlwifi repo on
> kernel.org. See link to git log of nl80211.h there [1].
>
You can find things there, but they might not be the most organized
always :)
Anyway, I think after Luca is handling the current round of NaN
submission he'll have the cycles to deal with FTM - I'll let him
comment. For all I care, they can also run in parallel, but that might
be more difficult for him.
johannes
^ permalink raw reply
* RTL8192EU on rtl8xxxu driver breaks every few minutes
From: Franc[e]sco @ 2016-09-19 19:42 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 555 bytes --]
Hi, I happen to own a RTL8192EU WiFi dongle which is marked as untested
by the rtl8xxxu driver.
I'm on a linux from scratch system using kernel 4.7.3 and wpa_supplicant
2.5.
The dongle appears to connect and work fine, but after around 10 minutes
it deauthenticates and enters and endless loop of authentication
timeout. This continues even if I bring the interface down and back up
again. The only way to restore the connection is to physically remove
and re-plug the usb dongle.
I have attached a dmesg log of connecting and entering the auth loop.
[-- Attachment #2: rtl8192eu-dmesg --]
[-- Type: text/plain, Size: 6251 bytes --]
[ 6622.717543] usb 2-1.7: new high-speed USB device number 12 using ehci-pci
[ 6622.803640] usb 2-1.7: New USB device found, idVendor=0bda, idProduct=818b
[ 6622.804026] usb 2-1.7: New USB device strings: Mfr=1, Product=2, SerialNumber
=3
[ 6622.804417] usb 2-1.7: Product: 802.11n NIC
[ 6622.804816] usb 2-1.7: Manufacturer: Realtek
[ 6622.805215] usb 2-1.7: SerialNumber: 00e04c000001
[ 6622.805905] usb 2-1.7: This Realtek USB WiFi dongle (0x0bda:0x818b) is untest
ed!
[ 6622.806332] usb 2-1.7: Please report results to Jes.Sorensen@gmail.com
[ 6622.970016] usb 2-1.7: Vendor: Realtek
[ 6622.970454] usb 2-1.7: Product: 802.11n NIC
[ 6622.970897] usb 2-1.7: Serial: �����������
[ 6622.971339] usb 2-1.7: rtl8192eu_parse_efuse: dumping efuse (0x200 bytes):
[ 6622.971802] usb 2-1.7: 00: 29 81 00 7c 01 40 03 00
[ 6622.972269] usb 2-1.7: 08: 40 74 04 50 14 00 00 00
[ 6622.972735] usb 2-1.7: 10: 21 20 1f 23 23 23 2d 2c
[ 6622.973202] usb 2-1.7: 18: 2b 2d 2d ff ef ef ff ff
[ 6622.973671] usb 2-1.7: 20: ff ff ff ff ff ff ff ff
[ 6622.974135] usb 2-1.7: 28: ff ff ff ff ff ff ff ff
[ 6622.974598] usb 2-1.7: 30: ff ff ff ff ff ff ff ff
[ 6622.975052] usb 2-1.7: 38: ff ff 1f 1d 1c 1e 1e 1e
[ 6622.975504] usb 2-1.7: 40: 2a 29 28 29 29 ff ef ef
[ 6622.975957] usb 2-1.7: 48: ff ff ff ff ff ff ff ff
[ 6622.976412] usb 2-1.7: 50: ff ff ff ff ff ff ff ff
[ 6622.976861] usb 2-1.7: 58: ff ff ff ff ff ff ff ff
[ 6622.977308] usb 2-1.7: 60: ff ff ff ff ff ff ff ff
[ 6622.977759] usb 2-1.7: 68: ff ff ff ff ff ff ff ff
[ 6622.978202] usb 2-1.7: 70: ff ff ff ff ff ff ff ff
[ 6622.978641] usb 2-1.7: 78: ff ff ff ff ff ff ff ff
[ 6622.979073] usb 2-1.7: 80: ff ff ff ff ff ff ff ff
[ 6622.979501] usb 2-1.7: 88: ff ff ff ff ff ff ff ff
[ 6622.979926] usb 2-1.7: 90: ff ff ff ff ff ff ff ff
[ 6622.980343] usb 2-1.7: 98: ff ff ff ff ff ff ff ff
[ 6622.980760] usb 2-1.7: a0: ff ff ff ff ff ff ff ff
[ 6622.981174] usb 2-1.7: a8: ff ff ff ff ff ff ff ff
[ 6622.981588] usb 2-1.7: b0: ff ff ff ff ff ff ff ff
[ 6622.982002] usb 2-1.7: b8: 20 0d ff 00 33 88 ff ff
[ 6622.982421] usb 2-1.7: c0: ff 01 20 13 00 00 00 ff
[ 6622.982848] usb 2-1.7: c8: 00 00 ff ff ff ff ff ff
[ 6622.983275] usb 2-1.7: d0: da 0b 8b 81 e7 47 02 00
[ 6622.983711] usb 2-1.7: d8: 19 88 00 1e 33 09 03 52
[ 6622.984150] usb 2-1.7: e0: 65 61 6c 74 65 6b 0d 03
[ 6622.984594] usb 2-1.7: e8: 38 30 32 2e 31 31 6e 20
[ 6622.985045] usb 2-1.7: f0: 4e 49 43 00 ff ff ff ff
[ 6622.985500] usb 2-1.7: f8: ff ff ff ff ff ff ff ff
[ 6622.985960] usb 2-1.7: 100: ff ff ff ff ff ff ff ff
[ 6622.986423] usb 2-1.7: 108: ff ff ff ff ff ff ff ff
[ 6622.986889] usb 2-1.7: 110: ff ff ff ff ff ff ff 0d
[ 6622.987354] usb 2-1.7: 118: 03 00 05 00 30 00 00 00
[ 6622.987827] usb 2-1.7: 120: 00 93 ff ff ff ff ff ff
[ 6622.988302] usb 2-1.7: 128: ff ff ff ff ff ff ff ff
[ 6622.988779] usb 2-1.7: 130: f6 a8 98 2d 03 92 98 00
[ 6622.989262] usb 2-1.7: 138: fc 8c 00 11 9b 44 02 0a
[ 6622.989750] usb 2-1.7: 140: ff ff ff ff ff ff ff ff
[ 6622.990243] usb 2-1.7: 148: ff ff ff ff ff ff ff ff
[ 6622.990736] usb 2-1.7: 150: ff ff ff ff ff ff ff ff
[ 6622.991214] usb 2-1.7: 158: ff ff ff ff ff ff ff ff
[ 6622.991679] usb 2-1.7: 160: ff ff ff ff ff ff ff ff
[ 6622.992133] usb 2-1.7: 168: ff ff ff ff ff ff ff ff
[ 6622.992580] usb 2-1.7: 170: ff ff ff ff ff ff ff ff
[ 6622.993013] usb 2-1.7: 178: ff ff ff ff ff ff ff ff
[ 6622.993437] usb 2-1.7: 180: ff ff ff ff ff ff ff ff
[ 6622.993847] usb 2-1.7: 188: ff ff ff ff ff ff ff ff
[ 6622.994254] usb 2-1.7: 190: ff ff ff ff ff ff ff ff
[ 6622.994653] usb 2-1.7: 198: ff ff ff ff ff ff ff ff
[ 6622.995035] usb 2-1.7: 1a0: ff ff ff ff ff ff ff ff
[ 6622.995409] usb 2-1.7: 1a8: ff ff ff ff ff ff ff ff
[ 6622.995774] usb 2-1.7: 1b0: ff ff ff ff ff ff ff ff
[ 6622.996129] usb 2-1.7: 1b8: ff ff ff ff ff ff ff ff
[ 6622.996479] usb 2-1.7: 1c0: ff ff ff ff ff ff ff ff
[ 6622.996827] usb 2-1.7: 1c8: ff ff ff ff ff ff ff ff
[ 6622.997161] usb 2-1.7: 1d0: ff ff ff ff ff ff ff ff
[ 6622.997483] usb 2-1.7: 1d8: ff ff ff ff ff ff ff ff
[ 6622.997798] usb 2-1.7: 1e0: ff ff ff ff ff ff ff ff
[ 6622.998109] usb 2-1.7: 1e8: ff ff ff ff ff ff ff ff
[ 6622.998413] usb 2-1.7: 1f0: ff ff ff ff ff ff ff ff
[ 6622.998711] usb 2-1.7: 1f8: ff ff ff ff ff ff ff ff
[ 6622.998996] usb 2-1.7: RTL8192EU rev B (SMIC) 2T2R, TX queues 3, WiFi=1, BT=0
, GPS=0, HI PA=0
[ 6622.999302] usb 2-1.7: RTL8192EU MAC: 00:19:88:00:1e:33
[ 6622.999606] usb 2-1.7: rtl8xxxu: Loading firmware rtlwifi/rtl8192eu_nic.bin
[ 6622.999941] usb 2-1.7: Firmware revision 19.0 (signature 0x92e1)
[ 6624.003786] rtl8xxxu 2-1.7:1.0 enx001988001e33: renamed from wlan0
[ 6633.949414] IPv6: ADDRCONF(NETDEV_UP): enx001988001e33: link is not ready
[ 6635.137882] enx001988001e33: authenticate with e0:3f:49:97:0c:68
[ 6635.160663] enx001988001e33: send auth to e0:3f:49:97:0c:68 (try 1/3)
[ 6635.162690] enx001988001e33: authenticated
[ 6635.163682] enx001988001e33: associate with e0:3f:49:97:0c:68 (try 1/3)
[ 6635.168464] enx001988001e33: RX AssocResp from e0:3f:49:97:0c:68 (capab=0xc11
status=0 aid=3)
[ 6635.170662] usb 2-1.7: rtl8xxxu_bss_info_changed: HT supported
[ 6635.172789] enx001988001e33: associated
[ 6635.173315] IPv6: ADDRCONF(NETDEV_CHANGE): enx001988001e33: link becomes read
y
[ 6635.919948] usb 2-1.7: rtl8xxxu_ampdu_action: IEEE80211_AMPDU_RX_START
[ 7722.939773] enx001988001e33: deauthenticated from e0:3f:49:97:0c:68 (Reason:
3=DEAUTH_LEAVING)
[ 7722.945389] usb 2-1.7: rtl8xxxu_ampdu_action: IEEE80211_AMPDU_RX_STOP
[ 7724.154574] enx001988001e33: authenticate with e0:3f:49:97:0c:68
[ 7724.177624] enx001988001e33: send auth to e0:3f:49:97:0c:68 (try 1/3)
[ 7724.378378] enx001988001e33: send auth to e0:3f:49:97:0c:68 (try 2/3)
[ 7724.579405] enx001988001e33: send auth to e0:3f:49:97:0c:68 (try 3/3)
[ 7724.780407] enx001988001e33: authentication with e0:3f:49:97:0c:68 timed out
[ 7726.379564] enx001988001e33: authenticate with e0:3f:49:97:0c:68
[ 7726.402023] enx001988001e33: send auth to e0:3f:49:97:0c:68 (try 1/3)
[ 7726.603430] enx001988001e33: send auth to e0:3f:49:97:0c:68 (try 2/3)
[ 7726.804431] enx001988001e33: send auth to e0:3f:49:97:0c:68 (try 3/3)
[ 7727.005433] enx001988001e33: authentication with e0:3f:49:97:0c:68 timed out
^ permalink raw reply
* Re: [PATCH 2/4] carl9170: fix debugfs crashes
From: Christian Lamparter @ 2016-09-19 20:12 UTC (permalink / raw)
To: Greg KH
Cc: Christian Lamparter, Kalle Valo, linux-kernel, linux-wireless,
b43-dev, Nicolai Stange, Ben Greear, Larry Finger
In-Reply-To: <20160918164408.GB19729@kroah.com>
On Sunday, September 18, 2016 6:44:08 PM CEST Greg KH wrote:
> On Sun, Sep 18, 2016 at 02:49:33PM +0200, Christian Lamparter wrote:
> > On Sunday, September 18, 2016 12:14:55 PM CEST Greg KH wrote:
> > > On Sun, Sep 18, 2016 at 10:54:18AM +0300, Kalle Valo wrote:
> > > > Greg KH <gregkh@linuxfoundation.org> writes:
> > > >
> > > > > On Sat, Sep 17, 2016 at 09:43:02PM +0200, Christian Lamparter wrote:
> > > > >> Ben Greear reported:
> > > > >> > I see lots of instability as soon as I load up the carl9710 NIC.
> > > > >> > My application is going to be poking at it's debugfs files...
> > > > >> >
> > > > >> > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
> > > > >> > [carl9170] at addr ffff8801bc1208b0
> > > > >> > Read of size 8 by task btserver/5888
> > > > >> > =======================================================================
> > > > >> > BUG kmalloc-256 (Tainted: G W ): kasan: bad access detected
> > > > >> > -----------------------------------------------------------------------
> > > > >> >
> > > > >> > INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
> > > > >> >...
> > > > >>
> > > > >> This breakage was caused by the introduction of intermediate
> > > > >> fops in debugfs by commit 9fd4dcece43a
> > > > >> ("debugfs: prevent access to possibly dead file_operations at file open")
> > > > >
> > > > > Because of this, these should all be backported to 4.7-stable, and
> > > > > 4.8-stable, right?
> > Ok, only b43legacy has debugfs enabled by default. For b43 and carl9170
> > debugfs support is usually disabled.
> >
> > Greg, would you take these four patches "as is" for -stable
> > or do you want a "minimal version" which just replaces the
> >
> > dfops = container_of(file->f_op, ...
> >
> > with
> >
> > dfops = container_of(file->f_path.dentry->d_fsdata, ...
> >
> > in the three drivers for -stable?
>
> No, I'll take this as is, we want things to remain as close as possible
> to Linus's tree. When we are not, is when things break.
>
> > > > Via which tree should these go, Greg's or mine?
> > >
> > > I'll take it if you ack it, as it's a debugfs issue.
> > For carl9170: Ben Greear has reported:
> > "I have verified this fixes my problem in the 4.7 kernel."
> >
> > But this was with a preliminary/minimal version so I didn't
> > add the tested-by tag.
> >
> > As for b43, I'll see if I have a working b43 in my collection
> > somewhere to confirm the issue and the fix. Question is, do
> > you want to wait or not?
>
> I'll queue these up this week, no rush.
I was able to sucessfully test the b43 patch on my iBook G4's BCM4306.
Thanks,
Christian
^ permalink raw reply
* Re: [v3 PATCH 1/2] rhashtable: Add rhlist interface
From: Thomas Graf @ 2016-09-19 21:16 UTC (permalink / raw)
To: Herbert Xu
Cc: Johannes Berg, David S. Miller, netdev, linux-wireless, tom,
Ben Greear
In-Reply-To: <E1blwIz-0003Mz-HD@gondolin.me.apana.org.au>
On 09/19/16 at 07:00pm, Herbert Xu wrote:
> The insecure_elasticity setting is an ugly wart brought out by
> users who need to insert duplicate objects (that is, distinct
> objects with identical keys) into the same table.
>
> In fact, those users have a much bigger problem. Once those
> duplicate objects are inserted, they don't have an interface to
> find them (unless you count the walker interface which walks
> over the entire table).
>
> Some users have resorted to doing a manual walk over the hash
> table which is of course broken because they don't handle the
> potential existence of multiple hash tables. The result is that
> they will break sporadically when they encounter a hash table
> resize/rehash.
>
> This patch provides a way out for those users, at the expense
> of an extra pointer per object. Essentially each object is now
> a list of objects carrying the same key. The hash table will
> only see the lists so nothing changes as far as rhashtable is
> concerned.
>
> To use this new interface, you need to insert a struct rhlist_head
> into your objects instead of struct rhash_head. While the hash
> table is unchanged, for type-safety you'll need to use struct
> rhltable instead of struct rhashtable. All the existing interfaces
> have been duplicated for rhlist, including the hash table walker.
>
> One missing feature is nulls marking because AFAIK the only potential
> user of it does not need duplicate objects. Should anyone need
> this it shouldn't be too hard to add.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Nice, I like how this simplifies users! Is this suitable for
ILA as well?
Acked-by: Thomas Graf <tgraf@suug.ch>
^ permalink raw reply
* Re: [PATCH] mwifiex: parse device tree node for PCIe
From: Rob Herring @ 2016-09-19 21:27 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, devicetree,
Wei-Ning Huang, Xinming Hu
In-Reply-To: <1473434254-16782-1-git-send-email-akarwar@marvell.com>
On Fri, Sep 09, 2016 at 08:47:34PM +0530, Amitkumar Karwar wrote:
> From: Xinming Hu <huxm@marvell.com>
>
> This patch derives device tree node from pcie bus layer framework.
> Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
> marvell-8xxx.txt) to accomodate PCIe changes.
>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> ---
> .../bindings/net/wireless/marvell-8xxx.txt | 64 ++++++++++++++++++++++
> .../bindings/net/wireless/marvell-sd8xxx.txt | 63 ---------------------
Resend using -M option so I do have to figure out if you added 1 line or
changed a bunch.
> drivers/net/wireless/marvell/mwifiex/pcie.c | 19 +++++++
> drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 +-
> 4 files changed, 85 insertions(+), 64 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> delete mode 100644 Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> new file mode 100644
> index 0000000..a8a95aa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> @@ -0,0 +1,64 @@
> +Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
> +------
> +
> +This node provides properties for controlling the marvell sdio/pcie wireless device.
> +The node is expected to be specified as a child node to the SDIO/PCIE controller that
> +connects the device to the system.
> +
> +Required properties:
> +
> + - compatible : should be one of the following:
> + * "marvell,sd8897"
> + * "marvell,sd8997"
> + * "marvell,pcie8997"
PCIe uses vendor and product IDs for compatible strings. Please read the
OF PCI bus bindings doc.
Rob
^ permalink raw reply
* Re: [v3 PATCH 1/2] rhashtable: Add rhlist interface
From: Herbert Xu @ 2016-09-20 1:52 UTC (permalink / raw)
To: Thomas Graf
Cc: Johannes Berg, David S. Miller, netdev, linux-wireless, tom,
Ben Greear
In-Reply-To: <20160919211621.GA20951@pox.localdomain>
On Mon, Sep 19, 2016 at 11:16:21PM +0200, Thomas Graf wrote:
>
> Nice, I like how this simplifies users! Is this suitable for
> ILA as well?
Does it have duplicate objects and use inelastic_security? If so
then yes it should switch over to rhlist.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] ath10k: fix debug cal data file
From: Nikolay Martynov @ 2016-09-20 3:26 UTC (permalink / raw)
To: kvalo; +Cc: Nikolay Martynov, ath10k, linux-wireless
It got broken by 0b8e3c4ca29fe2c0efd3d41a76e34a657b9f17a4
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
---
drivers/net/wireless/ath/ath10k/debug.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 8f0fd41..7e82947 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -109,6 +109,11 @@ struct ath10k_dump_file_data {
u8 data[0];
} __packed;
+struct ath10k_debug_cal_data {
+ u32 len;
+ u8 buf[0];
+};
+
void ath10k_info(struct ath10k *ar, const char *fmt, ...)
{
struct va_format vaf = {
@@ -1453,7 +1458,8 @@ static const struct file_operations fops_fw_dbglog = {
static int ath10k_debug_cal_data_open(struct inode *inode, struct file *file)
{
struct ath10k *ar = inode->i_private;
- void *buf;
+ struct ath10k_debug_cal_data *data;
+ u32 len;
u32 hi_addr;
__le32 addr;
int ret;
@@ -1466,12 +1472,15 @@ static int ath10k_debug_cal_data_open(struct inode *inode, struct file *file)
goto err;
}
- buf = vmalloc(ar->hw_params.cal_data_len);
- if (!buf) {
+ len = ar->hw_params.cal_data_len;
+ data = vmalloc(sizeof(struct ath10k_debug_cal_data) + len);
+ if (!data) {
ret = -ENOMEM;
goto err;
}
+ data->len = len;
+
hi_addr = host_interest_item_address(HI_ITEM(hi_board_data));
ret = ath10k_hif_diag_read(ar, hi_addr, &addr, sizeof(addr));
@@ -1480,21 +1489,20 @@ static int ath10k_debug_cal_data_open(struct inode *inode, struct file *file)
goto err_vfree;
}
- ret = ath10k_hif_diag_read(ar, le32_to_cpu(addr), buf,
- ar->hw_params.cal_data_len);
+ ret = ath10k_hif_diag_read(ar, le32_to_cpu(addr), data->buf, len);
if (ret) {
ath10k_warn(ar, "failed to read calibration data: %d\n", ret);
goto err_vfree;
}
- file->private_data = buf;
+ file->private_data = data;
mutex_unlock(&ar->conf_mutex);
return 0;
err_vfree:
- vfree(buf);
+ vfree(data);
err:
mutex_unlock(&ar->conf_mutex);
@@ -1506,11 +1514,10 @@ static ssize_t ath10k_debug_cal_data_read(struct file *file,
char __user *user_buf,
size_t count, loff_t *ppos)
{
- struct ath10k *ar = file->private_data;
- void *buf = file->private_data;
+ struct ath10k_debug_cal_data *data = file->private_data;
return simple_read_from_buffer(user_buf, count, ppos,
- buf, ar->hw_params.cal_data_len);
+ data->buf, data->len);
}
static int ath10k_debug_cal_data_release(struct inode *inode,
--
2.7.4
^ permalink raw reply related
* Re: Problem with 40Mhz on 2.5GHz with Intel 8260
From: Emmanuel Grumbach @ 2016-09-20 5:39 UTC (permalink / raw)
To: Volker Mische; +Cc: linux-wireless
In-Reply-To: <24d0d9c5-7695-9364-c5fa-97e9d52712dc@gmail.com>
Hi,
On Mon, Sep 19, 2016 at 5:00 PM, Volker Mische <volker.mische@gmail.com> wrote:
> Hi,
>
> I'm having connectivity issues with an Intel 8260 on a 2.5GHz network
> when using 40Mhz. I'm getting errors like
>
> Queue 2 stuck for 10000 ms.
>
> I've upgrade my system to the firmware version 21 (21.373438.0) and
> Kernel 4.8.0-rc6 in hope that it fixes the issue and to be able to debug
> the problem.
>
> I then found the page about platform noise [1]. I don't have any issue
> for several hours now (normally I was hitting the issue every few
> minutes) as I've set the cfg80211_disable_40mhz_24ghz parameter.
>
> Now I wonder, is it worth debugging the issue with being on 40MHz or is
> disabling the proper solution and I should bother.
Well... depends whom you ask and how much time you have :)
We tried a few times to debug those, but they take a very long time to debug
since typically we need lots of reproductions and the firmware team
doesn't always
the time to look at the data immediately so in the end, the people who
reported this
originally went away.
Note that 40MHz on 2.4GHz is not an optimal configuration in crowded
environment,
but if you live in a place where you are pretty much the only one using those
frequencies, then, it can be beneficial.
What you can try is to disable low power states (by using power_scheme
in iwlmvm)
and see if it helps. This setting has a bigger impact than
cfg80211_disable_40mhz_24ghz
but it can give a hint as where the problem is coming from.
>
> [1]:
> https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi#about_platform_noise
>
> Cheers,
> Volker
^ permalink raw reply
* Re: Problem with 40Mhz on 2.5GHz with Intel 8260
From: Volker Mische @ 2016-09-20 6:22 UTC (permalink / raw)
To: Emmanuel Grumbach; +Cc: linux-wireless
In-Reply-To: <CANUX_P1cFXTFk8c7iMZuVwoySMwVKPkLBOTr=sVC+t6xioPa=w@mail.gmail.com>
Hi,
On 09/20/2016 07:39 AM, Emmanuel Grumbach wrote:
> On Mon, Sep 19, 2016 at 5:00 PM, Volker Mische <volker.mische@gmail.com> wrote:
>> I'm having connectivity issues with an Intel 8260 on a 2.5GHz network
>> when using 40Mhz. I'm getting errors like
>>
>> Queue 2 stuck for 10000 ms.
>>
>> I've upgrade my system to the firmware version 21 (21.373438.0) and
>> Kernel 4.8.0-rc6 in hope that it fixes the issue and to be able to debug
>> the problem.
>>
>> I then found the page about platform noise [1]. I don't have any issue
>> for several hours now (normally I was hitting the issue every few
>> minutes) as I've set the cfg80211_disable_40mhz_24ghz parameter.
>>
>> Now I wonder, is it worth debugging the issue with being on 40MHz or is
>> disabling the proper solution and I should bother.
>
> Well... depends whom you ask and how much time you have :)
I really want to get this sorted out.
> We tried a few times to debug those, but they take a very long time to debug
> since typically we need lots of reproductions and the firmware team
> doesn't always
> the time to look at the data immediately so in the end, the people who
> reported this
> originally went away.
> Note that 40MHz on 2.4GHz is not an optimal configuration in crowded
> environment,
> but if you live in a place where you are pretty much the only one using those
> frequencies, then, it can be beneficial.
It's at home. I normally see only one other wifi (I need to check which
frequency that one is using).
> What you can try is to disable low power states (by using power_scheme
> in iwlmvm) and see if it helps.
I will try that.
> This setting has a bigger impact than cfg80211_disable_40mhz_24ghz
> but it can give a hint as where the problem is coming from.
I'll report back.
Should I open a bug report (or use an existing one) or should we keep
the discussion on the mailing list?
Cheers,
Volker
>> [1]:
>> https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi#about_platform_noise
^ permalink raw reply
* Re: nl80211 fine timing measurement support
From: Luca Coelho @ 2016-09-20 6:39 UTC (permalink / raw)
To: Arend Van Spriel, Lior David, Johannes Berg
Cc: Maya Erez, Jouni Malinen, linux-wireless
In-Reply-To: <45d2980c-aeb4-4faa-e73f-75747124e9eb@broadcom.com>
On Mon, 2016-09-19 at 20:42 +0200, Arend Van Spriel wrote:
>
> On 19-9-2016 19:31, Lior David wrote:
> >
> > Hi Johannes,
> >
> > We are working on adding indoor location support to the wil6210
> > 11ad driver. This includes fine timing measurement (FTM) as well as
> > something we call angle of arrival (AOA) which measures azimuth and
> > elevation.
> > Initially we implemented it internally using vendor commands but we
> > would like to upstream it using standard nl80211 API.
> > I noticed a patch you sent some time ago (https://patchwork.kernel.
> > org/patch/7790701/) for adding fine timing measurement support to
> > nl80211, it looks like a good baseline though we do have few issues
> > with it... However I did not see any comments or response on this
> > patch. Can you please update if you plan on eventually submitting
> > this patch?
>
> You can find several FTM related patches in backport-iwlwifi repo on
> kernel.org. See link to git log of nl80211.h there [1].
We have a full FTM implementation in our internal tree (which is
published in the URL Arend provided) and we are currently working on
cleaning it up for upstream submission. You should see patches from us
this week.
--
Cheers,
Luca.
^ 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