* [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
* [PATCH 1/1] rsi: fix memory leak in debugfs entry and supported bands
From: Prameela Rani Garnepudi @ 2016-09-20 6:43 UTC (permalink / raw)
To: linux-wireless
Cc: kvalo, johannes.berg, hofrat, xypron.glpk,
Prameela Rani Garnepudi, Prameela Rani Garnepudi
From: Prameela Rani Garnepudi <prameela.garnepudi@redpinesignals.com>
Signed-off-by: Prameela Rani Garnepudi <prameela.garnepudi@redpinesignals.com>
Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.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);
--
2.4.11
^ permalink raw reply related
* Re: [PATCH 2/4] carl9170: fix debugfs crashes
From: Greg KH @ 2016-09-20 6:50 UTC (permalink / raw)
To: Christian Lamparter
Cc: Kalle Valo, linux-kernel, linux-wireless, b43-dev, Nicolai Stange,
Ben Greear, Larry Finger
In-Reply-To: <4518961.zKaiaJ0DYM@debian64>
On Mon, Sep 19, 2016 at 10:12:08PM +0200, Christian Lamparter wrote:
> 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.
So is that a "Tested-by:"? :)
^ permalink raw reply
* [PATCH] ath10k: Ignore SWBA event for a vif if its marked for no beacon
From: Mohammed Shafi Shajakhan @ 2016-09-20 8:22 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Ignore processing further in SWBA event scheduled for a vif, if mac80211
has marked the particular vif for stop beaconing and brought the vdev
down in 'ath10k_control_beaconing'. This should potentially avoid ath10k
warning/error messages while running continuous wifi down/up with max
number of vaps configured. Found this change during code walk through
and going through other beacon configuration related functions in ath10k
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/wmi.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index eb4ab6f..f37f178 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -3514,6 +3514,12 @@ void ath10k_wmi_event_host_swba(struct ath10k *ar, struct sk_buff *skb)
continue;
}
+ /* mac80211 would have already asked us to stop beaconing and
+ * bring the vdev down, so continue in that case
+ */
+ if (!arvif->is_up)
+ continue;
+
/* There are no completions for beacons so wait for next SWBA
* before telling mac80211 to decrement CSA counter
*
--
1.9.1
^ permalink raw reply related
* Re: [v3 PATCH 0/2] rhashtable: rhashtable with duplicate objects
From: David Miller @ 2016-09-20 8:44 UTC (permalink / raw)
To: johannes; +Cc: herbert, netdev, linux-wireless, tgraf, tom, greearb
In-Reply-To: <1474284732.6544.2.camel@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Mon, 19 Sep 2016 13:32:12 +0200
> 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).
I'll apply this directly to net-next and push it out after some
build testing.
Thanks guys.
^ permalink raw reply
* pull-request: wireless-drivers 2016-09-20
From: Kalle Valo @ 2016-09-20 10:20 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
last pull request for 4.8, unless something really drastic comes up. And
a small one even, just a small fix to iwlwifi to avoid a firmware crash.
Please let me know if there are any problems.
Kalle
The following changes since commit a0714125d11bcf21599b08b25fdaf384c0db6712:
Merge ath-current from ath.git (2016-09-07 20:16:37 +0300)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2016-09-20
for you to fetch changes up to db64c5fa590b5d82ac0d5ec39bc498f95094e66b:
Merge tag 'iwlwifi-for-kalle-2016-09-15' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes (2016-09-17 17:06:22 +0300)
----------------------------------------------------------------
wireless-drivers fixes for 4.8
iwlwifi
* fix to prevent firmware crash when sending off-channel frames
----------------------------------------------------------------
Beni Lev (1):
iwlwifi: mvm: update TX queue before making a copy of the skb
Kalle Valo (1):
Merge tag 'iwlwifi-for-kalle-2016-09-15' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
^ permalink raw reply
* Re: brcmf_txfinalize misses 802.1x packet leading to infinite WARNINGs
From: Rafał Miłecki @ 2016-09-20 11:16 UTC (permalink / raw)
To: Hante Meuleman, Arend van Spriel, brcm80211-dev-list
Cc: linux-wireless, Rafał Miłecki
In-Reply-To: <b4df2418354fdf7eb585a898bf12b19f@mail.gmail.com>
Hi Hante,
I hit this problem again and I'm afraid it's getting even more complex. Last
time you were suspecting flowring deletion but it didn't make much sense to me.
It was because I didn't see brcmf_flowring_delete anywhere in my log.
Well, today it was different. I saw brcmf_flowring_delete which makes me wonder
if there is more than 1 source of this problem.
Good news is that today I got few extra debugging messages. Bad news is I was
experimenting with MAX_WAIT_FOR_8021X_TX. I added brcmf_netdev_wait_pend8021x to
the brcmf_cfg80211_get_station and I was running
while [ 1 ]; do iw dev wlan1-1 station get 88:53:2e:50:50:00 > /dev/null; done
I hope this log may be a bit helpful anyway.
So this time brcmf_flowring_delete was called indeed and I think there was a
race in brcmfmac code. It seems brcmu_pkt_buf_free_skb was called twice for the
same skb!
For the first time it was called from brcmf_flowring_delete. We called
dev_kfree_skb_any for that skb which means we shouldn't access it anymore.
For the second time it (brcmu_pkt_buf_free_skb) was call from brcmf_txfinalize.
Unfortunately when brcmf_txfinalize was analyzing that skb (that was already
freed and invalid) it didn't contain ETH_P_PAE in the ethhdr anymore so
atomic_dec(&ifp->pend_8021x_cnt);
wasn't called.
So my guess is that:
1) We should fix brcmf_flowring_delete to use brcmf_txfinalize
2) We should avoid freeing the same skb twice
[ 167.596719] brcmfmac: [brcmf_cfg80211_del_key -> __send_key_to_dongle] ifp:c64c6480 brcmf_ifname(ifp):wlan1-1
[ 167.611257] brcmfmac: CONSOLE: 026896.770 wl0: Proxy STA 78:d6:f0:9b:ba:bc link is already gone !!??
[ 167.623375] brcmfmac: [brcmf_flowring_delete -> __brcmu_pkt_buf_free_skb] [ifp: (null)] Freeing skb:c7240240 skb->dev:c64c6000 skb->dev->name:wlan1-1
[ 167.640721] brcmfmac: [__brcmf_txfinalize -> __brcmu_pkt_buf_free_skb] [ifp:c64c6480] ***BUG*** skb:c7240240 skb->dev:c64c6000 skb->dev->name:wlan1-1
[ 167.654247] brcmfmac: [__brcmf_txfinalize -> __brcmu_pkt_buf_free_skb] [ifp:c64c6480] Original data: 78 d6 f0 9b ba bc 92 8d 78 66 3a 57 88 8e
[ 167.658643] brcmfmac: [brcmf_netdev_wait_pend8021x] ***TIMEOUT WARNING*** ifp:c64c6480 brcmf_ifname(ifp):wlan1-1 brcmf_get_pend_8021x_cnt(ifp):1
[ 167.680249] brcmfmac: [__brcmf_txfinalize -> __brcmu_pkt_buf_free_skb] [ifp:c64c6480] Current data: 88 53 2e 50 50 00 ba 87 01 e2 06 f8 08 00
[ 167.693239] ------------[ cut here ]------------
[ 167.697893] WARNING: CPU: 0 PID: 616 at compat-wireless-2016-06-20/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c:73 __brcmu_pkt_buf_free_skb+0x1a0/0x2f8 [brcmfmac]()
[ 167.713587] Modules linked in: pppoe ppp_async iptable_nat brcmfmac pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_id xt_conntrack xt_commed
[ 167.785932] CPU: 0 PID: 616 Comm: irq/33-brcmf_pc Not tainted 4.4.21 #0
[ 167.792560] Hardware name: BCM5301X
[ 167.796050] Backtrace:
[ 167.798525] [<c001708c>] (dump_backtrace) from [<c0017288>] (show_stack+0x18/0x1c)
[ 167.806112] r7:00000049 r6:bf1d1255 r5:60000013 r4:00000000
[ 167.811831] [<c0017270>] (show_stack) from [<c017d038>] (dump_stack+0x84/0xa4)
[ 167.819069] [<c017cfb4>] (dump_stack) from [<c0021490>] (warn_slowpath_common+0x8c/0xb8)
[ 167.827175] r5:00000009 r4:00000000
[ 167.830774] [<c0021404>] (warn_slowpath_common) from [<c0021560>] (warn_slowpath_null+0x24/0x2c)
[ 167.839579] r8:c64c653c r7:bf1c9f39 r6:c64c6480 r5:c7240240 r4:c69571c0
[ 167.846357] [<c002153c>] (warn_slowpath_null) from [<bf1bd670>] (__brcmu_pkt_buf_free_skb+0x1a0/0x2f8 [brcmfmac])
[ 167.856658] [<bf1bd4d0>] (__brcmu_pkt_buf_free_skb [brcmfmac]) from [<bf1bdfac>] (__brcmf_txfinalize+0x184/0x1b4 [brcmfmac])
[ 167.867893] r8:cacd1720 r7:c723d180 r6:c7240240 r5:00000001 r4:c64c6480
[ 167.874665] [<bf1bde28>] (__brcmf_txfinalize [brcmfmac]) from [<bf1c378c>] (brcmf_msgbuf_txdata+0x508/0x6b0 [brcmfmac])
[ 167.885466] r10:c7240240 r9:cacd1720 r8:cacd1720 r7:c723d180 r6:00000003 r5:00000001
[ 167.893352] r4:c6801c00
[ 167.895912] [<bf1c33cc>] (brcmf_msgbuf_txdata [brcmfmac]) from [<bf1c3970>] (brcmf_proto_msgbuf_rx_trigger+0x3c/0xd0 [brcmfmac])
[ 167.907496] r10:00000000 r9:c0493882 r8:c68005e4 r7:c0057d98 r6:c78850c0 r5:00010000
[ 167.915382] r4:c6801c00
[ 167.917941] [<bf1c3934>] (brcmf_proto_msgbuf_rx_trigger [brcmfmac]) from [<bf1c800c>] (brcmf_pcie_isr_thread+0x1c4/0x238 [brcmfmac])
[ 167.929874] r7:c0057d98 r6:c78850c0 r5:00010000 r4:c6970800
[ 167.935587] [<bf1c7e48>] (brcmf_pcie_isr_thread [brcmfmac]) from [<c0057dbc>] (irq_thread_fn+0x24/0x3c)
[ 167.945002] r9:c0493882 r8:c68005e4 r7:c0057d98 r6:c78850c0 r5:c68005c0 r4:c68005c0
[ 167.952803] [<c0057d98>] (irq_thread_fn) from [<c00580a0>] (irq_thread+0xf8/0x1e4)
[ 167.960381] r7:c0057d98 r6:c73f6000 r5:c68005c0 r4:c78850c0
[ 167.966089] [<c0057fa8>] (irq_thread) from [<c00394c4>] (kthread+0xe0/0xf4)
[ 167.973064] r10:00000000 r9:00000000 r8:00000000 r7:c0057fa8 r6:c68005c0 r5:00000000
[ 167.980948] r4:c6800b80
[ 167.983497] [<c00393e4>] (kthread) from [<c00097b8>] (ret_from_fork+0x14/0x3c)
[ 167.990732] r7:00000000 r6:00000000 r5:c00393e4 r4:c6800b80
[ 167.996449] ---[ end trace 47c5009c15f68c3e ]---
[ 168.001094] brcmfmac: [brcmf_netdev_wait_pend8021x] List of pending 802.1x skbs:
[ 168.008509] brcmfmac: [brcmf_netdev_wait_pend8021x] skb:c7240240 skb->dev:c64c6000 skb->dev->name:wlan1-1
[ 168.038638] brcmfmac: [brcmf_netdev_wait_pend8021x] ***TIMEOUT WARNING*** ifp:c64c6480 brcmf_ifname(ifp):wlan1-1 brcmf_get_pend_8021x_cnt(ifp):1
[ 168.051812] brcmfmac: [brcmf_netdev_wait_pend8021x] List of pending 802.1x skbs:
[ 168.059240] brcmfmac: [brcmf_netdev_wait_pend8021x] skb:c7240240 skb->dev:c64c6000 skb->dev->name:wlan1-1
[ 168.079296] brcmfmac: [brcmf_netdev_wait_pend8021x] ***TIMEOUT WARNING*** ifp:c64c6480 brcmf_ifname(ifp):wlan1-1 brcmf_get_pend_8021x_cnt(ifp):1
[ 168.092313] brcmfmac: [brcmf_netdev_wait_pend8021x] List of pending 802.1x skbs:
[ 168.099740] brcmfmac: [brcmf_netdev_wait_pend8021x] skb:c7240240 skb->dev:c64c6000 skb->dev->name:wlan1-1
[ 168.128800] brcmfmac: [brcmf_netdev_wait_pend8021x] ***TIMEOUT WARNING*** ifp:c64c6480 brcmf_ifname(ifp):wlan1-1 brcmf_get_pend_8021x_cnt(ifp):1
[ 168.141983] brcmfmac: [brcmf_netdev_wait_pend8021x] List of pending 802.1x skbs:
[ 168.149416] brcmfmac: [brcmf_netdev_wait_pend8021x] skb:c7240240 skb->dev: (null) skb->dev->name:---
[ 168.169281] brcmfmac: [brcmf_netdev_wait_pend8021x] ***TIMEOUT WARNING*** ifp:c64c6480 brcmf_ifname(ifp):wlan1-1 brcmf_get_pend_8021x_cnt(ifp):1
[ 168.182302] brcmfmac: [brcmf_netdev_wait_pend8021x] List of pending 802.1x skbs:
[ 168.189732] brcmfmac: [brcmf_netdev_wait_pend8021x] skb:c7240240 skb->dev: (null) skb->dev->name:---
[ 168.218759] brcmfmac: [brcmf_netdev_wait_pend8021x] ***TIMEOUT WARNING*** ifp:c64c6480 brcmf_ifname(ifp):wlan1-1 brcmf_get_pend_8021x_cnt(ifp):1
[ 168.231926] brcmfmac: [brcmf_netdev_wait_pend8021x] List of pending 802.1x skbs:
[ 168.239354] brcmfmac: [brcmf_netdev_wait_pend8021x] skb:c7240240 skb->dev: (null) skb->dev->name:---
[ 168.259276] brcmfmac: [brcmf_netdev_wait_pend8021x] ***TIMEOUT WARNING*** ifp:c64c6480 brcmf_ifname(ifp):wlan1-1 brcmf_get_pend_8021x_cnt(ifp):1
[ 168.272305] brcmfmac: [brcmf_netdev_wait_pend8021x] List of pending 802.1x skbs:
[ 168.279732] brcmfmac: [brcmf_netdev_wait_pend8021x] skb:c7240240 skb->dev: (null) skb->dev->name:---
[ 168.308693] brcmfmac: [brcmf_netdev_wait_pend8021x] ***TIMEOUT WARNING*** ifp:c64c6480 brcmf_ifname(ifp):wlan1-1 brcmf_get_pend_8021x_cnt(ifp):1
[ 168.321854] brcmfmac: [brcmf_netdev_wait_pend8021x] List of pending 802.1x skbs:
[ 168.329292] brcmfmac: [brcmf_netdev_wait_pend8021x] skb:c7240240 skb->dev: (null) skb->dev->name:---
[ 168.349262] brcmfmac: [brcmf_netdev_wait_pend8021x] ***TIMEOUT WARNING*** ifp:c64c6480 brcmf_ifname(ifp):wlan1-1 brcmf_get_pend_8021x_cnt(ifp):1
[ 168.362273] brcmfmac: [brcmf_netdev_wait_pend8021x] List of pending 802.1x skbs:
[ 168.369708] brcmfmac: [brcmf_netdev_wait_pend8021x] skb:c7240240 skb->dev: (null) skb->dev->name:---
[ 168.398634] brcmfmac: [brcmf_netdev_wait_pend8021x] ***TIMEOUT WARNING*** ifp:c64c6480 brcmf_ifname(ifp):wlan1-1 brcmf_get_pend_8021x_cnt(ifp):1
[ 168.411800] brcmfmac: [brcmf_netdev_wait_pend8021x] List of pending 802.1x skbs:
[ 168.419232] brcmfmac: [brcmf_netdev_wait_pend8021x] skb:c7240240 skb->dev: (null) skb->dev->name:---
[ 168.439270] brcmfmac: [brcmf_netdev_wait_pend8021x] ***TIMEOUT WARNING*** ifp:c64c6480 brcmf_ifname(ifp):wlan1-1 brcmf_get_pend_8021x_cnt(ifp):1
[ 168.452280] brcmfmac: [brcmf_netdev_wait_pend8021x] List of pending 802.1x skbs:
[ 168.459704] brcmfmac: [brcmf_netdev_wait_pend8021x] skb:c7240240 skb->dev: (null) skb->dev->name:---
[ 168.488634] brcmfmac: [brcmf_netdev_wait_pend8021x] ***TIMEOUT WARNING*** ifp:c64c6480 brcmf_ifname(ifp):wlan1-1 brcmf_get_pend_8021x_cnt(ifp):1
[ 168.501817] brcmfmac: [brcmf_netdev_wait_pend8021x] List of pending 802.1x skbs:
[ 168.509246] brcmfmac: [brcmf_netdev_wait_pend8021x] skb:c7240240 skb->dev: (null) skb->dev->name:---
---
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 6 +-
.../wireless/broadcom/brcm80211/brcmfmac/core.c | 104 ++++++++++++++++++++-
.../wireless/broadcom/brcm80211/brcmfmac/core.h | 18 +++-
.../broadcom/brcm80211/brcmfmac/flowring.c | 2 +
.../broadcom/brcm80211/brcmfmac/fwsignal.c | 30 +++++-
.../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 21 +++++
.../net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 3 +
.../wireless/broadcom/brcm80211/brcmutil/utils.c | 2 +-
.../broadcom/brcm80211/include/brcmu_utils.h | 2 +-
9 files changed, 178 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 201a980..47d82f2 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -464,11 +464,12 @@ static void convert_key_from_CPU(struct brcmf_wsec_key *key,
}
static int
-send_key_to_dongle(struct brcmf_if *ifp, struct brcmf_wsec_key *key)
+__send_key_to_dongle(const char *c0, struct brcmf_if *ifp, struct brcmf_wsec_key *key)
{
int err;
struct brcmf_wsec_key_le key_le;
+ pr_info("[%s -> %s] ifp:%p brcmf_ifname(ifp):%s\n", c0, __func__, ifp, brcmf_ifname(ifp));
convert_key_from_CPU(key, &key_le);
brcmf_netdev_wait_pend8021x(ifp);
@@ -480,6 +481,7 @@ send_key_to_dongle(struct brcmf_if *ifp, struct brcmf_wsec_key *key)
brcmf_err("wsec_key error (%d)\n", err);
return err;
}
+#define send_key_to_dongle(ifp, key) __send_key_to_dongle(__func__, ifp, key)
static s32
brcmf_configure_arp_nd_offload(struct brcmf_if *ifp, bool enable)
@@ -2610,6 +2612,8 @@ brcmf_cfg80211_get_station(struct wiphy *wiphy, struct net_device *ndev,
int rssi;
u32 i;
+ brcmf_netdev_wait_pend8021x(ifp);
+
brcmf_dbg(TRACE, "Enter, MAC %pM\n", mac);
if (!check_vif_up(ifp->vif))
return -EIO;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 8d16f02..346d39a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -38,7 +38,52 @@
#include "pcie.h"
#include "common.h"
-#define MAX_WAIT_FOR_8021X_TX msecs_to_jiffies(950)
+#include <linux/sched.h>
+
+static size_t print_time(u64 ts, char *buf)
+{
+ unsigned long rem_nsec;
+
+ rem_nsec = do_div(ts, 1000000000);
+
+ if (!buf)
+ return snprintf(NULL, 0, "[%5lu.000000]", (unsigned long)ts);
+
+ return sprintf(buf, "[%5lu.%06lu]",
+ (unsigned long)ts, rem_nsec / 1000);
+}
+
+/* Free the driver packet. Free the tag if present */
+void __brcmu_pkt_buf_free_skb(const char *c0, struct brcmf_if *ifp, struct sk_buff *skb)
+{
+ if (!skb)
+ return;
+
+ if (ifp) {
+ struct pend_skb *e;
+
+ mutex_lock(&ifp->pend_8021x_mutex);
+ list_for_each_entry(e, &ifp->pend_8021x_skbs, list) {
+ if (e->skb == skb) {
+ pr_info("[%s -> %s] [ifp:%p] ***BUG*** skb:%p skb->dev:%p skb->dev->name:%s\n", c0, __func__, ifp, e->skb, e->skb->dev, e->skb->dev ? e->skb->dev->name : "---");
+ pr_info("[%s -> %s] [ifp:%p] Original data: %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x\n", c0, __func__, ifp,
+ e->data[0x00], e->data[0x01], e->data[0x02], e->data[0x03], e->data[0x04], e->data[0x05], e->data[0x06], e->data[0x07], e->data[0x08], e->data[0x09], e->data[0x0a], e->data[0x0b], e->data[0x0c], e->data[0x0d]);
+ pr_info("[%s -> %s] [ifp:%p] Current data: %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x %02x\n", c0, __func__, ifp,
+ skb->data[0x00], skb->data[0x01], skb->data[0x02], skb->data[0x03], skb->data[0x04], skb->data[0x05], skb->data[0x06], skb->data[0x07], skb->data[0x08], skb->data[0x09], skb->data[0x0a], skb->data[0x0b], skb->data[0x0c], skb->data[0x0d]);
+ WARN_ON(1);
+ break;
+ }
+ }
+ mutex_unlock(&ifp->pend_8021x_mutex);
+ } else if (strcmp(c0, "brcmf_msgbuf_query_dcmd")) {
+ pr_info("[%s -> %s] [ifp:%p] Freeing skb:%p skb->dev:%p skb->dev->name:%s\n", c0, __func__, ifp, skb, skb->dev, skb->dev ? skb->dev->name : "---");
+ }
+
+ WARN_ON(skb->next);
+ dev_kfree_skb_any(skb);
+}
+
+#define MAX_WAIT_FOR_8021X_TX msecs_to_jiffies(10)
#define BRCMF_BSSIDX_INVALID -1
@@ -247,8 +292,19 @@ static netdev_tx_t brcmf_netdev_start_xmit(struct sk_buff *skb,
goto done;
}
- if (eh->h_proto == htons(ETH_P_PAE))
+ if (eh->h_proto == htons(ETH_P_PAE)) {
+ struct pend_skb *e;
+
+ e = kzalloc(sizeof(*e), GFP_KERNEL);
+ e->skb = skb;
+ memcpy(e->data, skb->data, 14);
+ e->start_time = local_clock();
+
atomic_inc(&ifp->pend_8021x_cnt);
+ mutex_lock(&ifp->pend_8021x_mutex);
+ list_add_tail(&e->list, &ifp->pend_8021x_skbs);
+ mutex_unlock(&ifp->pend_8021x_mutex);
+ }
ret = brcmf_fws_process_skb(ifp, skb);
@@ -333,7 +389,7 @@ static int brcmf_rx_hdrpull(struct brcmf_pub *drvr, struct sk_buff *skb,
if (ret || !(*ifp) || !(*ifp)->ndev) {
if (ret != -ENODATA && *ifp)
(*ifp)->stats.rx_errors++;
- brcmu_pkt_buf_free_skb(skb);
+ __brcmu_pkt_buf_free_skb(__func__, *ifp, skb);
return -ENODATA;
}
@@ -378,7 +434,7 @@ void brcmf_rx_event(struct device *dev, struct sk_buff *skb)
brcmu_pkt_buf_free_skb(skb);
}
-void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff *txp, bool success)
+void __brcmf_txfinalize(const char *c0, struct brcmf_if *ifp, struct sk_buff *txp, bool success)
{
struct ethhdr *eh;
u16 type;
@@ -387,7 +443,30 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff *txp, bool success)
type = ntohs(eh->h_proto);
if (type == ETH_P_PAE) {
+ struct pend_skb *e, *tmp;
+
atomic_dec(&ifp->pend_8021x_cnt);
+ mutex_lock(&ifp->pend_8021x_mutex);
+ list_for_each_entry_safe(e, tmp, &ifp->pend_8021x_skbs, list) {
+ if (e->skb == txp) {
+ if (e->timedout) {
+ char start[32], commit[32];
+
+ print_time(e->start_time, start);
+ print_time(e->commit_time, commit);
+
+ pr_info("[%s -> %s] Finally finalizing skb:%p skb->dev:%p skb->dev->name:%s (start_time:%s; commit_time:%s)\n",
+ c0, __func__,
+ e->skb, e->skb->dev, e->skb->dev ? e->skb->dev->name : "---",
+ start, commit);
+ }
+
+ list_del(&e->list);
+ kfree(e);
+ break;
+ }
+ }
+ mutex_unlock(&ifp->pend_8021x_mutex);
if (waitqueue_active(&ifp->pend_8021x_wait))
wake_up(&ifp->pend_8021x_wait);
}
@@ -476,6 +555,8 @@ static int brcmf_netdev_open(struct net_device *ndev)
}
atomic_set(&ifp->pend_8021x_cnt, 0);
+ INIT_LIST_HEAD(&ifp->pend_8021x_skbs);
+ mutex_init(&ifp->pend_8021x_mutex);
/* Get current TOE mode from dongle */
if (brcmf_fil_iovar_int_get(ifp, "toe_ol", &toe_ol) >= 0
@@ -1169,7 +1250,20 @@ int brcmf_netdev_wait_pend8021x(struct brcmf_if *ifp)
!brcmf_get_pend_8021x_cnt(ifp),
MAX_WAIT_FOR_8021X_TX);
- WARN_ON(!err);
+ //WARN_ON(!err);
+ if (!err)
+ pr_info("[%s] ***TIMEOUT WARNING*** ifp:%p brcmf_ifname(ifp):%s brcmf_get_pend_8021x_cnt(ifp):%d\n", __func__, ifp, brcmf_ifname(ifp), brcmf_get_pend_8021x_cnt(ifp));
+ if (!list_empty(&ifp->pend_8021x_skbs)) {
+ struct pend_skb *e;
+
+ mutex_lock(&ifp->pend_8021x_mutex);
+ pr_info("[%s] List of pending 802.1x skbs:\n", __func__);
+ list_for_each_entry(e, &ifp->pend_8021x_skbs, list) {
+ e->timedout = true;
+ pr_info("[%s] skb:%p skb->dev:%p skb->dev->name:%s\n", __func__, e->skb, e->skb->dev, e->skb->dev ? e->skb->dev->name : "---");
+ }
+ mutex_unlock(&ifp->pend_8021x_mutex);
+ }
return !err;
}
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
index 8fa34ca..0ee20d4 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
@@ -50,6 +50,9 @@
#define NDOL_MAX_ENTRIES 8
+void __brcmu_pkt_buf_free_skb(const char *c0, struct brcmf_if *ifp, struct sk_buff *skb);
+#define brcmu_pkt_buf_free_skb(skb) __brcmu_pkt_buf_free_skb(__func__, ifp, skb)
+
/**
* struct brcmf_ampdu_rx_reorder - AMPDU receive reorder info
*
@@ -169,6 +172,15 @@ enum brcmf_netif_stop_reason {
BRCMF_NETIF_STOP_REASON_DISCONNECTED = BIT(2)
};
+struct pend_skb {
+ struct sk_buff *skb;
+ u8 data[14];
+ u64 start_time;
+ u64 commit_time;
+ bool timedout;
+ struct list_head list;
+};
+
/**
* struct brcmf_if - interface control information.
*
@@ -203,6 +215,9 @@ struct brcmf_if {
u8 netif_stop;
spinlock_t netif_stop_lock;
atomic_t pend_8021x_cnt;
+ struct list_head pend_8021x_skbs;
+ struct mutex pend_8021x_mutex;
+ bool pend_8021x_ready;
wait_queue_head_t pend_8021x_wait;
struct in6_addr ipv6_addr_tbl[NDOL_MAX_ENTRIES];
u8 ipv6addr_idx;
@@ -219,7 +234,8 @@ struct brcmf_if *brcmf_add_if(struct brcmf_pub *drvr, s32 bsscfgidx, s32 ifidx,
void brcmf_remove_interface(struct brcmf_if *ifp, bool rtnl_locked);
void brcmf_txflowblock_if(struct brcmf_if *ifp,
enum brcmf_netif_stop_reason reason, bool state);
-void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff *txp, bool success);
+void __brcmf_txfinalize(const char *c0, struct brcmf_if *ifp, struct sk_buff *txp, bool success);
+#define brcmf_txfinalize(ifp, txp, success) __brcmf_txfinalize(__func__, ifp, txp, success)
void brcmf_netif_rx(struct brcmf_if *ifp, struct sk_buff *skb);
void brcmf_net_setcarrier(struct brcmf_if *ifp, bool on);
void brcmf_c_set_joinpref_default(struct brcmf_if *ifp);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/flowring.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/flowring.c
index 7e269f9..87c8de0 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/flowring.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/flowring.c
@@ -249,6 +249,8 @@ void brcmf_flowring_delete(struct brcmf_flowring *flow, u16 flowid)
skb = skb_dequeue(&ring->skblist);
while (skb) {
+ struct brcmf_if *ifp = NULL;
+
brcmu_pkt_buf_free_skb(skb);
skb = skb_dequeue(&ring->skblist);
}
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
index 9f9024a..7a17afd 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
@@ -38,6 +38,8 @@
#include "proto.h"
#include "common.h"
+#include <linux/sched.h>
+
/**
* DOC: Firmware Signalling
*
@@ -590,6 +592,8 @@ static void brcmf_fws_psq_flush(struct brcmf_fws_info *fws, struct pktq *q,
for (prec = 0; prec < q->num_prec; prec++) {
skb = brcmu_pktq_pdeq_match(q, prec, matchfn, &ifidx);
while (skb) {
+ struct brcmf_if *ifp = NULL;
+
brcmu_pkt_buf_free_skb(skb);
skb = brcmu_pktq_pdeq_match(q, prec, matchfn, &ifidx);
}
@@ -697,6 +701,8 @@ static void brcmf_fws_hanger_cleanup(struct brcmf_fws_info *fws,
s == BRCMF_FWS_HANGER_ITEM_STATE_INUSE_SUPPRESSED) {
skb = h->items[i].pkt;
if (fn == NULL || fn(skb, &ifidx)) {
+ struct brcmf_if *ifp = NULL;
+
/* suppress packets freed from psq */
if (s == BRCMF_FWS_HANGER_ITEM_STATE_INUSE)
brcmu_pkt_buf_free_skb(skb);
@@ -845,6 +851,8 @@ static void brcmf_fws_bus_txq_cleanup(struct brcmf_fws_info *fws,
for (prec = 0; prec < txq->num_prec; prec++) {
skb = brcmu_pktq_pdeq_match(txq, prec, fn, &ifidx);
while (skb) {
+ struct brcmf_if *ifp = NULL;
+
hslot = brcmf_skb_htod_tag_get_field(skb, HSLOT);
hi = &fws->hanger.items[hslot];
WARN_ON(skb != hi->pkt);
@@ -971,8 +979,11 @@ static bool brcmf_fws_tim_update(struct brcmf_fws_info *fws,
brcmf_fws_unlock(fws);
err = brcmf_proto_txdata(fws->drvr, ifidx, data_offset, skb);
brcmf_fws_lock(fws);
- if (err)
+ if (err) {
+ struct brcmf_if *ifp = NULL;
+
brcmu_pkt_buf_free_skb(skb);
+ }
return true;
}
return false;
@@ -2056,6 +2067,22 @@ static int brcmf_fws_commit_skb(struct brcmf_fws_info *fws, int fifo,
(void)brcmf_proto_hdrpull(fws->drvr, false, skb, NULL);
goto rollback;
}
+ {
+ struct brcmf_if *ifp = brcmf_get_ifp(fws->drvr, brcmf_skb_if_flags_get_field(skb, INDEX));
+
+ if (ifp) {
+ struct pend_skb *e;
+
+ mutex_lock(&ifp->pend_8021x_mutex);
+ list_for_each_entry(e, &ifp->pend_8021x_skbs, list) {
+ if (e->skb == skb) {
+ e->commit_time = local_clock();
+ break;
+ }
+ }
+ mutex_unlock(&ifp->pend_8021x_mutex);
+ }
+ }
fws->stats.pkt2bus++;
fws->stats.send_pkts[fifo]++;
@@ -2454,6 +2481,7 @@ bool brcmf_fws_fc_active(struct brcmf_fws_info *fws)
void brcmf_fws_bustxfail(struct brcmf_fws_info *fws, struct sk_buff *skb)
{
+ struct brcmf_if *ifp = NULL;
u32 hslot;
if (brcmf_skbcb(skb)->state == BRCMF_FWS_SKBSTATE_TIM) {
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
index 2b9a2bc..6ff91c2 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
@@ -34,6 +34,8 @@
#include "bus.h"
#include "tracepoint.h"
+#include <linux/sched.h>
+
#define MSGBUF_IOCTL_RESP_TIMEOUT msecs_to_jiffies(2000)
@@ -392,6 +394,8 @@ brcmf_msgbuf_release_array(struct device *dev,
count = 0;
do {
if (array[count].allocated.counter) {
+ struct brcmf_if *ifp = NULL;
+
pktid = &array[count];
dma_unmap_single(dev, pktid->physaddr,
pktid->skb->len - pktid->data_offset,
@@ -483,6 +487,7 @@ static int brcmf_msgbuf_query_dcmd(struct brcmf_pub *drvr, int ifidx,
{
struct brcmf_msgbuf *msgbuf = (struct brcmf_msgbuf *)drvr->proto->pd;
struct sk_buff *skb = NULL;
+ struct brcmf_if *ifp = NULL;
int timeout;
int err;
@@ -747,6 +752,22 @@ static void brcmf_msgbuf_txflow(struct brcmf_msgbuf *msgbuf, u16 flowid)
brcmf_commonring_write_complete(commonring);
count = 0;
}
+ {
+ struct brcmf_if *ifp = brcmf_get_ifp(msgbuf->drvr, tx_msghdr->msg.ifidx);
+
+ if (ifp) {
+ struct pend_skb *e;
+
+ mutex_lock(&ifp->pend_8021x_mutex);
+ list_for_each_entry(e, &ifp->pend_8021x_skbs, list) {
+ if (e->skb == skb) {
+ e->commit_time = local_clock();
+ break;
+ }
+ }
+ mutex_unlock(&ifp->pend_8021x_mutex);
+ }
+ }
}
if (count)
brcmf_commonring_write_complete(commonring);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
index 2f978a3..edbe353 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
@@ -498,6 +498,7 @@ static void brcmf_usb_rx_complete(struct urb *urb)
{
struct brcmf_usbreq *req = (struct brcmf_usbreq *)urb->context;
struct brcmf_usbdev_info *devinfo = req->devinfo;
+ struct brcmf_if *ifp = NULL;
struct sk_buff *skb;
brcmf_dbg(USB, "Enter, urb->status=%d\n", urb->status);
@@ -548,6 +549,8 @@ static void brcmf_usb_rx_refill(struct brcmf_usbdev_info *devinfo,
ret = usb_submit_urb(req->urb, GFP_ATOMIC);
if (ret) {
+ struct brcmf_if *ifp = NULL;
+
brcmf_usb_del_fromq(devinfo, req);
brcmu_pkt_buf_free_skb(req->skb);
req->skb = NULL;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmutil/utils.c b/drivers/net/wireless/broadcom/brcm80211/brcmutil/utils.c
index 0543607..bf525b7 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmutil/utils.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmutil/utils.c
@@ -49,7 +49,7 @@ void brcmu_pkt_buf_free_skb(struct sk_buff *skb)
WARN_ON(skb->next);
dev_kfree_skb_any(skb);
}
-EXPORT_SYMBOL(brcmu_pkt_buf_free_skb);
+//EXPORT_SYMBOL(brcmu_pkt_buf_free_skb);
/*
* osl multiple-precedence packet queue
diff --git a/drivers/net/wireless/broadcom/brcm80211/include/brcmu_utils.h b/drivers/net/wireless/broadcom/brcm80211/include/brcmu_utils.h
index 4196952..7bd705d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcmu_utils.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcmu_utils.h
@@ -126,7 +126,7 @@ struct sk_buff *brcmu_pktq_pdeq_match(struct pktq *pq, int prec,
/* packet primitives */
struct sk_buff *brcmu_pkt_buf_get_skb(uint len);
-void brcmu_pkt_buf_free_skb(struct sk_buff *skb);
+//void brcmu_pkt_buf_free_skb(struct sk_buff *skb);
/* Empty the queue at particular precedence level */
/* callback function fn(pkt, arg) returns true if pkt belongs to if */
--
2.9.3
^ permalink raw reply related
* RE: [PATCH v2 2/9] mac80211: add boilerplate code for start / stop NAN
From: Beker, Ayala @ 2016-09-20 11:45 UTC (permalink / raw)
To: Arend Van Spriel, Otcheretianski, Andrei, Luca Coelho,
johannes@sipsolutions.net
Cc: linux-wireless@vger.kernel.org, Grumbach, Emmanuel,
Coelho, Luciano
In-Reply-To: <ab55211c-9e82-38cf-8f7f-effa4b12d72b@broadcom.com>
-----Original Message-----
From: Arend Van Spriel [mailto:arend.vanspriel@broadcom.com]
Sent: Sunday, September 18, 2016 22:01
To: Otcheretianski, Andrei <andrei.otcheretianski@intel.com>; Luca Coelho <luca@coelho.fi>; johannes@sipsolutions.net
Cc: linux-wireless@vger.kernel.org; Beker, Ayala <ayala.beker@intel.com>; Grumbach, Emmanuel <emmanuel.grumbach@intel.com>; Coelho, Luciano <luciano.coelho@intel.com>
Subject: Re: [PATCH v2 2/9] mac80211: add boilerplate code for start / stop NAN
On 18-9-2016 9:59, Otcheretianski, Andrei wrote:
>> -----Original Message-----
>> From: Arend Van Spriel [mailto:arend.vanspriel@broadcom.com]
>> Sent: Friday, September 16, 2016 14:09
>> To: Luca Coelho <luca@coelho.fi>; johannes@sipsolutions.net
>> Cc: linux-wireless@vger.kernel.org; Beker, Ayala
>> <ayala.beker@intel.com>; Otcheretianski, Andrei
>> <andrei.otcheretianski@intel.com>; Grumbach, Emmanuel
>> <emmanuel.grumbach@intel.com>; Coelho, Luciano
>> <luciano.coelho@intel.com>
>> Subject: Re: [PATCH v2 2/9] mac80211: add boilerplate code for start
>> / stop NAN
>>
>> On 16-9-2016 10:33, Luca Coelho wrote:
>>> From: Ayala Beker <ayala.beker@intel.com>
>>>
>>> This code doesn't do much besides allowing to start and stop the vif.
>>>
>>> Signed-off-by: Andrei Otcheretianski
>>> <andrei.otcheretianski@intel.com>
>>> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>>> Signed-off-by: Ayala Beker <ayala.beker@intel.com>
>>> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
>>> ---
>>> include/net/mac80211.h | 9 +++++++++
>>> net/mac80211/cfg.c | 36 ++++++++++++++++++++++++++++++++++
>>> net/mac80211/chan.c | 3 +++
>>> net/mac80211/driver-ops.h | 29 ++++++++++++++++++++++++++-
>>> net/mac80211/iface.c | 8 ++++++--
>>> net/mac80211/main.c | 5 +++++
>>> net/mac80211/offchannel.c | 3 ++-
>>> net/mac80211/trace.h | 50
>> +++++++++++++++++++++++++++++++++++++++++++++++
>>> net/mac80211/util.c | 3 ++-
>>> 9 files changed, 141 insertions(+), 5 deletions(-)
>>
>> [...]
>>
>>> diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
>>> index fe35a1c..67b42c8 100644
>>> --- a/net/mac80211/driver-ops.h
>>> +++ b/net/mac80211/driver-ops.h
>>> @@ -163,7 +163,8 @@ static inline void drv_bss_info_changed(struct
>>> ieee80211_local *local,
>>>
>>> if (WARN_ON_ONCE(sdata->vif.type ==
>> NL80211_IFTYPE_P2P_DEVICE ||
>>> (sdata->vif.type == NL80211_IFTYPE_MONITOR &&
>>> - !sdata->vif.mu_mimo_owner)))
>>> + !sdata->vif.mu_mimo_owner) ||
>>> + sdata->vif.type == NL80211_IFTYPE_NAN))
>>
>> Might be more clear to move this up right after P2P_DEVICE check.
>
> Why? It's a completely separate new condition - so it goes to the end.
> I would say readability. Both P2P_DEVICE and NAN checks are single comparisons as opposed to the MONITOR check.
>>
>>> return;
>>>
>>> if (!check_sdata_in_driver(sdata)) @@ -1165,4 +1166,30 @@ static
>>> inline void drv_wake_tx_queue(struct
>> ieee80211_local *local,
>>> local->ops->wake_tx_queue(&local->hw, &txq->txq); }
>>>
>>> +static inline int drv_start_nan(struct ieee80211_local *local,
>>> + struct ieee80211_sub_if_data *sdata,
>>> + struct cfg80211_nan_conf *conf) {
>>> + int ret;
>>> +
>>> + might_sleep();
>>> + check_sdata_in_driver(sdata);
>>> +
>>> + trace_drv_start_nan(local, sdata, conf);
>>> + ret = local->ops->start_nan(&local->hw, &sdata->vif, conf);
>>> + trace_drv_return_int(local, ret);
>>> + return ret;
>>> +}
>>> +
>>> +static inline void drv_stop_nan(struct ieee80211_local *local,
>>> + struct ieee80211_sub_if_data *sdata) {
>>> + might_sleep();
>>> + check_sdata_in_driver(sdata);
>>> +
>>> + trace_drv_stop_nan(local, sdata);
>>> + local->ops->stop_nan(&local->hw, &sdata->vif);
>>> + trace_drv_return_void(local);
>>> +}
>>> +
>>> #endif /* __MAC80211_DRIVER_OPS */
>>> diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c index
>>> e694ca2..507f46a 100644
>>> --- a/net/mac80211/iface.c
>>> +++ b/net/mac80211/iface.c
>>> @@ -327,6 +327,9 @@ static int ieee80211_check_queues(struct
>> ieee80211_sub_if_data *sdata,
>>> int n_queues = sdata->local->hw.queues;
>>> int i;
>>>
>>> + if (iftype == NL80211_IFTYPE_NAN)
>>> + return 0;
>>> +
>>> if (iftype != NL80211_IFTYPE_P2P_DEVICE) {
>>> for (i = 0; i < IEEE80211_NUM_ACS; i++) {
>>> if (WARN_ON_ONCE(sdata->vif.hw_queue[i] == @@
>> -647,7 +650,8 @@ int
>>> ieee80211_do_open(struct wireless_dev *wdev, bool coming_up)
>>> local->fif_probe_req++;
>>> }
>>>
>>> - if (sdata->vif.type != NL80211_IFTYPE_P2P_DEVICE)
>>> + if (sdata->vif.type != NL80211_IFTYPE_P2P_DEVICE &&
>>> + sdata->vif.type != NL80211_IFTYPE_NAN)
>>
>> similar check keeps reoccuring in various places so maybe we can
>> create a helper function for it.
>
> Right, but not sure that it deserves a function.
> If similar new iftypes are anticipated it would make sense as it would mean adding it in one place.
I don't think there is something in common to those interface types that can fit such a function semantically, so I decided not to change it.
Do you have any idea?
> Regards,
> Arend
---------------------------------------------------------------------
A member of the Intel Corporation group of companies
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply
* Re: [PATCH 1/1] rsi: fix memory leak in debugfs entry and supported bands
From: Arend Van Spriel @ 2016-09-20 12:27 UTC (permalink / raw)
To: Prameela Rani Garnepudi, linux-wireless
Cc: kvalo, johannes.berg, hofrat, xypron.glpk,
Prameela Rani Garnepudi
In-Reply-To: <1474353784-9552-1-git-send-email-prameela.j04cs@gmail.com>
On 20-9-2016 8:43, Prameela Rani Garnepudi wrote:
> From: Prameela Rani Garnepudi <prameela.garnepudi@redpinesignals.com>
>
> Signed-off-by: Prameela Rani Garnepudi <prameela.garnepudi@redpinesignals.com>
> Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
Now you are exaggerating ;-) One of these should be sufficient. Instead
some descriptive text in the commit message is required. Describe the
scenario in which the memory is leaked, ie. during driver unload.
> ---
> 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++) {
Use NUM_NL80211_BANDS instead of hardcoded value.
Regards,
Arend
> + struct ieee80211_supported_band *sbands = &adapter->sbands[i];
> +
> + kfree(sbands->channels);
> + }
^ permalink raw reply
* Re: [PATCH v2 2/9] mac80211: add boilerplate code for start / stop NAN
From: Arend Van Spriel @ 2016-09-20 12:29 UTC (permalink / raw)
To: Beker, Ayala, Otcheretianski, Andrei, Luca Coelho,
johannes@sipsolutions.net
Cc: linux-wireless@vger.kernel.org, Grumbach, Emmanuel,
Coelho, Luciano
In-Reply-To: <6E2DD73D17E17047917F6A81399A8ED3972503A6@hasmsx109.ger.corp.intel.com>
On 20-9-2016 13:45, Beker, Ayala wrote:
> -----Original Message-----
> From: Arend Van Spriel [mailto:arend.vanspriel@broadcom.com]
> Sent: Sunday, September 18, 2016 22:01
> To: Otcheretianski, Andrei <andrei.otcheretianski@intel.com>; Luca Coelho <luca@coelho.fi>; johannes@sipsolutions.net
> Cc: linux-wireless@vger.kernel.org; Beker, Ayala <ayala.beker@intel.com>; Grumbach, Emmanuel <emmanuel.grumbach@intel.com>; Coelho, Luciano <luciano.coelho@intel.com>
> Subject: Re: [PATCH v2 2/9] mac80211: add boilerplate code for start / stop NAN
>
> On 18-9-2016 9:59, Otcheretianski, Andrei wrote:
>>> -----Original Message-----
>>> From: Arend Van Spriel [mailto:arend.vanspriel@broadcom.com]
>>> Sent: Friday, September 16, 2016 14:09
>>> To: Luca Coelho <luca@coelho.fi>; johannes@sipsolutions.net
>>> Cc: linux-wireless@vger.kernel.org; Beker, Ayala
>>> <ayala.beker@intel.com>; Otcheretianski, Andrei
>>> <andrei.otcheretianski@intel.com>; Grumbach, Emmanuel
>>> <emmanuel.grumbach@intel.com>; Coelho, Luciano
>>> <luciano.coelho@intel.com>
>>> Subject: Re: [PATCH v2 2/9] mac80211: add boilerplate code for start
>>> / stop NAN
>>>
>>> On 16-9-2016 10:33, Luca Coelho wrote:
>>>> From: Ayala Beker <ayala.beker@intel.com>
>>>>
>>>> This code doesn't do much besides allowing to start and stop the vif.
>>>>
>>>> Signed-off-by: Andrei Otcheretianski
>>>> <andrei.otcheretianski@intel.com>
>>>> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>>>> Signed-off-by: Ayala Beker <ayala.beker@intel.com>
>>>> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
>>>> ---
>>>> include/net/mac80211.h | 9 +++++++++
>>>> net/mac80211/cfg.c | 36 ++++++++++++++++++++++++++++++++++
>>>> net/mac80211/chan.c | 3 +++
>>>> net/mac80211/driver-ops.h | 29 ++++++++++++++++++++++++++-
>>>> net/mac80211/iface.c | 8 ++++++--
>>>> net/mac80211/main.c | 5 +++++
>>>> net/mac80211/offchannel.c | 3 ++-
>>>> net/mac80211/trace.h | 50
>>> +++++++++++++++++++++++++++++++++++++++++++++++
>>>> net/mac80211/util.c | 3 ++-
>>>> 9 files changed, 141 insertions(+), 5 deletions(-)
>>>
>>> [...]
>>>
>>>> diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
>>>> index fe35a1c..67b42c8 100644
>>>> --- a/net/mac80211/driver-ops.h
>>>> +++ b/net/mac80211/driver-ops.h
>>>> @@ -163,7 +163,8 @@ static inline void drv_bss_info_changed(struct
>>>> ieee80211_local *local,
>>>>
>>>> if (WARN_ON_ONCE(sdata->vif.type ==
>>> NL80211_IFTYPE_P2P_DEVICE ||
>>>> (sdata->vif.type == NL80211_IFTYPE_MONITOR &&
>>>> - !sdata->vif.mu_mimo_owner)))
>>>> + !sdata->vif.mu_mimo_owner) ||
>>>> + sdata->vif.type == NL80211_IFTYPE_NAN))
>>>
>>> Might be more clear to move this up right after P2P_DEVICE check.
>>
>> Why? It's a completely separate new condition - so it goes to the end.
>
>> I would say readability. Both P2P_DEVICE and NAN checks are single comparisons as opposed to the MONITOR check.
>
>>>
>>>> return;
>>>>
>>>> if (!check_sdata_in_driver(sdata)) @@ -1165,4 +1166,30 @@ static
>>>> inline void drv_wake_tx_queue(struct
>>> ieee80211_local *local,
>>>> local->ops->wake_tx_queue(&local->hw, &txq->txq); }
>>>>
>>>> +static inline int drv_start_nan(struct ieee80211_local *local,
>>>> + struct ieee80211_sub_if_data *sdata,
>>>> + struct cfg80211_nan_conf *conf) {
>>>> + int ret;
>>>> +
>>>> + might_sleep();
>>>> + check_sdata_in_driver(sdata);
>>>> +
>>>> + trace_drv_start_nan(local, sdata, conf);
>>>> + ret = local->ops->start_nan(&local->hw, &sdata->vif, conf);
>>>> + trace_drv_return_int(local, ret);
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static inline void drv_stop_nan(struct ieee80211_local *local,
>>>> + struct ieee80211_sub_if_data *sdata) {
>>>> + might_sleep();
>>>> + check_sdata_in_driver(sdata);
>>>> +
>>>> + trace_drv_stop_nan(local, sdata);
>>>> + local->ops->stop_nan(&local->hw, &sdata->vif);
>>>> + trace_drv_return_void(local);
>>>> +}
>>>> +
>>>> #endif /* __MAC80211_DRIVER_OPS */
>>>> diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c index
>>>> e694ca2..507f46a 100644
>>>> --- a/net/mac80211/iface.c
>>>> +++ b/net/mac80211/iface.c
>>>> @@ -327,6 +327,9 @@ static int ieee80211_check_queues(struct
>>> ieee80211_sub_if_data *sdata,
>>>> int n_queues = sdata->local->hw.queues;
>>>> int i;
>>>>
>>>> + if (iftype == NL80211_IFTYPE_NAN)
>>>> + return 0;
>>>> +
>>>> if (iftype != NL80211_IFTYPE_P2P_DEVICE) {
>>>> for (i = 0; i < IEEE80211_NUM_ACS; i++) {
>>>> if (WARN_ON_ONCE(sdata->vif.hw_queue[i] == @@
>>> -647,7 +650,8 @@ int
>>>> ieee80211_do_open(struct wireless_dev *wdev, bool coming_up)
>>>> local->fif_probe_req++;
>>>> }
>>>>
>>>> - if (sdata->vif.type != NL80211_IFTYPE_P2P_DEVICE)
>>>> + if (sdata->vif.type != NL80211_IFTYPE_P2P_DEVICE &&
>>>> + sdata->vif.type != NL80211_IFTYPE_NAN)
>>>
>>> similar check keeps reoccuring in various places so maybe we can
>>> create a helper function for it.
>>
>> Right, but not sure that it deserves a function.
>
>> If similar new iftypes are anticipated it would make sense as it would mean adding it in one place.
>
> I don't think there is something in common to those interface types that can fit such a function semantically, so I decided not to change it.
> Do you have any idea?
What is common is that these are both non-netdev interface types.
>> Regards,
>> Arend
>
> ---------------------------------------------------------------------
> A member of the Intel Corporation group of companies
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
Maybe better to avoid such disclaimers when you are posting on community
mailing lists.
Regards,
Arend
^ 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