* Re: pull-request: iwlwifi-next 2017-11-03
From: Kalle Valo @ 2017-11-06 10:38 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <1509703364.4492.350.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> Here's the final set of patches intended for v4.15. It's not too
> important to get them into v4.15 if there is no time anymore. There
> are a few new PCI IDs that can be added in the rc series or stable
> (they need to go to other stable releases anyway). And there's also
> one bugfix that I could also send to rc. The rest are just cleanups,
> improvements or related to the A000 series. Let me know how it goes
> and I'll adapt if needed.
>
> I have sent this out before and kbuildbot reported success.
>
> Please let me know if there are any issues.
As you know we got one more week before the merge window starts, so I
should get this to v4.15.
> The following changes since commit e226fb5affccca98c405de80527180224d93d251:
>
> Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2017-11-02 19:48:25 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2017-11-03
>
> for you to fetch changes up to 57b36f7fcb39c5eae8c1f463699f747af69643ba:
>
> iwlwifi: add new cards for a000 series (2017-11-03 11:56:10 +0200)
>
> ----------------------------------------------------------------
> iwlwifi updates
>
> * Some new PCI IDs;
> * A bunch of cleanups;
> * The timers update by Kees;
> * Add more register dump call-sites;
> * A fix for a locking issue in the TX flush code;
> * Actual implementation of the TX flush code for A000;
> * An optimization to drop RX frames during restart to avoid BA issues;
>
> ----------------------------------------------------------------
> Emmanuel Grumbach (3):
> iwlwifi: mvm: rs: remove the ANT C from the toogle antenna logic
> iwlwifi: remove dead code for internal devices only
> iwlwifi: remove host assisted paging
>
> Ihab Zhaika (3):
> iwlwifi: add new cards for 8260 series
> iwlwifi: add new cards for 8265 series
> iwlwifi: add new cards for a000 series
>
> Kees Cook (1):
> iwlwifi: mvm: Convert timers to use timer_setup()
>
> Kirtika Ruchandani (1):
> iwlwifi: Add more call-sites for pcie reg dumper
>
> Liad Kaufman (1):
> iwlwifi: mvm: reset seq num after restart
>
> Luca Coelho (1):
> iwlwifi: mvm: hold mutex when flushing in iwl_mvm_flush_no_vif()
>
> Sara Sharon (6):
> iwlwifi: mvm: use RS macro instead of duplicating the code
> iwlwifi: mvm: cleanup references to aggregation count limit
> iwlwifi: mvm: improve latency when there is a reorder timeout
> iwlwifi: fix multi queue notification for a000 devices
> iwlwifi: mvm: refactor iwl_mvm_flush_no_vif
> iwlwifi: mvm: add missing implementation of flush for a000 devices
>
> Shahar S Matityahu (1):
> iwlwifi: drop RX frames during hardware restart
Pulled, thanks.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] brcmfmac: add support for external 32khz clock
From: Simon Shields @ 2017-11-06 10:29 UTC (permalink / raw)
To: devicetree
Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Kalle Valo
Some boards use an external 32khz clock for low-power
mode timing. Make sure the clock is powered on while the chipset
is active.
Signed-off-by: Simon Shields <simon@lineageos.org>
---
.../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 2 ++
drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h | 2 ++
drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c | 5 +++++
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 10 ++++++++++
4 files changed, 19 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
index b2bd4704f859..37add5e29272 100644
--- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
+++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
@@ -17,6 +17,8 @@ Optional properties:
When not specified the device will use in-band SDIO interrupts.
- interrupt-names : name of the out-of-band interrupt, which must be set
to "host-wake".
+ - clocks : external 32khz clock
+ - clock-names : name of the external 32khz clock, must be "32khz"
Example:
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
index a62f8e70b320..2e7fabae81d3 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
@@ -51,6 +51,7 @@ extern struct brcmf_mp_global_t brcmf_mp_global;
* @roamoff: Firmware roaming off?
* @ignore_probe_fail: Ignore probe failure.
* @country_codes: If available, pointer to struct for translating country codes
+ * @clk: External 32khz clock, if present.
* @bus: Bus specific platform data. Only SDIO at the mmoment.
*/
struct brcmf_mp_device {
@@ -60,6 +61,7 @@ struct brcmf_mp_device {
bool roamoff;
bool ignore_probe_fail;
struct brcmfmac_pd_cc *country_codes;
+ struct clk *clk;
union {
struct brcmfmac_sdio_pd sdio;
} bus;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
index aee6e5937c41..46f42a2c3d2b 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
@@ -13,6 +13,7 @@
* OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
+#include <linux/clk.h>
#include <linux/init.h>
#include <linux/of.h>
#include <linux/of_irq.h>
@@ -39,6 +40,10 @@ void brcmf_of_probe(struct device *dev, enum brcmf_bus_type bus_type,
if (of_property_read_u32(np, "brcm,drive-strength", &val) == 0)
sdio->drive_strength = val;
+ settings->clk = devm_clk_get(dev, "32khz");
+ if (IS_ERR(settings->clk))
+ settings->clk = NULL;
+
/* make sure there are interrupts defined in the node */
if (!of_find_property(np, "interrupts", NULL))
return;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 613caca7dc02..f4ceca6dbe74 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -14,6 +14,7 @@
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
+#include <linux/clk.h>
#include <linux/types.h>
#include <linux/atomic.h>
#include <linux/kernel.h>
@@ -3853,6 +3854,11 @@ brcmf_sdio_probe_attach(struct brcmf_sdio *bus)
brcmf_err("Failed to get device parameters\n");
goto fail;
}
+
+ /* enable external 32khz clock, if present */
+ if (sdiodev->settings->clk)
+ clk_prepare_enable(sdiodev->settings->clk);
+
/* platform specific configuration:
* alignments must be at least 4 bytes for ADMA
*/
@@ -4270,6 +4276,10 @@ void brcmf_sdio_remove(struct brcmf_sdio *bus)
}
brcmf_chip_detach(bus->ci);
}
+
+ if (bus->sdiodev->settings->clk)
+ clk_disable_unprepare(bus->sdiodev->settings->clk);
+
if (bus->sdiodev->settings)
brcmf_release_module_param(bus->sdiodev->settings);
--
2.15.0
^ permalink raw reply related
* Re: [PATCH] mac80211: Update last_ack status for all except probing frames
From: Johannes Berg @ 2017-11-06 10:29 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: linux-wireless, rmanohar
In-Reply-To: <1509409746-26592-1-git-send-email-rmanohar@qti.qualcomm.com>
On Mon, 2017-10-30 at 17:29 -0700, Rajkumar Manoharan wrote:
> Update last_ack status for all except station probing frames
> (i.e null data). Otherwise the station inactivity duration is
> cleared whenever AP is checking presence of idle stations by sending
> null data frame for every inactive threshold (ap_max_inactivity).
You make it sound like this is a problem, but don't explain why it
would be? I don't really see it anyway.
johannes
^ permalink raw reply
* Re: [PATCH] brcmfmac: add support for external 32khz clock
From: Kalle Valo @ 2017-11-06 9:42 UTC (permalink / raw)
To: Simon Shields
Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng
In-Reply-To: <20171104132421.GA1541@archbox.home>
Simon Shields <simon@lineageos.org> writes:
> Some boards use an external 32khz clock for low-power
> mode timing. Make sure the clock is powered on while the chipset
> is active.
>
> Signed-off-by: Simon Shields <simon@lineageos.org>
> ---
> .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 2 ++
For bindings changes I need an ack from device tree maintainers, so
please CC the device tree list.
--
Kalle Valo
^ permalink raw reply
* Re: ath10k: Fix reported HT MCS rates with NSS > 1
From: Sven Eckelmann @ 2017-11-06 9:02 UTC (permalink / raw)
To: Sebastian Gottschall; +Cc: Kalle Valo, ath10k, akolli, linux-wireless
In-Reply-To: <d27a10b1-6323-ebf0-5c2d-4a9c3b8d978d@dd-wrt.com>
[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]
On Montag, 6. November 2017 09:28:42 CET Sebastian Gottschall wrote:
> Am 06.11.2017 um 09:23 schrieb Sven Eckelmann:
> > On Sonntag, 5. November 2017 10:22:22 CET Sebastian Gottschall wrote:
> >> the assumption made in this patch is obviously wrong (at least for more
> >> recent firmwares and 9984)
> >> my log is flooded with messages like
> >> [208802.803537] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
> >> [208805.108515] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
> >> [208821.747621] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
> >> [208822.516599] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
> >> [208841.257780] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
[...]
> > This patch only splits WMI_RATE_PREAMBLE_HT & WMI_RATE_PREAMBLE_VHT. And for
> > WMI_RATE_PREAMBLE_HT (*not VHT*), it uses a slightly different approach. But
> > the WMI_RATE_PREAMBLE_VHT part (which you see in your logs) is basically
> > untouched.
>
> then a question follows up. is this check really neccessary?
Until we find out what the heck VHT MCS 15 should mean in this context - maybe.
But to the message - no, the message is most likely not necessary for each
received "invalid" peer tx stat.
Kind regards.
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v6] brcmfmac: add CLM download support
From: Arend van Spriel @ 2017-11-06 8:47 UTC (permalink / raw)
To: Wright Feng, franky.lin, hante.meuleman, kvalo, chi-hsien.lin
Cc: linux-wireless, brcm80211-dev-list.pdl, Chung-Hsien Hsu
In-Reply-To: <1507188678-24985-1-git-send-email-wright.feng@cypress.com>
On 10/5/2017 9:31 AM, Wright Feng wrote:
> From: Chung-Hsien Hsu <stanley.hsu@cypress.com>
>
> The firmware for brcmfmac devices includes information regarding
> regulatory constraints. For certain devices this information is kept
> separately in a binary form that needs to be downloaded to the device.
> This patch adds support to download this so-called CLM blob file. It
> uses the same naming scheme as the other firmware files with extension
> of .clm_blob.
>
> The CLM blob file is optional. If the file does not exist, the download
> process will be bypassed. It will not affect the driver loading.
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Chung-Hsien Hsu <stanley.hsu@cypress.com>
> ---
> v2: Revise commit message to describe in more detail
> v3: Add error handling in brcmf_c_get_clm_name function
> v4: Correct the length of dload_buf in brcmf_c_download function
> v5: Remove unnecessary cast and alignment
> v6: Add debug log for the case of no CLM file present
> ---
^ permalink raw reply
* Re: ath10k: Fix reported HT MCS rates with NSS > 1
From: Sebastian Gottschall @ 2017-11-06 8:28 UTC (permalink / raw)
To: Sven Eckelmann; +Cc: Kalle Valo, ath10k, akolli, linux-wireless
In-Reply-To: <1728147.6Xy77nSgBU@bentobox>
Am 06.11.2017 um 09:23 schrieb Sven Eckelmann:
> On Sonntag, 5. November 2017 10:22:22 CET Sebastian Gottschall wrote:
>> the assumption made in this patch is obviously wrong (at least for more
>> recent firmwares and 9984)
>> my log is flooded with messages like
>> [208802.803537] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
>> [208805.108515] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
>> [208821.747621] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
>> [208822.516599] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
>> [208841.257780] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
>>
>>
>> i tested this with the 10.4.3.5-0038 firmware which isnt official
>> published but made from athwlan.bin i got from qca chipcode
> Hm, yes there is most likely something wrong. But not sure whether this patch
> is actually the culprit. It looks to me like this would also be reported the
> same way without the patch. cec17c382140 ("ath10k: add per peer htt tx stats
> support for 10.4") seems to be your problem, right?
>
> This patch only splits WMI_RATE_PREAMBLE_HT & WMI_RATE_PREAMBLE_VHT. And for
> WMI_RATE_PREAMBLE_HT (*not VHT*), it uses a slightly different approach. But
> the WMI_RATE_PREAMBLE_VHT part (which you see in your logs) is basically
> untouched.
then a question follows up. is this check really neccessary?
Sebastian
>
> Kind regards,
> Sven
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
^ permalink raw reply
* Re: ath10k: Fix reported HT MCS rates with NSS > 1
From: Sven Eckelmann @ 2017-11-06 8:23 UTC (permalink / raw)
To: Sebastian Gottschall; +Cc: Kalle Valo, ath10k, akolli, linux-wireless
In-Reply-To: <94091927-c8a1-2918-749a-dc289686c268@dd-wrt.com>
[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]
On Sonntag, 5. November 2017 10:22:22 CET Sebastian Gottschall wrote:
> the assumption made in this patch is obviously wrong (at least for more
> recent firmwares and 9984)
> my log is flooded with messages like
> [208802.803537] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
> [208805.108515] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
> [208821.747621] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
> [208822.516599] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
> [208841.257780] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
>
>
> i tested this with the 10.4.3.5-0038 firmware which isnt official
> published but made from athwlan.bin i got from qca chipcode
Hm, yes there is most likely something wrong. But not sure whether this patch
is actually the culprit. It looks to me like this would also be reported the
same way without the patch. cec17c382140 ("ath10k: add per peer htt tx stats
support for 10.4") seems to be your problem, right?
This patch only splits WMI_RATE_PREAMBLE_HT & WMI_RATE_PREAMBLE_VHT. And for
WMI_RATE_PREAMBLE_HT (*not VHT*), it uses a slightly different approach. But
the WMI_RATE_PREAMBLE_VHT part (which you see in your logs) is basically
untouched.
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCHv2 2/2] ath10k: handle tdls peer events
From: mpubbise @ 2017-11-06 8:09 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Manikanta Pubbisetty
In-Reply-To: <1509955772-4941-1-git-send-email-mpubbise@qti.qualcomm.com>
From: Manikanta Pubbisetty <mpubbise@qti.qualcomm.com>
Handle tdls peer events from the target. TDLS events for the peer
could be discover, teardown, etc. As of now, adding the logic to
handle tdls teardown events alone.
Teardown due to peer traffic indication(PTR) timeout is one such
teardown event from the target.
Tested this change on QCA9888 with 10.4-3.5.1-00018 fw version.
Signed-off-by: Manikanta Pubbisetty <mpubbise@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/wmi.c | 72 +++++++++++++++++++++++++++++++++
1 file changed, 72 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index cad2e42..b6cbc02 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -29,6 +29,7 @@
#include "p2p.h"
#include "hw.h"
#include "hif.h"
+#include "txrx.h"
#define ATH10K_WMI_BARRIER_ECHO_ID 0xBA991E9
#define ATH10K_WMI_BARRIER_TIMEOUT_HZ (3 * HZ)
@@ -4456,6 +4457,74 @@ void ath10k_wmi_event_pdev_tpc_config(struct ath10k *ar, struct sk_buff *skb)
__le32_to_cpu(ev->rate_max));
}
+static void
+ath10k_wmi_handle_tdls_peer_event(struct ath10k *ar, struct sk_buff *skb)
+{
+ struct wmi_tdls_peer_event *ev;
+ struct ath10k_peer *peer;
+ struct ath10k_vif *arvif;
+ int vdev_id;
+ int peer_status;
+ int peer_reason;
+ u8 reason;
+
+ if (skb->len < sizeof(*ev)) {
+ ath10k_err(ar, "received tdls peer event with invalid size (%d bytes)\n",
+ skb->len);
+ return;
+ }
+
+ ev = (struct wmi_tdls_peer_event *)skb->data;
+ vdev_id = __le32_to_cpu(ev->vdev_id);
+ peer_status = __le32_to_cpu(ev->peer_status);
+ peer_reason = __le32_to_cpu(ev->peer_reason);
+
+ spin_lock_bh(&ar->data_lock);
+ peer = ath10k_peer_find(ar, vdev_id, ev->peer_macaddr.addr);
+ spin_unlock_bh(&ar->data_lock);
+
+ if (!peer) {
+ ath10k_warn(ar, "failed to find peer entry for %pM\n",
+ ev->peer_macaddr.addr);
+ return;
+ }
+
+ switch (peer_status) {
+ case WMI_TDLS_SHOULD_TEARDOWN:
+ switch (peer_reason) {
+ case WMI_TDLS_TEARDOWN_REASON_PTR_TIMEOUT:
+ case WMI_TDLS_TEARDOWN_REASON_NO_RESPONSE:
+ case WMI_TDLS_TEARDOWN_REASON_RSSI:
+ reason = WLAN_REASON_TDLS_TEARDOWN_UNREACHABLE;
+ break;
+ default:
+ reason = WLAN_REASON_TDLS_TEARDOWN_UNSPECIFIED;
+ break;
+ }
+
+ arvif = ath10k_get_arvif(ar, vdev_id);
+ if (!arvif) {
+ ath10k_warn(ar, "received tdls peer event for invalid vdev id %u\n",
+ vdev_id);
+ return;
+ }
+
+ ieee80211_tdls_oper_request(arvif->vif, ev->peer_macaddr.addr,
+ NL80211_TDLS_TEARDOWN, reason,
+ GFP_ATOMIC);
+
+ ath10k_dbg(ar, ATH10K_DBG_WMI,
+ "received tdls teardown event for peer %pM reason %u\n",
+ ev->peer_macaddr.addr, peer_reason);
+ break;
+ default:
+ ath10k_dbg(ar, ATH10K_DBG_WMI,
+ "received unknown tdls peer event %u\n",
+ peer_status);
+ break;
+ }
+}
+
void ath10k_wmi_event_pdev_ftm_intg(struct ath10k *ar, struct sk_buff *skb)
{
ath10k_dbg(ar, ATH10K_DBG_WMI, "WMI_PDEV_FTM_INTG_EVENTID\n");
@@ -5477,6 +5546,9 @@ static void ath10k_wmi_10_4_op_rx(struct ath10k *ar, struct sk_buff *skb)
case WMI_10_4_PDEV_TPC_CONFIG_EVENTID:
ath10k_wmi_event_pdev_tpc_config(ar, skb);
break;
+ case WMI_10_4_TDLS_PEER_EVENTID:
+ ath10k_wmi_handle_tdls_peer_event(ar, skb);
+ break;
default:
ath10k_warn(ar, "Unknown eventid: %d\n", id);
break;
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 1/2] ath10k: update tdls teardown state to target
From: mpubbise @ 2017-11-06 8:09 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Manikanta Pubbisetty
In-Reply-To: <1509955772-4941-1-git-send-email-mpubbise@qti.qualcomm.com>
From: Manikanta Pubbisetty <mpubbise@qti.qualcomm.com>
It is required to update the teardown state of the peer when
a tdls link with that peer is terminated. This information is
useful for the target to perform some cleanups wrt the tdls peer.
Without proper cleanup, target assumes that the peer is connected and
blocks future connection requests, updating the teardown state of the
peer addresses the problem.
Tested this change on QCA9888 with 10.4-3.5.1-00018 fw version.
Signed-off-by: Manikanta Pubbisetty <mpubbise@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 0a947ee..c6460e7 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6201,6 +6201,16 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
"mac vdev %d peer delete %pM sta %pK (sta gone)\n",
arvif->vdev_id, sta->addr, sta);
+ if (sta->tdls) {
+ ret = ath10k_mac_tdls_peer_update(ar, arvif->vdev_id,
+ sta,
+ WMI_TDLS_PEER_STATE_TEARDOWN);
+ if (ret)
+ ath10k_warn(ar, "failed to update tdls peer state for %pM state %d: %i\n",
+ sta->addr,
+ WMI_TDLS_PEER_STATE_TEARDOWN, ret);
+ }
+
ret = ath10k_peer_delete(ar, arvif->vdev_id, sta->addr);
if (ret)
ath10k_warn(ar, "failed to delete peer %pM for vdev %d: %i\n",
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 0/2] ath10k: more on tdls support for 10.4 firmwares
From: mpubbise @ 2017-11-06 8:09 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Manikanta Pubbisetty
From: Manikanta Pubbisetty <mpubbise@qti.qualcomm.com>
This patchset includes a bug fix and an enhancement of tdls functionality for 10.4 firmwares.
First patch in this series is a bug fix, second one is an enhancement.
Manikanta Pubbisetty (2):
ath10k: update tdls teardown state to target
ath10k: handle tdls peer events
v2:
- Corrected the warnings reported by ath10k-check
drivers/net/wireless/ath/ath10k/mac.c | 10 +++++
drivers/net/wireless/ath/ath10k/wmi.c | 72 +++++++++++++++++++++++++++++++++
2 files changed, 82 insertions(+)
--
1.7.9.5
^ permalink raw reply
* Re: Need support for Intel new wifi module 9462NGW
From: Luca Coelho @ 2017-11-06 7:22 UTC (permalink / raw)
To: Chris Chiu
Cc: johannes.berg, linuxwifi, linux-wireless, Linux Upstreaming Team
In-Reply-To: <CAB4CAwc43h5g+zLYd3hv=STELNGH+NEeQOMAXd-Gm0xj+TNuyA@mail.gmail.com>
On Mon, 2017-11-06 at 11:22 +0800, Chris Chiu wrote:
> Hi Luca,
Hi Chris,
> Any update for the firmware approval?
Yes, I published it last Thursday. Sorry, I was in such a hurry that I
forgot to tell you about it.
You can find it here:
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git/plain/iwlwifi-9260-th-b0-jf-b0-33.ucode?id=f132386b542b52ade0416ecb6cb7aef426f5d175
Let me know how it goes.
--
Cheers,
Luca.
^ permalink raw reply
* Re: rtl8821ae dbi read question
From: Nik Nyby @ 2017-11-06 4:09 UTC (permalink / raw)
To: Larry Finger, linux-wireless, pkshih
In-Reply-To: <702e4270-dcf3-5916-daee-f2265e0da907@lwfinger.net>
On 11/05/2017 09:09 PM, Larry Finger wrote:
> Disabling all of _rtl8821ae_enable_aspm_back_door() may not be wise. We
> tried that patch as part of debugging.
>
> That routine consists of two mdio r/w sequences, and 3 dbi r/w
> sequences. The third one of the latter is only used for RTL8812AE, thus
> it can be ignored.
>
> What happens if you try disabling those r/w pairs one at a time? It is
> possible that one, or more of them, should be disabled when aspm is
> zero.
I first tried disabling only the mdio sequences, then the dbi sequences.
I was able to reproduce my problem in both cases. But I have found that
my problem is resolved by only removing the enable_aspm() call, and
leaving the call to _rtl8821ae_enable_aspm_back_door() intact.
If removing rtlpriv->intf_ops->enable_aspm(hw) is the same as setting
aspm=0, then it's possible I'm not setting the option correctly. But as
far as I can see right now, removing enable_aspm() is necessary for my
stable connection.
> It should not matter whether the driver is built in, or loaded as
> a module. Please note that I never build that code in as I always want
> the option of refreshing the driver without rebooting.
Thanks for the info - I'll do the same.
^ permalink raw reply
* Re: Need support for Intel new wifi module 9462NGW
From: Chris Chiu @ 2017-11-06 3:22 UTC (permalink / raw)
To: Luca Coelho
Cc: johannes.berg, linuxwifi, linux-wireless, Linux Upstreaming Team
In-Reply-To: <1509434718.4492.195.camel@coelho.fi>
Hi Luca,
Any update for the firmware approval?
Chris
On Tue, Oct 31, 2017 at 3:25 PM, Luca Coelho <luca@coelho.fi> wrote:
> On Tue, 2017-10-31 at 12:13 +0800, Chris Chiu wrote:
>> Hi,
>
> Hi Chris,
>
>
>> We just have the Intel new WiFi module 9462NGW from Acer and
>> tried
>> to verify if it works on the latest linux kernel. Unfortunately it
>> seems not even detected because the PCI ID seems unknown to the
>> iwlwifi driver. Then I add the following line to
>> drivers/net/wireless/intel/iwlwifi/pcie/drv.c
>> iwl_hw_card_ids
>> {IWL_PCI_DEVICE(0x31DC, 0x02A4, iwl9460_2ac_cfg)},
>>
>> dmesg shows the following
>>
>> [ 12.994422] iwlwifi 0000:00:0c.0: Direct firmware load for
>> iwlwifi-9260-th-b0-jf-b0-33.ucode failed with error -2
>> [ 12.994442] iwlwifi 0000:00:0c.0: Direct firmware load for
>> iwlwifi-9260-th-b0-jf-b0-32.ucode failed with error -2
>> [ 12.994456] iwlwifi 0000:00:0c.0: Direct firmware load for
>> iwlwifi-9260-th-b0-jf-b0-31.ucode failed with error -2
>> [ 12.994470] iwlwifi 0000:00:0c.0: Direct firmware load for
>> iwlwifi-9260-th-b0-jf-b0-30.ucode failed with error -2
>> [ 12.994473] iwlwifi 0000:00:0c.0: no suitable firmware found!
>> [ 12.994477] iwlwifi 0000:00:0c.0: minimum version required:
>> iwlwifi-9260-th-b0-jf-b0-30
>> [ 12.994479] iwlwifi 0000:00:0c.0: maximum version supported:
>> iwlwifi-9260-th-b0-jf-b0-33
>>
>>
>>
>> I'm not able to find these missing files in linux-firmware.git and
>> any
>> other possible place. What's the status of supporting this 9462NGW?
>> Please let me know if any more information required. Thanks
>
> Unfortunately we have not published the firmware for this NIC yet.
> I'll try to get an approval to publish it today (or latest by the end
> of the week) and I'll let you know.
>
> --
> Cheers,
> Luca.
^ permalink raw reply
* Re: rtl8821ae dbi read question
From: Larry Finger @ 2017-11-06 2:09 UTC (permalink / raw)
To: Nik Nyby, linux-wireless, pkshih
In-Reply-To: <6912fa90-4b21-c325-993b-27fed3c75293@gnu.org>
On 11/05/2017 03:15 PM, Nik Nyby wrote:
> I also want to note that adding rtl8821ae.aspm=0 to my grub kernel boot command
> doesn't fix my problem. (I'm building this driver into the kernel, not as a
> module). My connection dropping problem is fixed only if I comment out the aspm
> init code in the driver, per this patch:
> https://patchwork.kernel.org/patch/9951511/
Disabling all of _rtl8821ae_enable_aspm_back_door() may not be wise. We tried
that patch as part of debugging.
That routine consists of two mdio r/w sequences, and 3 dbi r/w sequences. The
third one of the latter is only used for RTL8812AE, thus it can be ignored.
What happens if you try disabling those r/w pairs one at a time? It is possible
that one, or more of them, should be disabled when aspm is zero. It should not
matter whether the driver is built in, or loaded as a module. Please note that I
never build that code in as I always want the option of refreshing the driver
without rebooting.
Larry
^ permalink raw reply
* Re: rtl8821ae dbi read question
From: Larry Finger @ 2017-11-06 1:46 UTC (permalink / raw)
To: Nik Nyby, linux-wireless, pkshih
In-Reply-To: <6155a30b-ca6d-e27d-701e-9e1876a982ff@gnu.org>
On 11/05/2017 02:53 PM, Nik Nyby wrote:
> On 11/05/2017 11:50 AM, Larry Finger wrote:
>>
>> If you read the commit message for commit b8b8b16352cd, you will find that we
>> do not understand why using a byte read causes failure, but reverting the
>> change so that it is a word read made it function again. The "fix" was found
>> by a user doing bisection, and verified on my system, where the RTL8821AE has
>> stable connections. The transfer rates take wild swings, but the connection is
>> not dropped.
>>
>> If you NIC behaves differently, then you will need to help us debug the
>> problem. If you had a kernel that worked, then you might try bisection.
>
> I just tested on kernels 4.12 and 4.13 - my connection gets dropped on those
> kernels as well. Right now I'm using 4.14-rc7.
>
>> If that is not possible, you might try various combinations of module
>> parameters aspm, int_clear, and msi
> Thanks for these suggestions. Disabling ASPM solves my connection dropping
> issue! Previously, I was getting disconnected around 10 seconds after starting
> "git clone" on a large git repository. Now, I haven't seen the connection drop
> once.
>
> I can help debug the issue. I'm using a Lenovo Ideapad 320-15ABR laptop. Here's
> the lspci -vv info for my NIC:
>
> 01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821AE 802.11ac
> PCIe Wireless Network Adapter
> Subsystem: Lenovo RTL8821AE 802.11ac PCIe Wireless Network Adapter
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
> <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 32 bytes
> Interrupt: pin A routed to IRQ 33
> Region 0: I/O ports at 2000 [size=256]
> Region 2: Memory at f0b00000 (64-bit, non-prefetchable) [size=16K]
> Capabilities: <access denied>
> Kernel driver in use: rtl8821ae
If "aspm=0" fixes your issue, then there is nothing more to debug. That option
is there to handle cases where the PCI connection does not behave the way that
most do. This condition seems to be most common on Lenovo machines. Frequently,
ASPM problems are accompanied by PCI errors, but that seems not to be the case
for your machine. Create a suitable .conf file in /etc/modprobe.d/ and you
should be OK.
Larry
^ permalink raw reply
* Re: [PATCH] NFC: fdp: make struct nci_ops static
From: Samuel Ortiz @ 2017-11-06 0:06 UTC (permalink / raw)
To: Colin King
Cc: Andy Shevchenko, David S . Miller, Stephen Hemminger,
Johannes Berg, linux-wireless, kernel-janitors, linux-kernel
In-Reply-To: <20171005094712.28627-1-colin.king@canonical.com>
On Thu, Oct 05, 2017 at 10:47:12AM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The structure nci_ops is local to the source and does not need to
> be in global scope, so make it static.
>
> Cleans up sparse warning:
> symbol 'nci_ops' was not declared. Should it be static?
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/nfc/fdp/fdp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied as well, thanks.
Cheers,
Samuel.
^ permalink raw reply
* Re: [PATCH] nfc: s3fwrn5: make array match static const, reduces object code size
From: Samuel Ortiz @ 2017-11-06 0:03 UTC (permalink / raw)
To: Colin King
Cc: Robert Baldyga, Krzysztof Opasiak, linux-nfc, linux-wireless,
kernel-janitors, linux-kernel
In-Reply-To: <20170919142515.23196-1-colin.king@canonical.com>
Hi Colin,
On Tue, Sep 19, 2017 at 03:25:15PM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Don't populate the read-only array match on the stack, instead make
> it static const. Makes the object code smaller by over 310 bytes:
>
> Before:
> text data bss dec hex filename
> 8304 1084 128 9516 252c drivers/nfc/s3fwrn5/firmware.o
>
> After:
> text data bss dec hex filename
> 7894 1180 128 9202 23f2 drivers/nfc/s3fwrn5/firmware.o
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/nfc/s3fwrn5/firmware.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied to nfc-next, thanks.
Cheers,
Samuel.
^ permalink raw reply
* Re: [PATCH 0/8] constify nfc i2c_device_id
From: Samuel Ortiz @ 2017-11-06 0:00 UTC (permalink / raw)
To: Arvind Yadav
Cc: clement.perrochaud, charles.gorand, r.baldyga, k.opasiak, davem,
linux-kernel, linux-wireless
In-Reply-To: <1503335040-27101-1-git-send-email-arvind.yadav.cs@gmail.com>
Hi Arvind,
On Mon, Aug 21, 2017 at 10:33:52PM +0530, Arvind Yadav wrote:
> i2c_device_id are not supposed to change at runtime. All functions
> working with i2c_device_id provided by <linux/i2c.h> work with
> const i2c_device_id. So mark the non-const structs as const.
>
> Arvind Yadav (8):
> [PATCH 1/8] nfc: microread: constify i2c_device_id
> [PATCH 2/8] nfc: nfcmrvl: constify i2c_device_id
> [PATCH 3/8] nfc: nxp-nci: constify i2c_device_id
> [PATCH 4/8] nfc: pn533: constify i2c_device_id
> [PATCH 5/8] nfc: pn544: constify i2c_device_id
> [PATCH 6/8] nfc: s3fwrn5: constify i2c_device_id
> [PATCH 7/8] nfc: st-nci: constify i2c_device_id
> [PATCH 8/8] nfc: st21nfca: constify i2c_device_id
All 8 patches applied, thanks.
Cheers,
Samuel.
^ permalink raw reply
* Re: [PATCH] NFC: fix device-allocation error return
From: Samuel Ortiz @ 2017-11-05 23:54 UTC (permalink / raw)
To: Johan Hovold
Cc: David S. Miller, linux-wireless, netdev, Dan Carpenter, stable
In-Reply-To: <20170709110858.20331-1-johan@kernel.org>
Hi Johan,
On Sun, Jul 09, 2017 at 01:08:58PM +0200, Johan Hovold wrote:
> A recent change fixing NFC device allocation itself introduced an
> error-handling bug by returning an error pointer in case device-id
> allocation failed. This is clearly broken as the callers still expected
> NULL to be returned on errors as detected by Dan's static checker.
>
> Fix this up by returning NULL in the event that we've run out of memory
> when allocating a new device id.
>
> Note that the offending commit is marked for stable (3.8) so this fix
> needs to be backported along with it.
>
> Fixes: 20777bc57c34 ("NFC: fix broken device allocation")
> Cc: stable <stable@vger.kernel.org> # 3.8
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
> net/nfc/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks for the fix.
Cheers,
Samuel.
^ permalink raw reply
* Re: rtl8821ae dbi read question
From: James Cameron @ 2017-11-05 21:29 UTC (permalink / raw)
To: Nik Nyby; +Cc: Larry Finger, linux-wireless, pkshih
In-Reply-To: <6912fa90-4b21-c325-993b-27fed3c75293@gnu.org>
On Sun, Nov 05, 2017 at 04:15:36PM -0500, Nik Nyby wrote:
> I also want to note that adding rtl8821ae.aspm=0 to my grub kernel
> boot command doesn't fix my problem. (I'm building this driver into
> the kernel, not as a module). My connection dropping problem is
> fixed only if I comment out the aspm init code in the driver, per
> this patch:
> https://patchwork.kernel.org/patch/9951511/
Interesting; that patch was for testing, and did more than just aspm=0.
Check for a BIOS update from your vendor. Device registers can be
configured and persist despite warm reboot, which implies there is no
register reset in driver start or device reset, which further implies
that the BIOS can easily affect the outcome.
Check also for different behaviour after cold reboot; that is a power
down for 30 seconds then power up.
Do you yet have a known working kernel to bisect against?
--
James Cameron
http://quozl.netrek.org/
^ permalink raw reply
* Re: rtl8821ae dbi read question
From: Nik Nyby @ 2017-11-05 21:15 UTC (permalink / raw)
To: Larry Finger, linux-wireless, pkshih
In-Reply-To: <695fe947-7b0d-ef4b-5e90-ff503df6a08b@lwfinger.net>
I also want to note that adding rtl8821ae.aspm=0 to my grub kernel boot
command doesn't fix my problem. (I'm building this driver into the
kernel, not as a module). My connection dropping problem is fixed only
if I comment out the aspm init code in the driver, per this patch:
https://patchwork.kernel.org/patch/9951511/
^ permalink raw reply
* Re: rtl8821ae dbi read question
From: Nik Nyby @ 2017-11-05 20:53 UTC (permalink / raw)
To: Larry Finger, linux-wireless, pkshih
In-Reply-To: <695fe947-7b0d-ef4b-5e90-ff503df6a08b@lwfinger.net>
On 11/05/2017 11:50 AM, Larry Finger wrote:
>
> If you read the commit message for commit b8b8b16352cd, you will find
> that we do not understand why using a byte read causes failure, but
> reverting the change so that it is a word read made it function again.
> The "fix" was found by a user doing bisection, and verified on my
> system, where the RTL8821AE has stable connections. The transfer rates
> take wild swings, but the connection is not dropped.
>
> If you NIC behaves differently, then you will need to help us debug the
> problem. If you had a kernel that worked, then you might try bisection.
I just tested on kernels 4.12 and 4.13 - my connection gets dropped on
those kernels as well. Right now I'm using 4.14-rc7.
> If that is not possible, you might try various combinations of module
> parameters aspm, int_clear, and msi
Thanks for these suggestions. Disabling ASPM solves my connection
dropping issue! Previously, I was getting disconnected around 10 seconds
after starting "git clone" on a large git repository. Now, I haven't
seen the connection drop once.
I can help debug the issue. I'm using a Lenovo Ideapad 320-15ABR laptop.
Here's the lspci -vv info for my NIC:
01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821AE
802.11ac PCIe Wireless Network Adapter
Subsystem: Lenovo RTL8821AE 802.11ac PCIe Wireless Network Adapter
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 33
Region 0: I/O ports at 2000 [size=256]
Region 2: Memory at f0b00000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: rtl8821ae
^ permalink raw reply
* Re: rtl8821ae dbi read question
From: Larry Finger @ 2017-11-05 16:50 UTC (permalink / raw)
To: Nik Nyby, linux-wireless, pkshih
In-Reply-To: <d46763ef-14d1-a6fa-fb33-a0bd676ef056@gnu.org>
On 11/04/2017 06:27 PM, Nik Nyby wrote:
> In drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c, we have this function:
>
> static u8 _rtl8821ae_dbi_read(struct rtl_priv *rtlpriv, u16 addr)
> {
> u16 read_addr = addr & 0xfffc;
> u8 tmp = 0, count = 0, ret = 0;
>
> rtl_write_word(rtlpriv, REG_DBI_ADDR, read_addr);
> rtl_write_byte(rtlpriv, REG_DBI_FLAG, 0x2);
> tmp = rtl_read_byte(rtlpriv, REG_DBI_FLAG);
> count = 0;
> while (tmp && count < 20) {
> udelay(10);
> tmp = rtl_read_byte(rtlpriv, REG_DBI_FLAG);
> count++;
> }
> if (0 == tmp) {
> read_addr = REG_DBI_RDATA + addr % 4;
> ret = rtl_read_word(rtlpriv, read_addr);
> }
> return ret;
> }
>
> Near the end of the function, in this line:
>
> ret = rtl_read_word(rtlpriv, read_addr);
>
> rtl_read_word() returns a u16, but "ret" is declared as a u8. Is that a problem,
> or is this code correct?
>
> What's prompting this question is that I'm getting frequent disconnects from my
> access point with my rtl8821ae device. I've experienced this behavior both
> before and after the recent change to this function in commit
> b8b8b16352cd90c6083033fd4487f04fae935c18.
If you read the commit message for commit b8b8b16352cd, you will find that we do
not understand why using a byte read causes failure, but reverting the change so
that it is a word read made it function again. The "fix" was found by a user
doing bisection, and verified on my system, where the RTL8821AE has stable
connections. The transfer rates take wild swings, but the connection is not dropped.
If you NIC behaves differently, then you will need to help us debug the problem.
If you had a kernel that worked, then you might try bisection. If that is not
possible, you might try various combinations of module parameters aspm,
int_clear, and msi. Those parameters default to 1, so setting one or more of
them to zero is the test. Note, however, that changing any of these might cause
the system to fail, thus I recommend that you test changes dynamically with
modprobe, and not create a file in /etc/modprobe.d/ until you have verified that
changing one or more of these parameters actually helps. That will keep from
making your system unbootable.
Larry
^ permalink raw reply
* Re: ath10k: Fix reported HT MCS rates with NSS > 1
From: Sebastian Gottschall @ 2017-11-05 9:22 UTC (permalink / raw)
To: Kalle Valo, Sven Eckelmann; +Cc: ath10k, akolli, linux-wireless
In-Reply-To: <0a29ec25ec374a12adbc222af9a7dda1@euamsexm01a.eu.qualcomm.com>
the assumption made in this patch is obviously wrong (at least for more
recent firmwares and 9984)
my log is flooded with messages like
[208802.803537] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
[208805.108515] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
[208821.747621] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
[208822.516599] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
[208841.257780] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stats
i tested this with the 10.4.3.5-0038 firmware which isnt official
published but made from athwlan.bin i got from qca chipcode
Am 23.05.2017 um 17:28 schrieb Kalle Valo:
> Sven Eckelmann <sven.eckelmann@openmesh.com> wrote:
>> The QCA4019 firmware 10.4-3.2.1-00050 reports only HT MCS rates between
>> 0-9. But 802.11n MCS rates can be larger than that. For example a 2x2
>> device can send with up to MCS 15.
>>
>> The firmware encodes the higher MCS rates using the NSS field. The actual
>> calculation is not documented by QCA but it seems like the NSS field can be
>> mapped for HT rates to following MCS offsets:
>>
>> * NSS 1: 0
>> * NSS 2: 8
>> * NSS 3: 16
>> * NSS 4: 24
>>
>> This offset therefore has to be added for HT rates before they are stored
>> in the rate_info struct.
>>
>> Fixes: cec17c382140 ("ath10k: add per peer htt tx stats support for 10.4")
>> Signed-off-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
> Patch applied to ath-next branch of ath.git, thanks.
>
> c1dd8016ae02 ath10k: fix reported HT MCS rates with NSS > 1
>
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox