Re: [PATCH 4/8] ath10k: make dbglog debug messages be 'warn' level.
gree...@candelatech.com writes: > From: Ben Greear > > This only happens on firmware crash, and it appears this > logic is not always perfect, so make sure the information > is printed to logs at higher level. > > Signed-off-by: Ben Greear > --- > drivers/net/wireless/ath/ath10k/pci.c | 14 ++ > 1 file changed, 6 insertions(+), 8 deletions(-) > > diff --git a/drivers/net/wireless/ath/ath10k/pci.c > b/drivers/net/wireless/ath/ath10k/pci.c > index 0f7e845..dee0d5a 100644 > --- a/drivers/net/wireless/ath/ath10k/pci.c > +++ b/drivers/net/wireless/ath/ath10k/pci.c > @@ -1132,9 +1132,8 @@ static void ath10k_pci_dump_dbglog(struct ath10k *ar) > return; > } > > - ath10k_dbg(ar, ATH10K_DBG_PCI, > -"debug log header, dbuf: 0x%x dropped: %i\n", > -le32_to_cpu(dbg_hdr.dbuf), le32_to_cpu(dbg_hdr.dropped)); > + ath10k_warn(ar, "debug log header, dbuf: 0x%x dropped: %i\n", > + le32_to_cpu(dbg_hdr.dbuf), le32_to_cpu(dbg_hdr.dropped)); > dbufp = le32_to_cpu(dbg_hdr.dbuf); I think a new debug level is more approriate, this is just spamming the logs unnecessary. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cw1200: use msecs_to_jiffies for conversion
This is only an API consolidation to make things more readable.
Instances of HZ / CONST are replaced by appropriate msecs_to_jiffies().
Signed-off-by: Nicholas Mc Guire
---
Converting milliseconds to jiffies by "val * HZ / 1000" or passing
HZ / 10 is technically OK but appropriate msecs_to_jiffies(val), respectively
msecs_to_jiffies(100) is the cleaner solution and handles all corner cases
correctly. This is a minor API cleanup only.
Patch was only compile tested for x86_64_defconfig + CONFIG_CW1200=m
Patch is against 3.19.0-rc7 (localversion-next = -next-20150203)
drivers/net/wireless/cw1200/scan.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/cw1200/scan.c
b/drivers/net/wireless/cw1200/scan.c
index f2e276f..bff81b8 100644
--- a/drivers/net/wireless/cw1200/scan.c
+++ b/drivers/net/wireless/cw1200/scan.c
@@ -39,9 +39,9 @@ static int cw1200_scan_start(struct cw1200_common *priv,
struct wsm_scan *scan)
cancel_delayed_work_sync(&priv->clear_recent_scan_work);
atomic_set(&priv->scan.in_progress, 1);
atomic_set(&priv->recent_scan, 1);
- cw1200_pm_stay_awake(&priv->pm_state, tmo * HZ / 1000);
+ cw1200_pm_stay_awake(&priv->pm_state, msecs_to_jiffies(tmo));
queue_delayed_work(priv->workqueue, &priv->scan.timeout,
- tmo * HZ / 1000);
+ msecs_to_jiffies(tmo));
ret = wsm_scan(priv, scan);
if (ret) {
atomic_set(&priv->scan.in_progress, 0);
@@ -386,8 +386,8 @@ void cw1200_probe_work(struct work_struct *work)
if (down_trylock(&priv->scan.lock)) {
/* Scan is already in progress. Requeue self. */
schedule();
- queue_delayed_work(priv->workqueue,
- &priv->scan.probe_work, HZ / 10);
+ queue_delayed_work(priv->workqueue, &priv->scan.probe_work,
+ msecs_to_jiffies(100));
mutex_unlock(&priv->conf_mutex);
return;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: enable qca6174 hw3.2
Michal Kazior writes: > The 3.2 revision has a different target BMI > version so it wasn't recognized by ath10k (despite > the chip_id rev being on the supported list > already). > > Signed-off-by: Michal Kazior Thanks, applied to ath.git. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-RESEND] ath10k: add log level configuration for fw_dbglog
SenthilKumar Jegadeesan writes: > Introduce optional log level configuration for > existing debugfs fw_dbglog. > > It allow users to configure desired log level > for firmware debugs. > > To configure log level as WARN > > echo 0x 2 > /sys/kernel/debug/ieee80211/phy0/ath10k/fw_dbglog > > Loglevel Value > VERBOSE 0 > INFO 1 > WARN 2 > ERR 3 > > Signed-off-by: SenthilKumar Jegadeesan Thanks, applied to ath.git. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: Use TX cksum offload only for CHECKSUM_PARTIAL
Helmut Schaa writes: > Otherwise ath10k will just checksum everything even if it did not > go through the TCP/IP stack (for example bridged frames). In the worst > case this could mean recreating the checksum for incorrect data. > > Signed-off-by: Helmut Schaa Thanks, applied to ath.git. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] ath10k: change dma beacon cmd prototype
Michal Kazior writes: > The command logic shouldn't really care about > arvif structure. > > Signed-off-by: Michal Kazior Thanks, both patches applied to ath.git. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] mac80211: Allow 0 for NL80211_MESHCONF_PLINK_TIMEOUT to disable STA expiration
Both wpa_supplicant and mac80211 has inactivity timer. By default
wpa_supplicant will be timed out in 5 minutes and mac80211's it is 30 minutes.
If wpa_supplicant uses more long timer than mac80211, wpa_supplicant will get
unexpected disconnection by mac80211. This patch adds functionality of disabling
mac80211 inactivity timer to avoid to prevent wpa_supplicant inactivity timer.
I have thought setting 0x to NL80211_MESHCONF_PLINK_TIMEOUT will solve
this problem without this patch. But the approach does not work on 32 bit
system. To explain the reason, I will show STA expiration rule in kernel. This
is the expression.
(current jiffies) > (frame Rx jiffies + NL80211_MESHCONF_PLINK_TIMEOUT * 250)
On 32bit system, right side could be over flow and be unexpected small value if
NL80211_MESHCONF_PLINK_TIMEOUT is sufficiently large. STA expiration occurs by
this reason. So I made this patch.
Signed-off-by: Masashi Honma
---
net/mac80211/mesh.c| 3 ++-
net/wireless/nl80211.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 0c8b2a7..acf441f 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -574,7 +574,8 @@ static void ieee80211_mesh_housekeeping(struct
ieee80211_sub_if_data *sdata)
struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
u32 changed;
- ieee80211_sta_expire(sdata, ifmsh->mshcfg.plink_timeout * HZ);
+ if (ifmsh->mshcfg.plink_timeout > 0)
+ ieee80211_sta_expire(sdata, ifmsh->mshcfg.plink_timeout * HZ);
mesh_path_expire(sdata);
changed = mesh_accept_plinks_update(sdata);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index e9ad9d9..bef52af 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -5261,7 +5261,7 @@ do {
\
FILL_IN_MESH_PARAM_IF_SET(tb, cfg, dot11MeshAwakeWindowDuration,
0, 65535, mask,
NL80211_MESHCONF_AWAKE_WINDOW, nla_get_u16);
- FILL_IN_MESH_PARAM_IF_SET(tb, cfg, plink_timeout, 1, 0x,
+ FILL_IN_MESH_PARAM_IF_SET(tb, cfg, plink_timeout, 0, 0x,
mask, NL80211_MESHCONF_PLINK_TIMEOUT,
nla_get_u32);
if (mask_out)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
A short Question about driver for RTL8191SU
Hello there, is there any change to get the device in Monitor Mode with this driver? Device: Bus 003 Device 004: ID 0bda:8172 Realtek Semiconductor Corp. RTL8191SU 802.11n WLAN Adapter Provided by CSL: http://www.amazon.de/gp/product/B007K871ES?psc=1&redirect=true&ref_=oh_aui_detailpage_o04_s00 I have tried with default driver of Ubuntu 14.04 and actual Kali Linux (kali-linux-1.0.9a-amd64.iso) Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: Fix potential Rx ring corruption
Just letting you know that this patch seems to have resolved an rx corruption I was seeing when cpu went 100% sirq constantly for several seconds. I have tested now for about an hour and have not been able to reproduce the corruption so it seems very promising. I should note that this is on an ARMv8 processor in case you're interested. Thanks, Pushpal On Fri, Jan 9, 2015 at 5:57 AM, Vasanthakumar Thiagarajan wrote: > When replenishing Rx buffers driver updates the address of the > buffer and the index of rx buffer in rx ring to the firmware. > Change in order by CPU can cause rx ring corruption. Add memory > barrier before updating rx buffer index to guarantee the order. > > This could fix some instances of rx ring corruption due to done > bit in rx attention flag not set. > > Signed-off-by: Vasanthakumar Thiagarajan > --- > drivers/net/wireless/ath/ath10k/htt_rx.c |5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c > b/drivers/net/wireless/ath/ath10k/htt_rx.c > index 9c782a4..baa1c44 100644 > --- a/drivers/net/wireless/ath/ath10k/htt_rx.c > +++ b/drivers/net/wireless/ath/ath10k/htt_rx.c > @@ -97,6 +97,11 @@ static int __ath10k_htt_rx_ring_fill_n(struct ath10k_htt > *htt, int num) > } > > fail: > + /* > +* Make sure the rx buffer is updated before available buffer > +* index to avoid any potential rx ring corruption. > +*/ > + mb(); > *htt->rx_ring.alloc_idx.vaddr = __cpu_to_le32(idx); > return ret; > } > -- > 1.7.9.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
pull request: new firmware for Intel wireless Intel 3160 / 7260 / 7265 / 7265D devices
Hi, This is a pull request for new firmwares for the Intel wireless devices mentioned in the subject. I replace -10.ucode with new ones (that includes bug fixes). I add the brand new -12.ucode. Please pull. The following changes since commit 38e5405c96d10bb42b629b45210c46166461fc21: cxgb4: Update firmware to revision 1.12.25.0 (2014-12-01 15:48:02 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git master for you to fetch changes up to da4e58d47557776c5721bafb3f2b6c4a1a4ff0f3: iwlwifi: add new -12 firmware for 3160 / 7260 / 7265 / 7265D (2015-02-03 23:14:51 +0200) Emmanuel Grumbach (3): iwlwifi: update -10.ucode for 3160 / 7260 / 7265 / 7265D iwlwifi: update -10.ucode for 3160 / 7260 / 7265 / 7265D iwlwifi: add new -12 firmware for 3160 / 7260 / 7265 / 7265D WHENCE | 20 iwlwifi-3160-10.ucode | Bin 610168 -> 610064 bytes iwlwifi-3160-12.ucode | Bin 0 -> 683996 bytes iwlwifi-7260-10.ucode | Bin 672480 -> 672372 bytes iwlwifi-7260-12.ucode | Bin 0 -> 782300 bytes iwlwifi-7265-10.ucode | Bin 736968 -> 736864 bytes iwlwifi-7265-12.ucode | Bin 0 -> 880604 bytes iwlwifi-7265D-10.ucode | Bin 740636 -> 740456 bytes iwlwifi-7265D-12.ucode | Bin 0 -> 1002800 bytes 9 files changed, 16 insertions(+), 4 deletions(-) create mode 100644 iwlwifi-3160-12.ucode create mode 100644 iwlwifi-7260-12.ucode create mode 100644 iwlwifi-7265-12.ucode create mode 100644 iwlwifi-7265D-12.ucode diff --git a/WHENCE b/WHENCE index 44c41c7..1917288 100644 --- a/WHENCE +++ b/WHENCE @@ -816,7 +816,10 @@ File: iwlwifi-7260-9.ucode Version: 25.228.9.0 File: iwlwifi-7260-10.ucode -Version: 23.10.10.0 +Version: 23.12.10.0 + +File: iwlwifi-7260-12.ucode +Version: 25.15.12.0 File: iwlwifi-3160-7.ucode Version: 22.1.7.0 @@ -828,7 +831,10 @@ File: iwlwifi-3160-9.ucode Version: 25.228.9.0 File: iwlwifi-3160-10.ucode -Version: 23.10.10.0 +Version: 23.12.10.0 + +File: iwlwifi-3160-12.ucode +Version: 25.15.12.0 File: iwlwifi-7265-8.ucode Version: 22.24.8.0 @@ -837,10 +843,16 @@ File: iwlwifi-7265-9.ucode Version: 25.228.9.0 File: iwlwifi-7265-10.ucode -Version: 23.10.10.0 +Version: 23.12.10.0 + +File: iwlwifi-7265-12.ucode +Version: 25.15.12.0 File: iwlwifi-7265D-10.ucode -Version: 23.10.10.0 +Version: 23.12.10.0 + +File: iwlwifi-7265D-12.ucode +Version: 25.15.12.0 Licence: Redistributable. See LICENCE.iwlwifi_firmware for details diff --git a/iwlwifi-3160-10.ucode b/iwlwifi-3160-10.ucode index 8cec7bf..5f4173c 100644 Binary files a/iwlwifi-3160-10.ucode and b/iwlwifi-3160-10.ucode differ diff --git a/iwlwifi-3160-12.ucode b/iwlwifi-3160-12.ucode new file mode 100644 index 000..45bce48 Binary files /dev/null and b/iwlwifi-3160-12.ucode differ diff --git a/iwlwifi-7260-10.ucode b/iwlwifi-7260-10.ucode index 9e5b930..dca79e2 100644 Binary files a/iwlwifi-7260-10.ucode and b/iwlwifi-7260-10.ucode differ diff --git a/iwlwifi-7260-12.ucode b/iwlwifi-7260-12.ucode new file mode 100644 index 000..7ec91f0 Binary files /dev/null and b/iwlwifi-7260-12.ucode differ diff --git a/iwlwifi-7265-10.ucode b/iwlwifi-7265-10.ucode index 488ddd0..0571fcf 100644 Binary files a/iwlwifi-7265-10.ucode and b/iwlwifi-7265-10.ucode differ diff --git a/iwlwifi-7265-12.ucode b/iwlwifi-7265-12.ucode new file mode 100644 index 000..84ae2ce Binary files /dev/null and b/iwlwifi-7265-12.ucode differ diff --git a/iwlwifi-7265D-10.ucode b/iwlwifi-7265D-10.ucode index 01194db..d9b9aaf 100644 Binary files a/iwlwifi-7265D-10.ucode and b/iwlwifi-7265D-10.ucode differ diff --git a/iwlwifi-7265D-12.ucode b/iwlwifi-7265D-12.ucode new file mode 100644 index 000..3f36b55 Binary files /dev/null and b/iwlwifi-7265D-12.ucode differ signature.asc Description: This is a digitally signed message part
[ANN] new firmware for Intel 3160 / 7260 / 7265 / 7265D devices - Core9
Hi all, Intel released a new firmware for its WiFi devices listed in the subject. This release includes lots of bug fixes along with new features. The filename is iwlwifi--12.ucode and will be usable on kernel 3.19 and up. We also release release a re-spin of iwlwifi--10.ucode that includes a bug fix that has a major impact on users. Both firmware are available right now in our linux-firmware clone [1]. Note that I haven't yet updated the wiki [2] since I am still having issues with permissions, but that will hopefully be fixed soon. Pull request to the official linux-firmware will follow. Enjoy, and as always, feedback is appreciated! [1] https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/linux-firmware.git/ [2] https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi#firmware signature.asc Description: This is a digitally signed message part
[PATCH] ath5k: fix spontaneus AR5312 freezes
Sometimes while CPU have some load and ath5k doing the wireless
interface reset the whole WiSoC completely freezes. Set of tests shows
that using atomic delay function while we wait interface reset helps to
avoid such freezes.
The easiest way to reproduce this issue: create a station interface,
start continous scan with wpa_supplicant and load CPU by something. Or
just create multiple station interfaces and put them all in continous
scan.
This patch partially reverts the commit 1846ac3dbec0 ("ath5k: Use
usleep_range where possible"), which replaces initial udelay()
by usleep_range().
I do not know actual source of this issue, but all looks like that HW
freeze is caused by transaction on internal SoC bus, while wireless
block is in reset state.
Also I should note that I do not know how many chips are affected, but I
did not see this issue with chips, other than AR5312.
CC: Jiri Slaby
CC: Nick Kossifidis
CC: Luis R. Rodriguez
Fixes: 1846ac3dbec0 ("ath5k: Use usleep_range where possible")
Reported-by: Christophe Prevotaux
Tested-by: Christophe Prevotaux
Tested-by: Eric Bree
Signed-off-by: Sergey Ryazanov
---
I would like to sincerely thank Christophe for provided board and
for his patience and perseverance in solving problems with the
delivery ;)
---
drivers/net/wireless/ath/ath5k/reset.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath5k/reset.c
b/drivers/net/wireless/ath/ath5k/reset.c
index a3399c4..b9b651e 100644
--- a/drivers/net/wireless/ath/ath5k/reset.c
+++ b/drivers/net/wireless/ath/ath5k/reset.c
@@ -478,7 +478,7 @@ ath5k_hw_wisoc_reset(struct ath5k_hw *ah, u32 flags)
regval = ioread32(reg);
iowrite32(regval | val, reg);
regval = ioread32(reg);
- usleep_range(100, 150);
+ udelay(100);/* NB: should be atomic */
/* Bring BB/MAC out of reset */
iowrite32(regval & ~val, reg);
--
2.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND 0/2] Resend critical patches for rtl8192ee
Kalle, These are the two patches that would not apply to wireless-drivers-next. They have been rebased, and are generated against a pull done today. Thanks, Larry --- Larry Finger (1): rtlwifi: rtl8192ee: Fix problems with calculating free space in FIFO Troy Tan (1): rtlwifi: rtl8192ee: Fix handling of new style descriptors drivers/net/wireless/rtlwifi/pci.c | 31 +++-- drivers/net/wireless/rtlwifi/pci.h | 7 + drivers/net/wireless/rtlwifi/rtl8192ee/sw.c | 3 +-- drivers/net/wireless/rtlwifi/rtl8192ee/trx.c | 40 +--- drivers/net/wireless/rtlwifi/rtl8192ee/trx.h | 1 + drivers/net/wireless/rtlwifi/wifi.h | 1 + 6 files changed, 57 insertions(+), 26 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND 2/2] rtlwifi: rtl8192ee: Fix problems with calculating free space in FIFO
This driver utilizes a FIFO buffer for RX descriptors. There are four places
in the code where it calculates the number of free slots. Several of those
locations do the calculation incorrectly. To fix these and to prevent future
mistakes, a common inline routine is created.
Signed-off-by: Larry Finger
Cc: Stable [V3.18]
---
drivers/net/wireless/rtlwifi/pci.h | 7 +++
drivers/net/wireless/rtlwifi/rtl8192ee/trx.c | 9 +
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/pci.h
b/drivers/net/wireless/rtlwifi/pci.h
index 5e83230..d4567d1 100644
--- a/drivers/net/wireless/rtlwifi/pci.h
+++ b/drivers/net/wireless/rtlwifi/pci.h
@@ -325,4 +325,11 @@ static inline void pci_write32_async(struct rtl_priv
*rtlpriv,
writel(val, (u8 __iomem *) rtlpriv->io.pci_mem_start + addr);
}
+static inline u16 calc_fifo_space(u16 rp, u16 wp)
+{
+ if (rp <= wp)
+ return RTL_PCI_MAX_RX_COUNT - 1 + rp - wp;
+ return rp - wp - 1;
+}
+
#endif
diff --git a/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
index 1245e2f..d39ee67 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ee/trx.c
@@ -499,14 +499,7 @@ u16 rtl92ee_rx_desc_buff_remained_cnt(struct ieee80211_hw
*hw, u8 queue_index)
if (!start_rx)
return 0;
- if ((last_read_point > (RX_DESC_NUM_92E / 2)) &&
- (read_point <= (RX_DESC_NUM_92E / 2))) {
- remind_cnt = RX_DESC_NUM_92E - write_point;
- } else {
- remind_cnt = (read_point >= write_point) ?
-(read_point - write_point) :
-(RX_DESC_NUM_92E - write_point + read_point);
- }
+ remind_cnt = calc_fifo_space(read_point, write_point);
if (remind_cnt == 0)
return 0;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND 1/2] rtlwifi: rtl8192ee: Fix handling of new style descriptors
From: Troy Tan
The hardware and firmware for the RTL8192EE utilize a FIFO list of
descriptors. There were some problems with the initial implementation.
The worst of these failed to detect that the FIFO was becoming full,
which led to the device needing to be power cycled. As this condition
is not relevant to most of the devices supported by rtlwifi, a callback
routine was added to detect this situation. This patch implements the
necessary changes in the pci handler, and the linkage into the appropriate
rtl8192ee routine.
Signed-off-by: Troy Tan
Signed-off-by: Larry Finger
Cc: Stable [V3.18]
---
drivers/net/wireless/rtlwifi/pci.c | 31 +---
drivers/net/wireless/rtlwifi/rtl8192ee/sw.c | 3 +--
drivers/net/wireless/rtlwifi/rtl8192ee/trx.c | 20 ++
drivers/net/wireless/rtlwifi/rtl8192ee/trx.h | 1 +
drivers/net/wireless/rtlwifi/wifi.h | 1 +
5 files changed, 46 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/pci.c
b/drivers/net/wireless/rtlwifi/pci.c
index 846a2e6..88331d7 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -578,6 +578,13 @@ static void _rtl_pci_tx_isr(struct ieee80211_hw *hw, int
prio)
else
entry = (u8 *)(&ring->desc[ring->idx]);
+ if (rtlpriv->cfg->ops->get_available_desc &&
+ rtlpriv->cfg->ops->get_available_desc(hw, prio) <= 1) {
+ RT_TRACE(rtlpriv, (COMP_INTR | COMP_SEND), DBG_DMESG,
+"no available desc!\n");
+ return;
+ }
+
if (!rtlpriv->cfg->ops->is_tx_desc_closed(hw, prio, ring->idx))
return;
ring->idx = (ring->idx + 1) % ring->entries;
@@ -641,10 +648,9 @@ static void _rtl_pci_tx_isr(struct ieee80211_hw *hw, int
prio)
ieee80211_tx_status_irqsafe(hw, skb);
- if ((ring->entries - skb_queue_len(&ring->queue))
- == 2) {
+ if ((ring->entries - skb_queue_len(&ring->queue)) <= 4) {
- RT_TRACE(rtlpriv, COMP_ERR, DBG_LOUD,
+ RT_TRACE(rtlpriv, COMP_ERR, DBG_DMESG,
"more desc left, wake skb_queue@%d, ring->idx
= %d, skb_queue_len = 0x%x\n",
prio, ring->idx,
skb_queue_len(&ring->queue));
@@ -786,7 +792,7 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
rx_remained_cnt =
rtlpriv->cfg->ops->rx_desc_buff_remained_cnt(hw,
hw_queue);
- if (rx_remained_cnt < 1)
+ if (rx_remained_cnt == 0)
return;
} else {/* rx descriptor */
@@ -834,18 +840,18 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
else
skb_reserve(skb, stats.rx_drvinfo_size +
stats.rx_bufshift);
-
} else {
RT_TRACE(rtlpriv, COMP_ERR, DBG_WARNING,
"skb->end - skb->tail = %d, len is %d\n",
skb->end - skb->tail, len);
- break;
+ dev_kfree_skb_any(skb);
+ goto new_trx_end;
}
/* handle command packet here */
if (rtlpriv->cfg->ops->rx_command_packet &&
rtlpriv->cfg->ops->rx_command_packet(hw, stats, skb)) {
dev_kfree_skb_any(skb);
- goto end;
+ goto new_trx_end;
}
/*
@@ -895,6 +901,7 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
} else {
dev_kfree_skb_any(skb);
}
+new_trx_end:
if (rtlpriv->use_new_trx_flow) {
rtlpci->rx_ring[hw_queue].next_rx_rp += 1;
rtlpci->rx_ring[hw_queue].next_rx_rp %=
@@ -910,7 +917,6 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
rtlpriv->enter_ps = false;
schedule_work(&rtlpriv->works.lps_change_work);
}
-end:
if (rtlpriv->use_new_trx_flow) {
_rtl_pci_init_one_rxdesc(hw, (u8 *)buffer_desc,
rxring_idx,
@@ -1672,6 +1678,15 @@ static int rtl_pci_tx(struct ieee80211_hw *hw,
}
}
+ if (rtlpriv->cfg->ops->get_available_desc &&
+ rtlpriv->cfg->ops->get_available_desc(hw, hw_queue) == 0) {
+ R
Re: [V2,for,3.19,3/7] rtlwifi: rtl8192ee: Fix adhoc fail
On 02/03/2015 07:23 AM, Kalle Valo wrote:
Kalle Valo writes:
From: Troy Tan
When the buffer descriptor index exceeds 2, then a TX HANG condition
will result.
Signed-off-by: Troy Tan
Signed-off-by: Larry Finger
Cc: Stable [V3.18]
Thanks, 4 patches applied to wireless-drivers-next.git:
b661a5da5776 rtlwifi: rtl8192ee: Fix adhoc fail
6e5f44361628 rtlwifi: rtl8192ee: Fix TX hang due to failure to update TX write
point
92ff754240b8 rtlwifi: rtl8192ee: Fix parsing of received packet
21b39ddb5bb2 rtlwifi: rtl8192ee: Fix DMA stalls
3 patches skipped:
I had to skip these three patches because of my mistake. So what I did
was that I had merged ("fast forwarded") the net tree into my
wireless-drivers tree and not realising I should not do that. So now I
can't merge wireless-drivers into wireless-drivers-next anymore, as it
will pull unnecessary net changes.
[V2,for,3.19,1/7] rtlwifi: Remove logging statement that is no longer
needed
I'll apply this after 3.20-rc1 is released, it should apply then without
problems (or the conflicts are easy for me to fix). Luckily this is just
a cosmetic error and can wait for 3.20-rc2, right?
That is correct. 3.20-rc2 will be OK. I'll probably get a bunch of "your
driver is spamming my logs, but I can ignore them".
[V2,for,3.19,2/7] rtlwifi: rtl8192ee: Fix handling of new style descriptors
[V2,for,3.19,6/7] rtlwifi: rtl8192ee: Fix problems with calculating free space
in FIFO
Not sure what to do with these one. Should you rebase and send them now?
These two fix real bugs and need to be in the kernel ASAP. Unfortunately, I saw
you pass them off to DaveM and I deleted them from my "Submitted Patch" list. I
can recreate them from my working copy of wireless-drivers, and I will resubmit.
When I do, please process them as quickly as possible.
Thanks,
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Throughput regression with `tcp: refine TSO autosizing`
On Tue, 2015-02-03 at 06:27 -0800, Eric Dumazet wrote:
> Are packets TX completed after a timer or something ?
>
> Some very heavy stuff might run from tasklet (or other softirq triggered)
> event.
>
Right, commit 6c5151a9ffa9f796f2d707617cecb6b6b241dff8
("ath10k: batch htt tx/rx completions")
is very suspicious.
Please revert it.
BTW, ath10k_htt_txrx_compl_task() runs from softirq context, so the
_bh() prefixes are not really needed.
It seems lot of batching happens in wifi drivers, not necessarily at the
right places.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath9k_htc: add adaptive usb flow control to repair soft lockup with monitor mode
It seems to work without noticeable regressions.
Am 03.02.2015 um 12:52 schrieb Kalle Valo:
> yuweizh...@139.com writes:
>
>> From: Yuwei Zheng
>>
>> In the environment with heavy wifi traffic, set the ar9271 into monitor
>> mode, will
>> trigger a deadloop panic.
>>
>> The ath9k_hif_usb_rx_cb function excute on the interrupt context, and
>> ath9k_rx_tasklet excute
>> on the soft irq context. In other words, the ath9k_hif_usb_rx_cb have more
>> chance to excute than
>> ath9k_rx_tasklet. So in the worst condition, the rx.rxbuf receive list is
>> always full,
>> and the do {}while(true) loop will not be break. The kernel get a soft
>> lockup panic.
>
> The word wrapping is still wrong, please limit the width to 72 chars or
> so. But no need to wrap log snippets, they can exceed the limit.
>
>> Signed-off-by: Yuwei Zheng
>> Signed-off-by: Yuwei Zheng
>
> Why two of these? Please use just one Signed-off-by line. Unless these
> are two different persons with the same name :)
>
--
Regards,
Oleksij
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] staging: rtl8723au: multiple condition with no effect - if identical to else
On Tue, 03 Feb 2015, Jes Sorensen wrote: > Nicholas Mc Guire writes: > > A number if/else if/else branches are identical - so the condition has no > > effect on the effective code and can be significantly simplified - this > > patch removes the condition and the duplicated code. > > > > Signed-off-by: Nicholas Mc Guire > > --- > > > > This looks like the output of some broken code-generator - unlikely someone > > wrote this by hand. In any case it needs a review by someone that knows the > > details of the driver. > > > > Anyway the number of useless code repetition is potentially record breaking > > ! > > > > Patch was compile tested for x86_64_defconfig + CONFIG_STAGING=y > > CONFIG_R8723AU=m, CONFIG_8723AU_BT_COEXIST=y > > > > Patch is against 3.0.19-rc7 (localversoin = -next-20150203) > > > > .../staging/rtl8723au/hal/rtl8723a_bt-coexist.c| 60 > > +++- > > 1 file changed, 8 insertions(+), 52 deletions(-) > > Why make it simple if you can make it complicated :) > > I presume it's against 3.19-rc7 since a 3.0.19 would be rather obsolete. > yes - thats a typo - sorry for that. > Signed-off-by: Jes Sorensen -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Throughput regression with `tcp: refine TSO autosizing`
On Tue, 2015-02-03 at 12:50 +0100, Michal Kazior wrote:
> On 3 February 2015 at 02:18, Eric Dumazet wrote:
> > On Mon, 2015-02-02 at 10:52 -0800, Eric Dumazet wrote:
> >
> >> It seems to break ACK clocking badly (linux stack has a somewhat buggy
> >> tcp_tso_should_defer(), which relies on ACK being received smoothly, as
> >> no timer is setup to split the TSO packet.)
> >
> > Following patch might help the TSO split defer logic.
> >
> > It would avoid setting the TSO defer 'pseudo timer' twice, if/when TCP
> > Small Queue logic prevented the xmit at the expiration of first 'timer'.
> >
> > This patch clears the tso_deferred variable only if we could really
> > send something.
> >
> > Please try it, thanks !
> [..patch..]
>
> I've done a second round of tests. I've added the A-MSDU count
> parameter I've mentioned in my other email into the mix.
>
> net - net/master (includes stretch ack patches)
> net-tso - net/master + your TSO defer patch
> net-gro - net/master + my ath10k GRO patch
> net-gro-tso - net/master + duh
>
> Here's the best of amsdu count 1 and 3:
>
> ; for (i in */output.txt) { echo $i; for (j in (1 3)) { cat $i | awk
> 'x && /Mbits/ {y=$0}; x && y && !/Mbits/ {print y; x=0; y=""}; /set
> amsdu cnt to '$j'/{x=1}' | awk '{ if (x < $(NF-1)) {x=$(NF-1)} }
> END{print "A-MSDU limit='$j', " x " Mbits/sec"}' } }
> net-gro-tso/output.txt
> A-MSDU limit=1, 436 Mbits/sec
> A-MSDU limit=3, 284 Mbits/sec
> net-gro/output.txt
> A-MSDU limit=1, 444 Mbits/sec
> A-MSDU limit=3, 283 Mbits/sec
> net-tso/output.txt
> A-MSDU limit=1, 376 Mbits/sec
> A-MSDU limit=3, 251 Mbits/sec
> net/output.txt
> A-MSDU limit=1, 387 Mbits/sec
> A-MSDU limit=3, 260 Mbits/sec
>
> IOW:
> - stretch acks / TSO defer don't seem to help much (when compared to
> throughput results from yesterday)
> - GRO helps
> - disabling A-MSDU on sender helps
> - net/master+GRO still doesn't reach the performance from before the
> regression (~600mbps w/ GRO)
>
> You can grab logs and dumps here: http://www.filedropper.com/test2tar
>
Thanks for these traces.
There is absolutely a problem at the sender, as we can see a big 2ms
delay between reception of ACK and send of following packets.
TCP stack should generate them immediately.
Are you using some kind of netem qdisc ?
These 2ms delays, in a flow with a 5ms RTT are terrible.
06:54:57.408391 IP 192.168.1.2.5001 > 192.168.1.3.51645: Flags [.], ack
4294899240, win 11268, options [nop,nop,TS val 1053302 ecr 1052250], length 0
06:54:57.408418 IP 192.168.1.2.5001 > 192.168.1.3.51645: Flags [.], ack
4294910824, win 11268, options [nop,nop,TS val 1053303 ecr 1052251], length 0
06:54:57.408431 IP 192.168.1.2.5001 > 192.168.1.3.51645: Flags [.], ack
4294936888, win 11268, options [nop,nop,TS val 1053303 ecr 1052251], length 0
06:54:57.408453 IP 192.168.1.2.5001 > 192.168.1.3.51645: Flags [.], ack
4294962952, win 11268, options [nop,nop,TS val 1053303 ecr 1052251], length 0
06:54:57.408474 IP 192.168.1.2.5001 > 192.168.1.3.51645: Flags [.], ack 0, win
11268, options [nop,nop,TS val 1053303 ecr 1052251], length 0
06:54:57.410243 IP 192.168.1.3.51645 > 192.168.1.2.5001: Flags [.], seq
82536:83984, ack 1, win 457, options [nop,nop,TS val 1052256 ecr 1053303],
length 1448
06:54:57.410271 IP 192.168.1.3.51645 > 192.168.1.2.5001: Flags [.], seq
83984:85432, ack 1, win 457, options [nop,nop,TS val 1052256 ecr 1053303],
length 1448
06:54:57.410289 IP 192.168.1.3.51645 > 192.168.1.2.5001: Flags [.], seq
85432:86880, ack 1, win 457, options [nop,nop,TS val 1052256 ecr 1053303],
length 1448
06:54:57.410310 IP 192.168.1.3.51645 > 192.168.1.2.5001: Flags [.], seq
86880:88328, ack 1, win 457, options [nop,nop,TS val 1052256 ecr 1053303],
length 1448
06:54:57.410326 IP 192.168.1.3.51645 > 192.168.1.2.5001: Flags [.], seq
88328:89776, ack 1, win 457, options [nop,nop,TS val 1052256 ecr 1053303],
length 1448
06:54:57.410339 IP 192.168.1.3.51645 > 192.168.1.2.5001: Flags [.], seq
89776:91224, ack 1, win 457, options [nop,nop,TS val 1052256 ecr 1053303],
length 1448
06:54:57.410353 IP 192.168.1.3.51645 > 192.168.1.2.5001: Flags [.], seq
91224:92672, ack 1, win 457, options [nop,nop,TS val 1052256 ecr 1053303],
length 1448
06:54:57.410370 IP 192.168.1.3.51645 > 192.168.1.2.5001: Flags [.], seq
92672:94120, ack 1, win 457, options [nop,nop,TS val 1052256 ecr 1053303],
length 1448
...
06:54:57.411178 IP 192.168.1.2.5001 > 192.168.1.3.51645: Flags [.], ack 28960,
win 11268, options [nop,nop,TS val 1053306 ecr 1052253], length 0
06:54:57.411190 IP 192.168.1.2.5001 > 192.168.1.3.51645: Flags [.], ack 52128,
win 11268, options [nop,nop,TS val 1053306 ecr 1052254], length 0
06:54:57.411220 IP 192.168.1.2.5001 > 192.168.1.3.51645: Flags [.], ack 78192,
win 11268, options [nop,nop,TS val 1053306 ecr 1052254], length 0
06:54:57.411243 IP 192.168.1.2.5001 > 192.168.1.3.51645: Flags [.], ack 82536,
win 11268, options [nop,nop,TS val 1053306 ecr 1052254], length 0
< same 2ms unex
pull-request: mac80211-next 2015-02-03
Hi, Here's a last pull request for net-next - I hope it can still make it, we fixed a fairly large number of issues. Also there's a bunch of new ciphers, but see the details below. Let me know if there's any problem. Thanks, johannes The following changes since commit c1e140bf79d817d4a7aa9932eb98b0359c87af33: mac80211: delete the assoc/auth timer upon suspend (2015-01-19 18:59:20 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2015-02-03 for you to fetch changes up to 79044f60caa7c377333dc8f13cf1e48c144e2521: net: rfkill: Add Broadcom BCM2E40 bluetooth ACPI ID (2015-02-03 14:38:22 +0100) Last round of updates for net-next: * revert a patch that caused a regression with mesh userspace (Bob) * fix a number of suspend/resume related races (from Emmanuel, Luca and myself - we'll look at backporting later) * add software implementations for new ciphers (Jouni) * add a new ACPI ID for Broadcom's rfkill (Mika) * allow using netns FD for wireless (Vadim) * some other cleanups (various) Bob Copeland (1): Revert "mac80211: keep sending peer candidate events while in listen state" Emmanuel Grumbach (2): mac80211: synchronize_net() before flushing the queues mac80211: avoid races related to suspend flow Johannes Berg (9): mac80211: fix HW registration error paths mac80211: allow drivers to control software crypto nl80211: suppress smatch warnings mac80211: tdls: remove shadowing variable mac80211: tdls: disentangle HT supported conditions mac80211: fix per-TID RX-MSDU counter mac80211: support beacon statistics ath10k: use IEEE80211_HW_SW_CRYPTO_CONTROL nl80211: don't document per-wiphy interface dump Jouni Malinen (6): cfg80211: Fix BIP (AES-CMAC) cipher validation cfg80211: Add new GCMP, CCMP-256, BIP-GMAC, BIP-CMAC-256 ciphers mac80111: Add GCMP and GCMP-256 ciphers mac80111: Add CCMP-256 cipher mac80111: Add BIP-CMAC-256 cipher mac80111: Add BIP-GMAC-128 and BIP-GMAC-256 ciphers Lorenzo Bianconi (1): mac80211: enable TPC through mac80211 stack Luciano Coelho (3): nl80211: add an attribute to allow delaying the first scheduled scan cycle mac80211: complete scan work immediately if quiesced or suspended mac80211: handle potential race between suspend and scan completion Mika Westerberg (1): net: rfkill: Add Broadcom BCM2E40 bluetooth ACPI ID Sharon Dvir (1): wireless: docs: fix 'make pdfdocs' failure Vadim Kochan (1): nl80211: Allow set network namespace by fd Documentation/DocBook/80211.tmpl | 4 +- drivers/net/wireless/ath/ath10k/mac.c | 16 +- include/linux/ieee80211.h | 27 +++ include/net/cfg80211.h| 5 + include/net/mac80211.h| 39 ++- include/uapi/linux/nl80211.h | 26 +- net/core/net_namespace.c | 1 + net/mac80211/Kconfig | 1 + net/mac80211/Makefile | 2 + net/mac80211/aes_ccm.c| 21 +- net/mac80211/aes_ccm.h| 10 +- net/mac80211/aes_cmac.c | 34 ++- net/mac80211/aes_cmac.h | 5 +- net/mac80211/aes_gcm.c| 95 net/mac80211/aes_gcm.h| 22 ++ net/mac80211/aes_gmac.c | 84 +++ net/mac80211/aes_gmac.h | 20 ++ net/mac80211/cfg.c| 50 +++- net/mac80211/chan.c | 4 +- net/mac80211/debugfs_key.c| 55 + net/mac80211/ieee80211_i.h| 36 ++- net/mac80211/iface.c | 12 +- net/mac80211/key.c| 185 +- net/mac80211/key.h| 18 ++ net/mac80211/main.c | 107 +--- net/mac80211/mesh_plink.c | 7 - net/mac80211/mlme.c | 3 + net/mac80211/rx.c | 48 +++- net/mac80211/scan.c | 5 + net/mac80211/sta_info.c | 14 ++ net/mac80211/tdls.c | 37 ++- net/mac80211/tx.c | 20 +- net/mac80211/util.c | 27 ++- net/mac80211/wpa.c| 443 +- net/mac80211/wpa.h| 19 +- net/rfkill/rfkill-gpio.c | 1 + net/wireless/nl80211.c| 31 ++- net/wireless/util.c | 68 +- 38 files changed, 1426 insertions(+), 176 deletions(-) create mode 100644 net/mac80211/aes_gcm.c create mode 100644 net/mac80211/aes_gcm.h create mode 100644 net/mac80211/aes_gmac.c create mode 100644 net/mac80211/aes_gmac.h -- To unsubscribe from this list: send the line "unsubscribe
Re: [PATCH] net: rfkill: Add Broadcom BCM2E40 bluetooth ACPI ID
On Thu, 2015-01-29 at 18:26 +0200, Mika Westerberg wrote: > This is yet another Broadcom bluetooth chip with ACPI ID BCM2E40. Applied. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [1/6] wil6210: remove old Tx work-around
> In the Tx, work around used to force destination index 0 > to be used. This is no more necessary, as firmware supports > multiple destinations > > Signed-off-by: Vladimir Kondratiev Thanks, 6 patches applied to wireless-drivers-next.git: a3c74902082c wil6210: remove old Tx work-around e59d16c08b3a wil6210: avoid Tx descriptor double write 5933a06dc96c wil6210: fix race between xmit and Tx vring de-allocation 5b29c573f3dc wil6210: more Tx debug feeac225bed9 wil6210: print ciphers in debug info 7201472ed376 wil6210: Remove msm platform related code Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/17] ath9k patches
Sujith Manoharan writes: > From: Sujith Manoharan > > ath9k patches for -next. > > Sujith Manoharan (17): > ath9k: Remove ATH9K_HW_WOW_DEVICE_CAPABLE > ath9k: Return early for error conditions > ath9k: Remove redundant device_can_wakeup() check > ath9k: Check early for multi-vif/STA conditions > ath9k: Check multi-channel context for WOW > ath9k: Fix wow init/deinit > ath9k: Check WOW triggers properly > ath9k: Remove unused BMISS processing > ath9k: Remove ath9k_hw_wow_event_to_string > ath9k: Add a debugfs file for WOW > ath9k: Simplify user pattern configuration > ath9k: Add a HW structure for WOW > ath9k: Register max WOW patterns > ath9k: Move WOW registers to reg_wow.h > ath9k: Remove incorrect register macros > ath9k: Cleanup reg_wow.h > ath9k: Fix max pattern check Thanks, all 17 applied to wireless-drivers-next.git. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [1/4] mwifiex: correction in wakeup timer handling
> Wakeup timer is in sync with 'pm_wakeup_fw_try' flag. It > has been started instead of cancelling at one place. This > patch corrects it. > > Signed-off-by: Amitkumar Karwar > Signed-off-by: Cathy Luo Thanks, 4 patches applied to wireless-drivers-next.git: ee6f0dd8a836 mwifiex: correction in wakeup timer handling 7a1f4e61eb64 mwifiex: fix memory leak in mwifiex_send_processed_packet() 0ea3186ce03c mwifiex: fix NULL packet downloading issues fc8f0456dcce mwifiex: disable UAPSD mode when AP starts Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [V2,for,3.19,3/7] rtlwifi: rtl8192ee: Fix adhoc fail
Kalle Valo writes:
>> From: Troy Tan
>>
>> When the buffer descriptor index exceeds 2, then a TX HANG condition
>> will result.
>>
>> Signed-off-by: Troy Tan
>> Signed-off-by: Larry Finger
>> Cc: Stable [V3.18]
>
> Thanks, 4 patches applied to wireless-drivers-next.git:
>
> b661a5da5776 rtlwifi: rtl8192ee: Fix adhoc fail
> 6e5f44361628 rtlwifi: rtl8192ee: Fix TX hang due to failure to update TX
> write point
> 92ff754240b8 rtlwifi: rtl8192ee: Fix parsing of received packet
> 21b39ddb5bb2 rtlwifi: rtl8192ee: Fix DMA stalls
>
> 3 patches skipped:
I had to skip these three patches because of my mistake. So what I did
was that I had merged ("fast forwarded") the net tree into my
wireless-drivers tree and not realising I should not do that. So now I
can't merge wireless-drivers into wireless-drivers-next anymore, as it
will pull unnecessary net changes.
> [V2,for,3.19,1/7] rtlwifi: Remove logging statement that is no longer
> needed
I'll apply this after 3.20-rc1 is released, it should apply then without
problems (or the conflicts are easy for me to fix). Luckily this is just
a cosmetic error and can wait for 3.20-rc2, right?
> [V2,for,3.19,2/7] rtlwifi: rtl8192ee: Fix handling of new style descriptors
> [V2,for,3.19,6/7] rtlwifi: rtl8192ee: Fix problems with calculating free
> space in FIFO
Not sure what to do with these one. Should you rebase and send them now?
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: rtl8723au: multiple condition with no effect - if identical to else
Nicholas Mc Guire writes: > A number if/else if/else branches are identical - so the condition has no > effect on the effective code and can be significantly simplified - this > patch removes the condition and the duplicated code. > > Signed-off-by: Nicholas Mc Guire > --- > > This looks like the output of some broken code-generator - unlikely someone > wrote this by hand. In any case it needs a review by someone that knows the > details of the driver. > > Anyway the number of useless code repetition is potentially record breaking ! > > Patch was compile tested for x86_64_defconfig + CONFIG_STAGING=y > CONFIG_R8723AU=m, CONFIG_8723AU_BT_COEXIST=y > > Patch is against 3.0.19-rc7 (localversoin = -next-20150203) > > .../staging/rtl8723au/hal/rtl8723a_bt-coexist.c| 60 > +++- > 1 file changed, 8 insertions(+), 52 deletions(-) Why make it simple if you can make it complicated :) I presume it's against 3.19-rc7 since a 3.0.19 would be rather obsolete. Signed-off-by: Jes Sorensen -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [V2,for,3.19,3/7] rtlwifi: rtl8192ee: Fix adhoc fail
> From: Troy Tan > > When the buffer descriptor index exceeds 2, then a TX HANG condition > will result. > > Signed-off-by: Troy Tan > Signed-off-by: Larry Finger > Cc: Stable [V3.18] Thanks, 4 patches applied to wireless-drivers-next.git: b661a5da5776 rtlwifi: rtl8192ee: Fix adhoc fail 6e5f44361628 rtlwifi: rtl8192ee: Fix TX hang due to failure to update TX write point 92ff754240b8 rtlwifi: rtl8192ee: Fix parsing of received packet 21b39ddb5bb2 rtlwifi: rtl8192ee: Fix DMA stalls 3 patches skipped: [V2,for,3.19,1/7] rtlwifi: Remove logging statement that is no longer needed [V2,for,3.19,2/7] rtlwifi: rtl8192ee: Fix handling of new style descriptors [V2,for,3.19,6/7] rtlwifi: rtl8192ee: Fix problems with calculating free space in FIFO Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] staging: rtl8723au: multiple condition with no effect - if identical to else
A number if/else if/else branches are identical - so the condition has no
effect on the effective code and can be significantly simplified - this
patch removes the condition and the duplicated code.
Signed-off-by: Nicholas Mc Guire
---
This looks like the output of some broken code-generator - unlikely someone
wrote this by hand. In any case it needs a review by someone that knows the
details of the driver.
Anyway the number of useless code repetition is potentially record breaking !
Patch was compile tested for x86_64_defconfig + CONFIG_STAGING=y
CONFIG_R8723AU=m, CONFIG_8723AU_BT_COEXIST=y
Patch is against 3.0.19-rc7 (localversoin = -next-20150203)
.../staging/rtl8723au/hal/rtl8723a_bt-coexist.c| 60 +++-
1 file changed, 8 insertions(+), 52 deletions(-)
diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
b/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
index 412d8cf..73cfddd 100644
--- a/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
+++ b/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c
@@ -7255,63 +7255,19 @@ btdm_2AntTdmaDurationAdjust(struct rtw_adapter
*padapter, u8 bScoHid,
RTPRINT(FBT, BT_TRACE, ("[BTCoex], first run
TdmaDurationAdjust()!!\n"));
if (bScoHid) {
if (bTxPause) {
- if (maxInterval == 1) {
- btdm_2AntPsTdma(padapter, true, 15);
- pBtdm8723->psTdmaDuAdjType = 15;
- } else if (maxInterval == 2) {
- btdm_2AntPsTdma(padapter, true, 15);
- pBtdm8723->psTdmaDuAdjType = 15;
- } else if (maxInterval == 3) {
- btdm_2AntPsTdma(padapter, true, 15);
- pBtdm8723->psTdmaDuAdjType = 15;
- } else {
- btdm_2AntPsTdma(padapter, true, 15);
- pBtdm8723->psTdmaDuAdjType = 15;
- }
+ btdm_2AntPsTdma(padapter, true, 15);
+ pBtdm8723->psTdmaDuAdjType = 15;
} else {
- if (maxInterval == 1) {
- btdm_2AntPsTdma(padapter, true, 11);
- pBtdm8723->psTdmaDuAdjType = 11;
- } else if (maxInterval == 2) {
- btdm_2AntPsTdma(padapter, true, 11);
- pBtdm8723->psTdmaDuAdjType = 11;
- } else if (maxInterval == 3) {
- btdm_2AntPsTdma(padapter, true, 11);
- pBtdm8723->psTdmaDuAdjType = 11;
- } else {
- btdm_2AntPsTdma(padapter, true, 11);
- pBtdm8723->psTdmaDuAdjType = 11;
- }
+ btdm_2AntPsTdma(padapter, true, 11);
+ pBtdm8723->psTdmaDuAdjType = 11;
}
} else {
if (bTxPause) {
- if (maxInterval == 1) {
- btdm_2AntPsTdma(padapter, true, 7);
- pBtdm8723->psTdmaDuAdjType = 7;
- } else if (maxInterval == 2) {
- btdm_2AntPsTdma(padapter, true, 7);
- pBtdm8723->psTdmaDuAdjType = 7;
- } else if (maxInterval == 3) {
- btdm_2AntPsTdma(padapter, true, 7);
- pBtdm8723->psTdmaDuAdjType = 7;
- } else {
- btdm_2AntPsTdma(padapter, true, 7);
- pBtdm8723->psTdmaDuAdjType = 7;
- }
+ btdm_2AntPsTdma(padapter, true, 7);
+ pBtdm8723->psTdmaDuAdjType = 7;
} else {
- if (maxInterval == 1) {
- btdm_2AntPsTdma(padapter, true, 3);
- pBtdm8723->psTdmaDuAdjType = 3;
- } else if (maxInterval == 2) {
- btdm_2AntPsTdma(padapter, true, 3);
- pBtdm8723->psTdmaDuAdjType = 3;
- } else if (maxInterval == 3) {
-
Re: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
"Fu, Zhonghui" writes: >>From ff39ed4af9f1c50358fe92ec4c8eaac9db183e00 Mon Sep 17 00:00:00 2001 > From: Zhonghui Fu > Date: Mon, 26 Jan 2015 10:13:21 +0800 > Subject: [PATCH] brcmfmac: avoid duplicated suspend/resume operation > > WiFi chip has 2 SDIO functions, and PM core will trigger > twice suspend/resume operations for one WiFi chip to do > the same things. This patch avoid this case. > > Acked-by: Arend van Spriel > Signed-off-by: Zhonghui Fu This doesn't apply: Applying: brcmfmac: avoid duplicated suspend/resume operation Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c CONFLICT (content): Merge conflict in drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c Failed to merge in the changes. Patch failed at 0001 brcmfmac: avoid duplicated suspend/resume operation BTW, when you resend a patch please use "[PATCH v2]" (or v3, v4...) in the Subject field. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/6] rtlwifi: Change logging level for key change
Larry Finger writes:
> On 01/26/2015 02:42 PM, Larry Finger wrote:
>> A recent change in key handling included logging of these changes for
>> all debug levels. Such key changes should only be logged when a high
>> level of debugging is enabled.
>>
>> Signed-off-by: Larry Finger
>> ---
>> drivers/net/wireless/rtlwifi/cam.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/rtlwifi/cam.c
>> b/drivers/net/wireless/rtlwifi/cam.c
>> index 3ef870d..6e64792 100644
>> --- a/drivers/net/wireless/rtlwifi/cam.c
>> +++ b/drivers/net/wireless/rtlwifi/cam.c
>> @@ -406,7 +406,7 @@ u8 rtl_cam_get_free_entry(struct ieee80211_hw *hw,
>> struct ieee80211_sta *sta,
>> }
>> }
>> if (found) {
>> -RT_TRACE(rtlpriv, COMP_SEC, DBG_EMERG,
>> +RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG,
>> "key_index=%d,cam_bitmap: 0x%x entry_idx=%d\n",
>>key_index, rtlpriv->sec.cam_bitmap, entry_idx);
>> return entry_idx;
>>
>
> Kalle,
>
> Please include this patch even though the rest of this set should be
> dropped.
I tried to do that but it failed:
Applying: rtlwifi: Change logging level for key change
fatal: sha1 information is lacking or useless
(drivers/net/wireless/rtlwifi/cam.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 rtlwifi: Change logging level for key change
I was not even able to find that code from cam.c. Have I missed a patch?
> Once the wifi-BT communications problem is resolved, new versions of
> those will be presented.
Sounds good.
> I'm sorry that my commit message was not as informative as it could
> have been. I was presented with this material that I did not
> understand. One saving grace is that the RTL8812AE hardware is
> apparently rare - I certainly do not have any samples. I'm not sure of
> the value of a 1x1 implementation of 802.11ac, but that may be another
> example of my ignorance.
No worries. But stuff like this is usually best to send as RFC first and
ask people to analyse it before sending it officially.
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 4/4] ath10k: introduce basic tdls functionality
On 3 February 2015 at 11:41, Marek Puzyniak wrote:
[...]
> +static int ath10k_enable_tdls(struct ath10k *ar, u32 vdev_id, bool enable)
Function in mac.c should have a `ath10k_mac_` prefix.
> +{
> + int ret;
> + enum wmi_tdls_state state = WMI_TDLS_DISABLE;
> +
> + lockdep_assert_held(&ar->conf_mutex);
> +
> + if (enable)
> + state = WMI_TDLS_ENABLE_ACTIVE;
> +
> + ret = ath10k_wmi_update_fw_tdls_state(ar, vdev_id, state);
Anyway I see little point in having this wrapper function just to call
wmi function?
[...]
> +static int ath10k_tdls_peer_update(struct ath10k *ar, u32 vdev_id,
> + struct ieee80211_sta *sta,
> + enum wmi_tdls_peer_state state)
The ath10k_mac_ prefix is missing: ath10k_mac_tdls_peer_update().
> +{
> + int ret;
> + struct wmi_tdls_peer_update_cmd_arg arg;
> + struct wmi_tdls_peer_capab_arg cap;
> + struct wmi_channel_arg chan_arg;
I would `xxx = {}` to make these are zero-ed. Right now you pass
uninitialized vars from the stack..
> + int i;
> +
> + lockdep_assert_held(&ar->conf_mutex);
> +
> + arg.vdev_id = vdev_id;
> + arg.peer_state = state;
> + ether_addr_copy(arg.addr, sta->addr);
> +
> + cap.peer_max_sp = sta->max_sp;
> + cap.peer_uapsd_queues = sta->uapsd_queues;
> + cap.peer_curr_operclass = 0;
> + cap.self_curr_operclass = 0;
> + cap.peer_chan_len = 0;
> + cap.peer_operclass_len = 0;
> + cap.is_peer_responder = 0;
> + cap.buff_sta_support = 0;
> + cap.off_chan_support = 0;
> + cap.pref_offchan_num = 0;
> + cap.pref_offchan_bw = 0;
Once you `= {}` it's probably redundant to zero each structure member like that.
[...]
> @@ -4462,6 +4553,8 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
> if (ret)
> ath10k_warn(ar, "failed to delete peer %pM for vdev
> %d: %i\n",
> sta->addr, arvif->vdev_id, ret);
> + if (sta->tdls)
> + ath10k_enable_tdls(ar, arvif->vdev_id, false);
What if you have 2 TDLS peers? If you disconnect the first one you'll
disable TDLS on the entire vdev while the other peer is still
connected. I don't think that's desired.
Perhaps the per-vdev TDLS command can be called in
add_interface()/remove_interface()? If that's not possible I guess you
could use ieee80211_iterate_stations_atomic() to look if there's still
at least one TDLS peer present.
>
> ath10k_mac_dec_num_stations(arvif);
> } else if (old_state == IEEE80211_STA_AUTH &&
> @@ -4479,9 +4572,28 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
> ath10k_warn(ar, "failed to associate station %pM for
> vdev %i: %i\n",
> sta->addr, arvif->vdev_id, ret);
> } else if (old_state == IEEE80211_STA_ASSOC &&
> - new_state == IEEE80211_STA_AUTH &&
> - (vif->type == NL80211_IFTYPE_AP ||
> - vif->type == NL80211_IFTYPE_ADHOC)) {
> + new_state == IEEE80211_STA_AUTHORIZED &&
> + sta->tdls) {
> + /*
> +* Tdls station authorized.
> +*/
> + ath10k_dbg(ar, ATH10K_DBG_MAC, "mac tdls sta %pM
> authorized\n",
> + sta->addr);
> +
> + ret = ath10k_station_assoc(ar, vif, sta, false);
> + if (ret)
> + ath10k_warn(ar, "failed to associate station %pM for
> vdev %i: %i\n",
> + sta->addr, arvif->vdev_id, ret);
It's meaningless to call tdls_peer_update() if assoc failed. From
practical standpoint fw is probably dead at that point and subsequent
commands will timeout. You can `goto exit`.
[...]
> +static struct sk_buff *
> +ath10k_wmi_tlv_op_gen_update_fw_tdls_state(struct ath10k *ar, u32 vdev_id,
> + enum wmi_tdls_state state)
> +{
> + struct wmi_tdls_set_state_cmd *cmd;
> + struct wmi_tlv *tlv;
> + struct sk_buff *skb;
> + void *ptr;
> + size_t len;
> + /* Set to options from wmi_tlv_tdls_options,
> +* for now none of then are enabled.
Typo: s/then/them/
> +*/
> + u32 options = 0;
> +
> + len = sizeof(*tlv) + sizeof(*cmd);
> + skb = ath10k_wmi_alloc_skb(ar, sizeof(*tlv) + sizeof(*cmd));
Why not use `len` for alloc_skb()?
[...]
> +static struct sk_buff *
> +ath10k_wmi_tlv_op_gen_tdls_peer_update(struct ath10k *ar,
> + struct wmi_tdls_peer_update_cmd_arg
> *arg,
> + struct wmi_tdls_peer_capab_arg *cap,
> + struct wmi_channel_arg *chan_arg)
Could be const struct on these _args.
[...]
> diff --git a/driver
btcoex subsystem
Marcel Holtmann writes: >> I will work on combining the latest BT drivers from Realtek with >> btusb to see if I can achieve a patch that will both work with the >> Realtek hardware, and get approval from the reviewers. >> >> What would be an approved method of communicating between two kernel >> modules? Is there some example in the kernel that I could study? > > We need a btcoex subsystem that both WiFi and Bluetooth can register > to and communicate with. The need for this seems to periodically come up, I remember needing something like that back in the Maemo wl1251 days and also ath6kl needed this. Are there any ideas for this subsystem? How would this btcoex subsystem work? What kind of information would it provide? Is this something we should discuss at Ottawa? -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath9k_htc: add adaptive usb flow control to repair soft lockup with monitor mode
yuweizh...@139.com writes:
> From: Yuwei Zheng
>
> In the environment with heavy wifi traffic, set the ar9271 into monitor mode,
> will
> trigger a deadloop panic.
>
> The ath9k_hif_usb_rx_cb function excute on the interrupt context, and
> ath9k_rx_tasklet excute
> on the soft irq context. In other words, the ath9k_hif_usb_rx_cb have more
> chance to excute than
> ath9k_rx_tasklet. So in the worst condition, the rx.rxbuf receive list is
> always full,
> and the do {}while(true) loop will not be break. The kernel get a soft lockup
> panic.
The word wrapping is still wrong, please limit the width to 72 chars or
so. But no need to wrap log snippets, they can exceed the limit.
> Signed-off-by: Yuwei Zheng
> Signed-off-by: Yuwei Zheng
Why two of these? Please use just one Signed-off-by line. Unless these
are two different persons with the same name :)
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Throughput regression with `tcp: refine TSO autosizing`
On 3 February 2015 at 02:18, Eric Dumazet wrote:
> On Mon, 2015-02-02 at 10:52 -0800, Eric Dumazet wrote:
>
>> It seems to break ACK clocking badly (linux stack has a somewhat buggy
>> tcp_tso_should_defer(), which relies on ACK being received smoothly, as
>> no timer is setup to split the TSO packet.)
>
> Following patch might help the TSO split defer logic.
>
> It would avoid setting the TSO defer 'pseudo timer' twice, if/when TCP
> Small Queue logic prevented the xmit at the expiration of first 'timer'.
>
> This patch clears the tso_deferred variable only if we could really
> send something.
>
> Please try it, thanks !
[..patch..]
I've done a second round of tests. I've added the A-MSDU count
parameter I've mentioned in my other email into the mix.
net - net/master (includes stretch ack patches)
net-tso - net/master + your TSO defer patch
net-gro - net/master + my ath10k GRO patch
net-gro-tso - net/master + duh
Here's the best of amsdu count 1 and 3:
; for (i in */output.txt) { echo $i; for (j in (1 3)) { cat $i | awk
'x && /Mbits/ {y=$0}; x && y && !/Mbits/ {print y; x=0; y=""}; /set
amsdu cnt to '$j'/{x=1}' | awk '{ if (x < $(NF-1)) {x=$(NF-1)} }
END{print "A-MSDU limit='$j', " x " Mbits/sec"}' } }
net-gro-tso/output.txt
A-MSDU limit=1, 436 Mbits/sec
A-MSDU limit=3, 284 Mbits/sec
net-gro/output.txt
A-MSDU limit=1, 444 Mbits/sec
A-MSDU limit=3, 283 Mbits/sec
net-tso/output.txt
A-MSDU limit=1, 376 Mbits/sec
A-MSDU limit=3, 251 Mbits/sec
net/output.txt
A-MSDU limit=1, 387 Mbits/sec
A-MSDU limit=3, 260 Mbits/sec
IOW:
- stretch acks / TSO defer don't seem to help much (when compared to
throughput results from yesterday)
- GRO helps
- disabling A-MSDU on sender helps
- net/master+GRO still doesn't reach the performance from before the
regression (~600mbps w/ GRO)
You can grab logs and dumps here: http://www.filedropper.com/test2tar
Michał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Call Me.
Dear Sir, Please write or call me I have a prospective business deal. Regards, Ross Garry William. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ath9k_htc: add adaptive usb flow control to repair soft lockup with monitor mode
From: Yuwei Zheng
In the environment with heavy wifi traffic, set the ar9271 into monitor mode,
will
trigger a deadloop panic.
The ath9k_hif_usb_rx_cb function excute on the interrupt context, and
ath9k_rx_tasklet excute
on the soft irq context. In other words, the ath9k_hif_usb_rx_cb have more
chance to excute than
ath9k_rx_tasklet. So in the worst condition, the rx.rxbuf receive list is
always full,
and the do {}while(true) loop will not be break. The kernel get a soft lockup
panic.
[59011.007210] BUG: soft lockup - CPU#0 stuck for 23s!
[kworker/0:0:30609]
[59011.030560] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
[59013.804486] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
[59013.858522] Kernel panic - not syncing: softlockup: hung tasks
[59014.038891] Exception stack(0xdf4bbc38 to 0xdf4bbc80)
[59014.046834] bc20:
de57b950 6113
[59014.059579] bc40: bb32bb32 6113 de57b948 de57b500 dc7bb440
df4bbcd0
[59014.072337] bc60: de57b950 6113 df4bbcd0 df4bbc80 c04c259d c04c25a0
6133
[59014.085233] [] (__irq_svc+0x3b/0x5c) from []
(_raw_spin_unlock_irqrestore+0xc/0x10)
[59014.100437] [] (_raw_spin_unlock_irqrestore+0xc/0x10) from
[] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc])
[59014.118267] [] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc]) from
[] (tasklet_action+0x3b/0x98)
[59014.134132] [] (tasklet_action+0x3b/0x98) from []
(__do_softirq+0x99/0x16c)
[59014.147784] [] (__do_softirq+0x99/0x16c) from []
(irq_exit+0x5b/0x5c)
[59014.160653] [] (irq_exit+0x5b/0x5c) from []
(handle_IRQ+0x37/0x78)
[59014.173124] [] (handle_IRQ+0x37/0x78) from []
(omap3_intc_handle_irq+0x5f/0x68)
[59014.187225] [] (omap3_intc_handle_irq+0x5f/0x68) from
[](__irq_svc+0x3b/0x5c)
This bug can be see with low performance board, such as uniprocessor beagle
bone board.
Signed-off-by: Yuwei Zheng
Signed-off-by: Yuwei Zheng
---
drivers/net/wireless/ath/ath9k/hif_usb.c | 61 +++---
drivers/net/wireless/ath/ath9k/hif_usb.h | 6 +++
drivers/net/wireless/ath/ath9k/htc.h | 18
drivers/net/wireless/ath/ath9k/htc_drv_debug.c | 46 +++
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 25 +++
5 files changed, 149 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 8e7153b..718bbd6 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -640,6 +640,7 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
struct hif_device_usb *hif_dev =
usb_get_intfdata(usb_ifnum_to_if(urb->dev, 0));
int ret;
+ int delay;
if (!skb)
return;
@@ -658,7 +659,6 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
default:
goto resubmit;
}
-
if (likely(urb->actual_length != 0)) {
skb_put(skb, urb->actual_length);
ath9k_hif_usb_rx_stream(hif_dev, skb);
@@ -667,12 +667,18 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
resubmit:
skb_reset_tail_pointer(skb);
skb_trim(skb, 0);
-
- usb_anchor_urb(urb, &hif_dev->rx_submitted);
- ret = usb_submit_urb(urb, GFP_ATOMIC);
- if (ret) {
- usb_unanchor_urb(urb);
- goto free;
+ if (atomic_read(&hif_dev->rx_urb_submit_delay) > 0) {
+ usb_anchor_urb(urb, &hif_dev->rx_delayed_submitted);
+ delay = atomic_read(&hif_dev->rx_urb_submit_delay);
+ schedule_delayed_work(&hif_dev->rx_submit_delayed_work,
+ usecs_to_jiffies(delay));
+ } else {
+ usb_anchor_urb(urb, &hif_dev->rx_submitted);
+ ret = usb_submit_urb(urb, GFP_ATOMIC);
+ if (ret) {
+ usb_unanchor_urb(urb);
+ goto free;
+ }
}
return;
@@ -818,9 +824,43 @@ err:
return -ENOMEM;
}
+static void rx_urb_delayed_submit_handler(struct work_struct *work)
+{
+ struct hif_device_usb *hif_dev =
+ container_of(work,
+struct hif_device_usb,
+rx_submit_delayed_work.work);
+
+ struct urb *urb = NULL;
+ struct sk_buff *skb = NULL;
+ int ret;
+ int loop_times = 0;
+
+ while (true) {
+ loop_times++;
+ if (loop_times > (MAX_RX_URB_NUM))
+ atomic_add(ARC_RX_STEP, &hif_dev->rx_urb_submit_delay);
+
+ urb = usb_get_from_anchor(&hif_dev->rx_delayed_submitted);
+ if (urb) {
+ skb = (struct sk_buff *)urb->context;
+ ret = usb_submit_urb(urb, GFP_KERNEL);
+ if (ret != 0) {
+ usb_u
[RFC 2/4] ath10k: make peer type configurable
Peer type was hardcoded to default value.
For future implementation it is required
to make is configurable.
Signed-off-by: Marek Puzyniak
Signed-off-by: Marek Kwaczynski
---
drivers/net/wireless/ath/ath10k/mac.c | 14 +-
drivers/net/wireless/ath/ath10k/wmi-ops.h | 8 +---
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 5 +++--
drivers/net/wireless/ath/ath10k/wmi.c | 3 ++-
drivers/net/wireless/ath/ath10k/wmi.h | 6 ++
5 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index c5815ce..7f0a594 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -381,7 +381,8 @@ ath10k_mac_get_any_chandef_iter(struct ieee80211_hw *hw,
*def = &conf->def;
}
-static int ath10k_peer_create(struct ath10k *ar, u32 vdev_id, const u8 *addr)
+static int ath10k_peer_create(struct ath10k *ar, u32 vdev_id, const u8 *addr,
+ enum wmi_peer_type peer_type)
{
int ret;
@@ -390,7 +391,7 @@ static int ath10k_peer_create(struct ath10k *ar, u32
vdev_id, const u8 *addr)
if (ar->num_peers >= ar->max_num_peers)
return -ENOBUFS;
- ret = ath10k_wmi_peer_create(ar, vdev_id, addr);
+ ret = ath10k_wmi_peer_create(ar, vdev_id, addr, peer_type);
if (ret) {
ath10k_warn(ar, "failed to create wmi peer %pM on vdev %i:
%i\n",
addr, vdev_id, ret);
@@ -2772,7 +2773,8 @@ void ath10k_offchan_tx_work(struct work_struct *work)
peer_addr, vdev_id);
if (!peer) {
- ret = ath10k_peer_create(ar, vdev_id, peer_addr);
+ ret = ath10k_peer_create(ar, vdev_id, peer_addr,
+WMI_PEER_TYPE_DEFAULT);
if (ret)
ath10k_warn(ar, "failed to create peer %pM on
vdev %d: %d\n",
peer_addr, vdev_id, ret);
@@ -3686,7 +3688,8 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
if (arvif->vdev_type == WMI_VDEV_TYPE_AP ||
arvif->vdev_type == WMI_VDEV_TYPE_IBSS) {
- ret = ath10k_peer_create(ar, arvif->vdev_id, vif->addr);
+ ret = ath10k_peer_create(ar, arvif->vdev_id, vif->addr,
+WMI_PEER_TYPE_DEFAULT);
if (ret) {
ath10k_warn(ar, "failed to create vdev %i peer for
AP/IBSS: %d\n",
arvif->vdev_id, ret);
@@ -4439,7 +4442,8 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
goto exit;
}
- ret = ath10k_peer_create(ar, arvif->vdev_id, sta->addr);
+ ret = ath10k_peer_create(ar, arvif->vdev_id, sta->addr,
+WMI_PEER_TYPE_DEFAULT);
if (ret) {
ath10k_warn(ar, "failed to add peer %pM for vdev %d
when adding a new sta: %i\n",
sta->addr, arvif->vdev_id, ret);
diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h
b/drivers/net/wireless/ath/ath10k/wmi-ops.h
index 71334f5..16d2d7c 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
@@ -83,7 +83,8 @@ struct wmi_ops {
struct sk_buff *(*gen_vdev_wmm_conf)(struct ath10k *ar, u32 vdev_id,
const struct
wmi_wmm_params_all_arg *arg);
struct sk_buff *(*gen_peer_create)(struct ath10k *ar, u32 vdev_id,
- const u8 peer_addr[ETH_ALEN]);
+ const u8 peer_addr[ETH_ALEN],
+ enum wmi_peer_type peer_type);
struct sk_buff *(*gen_peer_delete)(struct ath10k *ar, u32 vdev_id,
const u8 peer_addr[ETH_ALEN]);
struct sk_buff *(*gen_peer_flush)(struct ath10k *ar, u32 vdev_id,
@@ -633,14 +634,15 @@ ath10k_wmi_vdev_wmm_conf(struct ath10k *ar, u32 vdev_id,
static inline int
ath10k_wmi_peer_create(struct ath10k *ar, u32 vdev_id,
- const u8 peer_addr[ETH_ALEN])
+ const u8 peer_addr[ETH_ALEN],
+ enum wmi_peer_type peer_type)
{
struct sk_buff *skb;
if (!ar->wmi.ops->gen_peer_create)
return -EOPNOTSUPP;
- skb = ar->wmi.ops->gen_peer_create(ar, vdev_id, peer_addr);
+ skb = ar->wmi.ops->gen_peer_create(ar, vdev_id, peer_addr, peer_type);
if (IS_ERR(skb))
return PTR_ERR(skb);
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index a846821..16b0e6b 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/dr
[RFC 1/4] ath10k: unify tx mode and dispatch
From: Michal Kazior
There are a few different tx paths depending on
firmware and frame itself.
Creating a uniform decision will make it possible
to switch between different txmode easier, both
for testing and for future features as well.
Signed-off-by: Michal Kazior
Signed-off-by: Marek Puzyniak
---
drivers/net/wireless/ath/ath10k/core.h | 2 +
drivers/net/wireless/ath/ath10k/htt_rx.c | 8 --
drivers/net/wireless/ath/ath10k/htt_tx.c | 30
drivers/net/wireless/ath/ath10k/mac.c| 128 ---
drivers/net/wireless/ath/ath10k/mac.h| 8 ++
5 files changed, 124 insertions(+), 52 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 57c7926..884ec6c 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -82,6 +82,8 @@ struct ath10k_skb_cb {
dma_addr_t paddr;
u8 eid;
u8 vdev_id;
+ enum ath10k_hw_txrx_mode txmode;
+ bool is_protected;
struct {
u8 tid;
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 08c924c..ad823c9 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -609,14 +609,6 @@ static int ath10k_htt_rx_crypto_tail_len(struct ath10k *ar,
return 0;
}
-struct rfc1042_hdr {
- u8 llc_dsap;
- u8 llc_ssap;
- u8 llc_ctrl;
- u8 snap_oui[3];
- __be16 snap_type;
-} __packed;
-
struct amsdu_subframe_hdr {
u8 dst[ETH_ALEN];
u8 src[ETH_ALEN];
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c
b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 92cc6e3..e3a762c 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -424,9 +424,8 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff
*msdu)
int res;
u8 flags0 = 0;
u16 msdu_id, flags1 = 0;
- dma_addr_t paddr;
- u32 frags_paddr;
- bool use_frags;
+ dma_addr_t paddr = 0;
+ u32 frags_paddr = 0;
res = ath10k_htt_tx_inc_pending(htt);
if (res)
@@ -444,12 +443,6 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff
*msdu)
prefetch_len = min(htt->prefetch_len, msdu->len);
prefetch_len = roundup(prefetch_len, 4);
- /* Since HTT 3.0 there is no separate mgmt tx command. However in case
-* of mgmt tx using TX_FRM there is not tx fragment list. Instead of tx
-* fragment list host driver specifies directly frame pointer. */
- use_frags = htt->target_version_major < 3 ||
- !ieee80211_is_mgmt(hdr->frame_control);
-
skb_cb->htt.txbuf = dma_pool_alloc(htt->tx_pool, GFP_ATOMIC,
&paddr);
if (!skb_cb->htt.txbuf) {
@@ -470,7 +463,12 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff
*msdu)
if (res)
goto err_free_txbuf;
- if (likely(use_frags)) {
+ switch (skb_cb->txmode) {
+ case ATH10K_HW_TXRX_RAW:
+ case ATH10K_HW_TXRX_NATIVE_WIFI:
+ flags0 |= HTT_DATA_TX_DESC_FLAGS0_MAC_HDR_PRESENT;
+ /* pass through */
+ case ATH10K_HW_TXRX_ETHERNET:
frags = skb_cb->htt.txbuf->frags;
frags[0].paddr = __cpu_to_le32(skb_cb->paddr);
@@ -478,15 +476,17 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff
*msdu)
frags[1].paddr = 0;
frags[1].len = 0;
- flags0 |= SM(ATH10K_HW_TXRX_NATIVE_WIFI,
-HTT_DATA_TX_DESC_FLAGS0_PKT_TYPE);
+ flags0 |= SM(skb_cb->txmode, HTT_DATA_TX_DESC_FLAGS0_PKT_TYPE);
frags_paddr = skb_cb->htt.txbuf_paddr;
- } else {
+ break;
+ case ATH10K_HW_TXRX_MGMT:
flags0 |= SM(ATH10K_HW_TXRX_MGMT,
HTT_DATA_TX_DESC_FLAGS0_PKT_TYPE);
+ flags0 |= HTT_DATA_TX_DESC_FLAGS0_MAC_HDR_PRESENT;
frags_paddr = skb_cb->paddr;
+ break;
}
/* Normally all commands go through HTC which manages tx credits for
@@ -512,11 +512,9 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff
*msdu)
prefetch_len);
skb_cb->htt.txbuf->htc_hdr.flags = 0;
- if (!ieee80211_has_protected(hdr->frame_control))
+ if (!skb_cb->is_protected)
flags0 |= HTT_DATA_TX_DESC_FLAGS0_NO_ENCRYPT;
- flags0 |= HTT_DATA_TX_DESC_FLAGS0_MAC_HDR_PRESENT;
-
flags1 |= SM((u16)vdev_id, HTT_DATA_TX_DESC_FLAGS1_VDEV_ID);
flags1 |= SM((u16)tid, HTT_DATA_TX_DESC_FLAGS1_EXT_TID);
flags1 |= HTT_DATA_TX_DESC_FLAGS1_CKSUM_L3_OFFLOAD;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 7fbb9aa..c5815ce 100644
--- a/drive
[RFC 3/4] mac80211: initialize rate control earlier for tdls station
Currently when TDLS station in driver goes from assoc
to authorized state it can not use rate control parameters
because rate control is not initialized yet. Some drivers
require parameters already initialized by rate control when
entering authorized state. It can be done by initializing
rate control after station transition to authorized state
but before notifying driver about that.
Signed-off-by: Marek Puzyniak
---
net/mac80211/cfg.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index a777114..3849054 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -952,12 +952,21 @@ static int sta_apply_auth_flags(struct ieee80211_local
*local,
}
if (mask & BIT(NL80211_STA_FLAG_AUTHORIZED)) {
- if (set & BIT(NL80211_STA_FLAG_AUTHORIZED))
+ if (set & BIT(NL80211_STA_FLAG_AUTHORIZED)) {
+ /*
+* When peer becomes authorized, init rate control as
+* well. Some drivers require rate control initialized
+* before drv_sta_state() is called.
+*/
+ if (test_sta_flag(sta, WLAN_STA_TDLS_PEER))
+ rate_control_rate_init(sta);
+
ret = sta_info_move_state(sta,
IEEE80211_STA_AUTHORIZED);
- else if (test_sta_flag(sta, WLAN_STA_AUTHORIZED))
+ } else if (test_sta_flag(sta, WLAN_STA_AUTHORIZED)) {
ret = sta_info_move_state(sta, IEEE80211_STA_ASSOC);
- else
+ } else {
ret = 0;
+ }
if (ret)
return ret;
}
@@ -1346,11 +1355,6 @@ static int ieee80211_change_station(struct wiphy *wiphy,
if (err)
goto out_err;
- /* When peer becomes authorized, init rate control as well */
- if (test_sta_flag(sta, WLAN_STA_TDLS_PEER) &&
- test_sta_flag(sta, WLAN_STA_AUTHORIZED))
- rate_control_rate_init(sta);
-
mutex_unlock(&local->sta_mtx);
if ((sdata->vif.type == NL80211_IFTYPE_AP ||
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 4/4] ath10k: introduce basic tdls functionality
This patch adds functions to enable/disable tdls
and to configure tdls peer station for tlv based firmware.
Tdls peer uapsd and tdls channel switching are not supported.
Transmitting tdls data frames works only for ethernet
type frames, that's why data addressed to tdls sta
is in ethernet format.
Tdls functionality for ath10k requires changes in mac80211
provided in patch:
mac80211: initialize rate control earlier for tdls station
Signed-off-by: Michal Kazior
Signed-off-by: Marek Kwaczynski
Signed-off-by: Marek Puzyniak
---
drivers/net/wireless/ath/ath10k/mac.c | 127 +++--
drivers/net/wireless/ath/ath10k/wmi-ops.h | 42 +
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 151 ++
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 52 ++
drivers/net/wireless/ath/ath10k/wmi.h | 37
5 files changed, 403 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 7f0a594..3ef4d98 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -535,6 +535,72 @@ static void ath10k_peer_cleanup_all(struct ath10k *ar)
ar->num_stations = 0;
}
+static int ath10k_enable_tdls(struct ath10k *ar, u32 vdev_id, bool enable)
+{
+ int ret;
+ enum wmi_tdls_state state = WMI_TDLS_DISABLE;
+
+ lockdep_assert_held(&ar->conf_mutex);
+
+ if (enable)
+ state = WMI_TDLS_ENABLE_ACTIVE;
+
+ ret = ath10k_wmi_update_fw_tdls_state(ar, vdev_id, state);
+ if (ret) {
+ ath10k_warn(ar, "failed to update fw tdls state on vdev %i:
%i\n",
+ vdev_id, ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int ath10k_tdls_peer_update(struct ath10k *ar, u32 vdev_id,
+ struct ieee80211_sta *sta,
+ enum wmi_tdls_peer_state state)
+{
+ int ret;
+ struct wmi_tdls_peer_update_cmd_arg arg;
+ struct wmi_tdls_peer_capab_arg cap;
+ struct wmi_channel_arg chan_arg;
+ int i;
+
+ lockdep_assert_held(&ar->conf_mutex);
+
+ arg.vdev_id = vdev_id;
+ arg.peer_state = state;
+ ether_addr_copy(arg.addr, sta->addr);
+
+ cap.peer_max_sp = sta->max_sp;
+ cap.peer_uapsd_queues = sta->uapsd_queues;
+ cap.peer_curr_operclass = 0;
+ cap.self_curr_operclass = 0;
+ cap.peer_chan_len = 0;
+ cap.peer_operclass_len = 0;
+ cap.is_peer_responder = 0;
+ cap.buff_sta_support = 0;
+ cap.off_chan_support = 0;
+ cap.pref_offchan_num = 0;
+ cap.pref_offchan_bw = 0;
+
+ for (i = 0; i < WMI_TDLS_MAX_SUPP_OPER_CLASSES; i++)
+ cap.peer_operclass[i] = 0;
+
+ if (state == WMI_TDLS_PEER_STATE_CONNECTED) {
+ if (!sta->tdls_initiator)
+ cap.is_peer_responder = 1;
+ }
+
+ ret = ath10k_wmi_tdls_peer_update(ar, &arg, &cap, &chan_arg);
+ if (ret) {
+ ath10k_warn(ar, "failed to update tdls peer %pM on vdev %i:
%i\n",
+ arg.addr, vdev_id, ret);
+ return ret;
+ }
+
+ return 0;
+}
+
//
/* Interface management */
//
@@ -2463,7 +2529,7 @@ static u8 ath10k_tx_h_get_vdev_id(struct ath10k *ar,
struct ieee80211_vif *vif)
static enum ath10k_hw_txrx_mode
ath10k_tx_h_get_txmode(struct ath10k *ar, struct ieee80211_vif *vif,
- struct sk_buff *skb)
+ struct ieee80211_sta *sta, struct sk_buff *skb)
{
const struct ieee80211_hdr *hdr = (void *)skb->data;
__le16 fc = hdr->frame_control;
@@ -2495,6 +2561,15 @@ ath10k_tx_h_get_txmode(struct ath10k *ar, struct
ieee80211_vif *vif,
!test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX, ar->fw_features))
return ATH10K_HW_TXRX_MGMT;
+ /* Workaround:
+*
+* Some wmi-tlv firmwares for qca6174 have broken Tx key selection for
+* NativeWifi txmode - it selects AP key instead of peer key. It seems
+* to work with Ethernet txmode so use it.
+*/
+ if (ieee80211_is_data_present(fc) && sta && sta->tdls)
+ return ATH10K_HW_TXRX_ETHERNET;
+
return ATH10K_HW_TXRX_NATIVE_WIFI;
}
@@ -3014,6 +3089,7 @@ static void ath10k_tx(struct ieee80211_hw *hw,
struct ath10k *ar = hw->priv;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct ieee80211_vif *vif = info->control.vif;
+ struct ieee80211_sta *sta = control->sta;
struct ieee80211_key_conf *key = info->control.hw_key;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
__le16 fc = hdr->frame_control;
@@ -3025,7 +3101,7 @@ static void ath10k_tx(struct ieee80211_hw *hw,
ATH10K_SKB_CB(skb)->htt.is_offchan = false;
ATH10K_S
[RFC 0/4] ath10k: add basic tdls support
This patchset introduces tdls funtionality without tdls peer uapsd and tdls channel switching. Tdls is supported by qca6174 hardware what is indicated by firmware through supported services. Tdls station when authorized requires some parameters that are filled in by rate control initialization. Because of that this patches contains one patch for mac80211 which moves rate control initialization before calling drivers station state with transition to authorized state. This patchset is RFC because it based on patchset from Michal: ath10k: add multi-channel support which is still under review. Marek Puzyniak (3): ath10k: make peer type configurable mac80211: initialize rate control earlier for tdls station ath10k: introduce basic tdls functionality Michal Kazior (1): ath10k: unify tx mode and dispatch drivers/net/wireless/ath/ath10k/core.h| 2 + drivers/net/wireless/ath/ath10k/htt_rx.c | 8 - drivers/net/wireless/ath/ath10k/htt_tx.c | 30 ++-- drivers/net/wireless/ath/ath10k/mac.c | 263 ++ drivers/net/wireless/ath/ath10k/mac.h | 8 + drivers/net/wireless/ath/ath10k/wmi-ops.h | 50 +- drivers/net/wireless/ath/ath10k/wmi-tlv.c | 156 +- drivers/net/wireless/ath/ath10k/wmi-tlv.h | 52 ++ drivers/net/wireless/ath/ath10k/wmi.c | 3 +- drivers/net/wireless/ath/ath10k/wmi.h | 43 + net/mac80211/cfg.c| 20 ++- 11 files changed, 561 insertions(+), 74 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath9k_htc: add adaptive rate control to repair soft lockup with monitor mode
Looks good,
please just one note. Rename "rate control" to "usb flow control", or
some thing like this. In this context "rate control" has different meaning.
I'll run you patches on my system with different adapters.
Am 03.02.2015 um 10:21 schrieb yuweizh...@139.com:
> From: Yuwei Zheng
>
> In the environment with heavy wifi traffic, set the ar9271 into monitor mode,
> will
> trigger a deadloop panic.
> The ath9k_hif_usb_rx_cb function excute on the interrupt context, and
> ath9k_rx_tasklet excute
> on the soft irq context. In other words, the ath9k_hif_usb_rx_cb have more
> chance to excute than
> ath9k_rx_tasklet. So in the worst condition, the rx.rxbuf receive list is
> always full,
> and the do {}while(true) loop will not be break. The kernel get a soft lockup
> panic.
> [59011.007210] BUG: soft lockup - CPU#0 stuck for 23s!
> [kworker/0:0:30609]
> [59011.030560] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
> [59013.804486] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
> [59013.858522] Kernel panic - not syncing: softlockup: hung tasks
> [59014.038891] Exception stack(0xdf4bbc38 to 0xdf4bbc80)
> [59014.046834] bc20:
> de57b950 6113
> [59014.059579] bc40: bb32bb32 6113 de57b948 de57b500 dc7bb440
> df4bbcd0
> [59014.072337] bc60: de57b950 6113 df4bbcd0 df4bbc80 c04c259d c04c25a0
> 6133
> [59014.085233] [] (__irq_svc+0x3b/0x5c) from []
> (_raw_spin_unlock_irqrestore+0xc/0x10)
> [59014.100437] [] (_raw_spin_unlock_irqrestore+0xc/0x10) from
> [] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc])
> [59014.118267] [] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc]) from
> [] (tasklet_action+0x3b/0x98)
> [59014.134132] [] (tasklet_action+0x3b/0x98) from []
> (__do_softirq+0x99/0x16c)
> [59014.147784] [] (__do_softirq+0x99/0x16c) from []
> (irq_exit+0x5b/0x5c)
> [59014.160653] [] (irq_exit+0x5b/0x5c) from []
> (handle_IRQ+0x37/0x78)
> [59014.173124] [] (handle_IRQ+0x37/0x78) from []
> (omap3_intc_handle_irq+0x5f/0x68)
> [59014.187225] [] (omap3_intc_handle_irq+0x5f/0x68) from
> [](__irq_svc+0x3b/0x5c)
> This bug can be see with low performance board, such as uniprocessor beagle
> bone board.
> Signed-off-by: Yuwei Zheng
> Signed-off-by: Yuwei Zheng
>
> ---
> drivers/net/wireless/ath/ath9k/hif_usb.c | 61
> +++---
> drivers/net/wireless/ath/ath9k/hif_usb.h | 6 +++
> drivers/net/wireless/ath/ath9k/htc.h | 18
> drivers/net/wireless/ath/ath9k/htc_drv_debug.c | 46 +++
> drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 25 +++
> 5 files changed, 149 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c
> b/drivers/net/wireless/ath/ath9k/hif_usb.c
> index 8e7153b..9166f10 100644
> --- a/drivers/net/wireless/ath/ath9k/hif_usb.c
> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
> @@ -640,6 +640,7 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
> struct hif_device_usb *hif_dev =
> usb_get_intfdata(usb_ifnum_to_if(urb->dev, 0));
> int ret;
> + int delay;
>
> if (!skb)
> return;
> @@ -658,7 +659,6 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
> default:
> goto resubmit;
> }
> -
> if (likely(urb->actual_length != 0)) {
> skb_put(skb, urb->actual_length);
> ath9k_hif_usb_rx_stream(hif_dev, skb);
> @@ -667,12 +667,18 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
> resubmit:
> skb_reset_tail_pointer(skb);
> skb_trim(skb, 0);
> -
> - usb_anchor_urb(urb, &hif_dev->rx_submitted);
> - ret = usb_submit_urb(urb, GFP_ATOMIC);
> - if (ret) {
> - usb_unanchor_urb(urb);
> - goto free;
> + if (atomic_read(&hif_dev->rx_urb_submit_delay) > 0) {
> + usb_anchor_urb(urb, &hif_dev->rx_delayed_submitted);
> + delay = atomic_read(&hif_dev->rx_urb_submit_delay);
> + schedule_delayed_work(&hif_dev->rx_submit_delayed_work,
> + usecs_to_jiffies(delay));
> + } else {
> + usb_anchor_urb(urb, &hif_dev->rx_submitted);
> + ret = usb_submit_urb(urb, GFP_ATOMIC);
> + if (ret) {
> + usb_unanchor_urb(urb);
> + goto free;
> + }
> }
>
> return;
> @@ -818,9 +824,43 @@ err:
> return -ENOMEM;
> }
>
> +static void rx_urb_delayed_submit_handler(struct work_struct *work)
> +{
> + struct hif_device_usb *hif_dev =
> + container_of(work,
> + struct hif_device_usb,
> + rx_submit_delayed_work.work);
> +
> + struct urb *urb = NULL;
> + struct sk_buff *skb = NULL;
> + int ret;
> + int loop_times = 0;
> +
> + while (true) {
> + loop_times++;
> + if (loop_tim
[PATCH] ath9k_htc: add adaptive rate control to repair soft lockup with monitor mode
From: Yuwei Zheng
In the environment with heavy wifi traffic, set the ar9271 into monitor mode,
will
trigger a deadloop panic.
The ath9k_hif_usb_rx_cb function excute on the interrupt context, and
ath9k_rx_tasklet excute
on the soft irq context. In other words, the ath9k_hif_usb_rx_cb have more
chance to excute than
ath9k_rx_tasklet. So in the worst condition, the rx.rxbuf receive list is
always full,
and the do {}while(true) loop will not be break. The kernel get a soft lockup
panic.
[59011.007210] BUG: soft lockup - CPU#0 stuck for 23s!
[kworker/0:0:30609]
[59011.030560] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
[59013.804486] BUG: scheduling while atomic: kworker/0:0/30609/0x40010100
[59013.858522] Kernel panic - not syncing: softlockup: hung tasks
[59014.038891] Exception stack(0xdf4bbc38 to 0xdf4bbc80)
[59014.046834] bc20:
de57b950 6113
[59014.059579] bc40: bb32bb32 6113 de57b948 de57b500 dc7bb440
df4bbcd0
[59014.072337] bc60: de57b950 6113 df4bbcd0 df4bbc80 c04c259d c04c25a0
6133
[59014.085233] [] (__irq_svc+0x3b/0x5c) from []
(_raw_spin_unlock_irqrestore+0xc/0x10)
[59014.100437] [] (_raw_spin_unlock_irqrestore+0xc/0x10) from
[] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc])
[59014.118267] [] (ath9k_rx_tasklet+0x290/0x490 [ath9k_htc]) from
[] (tasklet_action+0x3b/0x98)
[59014.134132] [] (tasklet_action+0x3b/0x98) from []
(__do_softirq+0x99/0x16c)
[59014.147784] [] (__do_softirq+0x99/0x16c) from []
(irq_exit+0x5b/0x5c)
[59014.160653] [] (irq_exit+0x5b/0x5c) from []
(handle_IRQ+0x37/0x78)
[59014.173124] [] (handle_IRQ+0x37/0x78) from []
(omap3_intc_handle_irq+0x5f/0x68)
[59014.187225] [] (omap3_intc_handle_irq+0x5f/0x68) from
[](__irq_svc+0x3b/0x5c)
This bug can be see with low performance board, such as uniprocessor beagle
bone board.
Signed-off-by: Yuwei Zheng
Signed-off-by: Yuwei Zheng
---
drivers/net/wireless/ath/ath9k/hif_usb.c | 61 +++---
drivers/net/wireless/ath/ath9k/hif_usb.h | 6 +++
drivers/net/wireless/ath/ath9k/htc.h | 18
drivers/net/wireless/ath/ath9k/htc_drv_debug.c | 46 +++
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 25 +++
5 files changed, 149 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 8e7153b..9166f10 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -640,6 +640,7 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
struct hif_device_usb *hif_dev =
usb_get_intfdata(usb_ifnum_to_if(urb->dev, 0));
int ret;
+ int delay;
if (!skb)
return;
@@ -658,7 +659,6 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
default:
goto resubmit;
}
-
if (likely(urb->actual_length != 0)) {
skb_put(skb, urb->actual_length);
ath9k_hif_usb_rx_stream(hif_dev, skb);
@@ -667,12 +667,18 @@ static void ath9k_hif_usb_rx_cb(struct urb *urb)
resubmit:
skb_reset_tail_pointer(skb);
skb_trim(skb, 0);
-
- usb_anchor_urb(urb, &hif_dev->rx_submitted);
- ret = usb_submit_urb(urb, GFP_ATOMIC);
- if (ret) {
- usb_unanchor_urb(urb);
- goto free;
+ if (atomic_read(&hif_dev->rx_urb_submit_delay) > 0) {
+ usb_anchor_urb(urb, &hif_dev->rx_delayed_submitted);
+ delay = atomic_read(&hif_dev->rx_urb_submit_delay);
+ schedule_delayed_work(&hif_dev->rx_submit_delayed_work,
+ usecs_to_jiffies(delay));
+ } else {
+ usb_anchor_urb(urb, &hif_dev->rx_submitted);
+ ret = usb_submit_urb(urb, GFP_ATOMIC);
+ if (ret) {
+ usb_unanchor_urb(urb);
+ goto free;
+ }
}
return;
@@ -818,9 +824,43 @@ err:
return -ENOMEM;
}
+static void rx_urb_delayed_submit_handler(struct work_struct *work)
+{
+ struct hif_device_usb *hif_dev =
+ container_of(work,
+struct hif_device_usb,
+rx_submit_delayed_work.work);
+
+ struct urb *urb = NULL;
+ struct sk_buff *skb = NULL;
+ int ret;
+ int loop_times = 0;
+
+ while (true) {
+ loop_times++;
+ if (loop_times > (MAX_RX_URB_NUM))
+ atomic_add(ARC_RX_STEP, &hif_dev->rx_urb_submit_delay);
+
+ urb = usb_get_from_anchor(&hif_dev->rx_delayed_submitted);
+ if (urb) {
+ skb = (struct sk_buff *)urb->context;
+ ret = usb_submit_urb(urb, GFP_KERNEL);
+ if (ret != 0) {
+ usb_unanchor_urb(u
Re: [Cerowrt-devel] Open Source RRM & Hand-Over Optimization (WAS: Throughput regression with `tcp: refine TSO autosizing`)
On Tue, Feb 3, 2015 at 12:27 AM, David Lang wrote: > On Mon, 2 Feb 2015, Avery Pennarun wrote: >> On Mon, Feb 2, 2015 at 11:44 AM, Björn Smedman wrote: >>> We've got an SDN-inspired architecture with 802.11 frame tunneling (a >>> la CAPWAP), airtime fairness, infrastructure initiated hand-over, >>> Opportunistic Key Caching (OKC), IEEE 802.11r Fast BSS Transition and >>> a few more goodies. It's currently free as in beer >>> (http://anyfi.net/software, >>> https://github.com/carrierwrt/carrierwrt/pull/7 and >>> http://www.anyfinetworks.com/download) up to 100 APs, but we're >>> definitely going to open source in one form or another. > > Please keep in touch, when it is released open source I'd be very interested > in trying it for SCaLE. I'll probably exceed your 100 radio free limit this > year, and it's hard to justify using non-free code at a linux conference > (not impossible, but not something I'm going to try to do 3 weeks before the > show :-) Will do. :) > I'm doing social engineering to push people to the 5GHz network (SSID for 5G > is scale, for 2.4 is scale-slow), it would be great to be able to do this > directly. And better handoffs as people move around would be good. > > It would also be good if something like this could help identify gaps in > coverage. If it can identify cases where users go from having coverage to > poor connectivity to having coverage, we can manually investigate to see > where in the building that is and see what we can do to fix it. Both of those should be well within scope. :) -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Open Source RRM & Hand-Over Optimization (WAS: Throughput regression with `tcp: refine TSO autosizing`)
On Mon, Feb 2, 2015 at 11:53 PM, Avery Pennarun wrote: > On Mon, Feb 2, 2015 at 11:44 AM, Björn Smedman wrote: >> On Mon, Feb 2, 2015 at 5:21 AM, Avery Pennarun wrote: >>> While there is definitely some work to be done in handoff, it seems >>> like there are some find implementations of this already in existence. >>> Several brands of "enterprise access point" setups seem to do well at >>> this. It would be nice if they interoperated, I guess. >>> >>> The fact that there's no open source version of this kind of handoff >>> feature bugs me, but we are working on it here and the work is all >>> planned to be open source, for example: (very early version) >>> https://gfiber.googlesource.com/vendor/google/platform/+/master/waveguide/ >> >> We've got an SDN-inspired architecture with 802.11 frame tunneling (a >> la CAPWAP), airtime fairness, infrastructure initiated hand-over, >> Opportunistic Key Caching (OKC), IEEE 802.11r Fast BSS Transition and >> a few more goodies. It's currently free as in beer >> (http://anyfi.net/software, >> https://github.com/carrierwrt/carrierwrt/pull/7 and >> http://www.anyfinetworks.com/download) up to 100 APs, but we're >> definitely going to open source in one form or another. >> >> We've also tried to raise some interest in fixing up CAPWAP >> (https://www.ietf.org/mail-archive/web/opsawg/current/msg03196.html), >> which is (unfortunately) the best open standard at the moment. >> Interest seems marginal though... > > This sounds cool. Is the CAPWAP/encapsulation stuff separable from > the rest? At 802.11ac speeds, a super fast WAN link, and a low-cost > SoC, too many layers can be a killer. Our current architecture is a bit "fixed function" with tunneling built in. That's because it's targeted at guest access / homespots where there's typically a "local MAC" for the home Wi-Fi network (which we don't touch), and for guests you usually want to tunnel anyway. Many use L2oGRE to tunnel a "second SSID" in this use-case, but since the visited AP is a point of attack we think you should encrypt "through" the AP. You can do that without any extra overhead since you're just shoveling encrypted 802.11 frames from one interface to another, but you're right it's a bit slower in practice: in the extreme case of frame shoveling in user space you're limited to about 40 Mbps (for guests) on a $10 SoC (but home Wi-Fi throughput is not impacted). What we're working on now though is an "Open wSwitch" that lets you pick and choose which frames to tunnel and where, even within one BSS / for a single STA. You'll also be able to set the temporal key (TK) from a central location so that you can do e.g. OKC / 802.11r combined with local bridging. This should make it possible to do both the secure guest access and the more enterprisy stuff over the same control plane protocol. We're also planning to put the 802.11 tunneling in kernel space this time, which should easily get you 100 Mbps of AES-128-CCM through a cheap SoC (and into/out of a cheap mobile device!). -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [iwlwifi] fail to flush all tx queues on kernel 3.17.6
Dear Emmanuel, The attached firmware works a LOT better than previous versions. For the first time since owning this laptop I'm able to stream .mkv files over a distance > 10 meters. When enabling WiFi, connecting to a network is a lot faster. Data throughput is a lot better as well. However, it's still not perfect, as the connection works for about 10 minutes before the whole driver suddenly stops working. Again there is no clue as to why this is happening anywhere in dmesg, syslog or w/e. Disabling and enabling WiFi via rfkill or by reloading the module fixes the problem for another 10 minutes. If I leave the connection idle, it doesn't crash as often. All in all, thank you very much for your help until now. Functionality is already a lot better than it was, and the WiFi card is now actually usable (enough) for me. Kind regards, Gerlof Fokkema On Mon, Feb 2, 2015 at 10:19 PM, Emmanuel Grumbach wrote: > On Mon, Feb 2, 2015 at 9:56 PM, Gerlof Fokkema > wrote: >> >> Dear Emmanuel, >> >> I have compiled and experimented with the kernel from this specific commit. >> While I don't get any crash logs from iwlmvm anymore, network performance is >> still truly horrible. >> >> After connecting the WiFi connection seems to work fine for a few minutes, >> and after that the network card does not seem to flush any data anymore. >> When running a ping job together with a download, fully utilizing WiFi, >> after a few minutes (or less) I get: >> >> 64 bytes from 172.16.2.1: icmp_seq=63 ttl=64 time=1476 ms >> 64 bytes from 172.16.2.1: icmp_seq=64 ttl=64 time=476 ms >> 64 bytes from 172.16.2.1: icmp_seq=65 ttl=64 time=10.6 ms >> 64 bytes from 172.16.2.1: icmp_seq=66 ttl=64 time=1558 ms >> 64 bytes from 172.16.2.1: icmp_seq=67 ttl=64 time=569 ms >> 64 bytes from 172.16.2.1: icmp_seq=68 ttl=64 time=9.97 ms >> ping: sendmsg: No buffer space available >> ping: sendmsg: No buffer space available >> >> It seems to me there is something fundamentally wrong with flushing network >> traffic, >> and with the newest commits it doesn't log these problems anymore either. >> >> This problem persists on linux 3.18.0 - 3.18.5 and on the aforementioned >> 3.19 branch. > > Can you try with this firmware: > https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/linux-firmware.git/plain/iwlwifi-7260-10.ucode?id=d5cd7a6cb5f85f6234cca596354e440061a28aa4 > > Please copy the file to /lib/firmware/ > > you may want to back up the previous version first. > >> >> Kind regards, >> >> Gerlof Fokkema >> >> On Thu, Jan 22, 2015 at 7:33 PM, Emmanuel Grumbach >> wrote: >>> >>> Hi, >>> >>> On Thu, Jan 22, 2015 at 4:14 PM, Gerlof Fokkema >>> wrote: >>> > Hello Emmanuel, >>> > >>> > First of all, thanks for your previous reply. >>> > I'm glad the issue is known and being looked at. >>> > >>> > Recently I tried linux kernel 3.18.2 on Arch linux and had the same >>> > issues I previously mentioned. >>> > Is there any bug report on this I can follow or any other way to be >>> > updated? >>> > >>> >>> This should help: >>> https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers.git/commit/?id=4e6c48e0984e28d064ee8fbc292aee7b7920c507 >>> >>> > >>> > On Tue, Dec 30, 2014 at 3:30 PM, Emmanuel Grumbach >>> > wrote: >>> >> Hi, >>> >> >>> >> Sorry for the delay. This one got lost in my inbox. >>> >> >>> >> On Sat, Dec 27, 2014 at 4:03 PM, Gerlof Fokkema >>> >> wrote: >>> >>> Hi all, >>> >>> >>> >>> Since a few weeks I own a laptop with an Intel Wireless 7260 wireless >>> >>> adapter. >>> >>> I first noticed that my connection started dropping when I transferred >>> >>> large files over WiFi. >>> >>> Later on I noticed this problem when the signal strength was low as >>> >>> well. >>> >>> >>> >>> I seem to be experiencing the bug described here: >>> >>> https://bugzilla.kernel.org/show_bug.cgi?id=56581 >>> >> >>> >> This bug relates to dvm - which is de-facto another driver. We made >>> >> this work around because >>> >> of firmware issues. These issues aren't supposed to happen on devices >>> >> supported by iwlmvm. >>> >> Obviously, they do. You are not the only one to report this issue. >>> >> I will discuss it with our firmware team. >>> >> >>> >>> >>> >>> However, if I read the changelogs correctly, this should've been fixed >>> >>> in 3.17.3. >>> >>> >>> >>> Atttached you'll find dmesg.log with the error. >>> >>> Excerpt: >>> >>> [ 152.941067] iwlwifi :03:00.0: fail to flush all tx fifo queues Q >>> >>> 2 >>> >>> [ 152.941072] iwlwifi :03:00.0: Current SW read_ptr 209 write_ptr >>> >>> 234 >>> >>> [ 152.941097] iwl data: : 00 00 00 00 00 00 00 00 00 00 00 00 >>> >>> 00 00 00 00 >>> >>> [ 152.94] iwlwifi :03:00.0: FH TRBs(0) = 0x80003000 >>> >>> [ 152.941125] iwlwifi :03:00.0: FH TRBs(1) = 0xc01100f2 >>> >>> [ 152.941139] iwlwifi :03:00.0: FH TRBs(2) = 0x >>> >>> When I try reconnecting to WiFi I get dozens more of those errors. >>> >>> >>> >>> Can someone point me
Re: Throughput regression with `tcp: refine TSO autosizing`
On 3 February 2015 at 00:06, Eric Dumazet wrote: > On Mon, 2015-02-02 at 13:25 -0800, Ben Greear wrote: > >> It is a big throughput win to have fewer TCP ack packets on >> wireless since it is a half-duplex environment. Is there anything >> we could improve so that we can have fewer acks and still get >> good tcp stack behaviour? > > First apply TCP stretch ack fixes to the sender. There is no way to get > good performance if the sender does not handle stretch ack. > > d6b1a8a92a14 tcp: fix timing issue in CUBIC slope calculation > 9cd981dcf174 tcp: fix stretch ACK bugs in CUBIC > c22bdca94782 tcp: fix stretch ACK bugs in Reno > 814d488c6126 tcp: fix the timid additive increase on stretch ACKs > e73ebb0881ea tcp: stretch ACK fixes prep > > Then, make sure you do not throttle ACK too long, especially if you hope > to get Gbit line rate on a 4 ms RTT flow. > > GRO does not mean : send one ACK every ms, or after 3ms delay... I think it's worth pointing out that If you assume 3-frame A-MSDU and 64-frame A-MPDU you get 192 frames (as far as TCP/IP is concerned) per aggregation window. Assuming effective 600mbps throughput: python> 1.0/600/8)*1024*1024)/1500)/(3*64)) 0.003663003663003663 This is probably worst case, but still probably worth to keep in mind. ath10k has a knob to tune A-MSDU aggregation count. The default is "3" and it's what I've been testing so far. When I change it to "1" on sender I get 250->400mbps boost in TCP -P5 but see no difference with -P1 (number of flows). Changing it to "1" on receiver yields no difference. I can try adding this configuration permutation to my future tests if you're interested. So that you have an idea - using "1" on sender degrades UDP throughput (even 690->500mbps in some cases). Michał -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH] mwifiex: handle command response in aggregation
Hi James,
>From: qu...@laptop.org [mailto:qu...@laptop.org]
>Sent: 23 January 2015 12:46
>To: Amitkumar Karwar; Avinash Patil
>Cc: linux-wireless@vger.kernel.org
>Subject: [RFC PATCH] mwifiex: handle command response in aggregation
>
>Firmware does occasionally pass a command response to the host on the
>data port. Ensure it is processed.
>
>http://dev.laptop.org/ticket/12749
>---
>Seen on device firmwares:
>
> 14.66.9.p96
> 14.66.35.p52
>
>Others not tested.
>
> drivers/net/wireless/mwifiex/sdio.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/net/wireless/mwifiex/sdio.c
>b/drivers/net/wireless/mwifiex/sdio.c
>index 933dae1..8fe6147 100644
>--- a/drivers/net/wireless/mwifiex/sdio.c
>+++ b/drivers/net/wireless/mwifiex/sdio.c
>@@ -1240,8 +1240,7 @@ static int
>mwifiex_sdio_card_to_host_mp_aggr(struct mwifiex_adapter *adapter,
> /* copy pkt to deaggr buf */
> skb_deaggr = card->mpa_rx.skb_arr[pind];
>
>- if ((pkt_type == MWIFIEX_TYPE_DATA) && (pkt_len <=
>- card->mpa_rx.len_arr[pind])) {
>+ if (pkt_len <= card->mpa_rx.len_arr[pind]) {
>
> memcpy(skb_deaggr->data, curr_ptr, pkt_len);
>
>@@ -1251,7 +1250,7 @@ static int
>mwifiex_sdio_card_to_host_mp_aggr(struct mwifiex_adapter *adapter,
> mwifiex_decode_rx_packet(adapter, skb_deaggr,
>pkt_type);
> } else {
>- dev_err(adapter->dev, "wrong aggr pkt:"
>+ dev_err(adapter->dev, "bad aggr pkt:"
> " type=%d len=%d max_len=%d\n",
> pkt_type, pkt_len,
> card->mpa_rx.len_arr[pind]);
>--
>1.9.1
>
>
We checked with our firmware engineer. There is no possibility of receiving
command response on data port. Probably this is a corrupted data received on
SDIO. If possible, could you print this data and share log?
Regards,
Amit
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: broken URLs of iwlwifi firmware tarballs
On Mon, 2015-02-02 at 22:48 +0100, Vladimír Čunát wrote:
> Hello,
> the URLs to iwlwifi firmware tarballs are broken.
> https://wireless.wiki.kernel.org/en/users/Drivers/iwlwifi
>
> Is that a temporary problem? I could find no mirrors for some of the
> files. (Besides, I found that nixos.org isn't the only user of those URLs.)
This was a problem with the markup conversion for the new wiki engine -
the links were converted to [[filename]] (to link to pages) instead of
{{filename}} (to link to attachments)
I've fixed that now.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Throughput regression with `tcp: refine TSO autosizing`
On 2 February 2015 at 19:52, Eric Dumazet wrote:
> On Mon, 2015-02-02 at 11:27 +0100, Michal Kazior wrote:
>
>> While testing I've had my internal GRO patch for ath10k and no stretch
>> ack patches.
>
> Thanks for the data, I took a look at it.
>
> I am afraid this GRO patch might be the problem.
The entire performance drop happens without the GRO patch as well. I
tested with it included because I intended to upstream it later. I'll
run without it in future tests.
[...]
> Could you make again your experiments using upstream kernel (David
> Miller net tree) ?
Sure.
> You also could post the GRO patch so that we can comment on it.
(You probably want to see mac80211 patch as well:
06d181a8fd58031db9c114d920b40d8820380a6e "mac80211: add NAPI support
back")
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 36a8fcf..367e896 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1147,6 +1147,12 @@ err:
}
EXPORT_SYMBOL(ath10k_core_start);
+static int ath10k_core_napi_dummy_poll(struct napi_struct *napi, int budget)
+{
+ WARN_ON(1);
+ return 0;
+}
+
int ath10k_wait_for_suspend(struct ath10k *ar, u32 suspend_opt)
{
int ret;
@@ -1414,6 +1420,10 @@ struct ath10k *ath10k_core_create(size_t
priv_size, struct device *dev,
INIT_WORK(&ar->register_work, ath10k_core_register_work);
INIT_WORK(&ar->restart_work, ath10k_core_restart);
+ init_dummy_netdev(&ar->napi_dev);
+ ieee80211_napi_add(ar->hw, &ar->napi, &ar->napi_dev,
+ ath10k_core_napi_dummy_poll, 64);
+
ret = ath10k_debug_create(ar);
if (ret)
goto err_free_wq;
@@ -1434,6 +1444,7 @@ void ath10k_core_destroy(struct ath10k *ar)
{
flush_workqueue(ar->workqueue);
destroy_workqueue(ar->workqueue);
+ netif_napi_del(&ar->napi);
ath10k_debug_destroy(ar);
ath10k_mac_destroy(ar);
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 2d9f871..b5a8847 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -623,6 +623,9 @@ struct ath10k {
struct dfs_pattern_detector *dfs_detector;
+ struct net_device napi_dev;
+ struct napi_struct napi;
+
#ifdef CONFIG_ATH10K_DEBUGFS
struct ath10k_debug debug;
#endif
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index c1da44f..7e58b38 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2061,5 +2061,7 @@ static void ath10k_htt_txrx_compl_task(unsigned long ptr)
ath10k_htt_rx_in_ord_ind(ar, skb);
dev_kfree_skb_any(skb);
}
+
+ napi_gro_flush(&htt->ar->napi, false);
spin_unlock_bh(&htt->rx_ring.lock);
}
So that you can quickly get an understanding how ath10k Rx works:
first tasklet (not visible in the patch) picks up smallish event
buffers from firmware and puts them into ath10k queue for latter
processing by another tasklet (the last hunk). Each such event buffer
is just some metainfo but can "carry" tens of frames (both Rx and Tx
completions). The count is arbitrary and depends on fw/hw combo and
air conditions. The GRO flush is called after all queued small event
buffers are processed (frames delivered up to mac80211 which can in
turn perform aggregation reordering in case some frames were
re-transmitted in the meantime before handing them to net subsystem).
Michał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
