* [PATCH] brcmfmac: Use net_device_stats from struct net_device
From: Tobias Klauser @ 2017-02-13 10:14 UTC (permalink / raw)
To: arend.vanspriel, franky.lin, hante.meuleman, kvalo
Cc: linux-wireless, brcm80211-dev-list.pdl, netdev
Instead of using a private copy of struct net_device_stats in struct
brcm_if, use stats from struct net_device. Also remove the now
unnecessary .ndo_get_stats function.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
.../wireless/broadcom/brcm80211/brcmfmac/core.c | 26 +++++++---------------
.../wireless/broadcom/brcm80211/brcmfmac/core.h | 2 --
2 files changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index b73a55b00fa7..60da86a8d95b 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -249,10 +249,10 @@ static netdev_tx_t brcmf_netdev_start_xmit(struct sk_buff *skb,
done:
if (ret) {
- ifp->stats.tx_dropped++;
+ ndev->stats.tx_dropped++;
} else {
- ifp->stats.tx_packets++;
- ifp->stats.tx_bytes += skb->len;
+ ndev->stats.tx_packets++;
+ ndev->stats.tx_bytes += skb->len;
}
/* Return ok: we always eat the packet */
@@ -296,15 +296,15 @@ void brcmf_txflowblock(struct device *dev, bool state)
void brcmf_netif_rx(struct brcmf_if *ifp, struct sk_buff *skb)
{
if (skb->pkt_type == PACKET_MULTICAST)
- ifp->stats.multicast++;
+ ifp->ndev->stats.multicast++;
if (!(ifp->ndev->flags & IFF_UP)) {
brcmu_pkt_buf_free_skb(skb);
return;
}
- ifp->stats.rx_bytes += skb->len;
- ifp->stats.rx_packets++;
+ ifp->ndev->stats.rx_bytes += skb->len;
+ ifp->ndev->stats.rx_packets++;
brcmf_dbg(DATA, "rx proto=0x%X\n", ntohs(skb->protocol));
if (in_interrupt())
@@ -327,7 +327,7 @@ static int brcmf_rx_hdrpull(struct brcmf_pub *drvr, struct sk_buff *skb,
if (ret || !(*ifp) || !(*ifp)->ndev) {
if (ret != -ENODATA && *ifp)
- (*ifp)->stats.rx_errors++;
+ (*ifp)->ndev->stats.rx_errors++;
brcmu_pkt_buf_free_skb(skb);
return -ENODATA;
}
@@ -388,7 +388,7 @@ void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff *txp, bool success)
}
if (!success)
- ifp->stats.tx_errors++;
+ ifp->ndev->stats.tx_errors++;
brcmu_pkt_buf_free_skb(txp);
}
@@ -411,15 +411,6 @@ void brcmf_txcomplete(struct device *dev, struct sk_buff *txp, bool success)
}
}
-static struct net_device_stats *brcmf_netdev_get_stats(struct net_device *ndev)
-{
- struct brcmf_if *ifp = netdev_priv(ndev);
-
- brcmf_dbg(TRACE, "Enter, bsscfgidx=%d\n", ifp->bsscfgidx);
-
- return &ifp->stats;
-}
-
static void brcmf_ethtool_get_drvinfo(struct net_device *ndev,
struct ethtool_drvinfo *info)
{
@@ -492,7 +483,6 @@ static int brcmf_netdev_open(struct net_device *ndev)
static const struct net_device_ops brcmf_netdev_ops_pri = {
.ndo_open = brcmf_netdev_open,
.ndo_stop = brcmf_netdev_stop,
- .ndo_get_stats = brcmf_netdev_get_stats,
.ndo_start_xmit = brcmf_netdev_start_xmit,
.ndo_set_mac_address = brcmf_netdev_set_mac_address,
.ndo_set_rx_mode = brcmf_netdev_set_multicast_list
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
index de3197be5491..6aecd8dfd824 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
@@ -171,7 +171,6 @@ enum brcmf_netif_stop_reason {
* @drvr: points to device related information.
* @vif: points to cfg80211 specific interface information.
* @ndev: associated network device.
- * @stats: interface specific network statistics.
* @multicast_work: worker object for multicast provisioning.
* @ndoffload_work: worker object for neighbor discovery offload configuration.
* @fws_desc: interface specific firmware-signalling descriptor.
@@ -187,7 +186,6 @@ struct brcmf_if {
struct brcmf_pub *drvr;
struct brcmf_cfg80211_vif *vif;
struct net_device *ndev;
- struct net_device_stats stats;
struct work_struct multicast_work;
struct work_struct ndoffload_work;
struct brcmf_fws_mac_descriptor *fws_desc;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] rtl8xxxu: Add (0x2357 0x0107) to the tested devices list.
From: Kalle Valo @ 2017-02-13 9:18 UTC (permalink / raw)
To: Aaryn Coutanche; +Cc: jes.sorensen, linux-wireless
In-Reply-To: <1486814067-9874-1-git-send-email-aaryncoutanche@gmail.com>
Aaryn Coutanche <aaryncoutanche@gmail.com> writes:
> From: Aaryn Coutanche <aaryncoutanche@gmail.com>
>
> ---
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 3 +++
> 1 file changed, 3 insertions(+)
Signed-off-by is missing, please read Documentation/SubmittingPatches.
Also write a short commit log and document the device you used to test
this etc.
--
Kalle Valo
^ permalink raw reply
* Re: VHT 160Mhz and nss related config.
From: Johannes Berg @ 2017-02-13 7:06 UTC (permalink / raw)
To: Ben Greear, linux-wireless@vger.kernel.org, ath10k
In-Reply-To: <0082a9e3-83f3-9bc3-af43-b890b91cfd93@candelatech.com>
On Fri, 2017-02-10 at 14:58 -0800, Ben Greear wrote:
> So, it appears that the ath10k QCA9984 4x4 160Mhz chip can do 4x4
> MIMO at VHT80, but
> it can do only 2x2 MIMO at VHT160/80+80.
>
> When configuring a peer, we need to tell the firmware the number of
> spatial streams
> of the peer at VHT160 and at VHT80 and lower. They are not the same
> value.
>
> I cannot think of any standard way to get this information based on
> VHT capabilities and such. Currently, one could just assume VHT160
> NSS is 1/2 of the VHT80 NSS, but that is unlikely to be true for all
> vendors.
This was recently added to the VHT capabilities in the spec, see Table
9-250 in 802.11-2016.
johannes
^ permalink raw reply
* Re: [PATCH] Make EN2 pin optional in the TRF7970A driver
From: Heiko Schocher @ 2017-02-13 6:38 UTC (permalink / raw)
To: Rob Herring
Cc: netdev, Guan Ben, Mark Jonas, devicetree, linux-wireless,
linux-kernel, Samuel Ortiz, Lauro Ramos Venancio,
Aloisio Almeida Jr, Mark Rutland
In-Reply-To: <20170210155114.pvjahqqjqurw5jdc@rob-hp-laptop>
Hello Rob,
Am 10.02.2017 um 16:51 schrieb Rob Herring:
> On Tue, Feb 07, 2017 at 06:22:04AM +0100, Heiko Schocher wrote:
>> From: Guan Ben <ben.guan@cn.bosch.com>
>>
>> Make the EN2 pin optional. This is useful for boards,
>> which have this pin fix wired, for example to ground.
>>
>> Signed-off-by: Guan Ben <ben.guan@cn.bosch.com>
>> Signed-off-by: Mark Jonas <mark.jonas@de.bosch.com>
>> Signed-off-by: Heiko Schocher <hs@denx.de>
>>
>> ---
>>
>> .../devicetree/bindings/net/nfc/trf7970a.txt | 4 ++--
>> drivers/nfc/trf7970a.c | 26 ++++++++++++----------
>> 2 files changed, 16 insertions(+), 14 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
>> index 32b35a0..5889a3d 100644
>> --- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
>> +++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
>> @@ -5,8 +5,8 @@ Required properties:
>> - spi-max-frequency: Maximum SPI frequency (<= 2000000).
>> - interrupt-parent: phandle of parent interrupt handler.
>> - interrupts: A single interrupt specifier.
>> -- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on the
>> - TRF7970A.
>> +- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2' pins on the
>> + TRF7970A. EN2 is optional.
>
> Could EN ever be optional/fixed? If so, perhaps deprecate this property
> and do 2 properties, one for each pin.
The hardware I have has the EN2 pin fix connected to ground. Looking
into http://www.ti.com/lit/ds/slos743k/slos743k.pdf page 19 table 6-3
and 6-4 the EN2 pin is a don;t core if EN = 1. If EN = 0 EN2 pin
selects between Power Down and Sleep Mode ... I see no reason why
this is not possible/allowed ...
Hmm.. I do not like the idea of deprecating the "ti,enable-gpios"
property into 2 seperate properties ... but if this would be a reason
for not accepting this patch, I can do this ... How should I name
the 2 new properties?
"ti,pin-enable" and "ti,pin-enable2" ?
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: VHT 160Mhz and nss related config.
From: Sebastian Gottschall @ 2017-02-12 20:21 UTC (permalink / raw)
To: Ben Greear, Adrian Chadd; +Cc: linux-wireless@vger.kernel.org, ath10k
In-Reply-To: <f2982636-263f-d475-6b0b-85effc184ece@candelatech.com>
Am 12.02.2017 um 17:05 schrieb Ben Greear:
>
>
> On 02/12/2017 02:56 AM, Sebastian Gottschall wrote:
>> Am 11.02.2017 um 20:38 schrieb Ben Greear:
>>> On 02/11/2017 10:21 AM, Sebastian Gottschall wrote:
>>>> Am 11.02.2017 um 18:58 schrieb Ben Greear:
>>>>> On 02/10/2017 08:37 PM, Adrian Chadd wrote:
>>>>>> On 10 February 2017 at 20:22, Sebastian Gottschall
>>>>>> <s.gottschall@dd-wrt.com> wrote:
>>>>>>> i really can't believe this. if this is true the 160 mhz mode
>>>>>>> would not
>>>>>>> make any sense.
>>>>>>> the maximum tx / rx rate for 4x4 vht80 and 2x2 vht160 is
>>>>>>> identical. so
>>>>>>> vht160 would not increase performance in any way
>>>>>>
>>>>>> Well, if it can also do 2x2 MU-MIMO at 160MHz then it can be a
>>>>>> perfectly fine STA to a 4x4 160MHz MU-MIMO chip that can actually
>>>>>> transmit 2x2 rates to different MU-MIMO peers.
>>>>>>
>>>>>> That's the outstanding question I have - is it like, 2x2 MU only, or
>>>>>> is it say, 2 concurrently different spatial stream 2x2 MU? Ie,
>>>>>> can you
>>>>>> have 2 peers, different VHT spatial groups (or 4 peers, 1 spatial
>>>>>> group each) all going at the same time?
>>>>>>
>>>>>> I'm .. not even sure how you're supposed to cleanly negotiate
>>>>>> that you
>>>>>> can do 4NSS in VHT80 but 2NSS in VHT160 to a peer... that only makes
>>>>>> sense if you're doing lots of 1NSS and 2NSS MU-MIMO peers..
>>>>>
>>>>> I think using the max-rx-rate logic might could imply this, but I
>>>>> am not sure
>>>>> many drivers fill this out properly.
>>>>>
>>>>> Looks like a mess waiting to happen to me.
>>>>>
>>>>> Even if you can do 1x1 160Mhz MU-MIMO to two stations, and I am
>>>>> not certain you
>>>>> can since in 80Mhz you can only do a 1x1 and a 2x2 (not two 2x2).
>>>>>
>>>>> So, from what I know currently, 80+80 is not that useful on the
>>>>> 9984 NIC...
>>>> never tried 80+80 since i need to enhance the channel logic alot in
>>>> my firmware code to handle it. would be great enough if vht160
>>>> would work as expected and
>>>> i'm not sure right now if it really works, even if the interface
>>>> initialized correctly it assocs only with vht80
>>>
>>> 160Mhz is really implemented as 80+80 internally it seems, so what I
>>> meant is that
>>> 160Mhz or 80+80 both have the 2x2 restriction.
>> since i have a older fw source. can you give me a hint where you
>> found a indication that its just 2x2?
>
> Look for:
>
> MAX_SPATIAL_STREAMS_SUPPORTED_AT_160MHZ
your findings where correct. frustrating.
>
> Thanks,
> Ben
>
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Berliner Ring 101, 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: [PATCH] ath9k: clean up and fix ath_tx_count_airtime
From: Toke Høiland-Jørgensen @ 2017-02-12 18:13 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Kalle Valo, linux-wireless
In-Reply-To: <e8a1dd5f-79a2-28b4-6cc7-fc1b28a6f327@nbd.name>
Felix Fietkau <nbd@nbd.name> writes:
> On 2017-02-12 17:36, Toke H=C3=B8iland-J=C3=B8rgensen wrote:
>> Felix Fietkau <nbd@nbd.name> writes:
>>=20
>>> On 2017-02-12 17:28, Kalle Valo wrote:
>>>> Felix Fietkau <nbd@nbd.name> writes:
>>>>=20
>>>>> On 2017-02-12 16:22, Toke H=C3=B8iland-J=C3=B8rgensen wrote:
>>>>>> Felix Fietkau <nbd@nbd.name> writes:
>>>>>>=20
>>>>>>> ath_tx_count_airtime is doing a lot of unnecessary work:
>>>>>>>
>>>>>>> - Redundant station lookup
>>>>>>> - Redundant rcu_read_lock/unlock
>>>>>>> - Useless memcpy of bf->rates
>>>>>>> - Useless NULL check of bf->bf_mpdu
>>>>>>> - Redundant lookup of the skb tid
>>>>>>>
>>>>>>> Additionally, it tries to look up the mac80211 queue index from the=
txq,
>>>>>>> which fails if the frame was delivered via the power save queue.
>>>>=20
>>>> What does this mean in practise, what's the user level impact?
>>>>=20
>>>>>>> This patch fixes all of these issues by passing down the right set =
of
>>>>>>> pointers instead of doing extra work
>>>>>>>
>>>>>>> Cc: stable@vger.kernel.org
>>>>>>> Fixes: 63fefa050477 ("ath9k: Introduce airtime fairness scheduling
>>>>>>> between stations")
>>>>>>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>>>>>>=20
>>>>>> Not sure if there's anything for stable to do with this; don't think=
the
>>>>>> airtime fairness code has gone into a release yet? Otherwise:
>>>>>>=20
>>>>>> Acked-by: Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk>
>>>>>
>>>>> I added this, because I'm not sure this patch will make it to 4.10 in
>>>>> time, since we're really close to a release. I assume this patch will
>>>>> probably go into 4.11.
>>>>=20
>>>> Yeah, to try to get a patch to 4.10 at this point needs to be a really
>>>> high profile regression. That is if Linus doesn't release 4.10 today, =
of
>>>> course.
>>> The symptoms are kernel crashes at least when operating in AP mode.
>>> It's pretty severe, so getting it into 4.10 would be preferable.
>>=20
>> I'm confused now. Wasn't the airtime fairness patch queued for 4.11?
> I'll check again, maybe I got the git-describe output wrong.
$ git describe --contains 63fefa050477
wireless-drivers-next-for-davem-2017-01-02~2^2~14
So I think we're good as long as this gets into the 4.11 cycle :)
-Toke
^ permalink raw reply
* Re: [PATCH] ath9k: clean up and fix ath_tx_count_airtime
From: Felix Fietkau @ 2017-02-12 16:40 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: Kalle Valo, linux-wireless
In-Reply-To: <87efz35pt4.fsf@alrua-karlstad>
On 2017-02-12 17:36, Toke Høiland-Jørgensen wrote:
> Felix Fietkau <nbd@nbd.name> writes:
>
>> On 2017-02-12 17:28, Kalle Valo wrote:
>>> Felix Fietkau <nbd@nbd.name> writes:
>>>
>>>> On 2017-02-12 16:22, Toke Høiland-Jørgensen wrote:
>>>>> Felix Fietkau <nbd@nbd.name> writes:
>>>>>
>>>>>> ath_tx_count_airtime is doing a lot of unnecessary work:
>>>>>>
>>>>>> - Redundant station lookup
>>>>>> - Redundant rcu_read_lock/unlock
>>>>>> - Useless memcpy of bf->rates
>>>>>> - Useless NULL check of bf->bf_mpdu
>>>>>> - Redundant lookup of the skb tid
>>>>>>
>>>>>> Additionally, it tries to look up the mac80211 queue index from the txq,
>>>>>> which fails if the frame was delivered via the power save queue.
>>>
>>> What does this mean in practise, what's the user level impact?
>>>
>>>>>> This patch fixes all of these issues by passing down the right set of
>>>>>> pointers instead of doing extra work
>>>>>>
>>>>>> Cc: stable@vger.kernel.org
>>>>>> Fixes: 63fefa050477 ("ath9k: Introduce airtime fairness scheduling
>>>>>> between stations")
>>>>>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>>>>>
>>>>> Not sure if there's anything for stable to do with this; don't think the
>>>>> airtime fairness code has gone into a release yet? Otherwise:
>>>>>
>>>>> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
>>>>
>>>> I added this, because I'm not sure this patch will make it to 4.10 in
>>>> time, since we're really close to a release. I assume this patch will
>>>> probably go into 4.11.
>>>
>>> Yeah, to try to get a patch to 4.10 at this point needs to be a really
>>> high profile regression. That is if Linus doesn't release 4.10 today, of
>>> course.
>> The symptoms are kernel crashes at least when operating in AP mode.
>> It's pretty severe, so getting it into 4.10 would be preferable.
>
> I'm confused now. Wasn't the airtime fairness patch queued for 4.11?
I'll check again, maybe I got the git-describe output wrong.
- Felix
^ permalink raw reply
* Re: [PATCH] ath9k: clean up and fix ath_tx_count_airtime
From: Toke Høiland-Jørgensen @ 2017-02-12 16:36 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Kalle Valo, linux-wireless
In-Reply-To: <61049ab3-a15e-b1cf-ca1d-4840a8aa35d9@nbd.name>
Felix Fietkau <nbd@nbd.name> writes:
> On 2017-02-12 17:28, Kalle Valo wrote:
>> Felix Fietkau <nbd@nbd.name> writes:
>>=20
>>> On 2017-02-12 16:22, Toke H=C3=B8iland-J=C3=B8rgensen wrote:
>>>> Felix Fietkau <nbd@nbd.name> writes:
>>>>=20
>>>>> ath_tx_count_airtime is doing a lot of unnecessary work:
>>>>>
>>>>> - Redundant station lookup
>>>>> - Redundant rcu_read_lock/unlock
>>>>> - Useless memcpy of bf->rates
>>>>> - Useless NULL check of bf->bf_mpdu
>>>>> - Redundant lookup of the skb tid
>>>>>
>>>>> Additionally, it tries to look up the mac80211 queue index from the t=
xq,
>>>>> which fails if the frame was delivered via the power save queue.
>>=20
>> What does this mean in practise, what's the user level impact?
>>=20
>>>>> This patch fixes all of these issues by passing down the right set of
>>>>> pointers instead of doing extra work
>>>>>
>>>>> Cc: stable@vger.kernel.org
>>>>> Fixes: 63fefa050477 ("ath9k: Introduce airtime fairness scheduling
>>>>> between stations")
>>>>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>>>>=20
>>>> Not sure if there's anything for stable to do with this; don't think t=
he
>>>> airtime fairness code has gone into a release yet? Otherwise:
>>>>=20
>>>> Acked-by: Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk>
>>>
>>> I added this, because I'm not sure this patch will make it to 4.10 in
>>> time, since we're really close to a release. I assume this patch will
>>> probably go into 4.11.
>>=20
>> Yeah, to try to get a patch to 4.10 at this point needs to be a really
>> high profile regression. That is if Linus doesn't release 4.10 today, of
>> course.
> The symptoms are kernel crashes at least when operating in AP mode.
> It's pretty severe, so getting it into 4.10 would be preferable.
I'm confused now. Wasn't the airtime fairness patch queued for 4.11?
-Toke
^ permalink raw reply
* Re: [PATCH] ath9k: clean up and fix ath_tx_count_airtime
From: Felix Fietkau @ 2017-02-12 16:32 UTC (permalink / raw)
To: Kalle Valo; +Cc: Toke Høiland-Jørgensen, linux-wireless
In-Reply-To: <87d1entltw.fsf@kamboji.qca.qualcomm.com>
On 2017-02-12 17:28, Kalle Valo wrote:
> Felix Fietkau <nbd@nbd.name> writes:
>
>> On 2017-02-12 16:22, Toke Høiland-Jørgensen wrote:
>>> Felix Fietkau <nbd@nbd.name> writes:
>>>
>>>> ath_tx_count_airtime is doing a lot of unnecessary work:
>>>>
>>>> - Redundant station lookup
>>>> - Redundant rcu_read_lock/unlock
>>>> - Useless memcpy of bf->rates
>>>> - Useless NULL check of bf->bf_mpdu
>>>> - Redundant lookup of the skb tid
>>>>
>>>> Additionally, it tries to look up the mac80211 queue index from the txq,
>>>> which fails if the frame was delivered via the power save queue.
>
> What does this mean in practise, what's the user level impact?
>
>>>> This patch fixes all of these issues by passing down the right set of
>>>> pointers instead of doing extra work
>>>>
>>>> Cc: stable@vger.kernel.org
>>>> Fixes: 63fefa050477 ("ath9k: Introduce airtime fairness scheduling
>>>> between stations")
>>>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>>>
>>> Not sure if there's anything for stable to do with this; don't think the
>>> airtime fairness code has gone into a release yet? Otherwise:
>>>
>>> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
>>
>> I added this, because I'm not sure this patch will make it to 4.10 in
>> time, since we're really close to a release. I assume this patch will
>> probably go into 4.11.
>
> Yeah, to try to get a patch to 4.10 at this point needs to be a really
> high profile regression. That is if Linus doesn't release 4.10 today, of
> course.
The symptoms are kernel crashes at least when operating in AP mode.
It's pretty severe, so getting it into 4.10 would be preferable.
- Felix
^ permalink raw reply
* Re: [PATCH] ath9k: clean up and fix ath_tx_count_airtime
From: Kalle Valo @ 2017-02-12 16:28 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Toke Høiland-Jørgensen, linux-wireless
In-Reply-To: <fbda67b4-7db6-984a-af50-610ec25d2fe0@nbd.name>
Felix Fietkau <nbd@nbd.name> writes:
> On 2017-02-12 16:22, Toke H=C3=B8iland-J=C3=B8rgensen wrote:
>> Felix Fietkau <nbd@nbd.name> writes:
>>=20
>>> ath_tx_count_airtime is doing a lot of unnecessary work:
>>>
>>> - Redundant station lookup
>>> - Redundant rcu_read_lock/unlock
>>> - Useless memcpy of bf->rates
>>> - Useless NULL check of bf->bf_mpdu
>>> - Redundant lookup of the skb tid
>>>
>>> Additionally, it tries to look up the mac80211 queue index from the txq,
>>> which fails if the frame was delivered via the power save queue.
What does this mean in practise, what's the user level impact?
>>> This patch fixes all of these issues by passing down the right set of
>>> pointers instead of doing extra work
>>>
>>> Cc: stable@vger.kernel.org
>>> Fixes: 63fefa050477 ("ath9k: Introduce airtime fairness scheduling
>>> between stations")
>>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>>=20
>> Not sure if there's anything for stable to do with this; don't think the
>> airtime fairness code has gone into a release yet? Otherwise:
>>=20
>> Acked-by: Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk>
>
> I added this, because I'm not sure this patch will make it to 4.10 in
> time, since we're really close to a release. I assume this patch will
> probably go into 4.11.
Yeah, to try to get a patch to 4.10 at this point needs to be a really
high profile regression. That is if Linus doesn't release 4.10 today, of
course.
--=20
Kalle Valo
^ permalink raw reply
* Re: VHT 160Mhz and nss related config.
From: Ben Greear @ 2017-02-12 16:05 UTC (permalink / raw)
To: Sebastian Gottschall, Adrian Chadd; +Cc: linux-wireless@vger.kernel.org, ath10k
In-Reply-To: <159ba156-cf2d-db0d-a6af-2557b9bfa6b6@dd-wrt.com>
On 02/12/2017 02:56 AM, Sebastian Gottschall wrote:
> Am 11.02.2017 um 20:38 schrieb Ben Greear:
>> On 02/11/2017 10:21 AM, Sebastian Gottschall wrote:
>>> Am 11.02.2017 um 18:58 schrieb Ben Greear:
>>>> On 02/10/2017 08:37 PM, Adrian Chadd wrote:
>>>>> On 10 February 2017 at 20:22, Sebastian Gottschall
>>>>> <s.gottschall@dd-wrt.com> wrote:
>>>>>> i really can't believe this. if this is true the 160 mhz mode would not
>>>>>> make any sense.
>>>>>> the maximum tx / rx rate for 4x4 vht80 and 2x2 vht160 is identical. so
>>>>>> vht160 would not increase performance in any way
>>>>>
>>>>> Well, if it can also do 2x2 MU-MIMO at 160MHz then it can be a
>>>>> perfectly fine STA to a 4x4 160MHz MU-MIMO chip that can actually
>>>>> transmit 2x2 rates to different MU-MIMO peers.
>>>>>
>>>>> That's the outstanding question I have - is it like, 2x2 MU only, or
>>>>> is it say, 2 concurrently different spatial stream 2x2 MU? Ie, can you
>>>>> have 2 peers, different VHT spatial groups (or 4 peers, 1 spatial
>>>>> group each) all going at the same time?
>>>>>
>>>>> I'm .. not even sure how you're supposed to cleanly negotiate that you
>>>>> can do 4NSS in VHT80 but 2NSS in VHT160 to a peer... that only makes
>>>>> sense if you're doing lots of 1NSS and 2NSS MU-MIMO peers..
>>>>
>>>> I think using the max-rx-rate logic might could imply this, but I am not sure
>>>> many drivers fill this out properly.
>>>>
>>>> Looks like a mess waiting to happen to me.
>>>>
>>>> Even if you can do 1x1 160Mhz MU-MIMO to two stations, and I am not certain you
>>>> can since in 80Mhz you can only do a 1x1 and a 2x2 (not two 2x2).
>>>>
>>>> So, from what I know currently, 80+80 is not that useful on the 9984 NIC...
>>> never tried 80+80 since i need to enhance the channel logic alot in my firmware code to handle it. would be great enough if vht160 would work as expected and
>>> i'm not sure right now if it really works, even if the interface initialized correctly it assocs only with vht80
>>
>> 160Mhz is really implemented as 80+80 internally it seems, so what I meant is that
>> 160Mhz or 80+80 both have the 2x2 restriction.
> since i have a older fw source. can you give me a hint where you found a indication that its just 2x2?
Look for:
MAX_SPATIAL_STREAMS_SUPPORTED_AT_160MHZ
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] ath9k: clean up and fix ath_tx_count_airtime
From: Felix Fietkau @ 2017-02-12 15:54 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: linux-wireless, kvalo
In-Reply-To: <87lgtb5t9h.fsf@alrua-karlstad>
On 2017-02-12 16:22, Toke Høiland-Jørgensen wrote:
> Felix Fietkau <nbd@nbd.name> writes:
>
>> ath_tx_count_airtime is doing a lot of unnecessary work:
>>
>> - Redundant station lookup
>> - Redundant rcu_read_lock/unlock
>> - Useless memcpy of bf->rates
>> - Useless NULL check of bf->bf_mpdu
>> - Redundant lookup of the skb tid
>>
>> Additionally, it tries to look up the mac80211 queue index from the txq,
>> which fails if the frame was delivered via the power save queue.
>>
>> This patch fixes all of these issues by passing down the right set of
>> pointers instead of doing extra work
>>
>> Cc: stable@vger.kernel.org
>> Fixes: 63fefa050477 ("ath9k: Introduce airtime fairness scheduling between stations")
>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>
> Not sure if there's anything for stable to do with this; don't think the
> airtime fairness code has gone into a release yet? Otherwise:
>
> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
I added this, because I'm not sure this patch will make it to 4.10 in
time, since we're really close to a release. I assume this patch will
probably go into 4.11.
- Felix
^ permalink raw reply
* Re: [PATCH] ath9k: clean up and fix ath_tx_count_airtime
From: Toke Høiland-Jørgensen @ 2017-02-12 15:22 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, kvalo
In-Reply-To: <20170212132931.43510-1-nbd@nbd.name>
Felix Fietkau <nbd@nbd.name> writes:
> ath_tx_count_airtime is doing a lot of unnecessary work:
>
> - Redundant station lookup
> - Redundant rcu_read_lock/unlock
> - Useless memcpy of bf->rates
> - Useless NULL check of bf->bf_mpdu
> - Redundant lookup of the skb tid
>
> Additionally, it tries to look up the mac80211 queue index from the txq,
> which fails if the frame was delivered via the power save queue.
>
> This patch fixes all of these issues by passing down the right set of
> pointers instead of doing extra work
>
> Cc: stable@vger.kernel.org
> Fixes: 63fefa050477 ("ath9k: Introduce airtime fairness scheduling betwee=
n stations")
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Not sure if there's anything for stable to do with this; don't think the
airtime fairness code has gone into a release yet? Otherwise:
Acked-by: Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk>
-Toke
^ permalink raw reply
* [PATCH] ath9k: clean up and fix ath_tx_count_airtime
From: Felix Fietkau @ 2017-02-12 13:29 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, toke
ath_tx_count_airtime is doing a lot of unnecessary work:
- Redundant station lookup
- Redundant rcu_read_lock/unlock
- Useless memcpy of bf->rates
- Useless NULL check of bf->bf_mpdu
- Redundant lookup of the skb tid
Additionally, it tries to look up the mac80211 queue index from the txq,
which fails if the frame was delivered via the power save queue.
This patch fixes all of these issues by passing down the right set of
pointers instead of doing extra work
Cc: stable@vger.kernel.org
Fixes: 63fefa050477 ("ath9k: Introduce airtime fairness scheduling between stations")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/ath/ath9k/xmit.c | 52 +++++++++++------------------------
1 file changed, 16 insertions(+), 36 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 8f9a87915ba9..30efe79e9d89 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -723,51 +723,31 @@ static bool bf_is_ampdu_not_probing(struct ath_buf *bf)
return bf_isampdu(bf) && !(info->flags & IEEE80211_TX_CTL_RATE_CTRL_PROBE);
}
-static void ath_tx_count_airtime(struct ath_softc *sc, struct ath_txq *txq,
- struct ath_buf *bf, struct ath_tx_status *ts)
+static void ath_tx_count_airtime(struct ath_softc *sc, struct ath_node *an,
+ struct ath_atx_tid *tid, struct ath_buf *bf,
+ struct ath_tx_status *ts)
{
- struct ath_node *an;
- struct ath_acq *acq = &sc->cur_chan->acq[txq->mac80211_qnum];
- struct sk_buff *skb;
- struct ieee80211_hdr *hdr;
- struct ieee80211_hw *hw = sc->hw;
- struct ieee80211_tx_rate rates[4];
- struct ieee80211_sta *sta;
- int i;
+ struct ath_txq *txq = tid->txq;
u32 airtime = 0;
-
- skb = bf->bf_mpdu;
- if(!skb)
- return;
-
- hdr = (struct ieee80211_hdr *)skb->data;
- memcpy(rates, bf->rates, sizeof(rates));
-
- rcu_read_lock();
-
- sta = ieee80211_find_sta_by_ifaddr(hw, hdr->addr1, hdr->addr2);
- if(!sta)
- goto exit;
-
-
- an = (struct ath_node *) sta->drv_priv;
+ int i;
airtime += ts->duration * (ts->ts_longretry + 1);
+ for(i = 0; i < ts->ts_rateindex; i++) {
+ int rate_dur = ath9k_hw_get_duration(sc->sc_ah, bf->bf_desc, i);
+ airtime += rate_dur * bf->rates[i].count;
+ }
- for(i=0; i < ts->ts_rateindex; i++)
- airtime += ath9k_hw_get_duration(sc->sc_ah, bf->bf_desc, i) * rates[i].count;
+ if (sc->airtime_flags & AIRTIME_USE_TX) {
+ int q = txq->mac80211_qnum;
+ struct ath_acq *acq = &sc->cur_chan->acq[q];
- if (!!(sc->airtime_flags & AIRTIME_USE_TX)) {
spin_lock_bh(&acq->lock);
- an->airtime_deficit[txq->mac80211_qnum] -= airtime;
- if (an->airtime_deficit[txq->mac80211_qnum] <= 0)
- __ath_tx_queue_tid(sc, ath_get_skb_tid(sc, an, skb));
+ an->airtime_deficit[q] -= airtime;
+ if (an->airtime_deficit[q] <= 0)
+ __ath_tx_queue_tid(sc, tid);
spin_unlock_bh(&acq->lock);
}
ath_debug_airtime(sc, an, 0, airtime);
-
-exit:
- rcu_read_unlock();
}
static void ath_tx_process_buffer(struct ath_softc *sc, struct ath_txq *txq,
@@ -791,13 +771,13 @@ static void ath_tx_process_buffer(struct ath_softc *sc, struct ath_txq *txq,
ts->duration = ath9k_hw_get_duration(sc->sc_ah, bf->bf_desc,
ts->ts_rateindex);
- ath_tx_count_airtime(sc, txq, bf, ts);
hdr = (struct ieee80211_hdr *) bf->bf_mpdu->data;
sta = ieee80211_find_sta_by_ifaddr(hw, hdr->addr1, hdr->addr2);
if (sta) {
struct ath_node *an = (struct ath_node *)sta->drv_priv;
tid = ath_get_skb_tid(sc, an, bf->bf_mpdu);
+ ath_tx_count_airtime(sc, an, tid, bf, ts);
if (ts->ts_status & (ATH9K_TXERR_FILT | ATH9K_TXERR_XRETRY))
tid->clear_ps_filter = true;
}
--
2.11.0
^ permalink raw reply related
* Re: VHT 160Mhz and nss related config.
From: Sebastian Gottschall @ 2017-02-12 10:56 UTC (permalink / raw)
To: Ben Greear, Adrian Chadd; +Cc: linux-wireless@vger.kernel.org, ath10k
In-Reply-To: <02b7f70a-7da2-f2e4-8904-bdffc3ca90a1@candelatech.com>
Am 11.02.2017 um 20:38 schrieb Ben Greear:
> On 02/11/2017 10:21 AM, Sebastian Gottschall wrote:
>> Am 11.02.2017 um 18:58 schrieb Ben Greear:
>>> On 02/10/2017 08:37 PM, Adrian Chadd wrote:
>>>> On 10 February 2017 at 20:22, Sebastian Gottschall
>>>> <s.gottschall@dd-wrt.com> wrote:
>>>>> i really can't believe this. if this is true the 160 mhz mode
>>>>> would not
>>>>> make any sense.
>>>>> the maximum tx / rx rate for 4x4 vht80 and 2x2 vht160 is
>>>>> identical. so
>>>>> vht160 would not increase performance in any way
>>>>
>>>> Well, if it can also do 2x2 MU-MIMO at 160MHz then it can be a
>>>> perfectly fine STA to a 4x4 160MHz MU-MIMO chip that can actually
>>>> transmit 2x2 rates to different MU-MIMO peers.
>>>>
>>>> That's the outstanding question I have - is it like, 2x2 MU only, or
>>>> is it say, 2 concurrently different spatial stream 2x2 MU? Ie, can you
>>>> have 2 peers, different VHT spatial groups (or 4 peers, 1 spatial
>>>> group each) all going at the same time?
>>>>
>>>> I'm .. not even sure how you're supposed to cleanly negotiate that you
>>>> can do 4NSS in VHT80 but 2NSS in VHT160 to a peer... that only makes
>>>> sense if you're doing lots of 1NSS and 2NSS MU-MIMO peers..
>>>
>>> I think using the max-rx-rate logic might could imply this, but I am
>>> not sure
>>> many drivers fill this out properly.
>>>
>>> Looks like a mess waiting to happen to me.
>>>
>>> Even if you can do 1x1 160Mhz MU-MIMO to two stations, and I am not
>>> certain you
>>> can since in 80Mhz you can only do a 1x1 and a 2x2 (not two 2x2).
>>>
>>> So, from what I know currently, 80+80 is not that useful on the 9984
>>> NIC...
>> never tried 80+80 since i need to enhance the channel logic alot in
>> my firmware code to handle it. would be great enough if vht160 would
>> work as expected and
>> i'm not sure right now if it really works, even if the interface
>> initialized correctly it assocs only with vht80
>
> 160Mhz is really implemented as 80+80 internally it seems, so what I
> meant is that
> 160Mhz or 80+80 both have the 2x2 restriction.
since i have a older fw source. can you give me a hint where you found a
indication that its just 2x2?
>
> Stock ath10k driver doesn't set the rxnss_override, so the chip will
> always be forced
> to send 1x1 at 160Mhz, so even if it associates and works at all, it
> will probably not put
> many 160Mhz frames on air since the rate-ctrl should choose 3x3 or 4x4
> 80Mhz as faster speeds.
sounds logic
>
> Thanks,
> Ben
>
>
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Berliner Ring 101, 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
* [PATCH 3/3] rtlwifi: btcoexist: Fix if == else warnings in halbtc8723b1ant.c
From: Larry Finger @ 2017-02-12 0:46 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Larry Finger, Julia Lawall
In-Reply-To: <20170212004605.1308-1-Larry.Finger@lwfinger.net>
The 0-DAY kernel test infrastructure reports the following:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c:1875:2-4: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c:2253:3-5: WARNING: possible condition with no effect (if == else)
Reported-by: kbuild-all@01.org
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Julia Lawall <julia.lawall@lip6.fr>
---
.../realtek/rtlwifi/btcoexist/halbtc8723b1ant.c | 24 ++++------------------
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
index e9f0a76..d67bbfb 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
@@ -1872,16 +1872,8 @@ static void halbtc8723b1ant_action_wifi_connected_bt_acl_busy(
}
} else if (bt_link_info->hid_exist &&
bt_link_info->a2dp_exist) { /*HID+A2DP */
- if ((bt_rssi_state == BTC_RSSI_STATE_HIGH) ||
- (bt_rssi_state == BTC_RSSI_STATE_STAY_HIGH)) {
- halbtc8723b1ant_ps_tdma(btcoexist, NORMAL_EXEC,
- true, 14);
- coex_dm->auto_tdma_adjust = false;
- } else { /*for low BT RSSI*/
- halbtc8723b1ant_ps_tdma(btcoexist, NORMAL_EXEC,
- true, 14);
- coex_dm->auto_tdma_adjust = false;
- }
+ halbtc8723b1ant_ps_tdma(btcoexist, NORMAL_EXEC, true, 14);
+ coex_dm->auto_tdma_adjust = false;
halbtc8723b1ant_coex_table_with_type(btcoexist, NORMAL_EXEC, 6);
/*PAN(OPP,FTP), HID+PAN(OPP,FTP) */
@@ -2250,16 +2242,8 @@ static void halbtc8723b1ant_run_coexist_mechanism(struct btc_coexist *btcoexist)
wifi_rssi_state =
halbtc8723b1ant_wifi_rssi_state(btcoexist,
1, 2, 30, 0);
- if ((wifi_rssi_state == BTC_RSSI_STATE_HIGH) ||
- (wifi_rssi_state == BTC_RSSI_STATE_STAY_HIGH)) {
- halbtc8723b1ant_limited_tx(btcoexist,
- NORMAL_EXEC,
- 1, 1, 1, 1);
- } else {
- halbtc8723b1ant_limited_tx(btcoexist,
- NORMAL_EXEC,
- 1, 1, 1, 1);
- }
+ halbtc8723b1ant_limited_tx(btcoexist,
+ NORMAL_EXEC, 1, 1, 1, 1);
} else {
halbtc8723b1ant_limited_tx(btcoexist, NORMAL_EXEC,
0, 0, 0, 0);
--
2.10.2
^ permalink raw reply related
* [PATCH 2/3] rtlwifi: btcoexist: Fix if == else warnings in halbtc8821a1ant.c
From: Larry Finger @ 2017-02-12 0:46 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Larry Finger, Julia Lawall
In-Reply-To: <20170212004605.1308-1-Larry.Finger@lwfinger.net>
The 0-DAY kernel test infrastructure reports the following:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c:1771:1-3: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c:2126:3-5: WARNING: possible condition with no effect (if == else)
Reported-by: kbuild-all@01.org
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Julia Lawall <julia.lawall@lip6.fr>
---
.../realtek/rtlwifi/btcoexist/halbtc8821a1ant.c | 18 +++---------------
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c
index 20562f0..8b689ed 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c
@@ -1768,11 +1768,7 @@ static void btc8821a1ant_act_bt_sco_hid_only_busy(struct btc_coexist *btcoexist,
/* tdma and coex table*/
halbtc8821a1ant_ps_tdma(btcoexist, NORMAL_EXEC, true, 5);
- if (BT_8821A_1ANT_WIFI_STATUS_NON_CONNECTED_ASSO_AUTH_SCAN ==
- wifi_status)
- halbtc8821a1ant_coex_table_with_type(btcoexist, NORMAL_EXEC, 1);
- else
- halbtc8821a1ant_coex_table_with_type(btcoexist, NORMAL_EXEC, 1);
+ halbtc8821a1ant_coex_table_with_type(btcoexist, NORMAL_EXEC, 1);
}
static void btc8821a1ant_act_wifi_con_bt_acl_busy(struct btc_coexist *btcoexist,
@@ -2123,16 +2119,8 @@ static void halbtc8821a1ant_run_coexist_mechanism(struct btc_coexist *btcoexist)
wifi_rssi_state =
halbtc8821a1ant_WifiRssiState(btcoexist, 1, 2,
30, 0);
- if ((wifi_rssi_state == BTC_RSSI_STATE_HIGH) ||
- (wifi_rssi_state == BTC_RSSI_STATE_STAY_HIGH)) {
- halbtc8821a1ant_limited_tx(btcoexist,
- NORMAL_EXEC, 1, 1,
- 1, 1);
- } else {
- halbtc8821a1ant_limited_tx(btcoexist,
- NORMAL_EXEC, 1, 1,
- 1, 1);
- }
+ halbtc8821a1ant_limited_tx(btcoexist,
+ NORMAL_EXEC, 1, 1, 1, 1);
} else {
halbtc8821a1ant_limited_tx(btcoexist, NORMAL_EXEC,
0, 0, 0, 0);
--
2.10.2
^ permalink raw reply related
* [PATCH 1/3] rtlwifi: btcoexist: Fix if == else warnings in halbtc8821a2ant.c
From: Larry Finger @ 2017-02-12 0:46 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Larry Finger, Julia Lawall
In-Reply-To: <20170212004605.1308-1-Larry.Finger@lwfinger.net>
The 0-DAY kernel test infrastructure reports the following:
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3023:1-3: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3035:2-4: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3037:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3047:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3075:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3085:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3129:1-3: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3141:2-4: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3143:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3153:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3179:2-4: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3181:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3192:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2677:1-3: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2833:1-3: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2847:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2857:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2885:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2895:3-5: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2940:1-3: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2788:2-4: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2391:2-4: WARNING: possible condition with no effect (if == else)
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2417:2-4: WARNING: possible condition with no effect (if == else)
Reported-by: kbuild-all@01.org
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Julia Lawall <julia.lawall@lip6.fr>
---
.../realtek/rtlwifi/btcoexist/halbtc8821a2ant.c | 185 +++------------------
1 file changed, 24 insertions(+), 161 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
index b5daa48..1717e9c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
@@ -2388,14 +2388,8 @@ static void halbtc8821a2ant_action_sco(struct btc_coexist *btcoexist)
* halbtc8821a2ant_ps_tdma(btcoexist, NORMAL_EXEC, true, 5);
*/
- if ((bt_rssi_state == BTC_RSSI_STATE_HIGH) ||
- (bt_rssi_state == BTC_RSSI_STATE_STAY_HIGH)) {
- halbtc8821a2ant_ps_tdma(btcoexist, NORMAL_EXEC,
- false, 0); /*for voice quality*/
- } else {
- halbtc8821a2ant_ps_tdma(btcoexist, NORMAL_EXEC,
- false, 0); /*for voice quality*/
- }
+ halbtc8821a2ant_ps_tdma(btcoexist, NORMAL_EXEC,
+ false, 0); /*for voice quality*/
/* sw mechanism */
if ((wifi_rssi_state == BTC_RSSI_STATE_HIGH) ||
@@ -2785,14 +2779,7 @@ static void halbtc8821a2ant_action_pan_hs(struct btc_coexist *btcoexist)
NORMAL_EXEC, false);
}
- if ((bt_rssi_state == BTC_RSSI_STATE_HIGH) ||
- (bt_rssi_state == BTC_RSSI_STATE_STAY_HIGH)) {
- halbtc8821a2ant_ps_tdma(btcoexist, NORMAL_EXEC,
- false, 1);
- } else {
- halbtc8821a2ant_ps_tdma(btcoexist, NORMAL_EXEC,
- false, 1);
- }
+ halbtc8821a2ant_ps_tdma(btcoexist, NORMAL_EXEC, false, 1);
/* sw mechanism */
if ((wifi_rssi_state == BTC_RSSI_STATE_HIGH) ||
@@ -2830,40 +2817,18 @@ static void halbtc8821a2ant_action_pan_edr_a2dp(struct btc_coexist *btcoexist)
btcoexist->btc_get(btcoexist, BTC_GET_U4_WIFI_BW, &wifi_bw);
- if (BTC_WIFI_BW_LEGACY == wifi_bw) {
- /* for HID at 11b/g mode */
- halbtc8821a2ant_coex_table(btcoexist, NORMAL_EXEC, 0x55ff55ff,
- 0x5afa5afa, 0xffff, 0x3);
- } else {
- /* for HID quality & wifi performance balance at 11n mode */
- halbtc8821a2ant_coex_table(btcoexist, NORMAL_EXEC, 0x55ff55ff,
- 0x5afa5afa, 0xffff, 0x3);
- }
+ halbtc8821a2ant_coex_table(btcoexist, NORMAL_EXEC, 0x55ff55ff,
+ 0x5afa5afa, 0xffff, 0x3);
if (BTC_WIFI_BW_HT40 == wifi_bw) {
/* fw mechanism */
if ((bt_rssi_state == BTC_RSSI_STATE_HIGH) ||
- (bt_rssi_state == BTC_RSSI_STATE_STAY_HIGH)) {
- if (bt_info_ext&BIT0) {
- /* a2dp basic rate */
- btc8821a2ant_tdma_dur_adj(btcoexist, false,
- false, 3);
- } else {
- /* a2dp edr rate */
- btc8821a2ant_tdma_dur_adj(btcoexist, false,
- false, 3);
- }
- } else {
- if (bt_info_ext&BIT0) {
- /* a2dp basic rate */
- btc8821a2ant_tdma_dur_adj(btcoexist, false,
- true, 3);
- } else {
- /* a2dp edr rate */
- btc8821a2ant_tdma_dur_adj(btcoexist, false,
- true, 3);
- }
- }
+ (bt_rssi_state == BTC_RSSI_STATE_STAY_HIGH))
+ btc8821a2ant_tdma_dur_adj(btcoexist, false,
+ false, 3);
+ else
+ btc8821a2ant_tdma_dur_adj(btcoexist, false,
+ true, 3);
/* sw mechanism */
if ((wifi_rssi_state == BTC_RSSI_STATE_HIGH) ||
@@ -2881,27 +2846,10 @@ static void halbtc8821a2ant_action_pan_edr_a2dp(struct btc_coexist *btcoexist)
} else {
/* fw mechanism */
if ((bt_rssi_state == BTC_RSSI_STATE_HIGH) ||
- (bt_rssi_state == BTC_RSSI_STATE_STAY_HIGH)) {
- if (bt_info_ext&BIT0) {
- /* a2dp basic rate */
- btc8821a2ant_tdma_dur_adj(btcoexist, false,
- false, 3);
- } else {
- /* a2dp edr rate */
- btc8821a2ant_tdma_dur_adj(btcoexist, false,
- false, 3);
- }
- } else {
- if (bt_info_ext&BIT0) {
- /* a2dp basic rate */
- btc8821a2ant_tdma_dur_adj(btcoexist, false,
- true, 3);
- } else {
- /* a2dp edr rate */
- btc8821a2ant_tdma_dur_adj(btcoexist, false,
- true, 3);
- }
- }
+ (bt_rssi_state == BTC_RSSI_STATE_STAY_HIGH))
+ btc8821a2ant_tdma_dur_adj(btcoexist, false, false, 3);
+ else
+ btc8821a2ant_tdma_dur_adj(btcoexist, false, true, 3);
/* sw mechanism */
if ((wifi_rssi_state == BTC_RSSI_STATE_HIGH) ||
@@ -2937,15 +2885,8 @@ static void halbtc8821a2ant_action_pan_edr_hid(struct btc_coexist *btcoexist)
btcoexist->btc_get(btcoexist, BTC_GET_U4_WIFI_BW, &wifi_bw);
- if (BTC_WIFI_BW_LEGACY == wifi_bw) {
- /* for HID at 11b/g mode */
- halbtc8821a2ant_coex_table(btcoexist, NORMAL_EXEC, 0x55ff55ff,
- 0x5a5f5a5f, 0xffff, 0x3);
- } else {
- /* for HID quality & wifi performance balance at 11n mode */
- halbtc8821a2ant_coex_table(btcoexist, NORMAL_EXEC, 0x55ff55ff,
- 0x5a5f5a5f, 0xffff, 0x3);
- }
+ halbtc8821a2ant_coex_table(btcoexist, NORMAL_EXEC, 0x55ff55ff,
+ 0x5a5f5a5f, 0xffff, 0x3);
if (BTC_WIFI_BW_HT40 == wifi_bw) {
halbtc8821a2ant_fw_dac_swing_lvl(btcoexist, NORMAL_EXEC, 3);
@@ -3020,40 +2961,12 @@ static void btc8821a2ant_act_hid_a2dp_pan_edr(struct btc_coexist *btcoexist)
btcoexist->btc_get(btcoexist, BTC_GET_U4_WIFI_BW, &wifi_bw);
- if (BTC_WIFI_BW_LEGACY == wifi_bw) {
- /* for HID at 11b/g mode */
- halbtc8821a2ant_coex_table(btcoexist, NORMAL_EXEC, 0x55ff55ff,
- 0x5a5a5a5a, 0xffff, 0x3);
- } else {
- /* for HID quality & wifi performance balance at 11n mode */
- halbtc8821a2ant_coex_table(btcoexist, NORMAL_EXEC, 0x55ff55ff,
- 0x5a5a5a5a, 0xffff, 0x3);
- }
+ halbtc8821a2ant_coex_table(btcoexist, NORMAL_EXEC, 0x55ff55ff,
+ 0x5a5a5a5a, 0xffff, 0x3);
if (BTC_WIFI_BW_HT40 == wifi_bw) {
/* fw mechanism */
- if ((bt_rssi_state == BTC_RSSI_STATE_HIGH) ||
- (bt_rssi_state == BTC_RSSI_STATE_STAY_HIGH)) {
- if (bt_info_ext&BIT0) {
- /* a2dp basic rate */
- btc8821a2ant_tdma_dur_adj(btcoexist, true,
- true, 3);
- } else {
- /* a2dp edr rate */
- btc8821a2ant_tdma_dur_adj(btcoexist, true,
- true, 3);
- }
- } else {
- if (bt_info_ext&BIT0) {
- /* a2dp basic rate */
- btc8821a2ant_tdma_dur_adj(btcoexist, true,
- true, 3);
- } else {
- /* a2dp edr rate */
- btc8821a2ant_tdma_dur_adj(btcoexist, true,
- true, 3);
- }
- }
+ btc8821a2ant_tdma_dur_adj(btcoexist, true, true, 3);
/* sw mechanism */
if ((wifi_rssi_state == BTC_RSSI_STATE_HIGH) ||
@@ -3126,40 +3039,12 @@ static void halbtc8821a2ant_action_hid_a2dp(struct btc_coexist *btcoexist)
btcoexist->btc_get(btcoexist, BTC_GET_U4_WIFI_BW, &wifi_bw);
- if (BTC_WIFI_BW_LEGACY == wifi_bw) {
- /* for HID at 11b/g mode */
- halbtc8821a2ant_coex_table(btcoexist, NORMAL_EXEC, 0x55ff55ff,
- 0x5f5b5f5b, 0xffffff, 0x3);
- } else {
- /*for HID quality & wifi performance balance at 11n mode*/
- halbtc8821a2ant_coex_table(btcoexist, NORMAL_EXEC, 0x55ff55ff,
- 0x5f5b5f5b, 0xffffff, 0x3);
- }
+ halbtc8821a2ant_coex_table(btcoexist, NORMAL_EXEC, 0x55ff55ff,
+ 0x5f5b5f5b, 0xffffff, 0x3);
if (BTC_WIFI_BW_HT40 == wifi_bw) {
/* fw mechanism */
- if ((bt_rssi_state == BTC_RSSI_STATE_HIGH) ||
- (bt_rssi_state == BTC_RSSI_STATE_STAY_HIGH)) {
- if (bt_info_ext&BIT0) {
- /* a2dp basic rate */
- btc8821a2ant_tdma_dur_adj(btcoexist,
- true, true, 2);
- } else {
- /* a2dp edr rate */
- btc8821a2ant_tdma_dur_adj(btcoexist,
- true, true, 2);
- }
- } else {
- if (bt_info_ext&BIT0) {
- /* a2dp basic rate */
- btc8821a2ant_tdma_dur_adj(btcoexist,
- true, true, 2);
- } else {
- /* a2dp edr rate */
- btc8821a2ant_tdma_dur_adj(btcoexist,
- true, true, 2);
- }
- }
+ btc8821a2ant_tdma_dur_adj(btcoexist, true, true, 2);
/* sw mechanism */
if ((wifi_rssi_state == BTC_RSSI_STATE_HIGH) ||
@@ -3176,29 +3061,7 @@ static void halbtc8821a2ant_action_hid_a2dp(struct btc_coexist *btcoexist)
}
} else {
/* fw mechanism */
- if ((bt_rssi_state == BTC_RSSI_STATE_HIGH) ||
- (bt_rssi_state == BTC_RSSI_STATE_STAY_HIGH)) {
- if (bt_info_ext&BIT0) {
- /* a2dp basic rate */
- btc8821a2ant_tdma_dur_adj(btcoexist,
- true, true, 2);
-
- } else {
- /* a2dp edr rate */
- btc8821a2ant_tdma_dur_adj(btcoexist,
- true, true, 2);
- }
- } else {
- if (bt_info_ext&BIT0) {
- /*a2dp basic rate*/
- btc8821a2ant_tdma_dur_adj(btcoexist,
- true, true, 2);
- } else {
- /*a2dp edr rate*/
- btc8821a2ant_tdma_dur_adj(btcoexist,
- true, true, 2);
- }
- }
+ btc8821a2ant_tdma_dur_adj(btcoexist, true, true, 2);
/* sw mechanism */
if ((wifi_rssi_state == BTC_RSSI_STATE_HIGH) ||
--
2.10.2
^ permalink raw reply related
* [PATCH 0/3] rtlwifi: btcoexist: Fix if == else warnings
From: Larry Finger @ 2017-02-12 0:46 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Larry Finger, Julia Lawall
The 0-DAY kernel test infrastructure reports several warnings where the
code in an if block is exactly the same as that of the else block.
These instances are simplified.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Larry Finger (3):
rtlwifi: btcoexist: Fix if == else warnings in halbtc8821a2ant.c
rtlwifi: btcoexist: Fix if == else warnings in halbtc8821a1ant.c
rtlwifi: btcoexist: Fix if == else warnings in halbtc8723b1ant.c
.../realtek/rtlwifi/btcoexist/halbtc8723b1ant.c | 24 +--
.../realtek/rtlwifi/btcoexist/halbtc8821a1ant.c | 18 +-
.../realtek/rtlwifi/btcoexist/halbtc8821a2ant.c | 185 +++------------------
3 files changed, 31 insertions(+), 196 deletions(-)
--
2.10.2
^ permalink raw reply
* Re: [PATCH v3] ath10k: add support for controlling tx power to a station
From: kbuild test robot @ 2017-02-12 0:17 UTC (permalink / raw)
To: Ashok Raj Nagarajan
Cc: kbuild-all, ath10k, linux-wireless, arnagara, Ashok Raj Nagarajan
In-Reply-To: <1486555117-25196-1-git-send-email-arnagara@qti.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]
Hi Ashok,
[auto build test ERROR on v4.9-rc8]
[cannot apply to ath6kl/ath-next next-20170210]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ashok-Raj-Nagarajan/ath10k-add-support-for-controlling-tx-power-to-a-station/20170208-203305
config: x86_64-randconfig-in0-02120025 (attached as .config)
compiler: gcc-4.6 (Debian 4.6.4-7) 4.6.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_sta_set_txpwr':
>> drivers/net/wireless/ath/ath10k/mac.c:5900:10: error: 'struct ieee80211_sta' has no member named 'txpwr'
drivers/net/wireless/ath/ath10k/mac.c: At top level:
>> drivers/net/wireless/ath/ath10k/mac.c:7469:2: error: unknown field 'sta_set_txpwr' specified in initializer
drivers/net/wireless/ath/ath10k/mac.c:7469:2: warning: initialization from incompatible pointer type [enabled by default]
drivers/net/wireless/ath/ath10k/mac.c:7469:2: warning: (near initialization for 'ath10k_ops.sta_pre_rcu_remove') [enabled by default]
drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_mac_register':
>> drivers/net/wireless/ath/ath10k/mac.c:8008:11: error: 'NL80211_EXT_FEATURE_STA_TX_PWR' undeclared (first use in this function)
drivers/net/wireless/ath/ath10k/mac.c:8008:11: note: each undeclared identifier is reported only once for each function it appears in
vim +5900 drivers/net/wireless/ath/ath10k/mac.c
5894 {
5895 struct ath10k *ar = hw->priv;
5896 struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
5897 int ret = 0;
5898 u16 txpwr;
5899
> 5900 txpwr = MBM_TO_DBM(sta->txpwr);
5901
5902 mutex_lock(&ar->conf_mutex);
5903
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28657 bytes --]
^ permalink raw reply
* Re: [PATCH v3] ath10k: add support for controlling tx power to a station
From: kbuild test robot @ 2017-02-12 0:04 UTC (permalink / raw)
To: Ashok Raj Nagarajan
Cc: kbuild-all, ath10k, linux-wireless, arnagara, Ashok Raj Nagarajan
In-Reply-To: <1486555117-25196-1-git-send-email-arnagara@qti.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 2569 bytes --]
Hi Ashok,
[auto build test ERROR on v4.9-rc8]
[cannot apply to ath6kl/ath-next next-20170210]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ashok-Raj-Nagarajan/ath10k-add-support-for-controlling-tx-power-to-a-station/20170208-203305
config: i386-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_sta_set_txpwr':
drivers/net/wireless/ath/ath10k/mac.c:5900:15: error: 'struct ieee80211_sta' has no member named 'txpwr'
txpwr = MBM_TO_DBM(sta->txpwr);
^~
drivers/net/wireless/ath/ath10k/mac.c: At top level:
drivers/net/wireless/ath/ath10k/mac.c:7469:2: error: unknown field 'sta_set_txpwr' specified in initializer
.sta_set_txpwr = ath10k_sta_set_txpwr,
^
>> drivers/net/wireless/ath/ath10k/mac.c:7469:19: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.sta_set_txpwr = ath10k_sta_set_txpwr,
^~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/ath/ath10k/mac.c:7469:19: note: (near initialization for 'ath10k_ops.sta_pre_rcu_remove')
drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_mac_register':
drivers/net/wireless/ath/ath10k/mac.c:8008:11: error: 'NL80211_EXT_FEATURE_STA_TX_PWR' undeclared (first use in this function)
NL80211_EXT_FEATURE_STA_TX_PWR);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/ath/ath10k/mac.c:8008:11: note: each undeclared identifier is reported only once for each function it appears in
cc1: some warnings being treated as errors
vim +7469 drivers/net/wireless/ath/ath10k/mac.c
7463 .bss_info_changed = ath10k_bss_info_changed,
7464 .hw_scan = ath10k_hw_scan,
7465 .cancel_hw_scan = ath10k_cancel_hw_scan,
7466 .set_key = ath10k_set_key,
7467 .set_default_unicast_key = ath10k_set_default_unicast_key,
7468 .sta_state = ath10k_sta_state,
> 7469 .sta_set_txpwr = ath10k_sta_set_txpwr,
7470 .conf_tx = ath10k_conf_tx,
7471 .remain_on_channel = ath10k_remain_on_channel,
7472 .cancel_remain_on_channel = ath10k_cancel_remain_on_channel,
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56232 bytes --]
^ permalink raw reply
* Re: VHT 160Mhz and nss related config.
From: Ben Greear @ 2017-02-11 19:38 UTC (permalink / raw)
To: Sebastian Gottschall, Adrian Chadd; +Cc: linux-wireless@vger.kernel.org, ath10k
In-Reply-To: <bbf485eb-f3aa-f49b-8401-03632bc70a7f@dd-wrt.com>
On 02/11/2017 10:21 AM, Sebastian Gottschall wrote:
> Am 11.02.2017 um 18:58 schrieb Ben Greear:
>> On 02/10/2017 08:37 PM, Adrian Chadd wrote:
>>> On 10 February 2017 at 20:22, Sebastian Gottschall
>>> <s.gottschall@dd-wrt.com> wrote:
>>>> i really can't believe this. if this is true the 160 mhz mode would not
>>>> make any sense.
>>>> the maximum tx / rx rate for 4x4 vht80 and 2x2 vht160 is identical. so
>>>> vht160 would not increase performance in any way
>>>
>>> Well, if it can also do 2x2 MU-MIMO at 160MHz then it can be a
>>> perfectly fine STA to a 4x4 160MHz MU-MIMO chip that can actually
>>> transmit 2x2 rates to different MU-MIMO peers.
>>>
>>> That's the outstanding question I have - is it like, 2x2 MU only, or
>>> is it say, 2 concurrently different spatial stream 2x2 MU? Ie, can you
>>> have 2 peers, different VHT spatial groups (or 4 peers, 1 spatial
>>> group each) all going at the same time?
>>>
>>> I'm .. not even sure how you're supposed to cleanly negotiate that you
>>> can do 4NSS in VHT80 but 2NSS in VHT160 to a peer... that only makes
>>> sense if you're doing lots of 1NSS and 2NSS MU-MIMO peers..
>>
>> I think using the max-rx-rate logic might could imply this, but I am not sure
>> many drivers fill this out properly.
>>
>> Looks like a mess waiting to happen to me.
>>
>> Even if you can do 1x1 160Mhz MU-MIMO to two stations, and I am not certain you
>> can since in 80Mhz you can only do a 1x1 and a 2x2 (not two 2x2).
>>
>> So, from what I know currently, 80+80 is not that useful on the 9984 NIC...
> never tried 80+80 since i need to enhance the channel logic alot in my firmware code to handle it. would be great enough if vht160 would work as expected and
> i'm not sure right now if it really works, even if the interface initialized correctly it assocs only with vht80
160Mhz is really implemented as 80+80 internally it seems, so what I meant is that
160Mhz or 80+80 both have the 2x2 restriction.
Stock ath10k driver doesn't set the rxnss_override, so the chip will always be forced
to send 1x1 at 160Mhz, so even if it associates and works at all, it will probably not put
many 160Mhz frames on air since the rate-ctrl should choose 3x3 or 4x4 80Mhz as faster speeds.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: VHT 160Mhz and nss related config.
From: Sebastian Gottschall @ 2017-02-11 18:21 UTC (permalink / raw)
To: Ben Greear, Adrian Chadd; +Cc: linux-wireless@vger.kernel.org, ath10k
In-Reply-To: <589F50B8.4020609@candelatech.com>
Am 11.02.2017 um 18:58 schrieb Ben Greear:
> On 02/10/2017 08:37 PM, Adrian Chadd wrote:
>> On 10 February 2017 at 20:22, Sebastian Gottschall
>> <s.gottschall@dd-wrt.com> wrote:
>>> i really can't believe this. if this is true the 160 mhz mode would
>>> not
>>> make any sense.
>>> the maximum tx / rx rate for 4x4 vht80 and 2x2 vht160 is identical. so
>>> vht160 would not increase performance in any way
>>
>> Well, if it can also do 2x2 MU-MIMO at 160MHz then it can be a
>> perfectly fine STA to a 4x4 160MHz MU-MIMO chip that can actually
>> transmit 2x2 rates to different MU-MIMO peers.
>>
>> That's the outstanding question I have - is it like, 2x2 MU only, or
>> is it say, 2 concurrently different spatial stream 2x2 MU? Ie, can you
>> have 2 peers, different VHT spatial groups (or 4 peers, 1 spatial
>> group each) all going at the same time?
>>
>> I'm .. not even sure how you're supposed to cleanly negotiate that you
>> can do 4NSS in VHT80 but 2NSS in VHT160 to a peer... that only makes
>> sense if you're doing lots of 1NSS and 2NSS MU-MIMO peers..
>
> I think using the max-rx-rate logic might could imply this, but I am
> not sure
> many drivers fill this out properly.
>
> Looks like a mess waiting to happen to me.
>
> Even if you can do 1x1 160Mhz MU-MIMO to two stations, and I am not
> certain you
> can since in 80Mhz you can only do a 1x1 and a 2x2 (not two 2x2).
>
> So, from what I know currently, 80+80 is not that useful on the 9984
> NIC...
never tried 80+80 since i need to enhance the channel logic alot in my
firmware code to handle it. would be great enough if vht160 would work
as expected and i'm not sure right now if it really works, even if the
interface initialized correctly it assocs only with vht80
>
> Thanks,
> Ben
>
>>
>>
>> -adrian
>>
>>>
>>> Am 10.02.2017 um 23:58 schrieb Ben Greear:
>>>>
>>>> So, it appears that the ath10k QCA9984 4x4 160Mhz chip can do 4x4
>>>> MIMO at
>>>> VHT80, but
>>>> it can do only 2x2 MIMO at VHT160/80+80.
>>>>
>>>> When configuring a peer, we need to tell the firmware the number of
>>>> spatial streams
>>>> of the peer at VHT160 and at VHT80 and lower. They are not the same
>>>> value.
>>>>
>>>> I cannot think of any standard way to get this information based on
>>>> VHT
>>>> capabilities
>>>> and such. Currently, one could just assume VHT160 NSS is 1/2 of
>>>> the VHT80
>>>> NSS,
>>>> but that is unlikely to be true for all vendors.
>>>>
>>>> Any ideas?
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>
>>>
>>> --
>>> Mit freundlichen Grüssen / Regards
>>>
>>> Sebastian Gottschall / CTO
>>>
>>> NewMedia-NET GmbH - DD-WRT
>>> Firmensitz: Berliner Ring 101, 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
>>>
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>
>
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Berliner Ring 101, 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: [PATCH] rtlwifi: btcoexist: fix semicolon.cocci warnings
From: Larry Finger @ 2017-02-11 18:09 UTC (permalink / raw)
To: Julia Lawall
Cc: Kalle Valo, Chaoming Li, Joe Perches, netdev, linux-wireless,
linux-kernel, kbuild-all
In-Reply-To: <alpine.DEB.2.20.1702092111340.1985@hadrien>
On 02/09/2017 02:12 PM, Julia Lawall wrote:
> Remove unneeded semicolon.
>
> Generated by: scripts/coccinelle/misc/semicolon.cocci
>
> CC: Larry Finger <Larry.Finger@lwfinger.net>
> Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Thanks,
Larry
> ---
>
> halbtc8821a2ant.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
> @@ -2877,7 +2877,7 @@ static void halbtc8821a2ant_action_pan_e
> false, false);
> btc8821a2ant_sw_mech2(btcoexist, false, false,
> false, 0x18);
> - };
> + }
> } else {
> /* fw mechanism */
> if ((bt_rssi_state == BTC_RSSI_STATE_HIGH) ||
>
^ permalink raw reply
* Re: VHT 160Mhz and nss related config.
From: Ben Greear @ 2017-02-11 17:58 UTC (permalink / raw)
To: Adrian Chadd, Sebastian Gottschall; +Cc: linux-wireless@vger.kernel.org, ath10k
In-Reply-To: <CAJ-VmokKafmamWJJ0-=PJ_oNBejbqcHbd8NO7-M9=Z6DFRuhzw@mail.gmail.com>
On 02/10/2017 08:37 PM, Adrian Chadd wrote:
> On 10 February 2017 at 20:22, Sebastian Gottschall
> <s.gottschall@dd-wrt.com> wrote:
>> i really can't believe this. if this is true the 160 mhz mode would not
>> make any sense.
>> the maximum tx / rx rate for 4x4 vht80 and 2x2 vht160 is identical. so
>> vht160 would not increase performance in any way
>
> Well, if it can also do 2x2 MU-MIMO at 160MHz then it can be a
> perfectly fine STA to a 4x4 160MHz MU-MIMO chip that can actually
> transmit 2x2 rates to different MU-MIMO peers.
>
> That's the outstanding question I have - is it like, 2x2 MU only, or
> is it say, 2 concurrently different spatial stream 2x2 MU? Ie, can you
> have 2 peers, different VHT spatial groups (or 4 peers, 1 spatial
> group each) all going at the same time?
>
> I'm .. not even sure how you're supposed to cleanly negotiate that you
> can do 4NSS in VHT80 but 2NSS in VHT160 to a peer... that only makes
> sense if you're doing lots of 1NSS and 2NSS MU-MIMO peers..
I think using the max-rx-rate logic might could imply this, but I am not sure
many drivers fill this out properly.
Looks like a mess waiting to happen to me.
Even if you can do 1x1 160Mhz MU-MIMO to two stations, and I am not certain you
can since in 80Mhz you can only do a 1x1 and a 2x2 (not two 2x2).
So, from what I know currently, 80+80 is not that useful on the 9984 NIC...
Thanks,
Ben
>
>
> -adrian
>
>>
>> Am 10.02.2017 um 23:58 schrieb Ben Greear:
>>>
>>> So, it appears that the ath10k QCA9984 4x4 160Mhz chip can do 4x4 MIMO at
>>> VHT80, but
>>> it can do only 2x2 MIMO at VHT160/80+80.
>>>
>>> When configuring a peer, we need to tell the firmware the number of
>>> spatial streams
>>> of the peer at VHT160 and at VHT80 and lower. They are not the same
>>> value.
>>>
>>> I cannot think of any standard way to get this information based on VHT
>>> capabilities
>>> and such. Currently, one could just assume VHT160 NSS is 1/2 of the VHT80
>>> NSS,
>>> but that is unlikely to be true for all vendors.
>>>
>>> Any ideas?
>>>
>>> Thanks,
>>> Ben
>>>
>>
>>
>> --
>> Mit freundlichen Grüssen / Regards
>>
>> Sebastian Gottschall / CTO
>>
>> NewMedia-NET GmbH - DD-WRT
>> Firmensitz: Berliner Ring 101, 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
>>
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ 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