* Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets
From: IgorMitsyanko @ 2016-09-20 19:05 UTC (permalink / raw)
To: Kalle Valo
Cc: johannes, linux-wireless, Avinash Patil, Dmitrii Lebed,
Sergei Maksimenko, Sergey Matyukevich, Bindu Therthala,
Huizhao Wang, Kamlesh Rath
In-Reply-To: <87a8f68wae.fsf@kamboji.qca.qualcomm.com>
On 09/17/2016 04:56 PM, Kalle Valo wrote:
> <igor.mitsyanko.os@quantenna.com> writes:
>
>> From: Avinash Patil <avinashp@quantenna.com>
>>
>> This patch adds support for new FullMAC WiFi driver for Quantenna
>> QSR10G chipsets.
>>
>> QSR10G is Quantenna's 8x8, 160M, 11ac offering.
>> QSR10G supports 2 simultaneous WMACs- one 5G and one 2G. 5G WMAC
>> supports 160M, 8x8 configuration.
>> FW supports 8 concurrent virtual interfaces on each WMAC.
>>
>> Patch introduces 2 new drivers- qtnfmac.ko for interfacing with
>> kernel/cfg80211 and qtnfmac_pcie.ko for PCIe bus interface.
>>
>> Signed-off-by: Dmitrii Lebed <dlebed@quantenna.com>
>> Signed-off-by: Sergei Maksimenko <smaksimenko@quantenna.com>
>> Signed-off-by: Sergey Matyukevich <smatyukevich@quantenna.com>
>> Signed-off-by: Bindu Therthala <btherthala@quantenna.com>
>> Signed-off-by: Huizhao Wang <hwang@quantenna.com>
>> Signed-off-by: Kamlesh Rath <krath@quantenna.com>
>> Signed-off-by: Avinash Patil <avinashp@quantenna.com>
>> Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
> More comments:
>
>> +/* FW names */
>> +
>> +#define QTN_PCI_FW_NAME "pearl-linux.lzma.img"
> The firmware name gives no indication what this file is about (remember
> that linux-firmware.git has a lot of files). Please name it properly,
> don't just use what is used in by firmware build scripts :) Take into
> account also future hw support, all firmware files need to coexist in
> the same repository without user invention. In a way the firmware
> filename is part of kernel/userspace interface and needs to be stable.
>
> For example, you could use something like "qtnfmac/qsr10g.img" (assuming
> qsr10g is the name of chip).
Ok, we will reconsider our naming conventions, take into account more
devices that we need to support in the future.
I'm thinking about something like:
qtn/fmac_qsr10g.img <---- FullMAC QSR10G device
qtn/fmac_qsr1000.img <---- FullMAC QSR1000 device
qtn/smac_qsr10g.img <---- SoftMAC QSR10G
qtn/smac_qsr10000.img <----- SoftMAC QSR1000
etc
>
> I forgot already, is the firmware image ready for submission to
> linux-firmware.git?
Yes, we have firmware binary license prepared by our legal department
and its ready for submitting. Will send in parallel with next patch
revision (only to linux-wireless for now, not to linux-firmware, as was
discussed).
>
>> + pr_info("%s: %sregistered mgmt frame type 0x%x\n", __func__,
>> + reg ? "" : "un", frame_type);
> The driver seems to be quite spammy with info messages:
>
> qtnfmac/cfg80211.c: pr_info("%s: %sregistered mgmt frame type 0x%x\n", __func__,
> qtnfmac/cfg80211.c: pr_info("QTNF: %s cipher=%x, idx=%u, pairwise=%u\n", __func__,
> qtnfmac/cfg80211.c: pr_info("QTNF: %s idx=%u, pairwise=%u\n", __func__, key_index,
> qtnfmac/cfg80211.c: pr_info("QTNF: %s idx=%u, unicast=%u, multicast=%u\n", __func__,
> qtnfmac/cfg80211.c: pr_info("QTNF: %s idx=%u\n", __func__, key_index);
> qtnfmac/cfg80211.c: pr_info("%s: initiator=%d, alpha=%c%c, macid=%d\n", __func__,
> qtnfmac/cfg80211.c: pr_info("%s: MAX_IF: %zu; MODES: %.4X; RADAR WIDTHS: %.2X\n", __func__,
> qtnfmac/cfg80211.c: pr_info("macid=%d, phymode=%#x\n", mac->macid, mac->macinfo.phymode);
> qtnfmac/commands.c: pr_info("%s: unexpected TLV type: %.4X\n",
> qtnfmac/commands.c: pr_info("%s: STA %pM not found\n", __func__, sta_mac);
> qtnfmac/commands.c: pr_info("country-code from EP: %c%c\n", hwinfo->country_code[0],
> qtnfmac/commands.c: pr_info("fw_version = %d, num_mac=%d, mac_bitmap=%#x\n",
> qtnfmac/commands.c: pr_info("iface limit record count=%zu\n", record_count);
> qtnfmac/commands.c: pr_info("MAC%d reported channels %d\n",
> qtnfmac/init.c: pr_info("%s: macid=%d\n", __func__, macid);
> qtnfmac/pcie.c: pr_info("enabled PCIE MSI interrupt\n");
> qtnfmac/pcie.c: pr_info("%s: BAR[%u] vaddr=0x%p busaddr=0x%p len=%u\n",
> qtnfmac/pcie.c: pr_info("%s: set mps to %d (was %d, max %d)\n",
> qtnfmac/pcie.c: pr_info("fw download started: fw start addr = 0x%p, size=%d\n",
> qtnfmac/pcie.c: pr_info("fw download completed: totally sent %d blocks\n", blk);
> qtnfmac/pcie.c: pr_info("RC is ready to boot EP...\n");
> qtnfmac/pcie.c: pr_info("starting download firmware %s...\n", bus->fwname);
> qtnfmac/pcie.c: pr_info("successful init of PCI device %x\n", pdev->device);
> qtnfmac/pcie.c: pr_info("Register Quantenna FullMAC PCIE driver\n");
> qtnfmac/pcie.c: pr_info("Unregister Quantenna FullMAC PCIE driver\n");
> qtnfmac/trans.c: pr_info("%s: interrupted\n", __func__);
> qtnfmac/trans.c: pr_info("%s: skb dropped\n", __func__);
>
> Usualle the preference is that driver is quiet until something goes
> wrong. I hope some of these could be debug messages.
We will reduce noise generated by driver.
>
>> --- /dev/null
>> +++ b/drivers/net/wireless/quantenna/qtnfmac/pcie.c
>> @@ -0,0 +1,1374 @@
>> +/**
>> + * Copyright (c) 2015-2016 Quantenna Communications, Inc.
>> + * All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version 2
>> + * of the License, or (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + **/
>> +
>> +#undef DEBUG
> Why?
Good question) Will remove.
>
^ permalink raw reply
* Re: RTL8192EU on rtl8xxxu driver breaks every few minutes
From: Jes Sorensen @ 2016-09-20 20:12 UTC (permalink / raw)
To: Franc[e]sco; +Cc: linux-wireless
In-Reply-To: <c6784dde-65df-87cd-f97e-33fbd8dd55ff@waifu.club>
"Franc[e]sco" <lolisamurai@waifu.club> writes:
> 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.
Please provide details about the AP you are trying to connect to and iw
link output.
Jes
^ permalink raw reply
* Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets
From: IgorMitsyanko @ 2016-09-20 18:51 UTC (permalink / raw)
To: Kalle Valo
Cc: johannes, linux-wireless, Avinash Patil, Dmitrii Lebed,
Sergei Maksimenko, Sergey Matyukevich, Bindu Therthala,
Huizhao Wang, Kamlesh Rath
In-Reply-To: <87eg4i8wqi.fsf@kamboji.qca.qualcomm.com>
On 09/17/2016 04:46 PM, Kalle Valo wrote:
> <igor.mitsyanko.os@quantenna.com> writes:
>
>> From: Avinash Patil <avinashp@quantenna.com>
>>
>> This patch adds support for new FullMAC WiFi driver for Quantenna
>> QSR10G chipsets.
>>
>> QSR10G is Quantenna's 8x8, 160M, 11ac offering.
>> QSR10G supports 2 simultaneous WMACs- one 5G and one 2G. 5G WMAC
>> supports 160M, 8x8 configuration.
>> FW supports 8 concurrent virtual interfaces on each WMAC.
>>
>> Patch introduces 2 new drivers- qtnfmac.ko for interfacing with
>> kernel/cfg80211 and qtnfmac_pcie.ko for PCIe bus interface.
>>
>> Signed-off-by: Dmitrii Lebed <dlebed@quantenna.com>
>> Signed-off-by: Sergei Maksimenko <smaksimenko@quantenna.com>
>> Signed-off-by: Sergey Matyukevich <smatyukevich@quantenna.com>
>> Signed-off-by: Bindu Therthala <btherthala@quantenna.com>
>> Signed-off-by: Huizhao Wang <hwang@quantenna.com>
>> Signed-off-by: Kamlesh Rath <krath@quantenna.com>
>> Signed-off-by: Avinash Patil <avinashp@quantenna.com>
>> Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
> I read this through and looking good. Below are some comments.
>
> I also saw few warnings but I suspect they are because of cfg80211 API
> changes (didn't bother to check that now):
>
> drivers/net/wireless/quantenna/qtnfmac/event.c: In function `qtnf_event_handle_scan_complete':
> drivers/net/wireless/quantenna/qtnfmac/event.c:342:2: warning: passing argument 2 of `cfg80211_scan_done' makes pointer from integer without a cast [enabled by default]
> ./include/net/cfg80211.h:4104:6: note: expected `struct cfg80211_scan_info *' but argument is of type `u32'
> drivers/net/wireless/quantenna/qtnfmac/cfg80211.c: In function `qtnf_virtual_intf_cleanup':
> drivers/net/wireless/quantenna/qtnfmac/cfg80211.c:1093:4: warning: passing argument 2 of `cfg80211_scan_done' makes pointer from integer without a cast [enabled by default]
> ./include/net/cfg80211.h:4104:6: note: expected `struct cfg80211_scan_info *' but argument is of type `int'
We will rebase before resubmitting, and address other issues that
builbot has reported.
>
>> Resend to correct email kvalo@codeaurora.org.
> BTW, no need to send me directly. I take patches directly from patchwork
> so sending them to linux-wireless is enough. Doesn't do any harm to send
> them to, I just immediately delete them from my INBOX :)
Noted)
>
>> Changelist V1->V2:
>> 1. Get rid of confidentiality footer.
>> 2. Rewrite qlink.h header to make it easier to use, add
>> documentation to most of qlink.h definitions.
>>
>> MAINTAINERS | 8 +
>> drivers/net/wireless/Kconfig | 1 +
>> drivers/net/wireless/Makefile | 1 +
>> drivers/net/wireless/quantenna/Kconfig | 16 +
>> drivers/net/wireless/quantenna/Makefile | 6 +
>> drivers/net/wireless/quantenna/include/bus.h | 195 ++
>> .../wireless/quantenna/include/pcie_regs_pearl.h | 353 ++++
>> drivers/net/wireless/quantenna/include/qlink.h | 939 ++++++++++
>> .../net/wireless/quantenna/include/qtn_hw_ids.h | 34 +
>> .../net/wireless/quantenna/include/shm_ipc_defs.h | 46 +
> Is there a particular reason why you have a separate include directory?
> There's just one quantenna driver for now so the extra include directory
> feels unnecessary. I would prefer to have that only once there are two
> quantenna drivers and we know exactly what is shared between the two.
No particular reason, just prepared for any potential future additions,
like different transport for example (USB, SDIO) or new driver.
Will drop separate include directory for the initial patch.
>
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -9151,6 +9151,14 @@ L: qemu-devel@nongnu.org
>> S: Maintained
>> F: drivers/firmware/qemu_fw_cfg.c
>>
>> +QUANTENNA QTNFMAC WIRELESS DRIVER
>> +M: Igor Mitsyanko <imitsyanko@quantenna.com>
>> +M: Avinash Patil <avinashp@quantenna.com>
>> +M: Sergey Matyukevich <smatyukevich@quantenna.com>
>> +L: linux-wireless@vger.kernel.org
>> +S: Maintained
>> +F: drivers/net/wireless/quantenna/qtnfmac
> The include directory is not listed.
>
>> +ccflags-y += -D__CHECK_ENDIAN
> Very good.
>
>> +/* Supported rates to be advertised to the cfg80211 */
>> +static struct ieee80211_rate qtnf_rates[] = {
>> + {.bitrate = 10, .hw_value = 2, },
>> + {.bitrate = 20, .hw_value = 4, },
>> + {.bitrate = 55, .hw_value = 11, },
>> + {.bitrate = 110, .hw_value = 22, },
>> + {.bitrate = 60, .hw_value = 12, },
>> + {.bitrate = 90, .hw_value = 18, },
>> + {.bitrate = 120, .hw_value = 24, },
>> + {.bitrate = 180, .hw_value = 36, },
>> + {.bitrate = 240, .hw_value = 48, },
>> + {.bitrate = 360, .hw_value = 72, },
>> + {.bitrate = 480, .hw_value = 96, },
>> + {.bitrate = 540, .hw_value = 108, },
>> +};
>> +
>> +/* Channel definitions to be advertised to cfg80211 */
>> +static struct ieee80211_channel qtnf_channels_2ghz[] = {
>> + {.center_freq = 2412, .hw_value = 1, },
>> + {.center_freq = 2417, .hw_value = 2, },
>> + {.center_freq = 2422, .hw_value = 3, },
>> + {.center_freq = 2427, .hw_value = 4, },
>> + {.center_freq = 2432, .hw_value = 5, },
>> + {.center_freq = 2437, .hw_value = 6, },
>> + {.center_freq = 2442, .hw_value = 7, },
>> + {.center_freq = 2447, .hw_value = 8, },
>> + {.center_freq = 2452, .hw_value = 9, },
>> + {.center_freq = 2457, .hw_value = 10, },
>> + {.center_freq = 2462, .hw_value = 11, },
>> + {.center_freq = 2467, .hw_value = 12, },
>> + {.center_freq = 2472, .hw_value = 13, },
>> + {.center_freq = 2484, .hw_value = 14, },
>> +};
> I guess some of these static variables could be also const, but didn't
> check.
We did some changes to this code recently: will get bands info (channel
list, rates, capabilities etc) from wireless device itself, it will be
in next patch revision.
>
>> +MODULE_AUTHOR("Quantenna Communications");
>> +MODULE_DESCRIPTION("Quantenna 802.11 wireless LAN FullMAC driver.");
>> +MODULE_LICENSE("Dual BSD/GPL");
> [...]
>
>> +++ b/drivers/net/wireless/quantenna/qtnfmac/core.h
>> @@ -0,0 +1,170 @@
>> +/**
>> + * Copyright (c) 2015-2016 Quantenna Communications, Inc.
>> + * All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version 2
>> + * of the License, or (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + **/
> MODULE_LICENSE() doesn't match license in headers, is that correct?
That's an overlook, should be simple GPL, thanks for noticing.
>
>> +static int
>> +qtnf_event_handle_sta_assoc(struct qtnf_wmac *mac, struct qtnf_vif *vif,
>> + const struct qlink_event_sta_assoc *sta_assoc,
>> + u16 len)
>> +{
>> + const u8 *sta_addr;
>> + u16 frame_control;
>> + struct station_info sinfo = { 0 };
>> + size_t payload_len;
>> + u16 tlv_type;
>> + u16 tlv_value_len;
>> + size_t tlv_full_len;
>> + const struct qlink_tlv_hdr *tlv;
>> +
>> + if (unlikely(len < sizeof(*sta_assoc))) {
>> + pr_err("%s: payload is too short (%u < %zu)\n", __func__,
>> + len, sizeof(*sta_assoc));
>> + return -EINVAL;
>> + }
> I see unlikely() used a lot, I counted 145 times. Not a big issue but I
> don't see the point. In hot path I understand using it, but not
> everywhere.
Agree, but would you suggest that we remove the ones that we already
have but that are not really needed?
>
>> +/* sysfs knobs: stats and other diagnistics */
> Johannes also commented about this. Please use debugfs or some generic
> interface.
OK
>
^ permalink raw reply
* Re: nl80211 fine timing measurement support
From: Lior David @ 2016-09-20 20:57 UTC (permalink / raw)
To: Luca Coelho, Arend Van Spriel, Johannes Berg
Cc: Maya Erez, Jouni Malinen, linux-wireless
In-Reply-To: <1474353599.5664.125.camel@coelho.fi>
On 9/20/2016 9:39 AM, Luca Coelho wrote:
> 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.
>
That's great to hear, thanks :-)
I reviewed your FTM nl80211 API and have some comments. I can send these
comments once you send the cleaned up patch (most are small issues), but there
is one issue I would like to raise in advance:
In the measurement response you report the final calculated RTT (is this
for each burst or calculated from all bursts?). Our implementation
reports the raw measurement results (t1, t2, t3, t4 for each measurement
as well as TOD and TOA errors at responder and initiator as defined in IEEE
P802.11-REVmc/D7.0, 9.6.8.33). Reporting the final RTT does have benefits, so I
checked with our location framework developers. The general consensus is they
prefer to get the raw results, mainly because there are some useful analysis
algorithms they can run, and in addition the firmware may not be strong enough
to perform the calculations for deriving the final RTT (it could be done in the
driver but I don't think this is a proper place for it). Maybe we should
provide option for reporting both raw and RTT results where drivers can
support either or both?
For reference, we have also implemented FTM internally using vendor
commands. The vendor commands API that we defined can be seen at [1],
the actual implementation is still under internal review so not yet
published.
Thanks,
Lior
[1] http://w1.fi/cgit/hostap/commit/?id=fcd85d9a3f2d9d63d0fa57e93446ad467db75b23
> --
> Cheers,
> Luca.
>
^ permalink raw reply
* [PATCH RFC] brcmfmac: stop netif queue when waiting for packets transmission
From: Rafał Miłecki @ 2016-09-20 22:00 UTC (permalink / raw)
To: Hante Meuleman, Arend van Spriel, brcm80211-dev-list
Cc: linux-wireless, Rafał Miłecki, Arend van Spriel,
Franky Lin, Hante Meuleman, Kalle Valo, Pieter-Paul Giesberts,
Franky (Zhenhui) Lin,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
open list:NETWORKING DRIVERS, open list
From: Rafał Miłecki <rafal@milecki.pl>
Sending a new key to the firmware should be done without any 802.1x
packets pending. Currently brcmfmac has very trivial code waiting for
that condition and it doesn't seem to be enough.
We should stop netif from sending any extra packets in order to:
1) Make sure new 802.1x packets won't be coming over and over
2) Avoid a race with netif providing a new packet right after our
waiting code
Another solution would be to accept only non-802.1x packets. This would
require enqueuing all packets and hacking brcmf_fws_dequeue_worker to
dequeue only non-802.1x ones but that would most likely result in too
hacky code.
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 201a980..1791060 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -471,11 +471,14 @@ send_key_to_dongle(struct brcmf_if *ifp, struct brcmf_wsec_key *key)
convert_key_from_CPU(key, &key_le);
+ netif_stop_queue(ifp->ndev);
brcmf_netdev_wait_pend8021x(ifp);
err = brcmf_fil_bsscfg_data_set(ifp, "wsec_key", &key_le,
sizeof(key_le));
+ netif_start_queue(ifp->ndev);
+
if (err)
brcmf_err("wsec_key error (%d)\n", err);
return err;
--
2.9.3
^ permalink raw reply related
* [PATCH 3/4] rtl8xxxu: Use a struct rtl8xxxu_fileops * in rtl8xxxu_init_device()
From: Jes.Sorensen @ 2016-09-21 1:19 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Larry.Finger, Jes Sorensen
In-Reply-To: <1474420769-20086-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
This saves some 217, or about, derefences of priv->fops.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 37 +++++++++++-----------
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index c628b90..71145eb 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -3886,6 +3886,7 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
{
struct rtl8xxxu_priv *priv = hw->priv;
struct device *dev = &priv->udev->dev;
+ struct rtl8xxxu_fileops *fops = priv->fops;
bool macpower;
int ret;
u8 val8;
@@ -3904,7 +3905,7 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
else
macpower = true;
- ret = priv->fops->power_on(priv);
+ ret = fops->power_on(priv);
if (ret < 0) {
dev_warn(dev, "%s: Failed power on\n", __func__);
goto exit;
@@ -3921,7 +3922,7 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
/*
* Set RX page boundary
*/
- rtl8xxxu_write16(priv, REG_TRXFF_BNDY + 2, priv->fops->trxff_boundary);
+ rtl8xxxu_write16(priv, REG_TRXFF_BNDY + 2, fops->trxff_boundary);
ret = rtl8xxxu_download_firmware(priv);
dev_dbg(dev, "%s: download_firmware %i\n", __func__, ret);
@@ -3932,8 +3933,8 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
if (ret)
goto exit;
- if (priv->fops->phy_init_antenna_selection)
- priv->fops->phy_init_antenna_selection(priv);
+ if (fops->phy_init_antenna_selection)
+ fops->phy_init_antenna_selection(priv);
ret = rtl8xxxu_init_mac(priv);
@@ -3946,7 +3947,7 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
if (ret)
goto exit;
- ret = priv->fops->init_phy_rf(priv);
+ ret = fops->init_phy_rf(priv);
if (ret)
goto exit;
@@ -3971,7 +3972,7 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
/*
* Set TX buffer boundary
*/
- val8 = priv->fops->total_page_num + 1;
+ val8 = fops->total_page_num + 1;
rtl8xxxu_write8(priv, REG_TXPKTBUF_BCNQ_BDNY, val8);
rtl8xxxu_write8(priv, REG_TXPKTBUF_MGQ_BDNY, val8);
@@ -3984,14 +3985,14 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
* The vendor drivers set PBP for all devices, except 8192e.
* There is no explanation for this in any of the sources.
*/
- val8 = (priv->fops->pbp_rx << PBP_PAGE_SIZE_RX_SHIFT) |
- (priv->fops->pbp_tx << PBP_PAGE_SIZE_TX_SHIFT);
+ val8 = (fops->pbp_rx << PBP_PAGE_SIZE_RX_SHIFT) |
+ (fops->pbp_tx << PBP_PAGE_SIZE_TX_SHIFT);
if (priv->rtl_chip != RTL8192E)
rtl8xxxu_write8(priv, REG_PBP, val8);
dev_dbg(dev, "%s: macpower %i\n", __func__, macpower);
if (!macpower) {
- ret = priv->fops->llt_init(priv);
+ ret = fops->llt_init(priv);
if (ret) {
dev_warn(dev, "%s: LLT table init failed\n", __func__);
goto exit;
@@ -4000,12 +4001,12 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
/*
* Chip specific quirks
*/
- priv->fops->usb_quirks(priv);
+ fops->usb_quirks(priv);
/*
* Enable TX report and TX report timer for 8723bu/8188eu/...
*/
- if (priv->fops->has_tx_report) {
+ if (fops->has_tx_report) {
val8 = rtl8xxxu_read8(priv, REG_TX_REPORT_CTRL);
val8 |= TX_REPORT_CTRL_TIMER_ENABLE;
rtl8xxxu_write8(priv, REG_TX_REPORT_CTRL, val8);
@@ -4140,8 +4141,8 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
rtl8xxxu_write8(priv, REG_RSV_CTRL, val8);
}
- if (priv->fops->init_aggregation)
- priv->fops->init_aggregation(priv);
+ if (fops->init_aggregation)
+ fops->init_aggregation(priv);
/*
* Enable CCK and OFDM block
@@ -4158,7 +4159,7 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
/*
* Start out with default power levels for channel 6, 20MHz
*/
- priv->fops->set_tx_power(priv, 1, false);
+ fops->set_tx_power(priv, 1, false);
/* Let the 8051 take control of antenna setting */
if (priv->rtl_chip != RTL8192E) {
@@ -4174,8 +4175,8 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
rtl8xxxu_write16(priv, REG_FAST_EDCA_CTRL, 0);
- if (priv->fops->init_statistics)
- priv->fops->init_statistics(priv);
+ if (fops->init_statistics)
+ fops->init_statistics(priv);
if (priv->rtl_chip == RTL8192E) {
/*
@@ -4193,12 +4194,12 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
rtl8723a_phy_lc_calibrate(priv);
- priv->fops->phy_iq_calibrate(priv);
+ fops->phy_iq_calibrate(priv);
/*
* This should enable thermal meter
*/
- if (priv->fops->gen2_thermal_meter)
+ if (fops->gen2_thermal_meter)
rtl8xxxu_write_rfreg(priv,
RF_A, RF6052_REG_T_METER_8723B, 0x37cf8);
else
--
2.7.4
^ permalink raw reply related
* [PATCH 1/4] rtl8xxxu: Fix off by one error calculating pubq
From: Jes.Sorensen @ 2016-09-21 1:19 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Larry.Finger, Jes Sorensen
In-Reply-To: <1474420769-20086-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
This was detected tracing the 8188eu driver, but doesn't seem to make
any difference when using it.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index ca92022..98fcd7b 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -3869,7 +3869,7 @@ static void rtl8xxxu_init_queue_reserved_page(struct rtl8xxxu_priv *priv)
val32 = (nq << RQPN_NPQ_SHIFT) | (eq << RQPN_EPQ_SHIFT);
rtl8xxxu_write32(priv, REG_RQPN_NPQ, val32);
- pubq = fops->total_page_num - hq - lq - nq;
+ pubq = fops->total_page_num - hq - lq - nq - 1;
val32 = RQPN_LOAD;
val32 |= (hq << RQPN_HI_PQ_SHIFT);
--
2.7.4
^ permalink raw reply related
* [PATCH 2/4] rtl8xxxu: Clean up llt_init() API
From: Jes.Sorensen @ 2016-09-21 1:19 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Larry.Finger, Jes Sorensen
In-Reply-To: <1474420769-20086-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
Remove last_tx_page argument from the llt_init() function. The
rtl8xxxu_fileops structure contains the correct TX_TOTAL_PAGE_NUM
value for the device, and rtl8xxxu_auto_llt_table() doesn't need to
know the value in the first place.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 6 +++---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 9 ++++++---
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 1f54b89..a10a57c 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1318,7 +1318,7 @@ struct rtl8xxxu_fileops {
int (*power_on) (struct rtl8xxxu_priv *priv);
void (*power_off) (struct rtl8xxxu_priv *priv);
void (*reset_8051) (struct rtl8xxxu_priv *priv);
- int (*llt_init) (struct rtl8xxxu_priv *priv, u8 last_tx_page);
+ int (*llt_init) (struct rtl8xxxu_priv *priv);
void (*init_phy_bb) (struct rtl8xxxu_priv *priv);
int (*init_phy_rf) (struct rtl8xxxu_priv *priv);
void (*phy_init_antenna_selection) (struct rtl8xxxu_priv *priv);
@@ -1400,14 +1400,14 @@ int rtl8xxxu_load_firmware(struct rtl8xxxu_priv *priv, char *fw_name);
void rtl8xxxu_firmware_self_reset(struct rtl8xxxu_priv *priv);
void rtl8xxxu_power_off(struct rtl8xxxu_priv *priv);
void rtl8xxxu_reset_8051(struct rtl8xxxu_priv *priv);
-int rtl8xxxu_auto_llt_table(struct rtl8xxxu_priv *priv, u8 last_tx_page);
+int rtl8xxxu_auto_llt_table(struct rtl8xxxu_priv *priv);
void rtl8xxxu_gen2_prepare_calibrate(struct rtl8xxxu_priv *priv, u8 start);
int rtl8xxxu_flush_fifo(struct rtl8xxxu_priv *priv);
int rtl8xxxu_gen2_h2c_cmd(struct rtl8xxxu_priv *priv,
struct h2c_cmd *h2c, int len);
int rtl8xxxu_active_to_lps(struct rtl8xxxu_priv *priv);
void rtl8xxxu_disabled_to_emu(struct rtl8xxxu_priv *priv);
-int rtl8xxxu_init_llt_table(struct rtl8xxxu_priv *priv, u8 last_tx_page);
+int rtl8xxxu_init_llt_table(struct rtl8xxxu_priv *priv);
void rtl8xxxu_gen1_phy_iq_calibrate(struct rtl8xxxu_priv *priv);
void rtl8xxxu_gen1_init_phy_bb(struct rtl8xxxu_priv *priv);
void rtl8xxxu_gen1_set_tx_power(struct rtl8xxxu_priv *priv,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 98fcd7b..c628b90 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -2472,10 +2472,13 @@ static int rtl8xxxu_llt_write(struct rtl8xxxu_priv *priv, u8 address, u8 data)
return ret;
}
-int rtl8xxxu_init_llt_table(struct rtl8xxxu_priv *priv, u8 last_tx_page)
+int rtl8xxxu_init_llt_table(struct rtl8xxxu_priv *priv)
{
int ret;
int i;
+ u8 last_tx_page;
+
+ last_tx_page = priv->fops->total_page_num;
for (i = 0; i < last_tx_page; i++) {
ret = rtl8xxxu_llt_write(priv, i, i + 1);
@@ -2503,7 +2506,7 @@ exit:
return ret;
}
-int rtl8xxxu_auto_llt_table(struct rtl8xxxu_priv *priv, u8 last_tx_page)
+int rtl8xxxu_auto_llt_table(struct rtl8xxxu_priv *priv)
{
u32 val32;
int ret = 0;
@@ -3988,7 +3991,7 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
dev_dbg(dev, "%s: macpower %i\n", __func__, macpower);
if (!macpower) {
- ret = priv->fops->llt_init(priv, TX_TOTAL_PAGE_NUM);
+ ret = priv->fops->llt_init(priv);
if (ret) {
dev_warn(dev, "%s: LLT table init failed\n", __func__);
goto exit;
--
2.7.4
^ permalink raw reply related
* [PATCH 4/4] rtl8xxxu: Stop log spam from each successful interrupt
From: Jes.Sorensen @ 2016-09-21 1:19 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Larry.Finger, Jes Sorensen
In-Reply-To: <1474420769-20086-1-git-send-email-Jes.Sorensen@redhat.com>
From: Larry Finger <Larry.Finger@lwfinger.net>
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>
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
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 a10a57c..10166289 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 71145eb..b2d7f6e 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -5375,7 +5375,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.7.4
^ permalink raw reply related
* [PATCH 0/4] rtl8xxxu - four patches for 4.9
From: Jes.Sorensen @ 2016-09-21 1:19 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Larry.Finger, Jes Sorensen
From: Jes Sorensen <Jes.Sorensen@redhat.com>
Hi,
This is a small set of patches, all but one are preparatory for the
8188eu support I am working on. The last is Larry's patch to reduce
debug messages.
It would be great to get in for 4.9.
Cheers,
Jes
Jes Sorensen (3):
rtl8xxxu: Fix off by one error calculating pubq
rtl8xxxu: Clean up llt_init() API
rtl8xxxu: Use a struct rtl8xxxu_fileops * in rtl8xxxu_init_device()
Larry Finger (1):
rtl8xxxu: Stop log spam from each successful interrupt
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 7 ++--
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 49 ++++++++++++----------
2 files changed, 31 insertions(+), 25 deletions(-)
--
2.7.4
^ permalink raw reply
* ath9k_htc kernel driver regression affecting throughput
From: bruce m beach @ 2016-09-21 3:43 UTC (permalink / raw)
To: linux-wireless; +Cc: linux
Oleksij
I looked at
https://unix.stackexchange.com/questions/122050/
send-traffic-to-self-over-physical-network-on-ubuntu
It appearred to too complicated but
https://unix.stackexchange.com/questions/122050/
send-traffic-to-self-over-physical-network-on-ubuntu
with:
# Create a network namespace and move one of interfaces into it:
ip netns add test2
ip link set wlan0 netns test2
# Start a shell in the new namespace:
ip netns exec test2 bash
# Then proceed as if you had two machines. When finished exit the shell and
# delete the namespace:
ip netns del test2
Certainly looks interesting but after I got a
RTNETLINK answers: Invalid argument
I lost interest. My heart isn't in it. I'm still working on the firmware. I
have started a new tree (tree #3) that consists of a userland firmware uploader
and until recently the following firmware:
app_start( void ) {}
i.e a lable that the code jumps to and nothing else. At this point I have
added VendorCommand(), and a debugger via ep0. ( ep0 is a good choice
since it is available a boot, no matter what) and over the next few
months I am going to move ->all<- the rom code into ram starting with
the USB subsystem.
Bruce
^ permalink raw reply
* Re: ath9k_htc kernel driver regression affecting throughput
From: Oleksij Rempel @ 2016-09-21 4:30 UTC (permalink / raw)
To: bruce m beach, linux-wireless
In-Reply-To: <CAArymCks5NN=09EdJ4uaoRrHZciYAkYTES+i62BkfZ4R-W30HQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1588 bytes --]
Am 21.09.2016 um 05:43 schrieb bruce m beach:
> Oleksij
>
> I looked at
> https://unix.stackexchange.com/questions/122050/
> send-traffic-to-self-over-physical-network-on-ubuntu
>
> It appearred to too complicated but
>
> https://unix.stackexchange.com/questions/122050/
> send-traffic-to-self-over-physical-network-on-ubuntu
> with:
> # Create a network namespace and move one of interfaces into it:
> ip netns add test2
> ip link set wlan0 netns test2
> # Start a shell in the new namespace:
> ip netns exec test2 bash
> # Then proceed as if you had two machines. When finished exit the shell and
> # delete the namespace:
> ip netns del test2
> Certainly looks interesting but after I got a
> RTNETLINK answers: Invalid argument
> I lost interest. My heart isn't in it. I'm still working on the firmware. I
> have started a new tree (tree #3) that consists of a userland firmware uploader
> and until recently the following firmware:
>
> app_start( void ) {}
>
> i.e a lable that the code jumps to and nothing else. At this point I have
> added VendorCommand(), and a debugger via ep0. ( ep0 is a good choice
> since it is available a boot, no matter what) and over the next few
> months I am going to move ->all<- the rom code into ram starting with
> the USB subsystem.
>
> Bruce
>
Wow, this sounds interesting :)
We recently updated FW to GCC 6.2 which can detect more problems. So it
will be probably interesting for you to pick this patch out.
--
Regards,
Oleksij
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
^ permalink raw reply
* [PATCH] rsi: fix memory lean in module unload
From: Prameela Rani Garnepudi @ 2016-09-21 5:59 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, johannes.berg, hofrat, xypron.glpk, prameela.j04cs
Moved debugfs entry removal under CONFIG_RSI_DEBUGFS flag
Added freeing of below structures
* channels list in each supported band
* rsi debugfs info
Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
---
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
index dbb2389..f4bbf15 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;
+ enum nl80211_band band;
if (hw) {
ieee80211_stop_queues(hw);
@@ -201,7 +202,17 @@ void rsi_mac80211_detach(struct rsi_hw *adapter)
ieee80211_free_hw(hw);
}
+ for (band = 0; band < 2; band++) {
+ struct ieee80211_supported_band *sband =
+ &adapter->sbands[band];
+
+ kfree(sband->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
* [PATCH] brcmfmac: fix memory leak in brcmf_fill_bss_param
From: Rafał Miłecki @ 2016-09-21 6:23 UTC (permalink / raw)
To: Kalle Valo
Cc: Rafał Miłecki, Arend van Spriel, Franky Lin,
Hante Meuleman, Pieter-Paul Giesberts, Franky (Zhenhui) Lin,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
open list:NETWORKING DRIVERS, open list
From: Rafał Miłecki <rafal@milecki.pl>
This function is called from get_station callback which means that every
time user space was getting/dumping station(s) we were leaking 2 KiB.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Fixes: 1f0dc59a6de ("brcmfmac: rework .get_station() callback")
Cc: stable@vger.kernel.org # 4.2+
---
Kalle, ideally this should go as 4.8 fix, but I'm aware it's quite late.
If you are not planning to send another pull request, just get it for
the next release and let's let stable guys backport it.
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index b8aec5e5..62a7675 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -2533,7 +2533,7 @@ static void brcmf_fill_bss_param(struct brcmf_if *ifp, struct station_info *si)
WL_BSS_INFO_MAX);
if (err) {
brcmf_err("Failed to get bss info (%d)\n", err);
- return;
+ goto out_kfree;
}
si->filled |= BIT(NL80211_STA_INFO_BSS_PARAM);
si->bss_param.beacon_interval = le16_to_cpu(buf->bss_le.beacon_period);
@@ -2545,6 +2545,9 @@ static void brcmf_fill_bss_param(struct brcmf_if *ifp, struct station_info *si)
si->bss_param.flags |= BSS_PARAM_FLAGS_SHORT_PREAMBLE;
if (capability & WLAN_CAPABILITY_SHORT_SLOT_TIME)
si->bss_param.flags |= BSS_PARAM_FLAGS_SHORT_SLOT_TIME;
+
+out_kfree:
+ kfree(buf);
}
static s32
--
2.9.3
^ permalink raw reply related
* Re: Problem with 40Mhz on 2.5GHz with Intel 8260
From: Emmanuel Grumbach @ 2016-09-21 6:54 UTC (permalink / raw)
To: Volker Mische; +Cc: linux-wireless
In-Reply-To: <79ad55e3-d7f7-0605-3499-a6b289dfb4f6@gmail.com>
> Hi,
>
> On 09/20/2016 08:22 AM, Volker Mische wrote:
>> 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.
>
>>> 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.
>
> I've set the iwlmvm power_scheme to 1 (and allowed the 40Mhz
> connection). First I thought it's good, but after a while the queue
> still got stuck. Especially after waking up from a suspend (not sure if
> that matters).
Ok - good to know.
>
> What are the next steps?
can you try to unplug the power cord? I had reports that said that
this can help. Again, just a debug step to give us a hint of what you
can be experiencing.
Besides this, we need to go for firmware debugging. But as I said,
don't expect this to be fast and easy. Please open a bug in
bugzilla.kernel.org. CC linuxwifi@intel.com and we will guide you
there on how to provide the information we need.
^ permalink raw reply
* Re: Problem with 40Mhz on 2.5GHz with Intel 8260
From: Volker Mische @ 2016-09-21 7:01 UTC (permalink / raw)
To: Emmanuel Grumbach; +Cc: linux-wireless
In-Reply-To: <CANUX_P1n3aVC=95q1=dJFU=7WYof=adm=P1anyhG0nnr9vKGKA@mail.gmail.com>
Hi,
On 09/21/2016 08:54 AM, Emmanuel Grumbach wrote:
>> On 09/20/2016 08:22 AM, Volker Mische wrote:
>>> 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.
>>
>>>> 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.
>>
>> I've set the iwlmvm power_scheme to 1 (and allowed the 40Mhz
>> connection). First I thought it's good, but after a while the queue
>> still got stuck. Especially after waking up from a suspend (not sure if
>> that matters).
>
> Ok - good to know.
>
>>
>> What are the next steps?
>
> can you try to unplug the power cord? I had reports that said that
> this can help. Again, just a debug step to give us a hint of what you
> can be experiencing.
Unplug without any module parameters or combined with the
cfg80211_disable_40mhz_24ghz or power_scheme one?
> Besides this, we need to go for firmware debugging. But as I said,
> don't expect this to be fast and easy. Please open a bug in
> bugzilla.kernel.org. CC linuxwifi@intel.com and we will guide you
> there on how to provide the information we need.
OK, will do once I did try with unplugging. I've seen previous reports
on the issue. As I'm already running a Kernel compiled from source I
hope that at least I can move fast :)
Cheers,
Volker
^ permalink raw reply
* Re: Problem with 40Mhz on 2.5GHz with Intel 8260
From: Emmanuel Grumbach @ 2016-09-21 7:20 UTC (permalink / raw)
To: Volker Mische; +Cc: linux-wireless
In-Reply-To: <d0faec3a-b915-f4f6-5cd4-a4cff7f1dd7b@gmail.com>
>>>
>>> I've set the iwlmvm power_scheme to 1 (and allowed the 40Mhz
>>> connection). First I thought it's good, but after a while the queue
>>> still got stuck. Especially after waking up from a suspend (not sure if
>>> that matters).
>>
>> Ok - good to know.
>>
>>>
>>> What are the next steps?
>>
>> can you try to unplug the power cord? I had reports that said that
>> this can help. Again, just a debug step to give us a hint of what you
>> can be experiencing.
>
> Unplug without any module parameters or combined with the
> cfg80211_disable_40mhz_24ghz or power_scheme one?
Nope - default configuration.
>
>
>> Besides this, we need to go for firmware debugging. But as I said,
>> don't expect this to be fast and easy. Please open a bug in
>> bugzilla.kernel.org. CC linuxwifi@intel.com and we will guide you
>> there on how to provide the information we need.
>
> OK, will do once I did try with unplugging. I've seen previous reports
> on the issue. As I'm already running a Kernel compiled from source I
> hope that at least I can move fast :)
Oh - the firmware debugging doesn't involve any source modification.
>
> Cheers,
> Volker
>
^ permalink raw reply
* Re: [PATCH v2 2/9] mac80211: add boilerplate code for start / stop NAN
From: Arend Van Spriel @ 2016-09-21 8:00 UTC (permalink / raw)
To: Luca Coelho, Beker, Ayala, Otcheretianski, Andrei,
johannes@sipsolutions.net
Cc: linux-wireless@vger.kernel.org, Grumbach, Emmanuel
In-Reply-To: <1474382205.5664.196.camel@coelho.fi>
On 20-9-2016 16:36, Luca Coelho wrote:
> Hi Arend,
>
> On Tue, 2016-09-20 at 14:29 +0200, Arend Van Spriel wrote:
>> On 20-9-2016 13:45, Beker, Ayala wrote:
>>> 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.
>
> I tend to agree with you. I also thought about an
> ieee80211_has_netdev() function for this, but I didn't check whether
> this was exactly what we need...
Maybe it does not fit all instances, but quite a few checks are there to
skip netdev related stuff.
> In any case, do you mind if we address this in a separate patch?
Fine by me.
Regards,
Arend
> --
> Cheers,
> Luca.
>
^ permalink raw reply
* wifi test automation?
From: Oleksij Rempel @ 2016-09-21 8:41 UTC (permalink / raw)
To: linux-wireless
Hallo all,
What kind of WiFi testomation are you using?
Right now i found some links, do some of this used by WiFi devs?
http://avocado-framework.github.io/
https://autotest.github.io/
https://github.com/Wi-FiTestSuite
https://wireless.wiki.kernel.org/en/developers/testing/wifi-test
^ permalink raw reply
* [PATCH] rsi: fix memory leak in module unload
From: Prameela Rani Garnepudi @ 2016-09-21 8:39 UTC (permalink / raw)
To: linux-wireless
Cc: kvalo, johannes.berg, hofrat, xypron.glpk, prameela.garnepudi,
Prameela Rani Garnepudi
debugfs entry removal statement moved inside CONFIG_RSI_DEBUGSFS flag
added freeing of below structures
* channel list for each supported band
* rsi debugfs info
Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
---
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
index dbb2389..f4bbf15 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;
+ enum nl80211_band band;
if (hw) {
ieee80211_stop_queues(hw);
@@ -201,7 +202,17 @@ void rsi_mac80211_detach(struct rsi_hw *adapter)
ieee80211_free_hw(hw);
}
+ for (band = 0; band < 2; band++) {
+ struct ieee80211_supported_band *sband =
+ &adapter->sbands[band];
+
+ kfree(sband->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 v3 0/9] Add support for Neighbor Awareness Networking
From: Arend Van Spriel @ 2016-09-21 9:40 UTC (permalink / raw)
To: Luca Coelho, johannes
Cc: linux-wireless, ayala.beker, andrei.otcheretianski, Luca Coelho
In-Reply-To: <20160920143121.28247-1-luca@coelho.fi>
On 20-9-2016 16:31, Luca Coelho wrote:
> From: Luca Coelho <luciano.coelho@intel.com>
>
> Hi,
>
> Now v3 of the NAN patchset. Ayala has taken care of the kbuild bot
> compilation errors and of all Arend's comments, except for the one
> about adding a helper function instead checking for P2P_DEVICE and NAN
> for non-netdev interfaces.
>
> Comments are welcome, as always.
This series exports three functions to be used by drivers:
void cfg80211_free_nan_func(struct cfg80211_nan_func *f);
void cfg80211_nan_match(struct wireless_dev *wdev,
struct cfg80211_nan_match_params *match, gfp_t gfp);
void cfg80211_nan_func_terminated(struct wireless_dev *wdev,
u8 inst_id,
enum nl80211_nan_func_term_reason reason,
u64 cookie, gfp_t gfp);
Some more descriptive text about the use of these functions would be
appropriate I think. For example looking at the patch series it seems
the responsibility to call cfg80211_free_nan_func() is in the driver
although allocation is done by cfg80211. Actually, I do not see mac80211
calling it so are we leaking there? I would expect it being called in
.del_nan_func() callback and/or .stop_nan(). Rather than exporting
cfg80211_free_nan_func() I would prefer calling
cfg80211_nan_func_terminated() and have cfg80211 take care of freeing
nan_func resources.
Regards,
Arend
> Cheers,
> Luca.
>
>
> Ayala Beker (9):
> cfg80211: add start / stop NAN commands
> mac80211: add boilerplate code for start / stop NAN
> cfg80211: add add_nan_func / del_nan_func
> cfg80211: allow the user space to change current NAN configuration
> cfg80211: provide a function to report a match for NAN
> cfg80211: Provide an API to report NAN function termination
> mac80211: implement nan_change_conf
> mac80211: Implement add_nan_func and rm_nan_func
> mac80211: Add API to report NAN function match
>
> include/net/cfg80211.h | 184 ++++++++++++-
> include/net/mac80211.h | 65 +++++
> include/uapi/linux/nl80211.h | 253 +++++++++++++++++
> net/mac80211/cfg.c | 208 ++++++++++++++
> net/mac80211/chan.c | 6 +
> net/mac80211/driver-ops.h | 80 ++++++
> net/mac80211/ieee80211_i.h | 17 ++
> net/mac80211/iface.c | 28 +-
> net/mac80211/main.c | 8 +
> net/mac80211/offchannel.c | 4 +-
> net/mac80211/rx.c | 3 +
> net/mac80211/trace.h | 133 +++++++++
> net/mac80211/util.c | 50 +++-
> net/wireless/chan.c | 2 +
> net/wireless/core.c | 35 +++
> net/wireless/core.h | 3 +
> net/wireless/mlme.c | 1 +
> net/wireless/nl80211.c | 642 ++++++++++++++++++++++++++++++++++++++++++-
> net/wireless/rdev-ops.h | 58 ++++
> net/wireless/trace.h | 90 ++++++
> net/wireless/util.c | 28 +-
> 21 files changed, 1888 insertions(+), 10 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 2/4] carl9170: fix debugfs crashes
From: Greg KH @ 2016-09-21 10:13 UTC (permalink / raw)
To: Christian Lamparter
Cc: Kalle Valo, Christian Lamparter, linux-kernel, linux-wireless,
b43-dev, Nicolai Stange, Ben Greear, Larry Finger
In-Reply-To: <ccf228acb7af8ee3bbd82f72f28ebc068f37cb8e.1474140477.git.chunkeey@gmail.com>
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")
>
> Thankfully, the original/real fops are still available in d_fsdata.
>
> Reported-by: Ben Greear <greearb@candelatech.com>
> Reviewed-by: Nicolai Stange <nicstange@gmail.com>
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> Acked-by: Kalle Valo <kvalo@codeaurora.org>
> Cc: stable <stable@vger.kernel.org> # 4.7+
> ---
> drivers/net/wireless/ath/carl9170/debug.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/carl9170/debug.c b/drivers/net/wireless/ath/carl9170/debug.c
> index 01a0919..ad7ffd5 100644
> --- a/drivers/net/wireless/ath/carl9170/debug.c
> +++ b/drivers/net/wireless/ath/carl9170/debug.c
> @@ -75,7 +75,7 @@ static ssize_t carl9170_debugfs_read(struct file *file, char __user *userbuf,
>
> if (!ar)
> return -ENODEV;
> - dfops = container_of(file->f_path.dentry->d_fsdata,
> + dfops = container_of(debugfs_real_fops(file),
> struct carl9170_debugfs_fops, fops);
>
> if (!dfops->read)
> @@ -128,7 +128,7 @@ static ssize_t carl9170_debugfs_write(struct file *file,
>
> if (!ar)
> return -ENODEV;
> - dfops = container_of(file->f_path.dentry->d_fsdata,
> + dfops = container_of(debugfs_real_fops(file),
> struct carl9170_debugfs_fops, fops);
> if (!dfops->write)
> return -ENOSYS;
What tree is this against? I can't apply it to 4.8-rc5, or 4.8-rc7, are
you sure it is still needed?
thanks,
greg k-h
^ permalink raw reply
* [PATCH] ath10k: fix copy engine 5 destination ring stuck
From: Rajkumar Manoharan @ 2016-09-21 10:58 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, rmanohar, Rajkumar Manoharan, stable
Firmware is running watchdog timer for tracking copy engine ring index
and write index. Whenever both indices are stuck at same location for
given duration, watchdog will be trigger to assert target. While
updating copy engine destination ring write index, driver ensures that
write index will not be same as read index by finding delta between these
two indices (CE_RING_DELTA).
HTT target to host copy engine (CE5) is special case where ring buffers
will be reused and delta check is not applied while updating write index.
In rare scenario, whenever CE5 ring is full, both indices will be referring
same location and this is causing CE ring stuck issue as explained
above. This issue is originally reported on IPQ4019 during long hour stress
testing and during veriwave max clients testsuites. The same issue is
also observed in other chips as well. Fix this by ensuring that write
index is one less than read index which means that full ring is
available for receiving data.
Cc: stable@vger.kernel.org
Tested-by: Tamizh chelvam <c_traja@qti.qualcomm.com>
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/ce.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c
index 65d8d714e917..00d3f93058db 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -433,6 +433,13 @@ void ath10k_ce_rx_update_write_idx(struct ath10k_ce_pipe *pipe, u32 nentries)
unsigned int nentries_mask = dest_ring->nentries_mask;
unsigned int write_index = dest_ring->write_index;
u32 ctrl_addr = pipe->ctrl_addr;
+ u32 cur_write_idx = ath10k_ce_dest_ring_write_index_get(ar, ctrl_addr);
+
+ /* Prevent CE ring stuck issue that will occur when ring is full.
+ * Make sure that write index is 1 less than read index.
+ */
+ if ((cur_write_idx + nentries) == dest_ring->sw_index)
+ nentries -= 1;
write_index = CE_RING_IDX_ADD(nentries_mask, write_index, nentries);
ath10k_ce_dest_ring_write_index_set(ar, ctrl_addr, write_index);
--
2.10.0
^ permalink raw reply related
* RE: [PATCH v3 0/9] Add support for Neighbor Awareness Networking
From: Otcheretianski, Andrei @ 2016-09-21 11:36 UTC (permalink / raw)
To: Arend Van Spriel, Luca Coelho, johannes@sipsolutions.net
Cc: linux-wireless@vger.kernel.org, Beker, Ayala, Coelho, Luciano
In-Reply-To: <1fea85b0-02f0-964d-ca3d-99453f6de421@broadcom.com>
> -----Original Message-----
> From: Arend Van Spriel [mailto:arend.vanspriel@broadcom.com]
> Sent: Wednesday, September 21, 2016 12:40
> 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>; Coelho, Luciano
> <luciano.coelho@intel.com>
> Subject: Re: [PATCH v3 0/9] Add support for Neighbor Awareness
> Networking
>
>
>
> On 20-9-2016 16:31, Luca Coelho wrote:
> > From: Luca Coelho <luciano.coelho@intel.com>
> >
> > Hi,
> >
> > Now v3 of the NAN patchset. Ayala has taken care of the kbuild bot
> > compilation errors and of all Arend's comments, except for the one
> > about adding a helper function instead checking for P2P_DEVICE and NAN
> > for non-netdev interfaces.
> >
> > Comments are welcome, as always.
>
> This series exports three functions to be used by drivers:
>
> void cfg80211_free_nan_func(struct cfg80211_nan_func *f); void
> cfg80211_nan_match(struct wireless_dev *wdev,
> struct cfg80211_nan_match_params *match, gfp_t
> gfp); void cfg80211_nan_func_terminated(struct wireless_dev *wdev,
> u8 inst_id,
> enum nl80211_nan_func_term_reason
> reason,
> u64 cookie, gfp_t gfp);
>
> Some more descriptive text about the use of these functions would be
> appropriate I think. For example looking at the patch series it seems the
> responsibility to call cfg80211_free_nan_func() is in the driver although
> allocation is done by cfg80211.
Regarding the cfg80211_free_nan_func() it is documented in patch "[PATCH v3 3/9] cfg80211: add add_nan_func / del_nan_func"
Here:
* @add_nan_func: Add a NAN function. Returns negative value on failure.
* On success @nan_func ownership is transferred to the driver and
* it may access it outside of the scope of this function. The driver
* should free the @nan_func when no longer needed by calling
* cfg80211_free_nan_func().
* On success the driver should assign an instance_id in the
* provided @nan_func.
All the others are pretty much straight forward. Match and termination events are defined in NAN spec - so it should be easy to know when to call these functions.
> Actually, I do not see mac80211 calling it so are
> we leaking there? I would expect it being called in
> .del_nan_func() callback and/or .stop_nan().
It is. Look at "[PATCH v3 8/9] mac80211: Implement add_nan_func and rm_nan_func".
It is called in stop_nan() and nan_func_terminated() callback.
The nan function can't be freed directly in del_nan_func() - otherwise it would be racy with match/termination notifications.
> Rather than exporting
> cfg80211_free_nan_func() I would prefer calling
> cfg80211_nan_func_terminated() and have cfg80211 take care of freeing
> nan_func resources.
As I already answered, there are some situations when the wdev isn't available and mac80211 can't call cfg80211_nan_func_terminated() - for example nan interface is being stopped (at least it's true for mac80211).
Also I think that the driver should be able to free the nan function without being forced to send notification to the user space and the other way around.
>
> Regards,
> Arend
>
> > Cheers,
> > Luca.
> >
> >
> > Ayala Beker (9):
> > cfg80211: add start / stop NAN commands
> > mac80211: add boilerplate code for start / stop NAN
> > cfg80211: add add_nan_func / del_nan_func
> > cfg80211: allow the user space to change current NAN configuration
> > cfg80211: provide a function to report a match for NAN
> > cfg80211: Provide an API to report NAN function termination
> > mac80211: implement nan_change_conf
> > mac80211: Implement add_nan_func and rm_nan_func
> > mac80211: Add API to report NAN function match
> >
> > include/net/cfg80211.h | 184 ++++++++++++-
> > include/net/mac80211.h | 65 +++++
> > include/uapi/linux/nl80211.h | 253 +++++++++++++++++
> > net/mac80211/cfg.c | 208 ++++++++++++++
> > net/mac80211/chan.c | 6 +
> > net/mac80211/driver-ops.h | 80 ++++++
> > net/mac80211/ieee80211_i.h | 17 ++
> > net/mac80211/iface.c | 28 +-
> > net/mac80211/main.c | 8 +
> > net/mac80211/offchannel.c | 4 +-
> > net/mac80211/rx.c | 3 +
> > net/mac80211/trace.h | 133 +++++++++
> > net/mac80211/util.c | 50 +++-
> > net/wireless/chan.c | 2 +
> > net/wireless/core.c | 35 +++
> > net/wireless/core.h | 3 +
> > net/wireless/mlme.c | 1 +
> > net/wireless/nl80211.c | 642
> ++++++++++++++++++++++++++++++++++++++++++-
> > net/wireless/rdev-ops.h | 58 ++++
> > net/wireless/trace.h | 90 ++++++
> > net/wireless/util.c | 28 +-
> > 21 files changed, 1888 insertions(+), 10 deletions(-)
> >
^ permalink raw reply
* Re: TCP data throughput for BCM43362
From: Arend van Spriel @ 2016-09-21 14:15 UTC (permalink / raw)
To: Jörg Krause, Franky Lin
Cc: Brett Rudley, brcm80211-dev-list, Hante Meuleman, Franky Lin,
linux-wireless, Arend van Spriel
In-Reply-To: <1474266984.7448.1.camel@embedded.rocks>
On 19-09-16 08:36, Jörg Krause wrote:
> Hi Arend,
>
> On Wed, 2016-09-14 at 20:13 +0200, Arend Van Spriel wrote:
>> On 14-9-2016 15:41, Jörg Krause wrote:
>>>
>>> Hi,
>>>
>>> On Mon, 2016-08-29 at 23:15 +0200, Jörg Krause wrote:
>>>>
>>>> On Mi, 2016-08-24 at 20:35 +0200, Arend Van Spriel wrote:
>>>>>
>>>>>
>>>>> On 22-8-2016 15:37, Jörg Krause wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I am back from vacation and I'd like to do more
>>>>>> investigations
>>>>>> about
>>>>>> this issue. Please see my comments below...
>>>>>>
>>>>>> On Sun, 2016-08-07 at 13:41 +0200, Arend van Spriel wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 06-08-16 16:12, Jörg Krause wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>
>>>>>>> A bit weird email format making it a bit hard to determine
>>>>>>> where
>>>>>>> your
>>>>>>> last reply starts...
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fr, 2016-08-05 at 17:56 -0700, Franky Lin wrote:
>>>>>>>>
>>>>>>>> On Fri, Aug 5, 2016 at 2:29 PM, Jörg Krause <joerg.krause
>>>>>>>> @emb
>>>>>>>> ed
>>>>>>>> ded.
>>>>>>>> ro
>>>>>>>> cks>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 5. August 2016 23:01:10 MESZ, schrieb Arend Van Spriel
>>>>>>>> <
>>>>>>>> arend.vanspriel@broadcom.com>:
>>>>>>>>
>>>>>>>>
>>>>>>>> Op 5 aug. 2016 22:46 schreef "Jörg Krause"
>>>>>>>> <joerg.krause@embedded.rocks>:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm using a custom ARM board with an BCM43362 wifi chip
>>>>>>>> from
>>>>>>>>
>>>>>>>> Broadcom.
>>>>>>>>
>>>>>>>>
>>>>>>>> The wifi chip is attached via SDIO to the controller with
>>>>>>>> a
>>>>>>>> clock of
>>>>>>>> 48MHz. Linux kernel version is 4.7.
>>>>>>>>
>>>>>>>> When measuring the network bandwidth with iperf3 I get a
>>>>>>>> bandwith of
>>>>>>>> only around 5 Mbps. I found a similar thread at the
>>>>>>>> Broadcom
>>>>>>>>
>>>>>>>> community
>>>>>>>>
>>>>>>>>
>>>>>>>> [1] where the test was done with a M4 CPU + BCM43362 and
>>>>>>>> an
>>>>>>>> average
>>>>>>>> result of 3.3 Mbps.
>>>>>>>>
>>>>>>>> Interestingly, a BCM43362 Wi-Fi Dev Kit [2] notes a TCP
>>>>>>>> data
>>>>>>>>
>>>>>>>> throughput
>>>>>>>>
>>>>>>>>
>>>>>>>> greater than 20 Mbps.
>>>>>>>>
>>>>>>>> Why is the throughput I measured much lower? Note that I
>>>>>>>> measured
>>>>>>>> several times with almost no neighbor devices or
>>>>>>>> networks.
>>>>>>>>
>>>>>>>> This is a test sample measured with iperf3:
>>>>>>>>
>>>>>>>> $ iperf3 -c 192.168.2.1 -i 1 -t 10
>>>>>>>> Connecting to host 192.168.2.1, port 5201
>>>>>>>> [ 4] local 192.168.2.155 port 36442 connected to
>>>>>>>> 192.168.2.1
>>>>>>>>
>>>>>>>> port
>>>>>>>>
>>>>>>>>
>>>>>>>> 5201
>>>>>>>> [ ID]
>>>>>>>> Interval Transfer Bandwidth Retr Cwn
>>>>>>>> d
>>>>>>>> [ 4] 0.00-1.00 sec 615 KBytes 5.04
>>>>>>>> Mbits/sec 0 56.6
>>>>>>>> KBytes
>>>>>>>> [ 4] 1.00-2.00 sec 622 KBytes 5.10
>>>>>>>> Mbits/sec 0 84.8
>>>>>>>> KBytes
>>>>>>>> [ 4] 2.00-3.00 sec 625 KBytes 5.12
>>>>>>>> Mbits/sec 0 113
>>>>>>>> KBytes
>>>>>>>> [ 4] 3.00-4.00 sec 571 KBytes 4.68
>>>>>>>> Mbits/sec 0 140
>>>>>>>> KBytes
>>>>>>>> [ 4] 4.00-5.00 sec 594 KBytes 4.87
>>>>>>>> Mbits/sec 0 167
>>>>>>>> KBytes
>>>>>>>> [ 4] 5.00-6.00 sec 628 KBytes 5.14
>>>>>>>> Mbits/sec 0 195
>>>>>>>> KBytes
>>>>>>>> [ 4] 6.00-7.00 sec 619 KBytes 5.07
>>>>>>>> Mbits/sec 0 202
>>>>>>>> KBytes
>>>>>>>> [ 4] 7.00-8.00 sec 608 KBytes 4.98
>>>>>>>> Mbits/sec 0 202
>>>>>>>> KBytes
>>>>>>>> [ 4] 8.00-9.00 sec 602 KBytes 4.93
>>>>>>>> Mbits/sec 0 202
>>>>>>>> KBytes
>>>>>>>> [ 4] 9.00-10.00 sec 537 KBytes 4.40
>>>>>>>> Mbits/sec 0 202
>>>>>>>> KBytes
>>>>>>>> - - - - - - - - - - - - - - - - - - - - - - - - -
>>>>>>>> [ ID]
>>>>>>>> Interval Transfer Bandwidth Retr
>>>>>>>> [ 4] 0.00-10.00 sec 5.88 MBytes 4.93
>>>>>>>> Mbits/sec 0 sender
>>>>>>>> [ 4] 0.00-10.00 sec 5.68 MBytes 4.76
>>>>>>>> Mbits/sec receiver
>>>>>>>>
>>>>>>>>
>>>>>>>> Not overly familiar with iperf3. Do these lines mean you
>>>>>>>> are
>>>>>>>> doing
>>>>>>>> bidirectional test, ie. upstream and downstream at the
>>>>>>>> same
>>>>>>>> time.
>>>>>>>> Another
>>>>>>>> thing affecting tput could be power-save.
>>>>>>>>
>>>>>>>>
>>>>>>>> No, iperf3 does not support bidrectional test. Power-save
>>>>>>>> is
>>>>>>>> turned
>>>>>>>> off.
>>>>>>>>
>>>>>>>> What does iw link say?
>>>>>>>>
>>>>>>>
>>>>>>> but I guess it starts here!
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I compared the results with a Cubietruck I have:
>>>>>>>>
>>>>>>>> # iperf3 -s
>>>>>>>> -------------------------------------------------------
>>>>>>>> ----
>>>>>>>> Server listening on 5201
>>>>>>>> -------------------------------------------------------
>>>>>>>> ----
>>>>>>>> Accepted connection from 192.168.178.46, port 42906
>>>>>>>> [ 5] local 192.168.178.38 port 5201 connected to
>>>>>>>> 192.168.178.46
>>>>>>>> port
>>>>>>>> 42908
>>>>>>>> [ ID] Interval Transfer Bandwidth
>>>>>>>> [ 5] 0.00-1.00 sec 2.29 MBytes 19.2
>>>>>>>> Mbits/sec
>>>>>>>> [ 5] 1.00-2.00 sec 2.21 MBytes 18.5
>>>>>>>> Mbits/sec
>>>>>>>> [ 5] 2.00-3.00 sec 2.17 MBytes 18.2
>>>>>>>> Mbits/sec
>>>>>>>> [ 5] 3.00-4.00 sec 2.09 MBytes 17.6
>>>>>>>> Mbits/sec
>>>>>>>> [ 5] 4.00-5.00 sec 2.20 MBytes 18.5
>>>>>>>> Mbits/sec
>>>>>>>> [ 5] 5.00-6.00 sec 2.64 MBytes 22.1
>>>>>>>> Mbits/sec
>>>>>>>> [ 5] 6.00-7.00 sec 2.67 MBytes 22.4
>>>>>>>> Mbits/sec
>>>>>>>> [ 5] 7.00-8.00 sec 2.62 MBytes 22.0
>>>>>>>> Mbits/sec
>>>>>>>> [ 5] 8.00-9.00 sec 2.35 MBytes 19.8
>>>>>>>> Mbits/sec
>>>>>>>> [ 5] 9.00-10.00 sec 2.30 MBytes 19.3
>>>>>>>> Mbits/sec
>>>>>>>> [ 5] 10.00-10.03 sec 83.4 KBytes 23.5
>>>>>>>> Mbits/sec
>>>>>>>> - - - - - - - - - - - - - - - - - - - - - - - - -
>>>>>>>> [ ID]
>>>>>>>> Interval Transfer Bandwidth Retr
>>>>>>>> [ 5] 0.00-10.03 sec 23.9 MBytes 20.0
>>>>>>>> Mbits/sec 0 sender
>>>>>>>> [ 5] 0.00-10.03 sec 23.6 MBytes 19.8
>>>>>>>> Mbits/sec receiver
>>>>>>>>
>>>>>>>> # iw dev wlan0 link
>>>>>>>> Connected to xx:xx:xx:xx:xx (on wlan0)
>>>>>>>> SSID: xxx
>>>>>>>> freq: 2437
>>>>>>>> tx bitrate: 65.0 MBit/s
>>>>>>>>
>>>>>>>> bss flags: short-preamble short-slot-time
>>>>>>>> dtim period: 1
>>>>>>>> beacon int: 100
>>>>>>>
>>>>>>> Too bad RSSI is not in the output above. That may be due to
>>>>>>> a
>>>>>>> regression
>>>>>>> in our driver which has been fixed by commit 94abd778a7bb
>>>>>>> ("brcmfmac:
>>>>>>> add fallback for devices that do not report per-chain
>>>>>>> values").
>>>>>>> However,
>>>>>>> the tx bitrate seems within the same range as the other
>>>>>>> platform.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The Cubietruck works also with the brcmfmac driver.
>>>>>>>>
>>>>>>>> May it depend on the NVRAM file?
>>>>>>>
>>>>>>> Not sure. Can you tell me a bit more about the custom ARM
>>>>>>> board.
>>>>>>> Does
>>>>>>> it
>>>>>>> use the same wifi module as Cubietruck, ie. the AMPAK
>>>>>>> AP6210?
>>>>>>> If
>>>>>>> you
>>>>>>> can
>>>>>>> make a wireshark sniff we can check the actual bitrate and
>>>>>>> medium
>>>>>>> density in terms of packets. Another thing to look at is
>>>>>>> the
>>>>>>> SDIO
>>>>>>> host
>>>>>>> controller. In brcmf_sdiod_sgtable_alloc() some key values
>>>>>>> are
>>>>>>> used
>>>>>>> from
>>>>>>> the host controller. It only logs the number of entries of
>>>>>>> the
>>>>>>> scatter-gather table, but could you add the other values in
>>>>>>> this
>>>>>>> function that are used to determine the number of entries.
>>>>>>
>>>>>> My board uses the BCM43362 chip solely (no Bluetooth)
>>>>>> attached to
>>>>>> the
>>>>>> SDIO interface of a NXP i.MX28 processor.
>>>>>>
>>>>>> I added some additional printk() to
>>>>>> brcmf_sdiod_sgtable_alloc().
>>>>>> These
>>>>>> are the values printed after modprobe brcmfmac:
>>>>>>
>>>>>> [ 8.926657] sg_support=1
>>>>>> [ 8.929440] max_blocks=511
>>>>>> [ 8.932213] max_request_size=261632
>>>>>> [ 8.935741] max_segment_count=52
>>>>>> [ 8.939005] max_segment_size=65280
>>>>>> [ 8.946095] nents=35
>>>>>
>>>>> Thanks. That looks good.
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Additionally I attached a xz compresses wireshark sniff while
>>>>>> running
>>>>>> iper3 between the BCM43362 running as in AP mode with iperf3
>>>>>> as a
>>>>>> server and a PC in station mode running iperf3 as a client.
>>>>>
>>>>> Looking at the sniff it seems you captured on the ethernet
>>>>> side.
>>>>> That
>>>>> does not give me any 802.11 specific info. Can you make a
>>>>> wireless
>>>>> capture preferably without encryption.
>>>>
>>>> You,re right! Sorry for this mistake. I did a re-capture on the
>>>> wireless side now.
>>>
>>> Anything new about this? Anything I can do to help?
>>
>> I missed your previous email. Was already wondering whether to ping
>> you.
>> Digging around in my email folders I found it so will take a look at
>> it.
>
> Did you had some time to look at this?
Sorry for the delay, but I am kinda swamped. Will try spent some time on
it later this week.
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