* 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: 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: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 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: 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] 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: 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] 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
* [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] brcmfmac: Use net_device_stats from struct net_device
From: Arend Van Spriel @ 2017-02-13 10:17 UTC (permalink / raw)
To: Tobias Klauser, franky.lin, hante.meuleman, kvalo
Cc: linux-wireless, brcm80211-dev-list.pdl, netdev
In-Reply-To: <20170213101409.8205-1-tklauser@distanz.ch>
On 13-2-2017 11:14, Tobias Klauser wrote:
> 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.
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> 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;
>
^ permalink raw reply
* Re: Submitted patches for 4.11 NOW
From: Kalle Valo @ 2017-02-13 10:50 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <87mvdza6nh.fsf@codeaurora.org>
Kalle Valo <kvalo@codeaurora.org> writes:
> Linus is hinting that he might release the final 4.10 next Sunday. So if
> you want have patches with new features in 4.11 better post them NOW to
> not the miss the merge window.
He actually released 4.10-rc8 so we got some more time. So if there's
something still you want to have in 4.11 send them now and let's see if
they make it.
New drivers are an exception to here, to get more testing time I don't
want to apply them this late in the cycle.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath9k: clean up and fix ath_tx_count_airtime
From: Kalle Valo @ 2017-02-13 15:28 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Toke Høiland-Jørgensen, 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.
Indeed, that's pretty severe :) But better to mention that in the commit
log, I'll add that during commit.
Like Toke said, luckily 63fefa050477 is not in 4.10 so I'll push this to
4.11.
--=20
Kalle Valo
^ permalink raw reply
* Re: [PATCH - REGRESSION] mwifiex: don't enable/disable IRQ 0 during suspend/resume
From: Kalle Valo @ 2017-02-13 15:30 UTC (permalink / raw)
To: Brian Norris
Cc: Amitkumar Karwar, Nishant Sarmukadam, linux-kernel,
linux-wireless, Rajat Jain
In-Reply-To: <20170210215525.139701-1-briannorris@chromium.org>
Brian Norris <briannorris@chromium.org> writes:
> If we don't have an out-of-band wakeup IRQ configured through DT (as
> most platforms don't), then we fall out of this function with
> 'irq_wakeup == 0'. Other code (e.g., mwifiex_disable_wake() and
> mwifiex_enable_wake()) treats 'irq_wakeup >= 0' as a valid IRQ, and so
> we end up calling {enable,disable}_irq() on IRQ 0.
>
> That seems bad, so let's not do that.
>
> Same problem as fixed in this patch:
>
> https://patchwork.kernel.org/patch/9531693/
> [PATCH v2 2/3] btmrvl: set irq_bt to -1 when failed to parse it
>
> with the difference that:
> (a) this one is actually a regression and
> (b) this affects both device tree and non-device-tree systems
>
> While fixing the regression, also drop the verbosity on the parse
> failure, so we don't see this when a DT node is present but doesn't have
> an interrupt property (this is perfectly legal):
>
> [ 21.999000] mwifiex_pcie 0000:01:00.0: fail to parse irq_wakeup from device tree
>
> Fixes: 853402a00823 ("mwifiex: Enable WoWLAN for both sdio and pcie")
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> This is a 4.10 regression. Not sure if it's critical to push quickly, or if it
> should just be tagged -stable and pushed in 4.11.
It's really late for 4.10, so I would rather push it to 4.11.
--
Kalle Valo
^ permalink raw reply
* [PATCH] ath9k: Access rchan::buf only with per_cpu helper
From: Sven Eckelmann @ 2017-02-13 15:56 UTC (permalink / raw)
To: linux-wireless
Cc: ath9k-devel, kvalo, netdev, sw, Sven Eckelmann, Akash Goel,
Nick Kossifidis
The relayfs was changed to use per CPU constructs to handle the rchan
buffers. But the users of the rchan buffers in other parts of the kernel
were not modified. This caused crashes like
BUG: unable to handle kernel paging request at 00003a5198a0b910
IP: [<ffffffffa973cb3a>] ath_cmn_process_fft+0xea/0x610
PGD 0 [ 179.522449]
Oops: 0000 [#1] SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-rc5 #1
[...]
Call Trace:
<IRQ> [ 179.656426] [<ffffffffa9704373>] ? ath_rx_tasklet+0x2f3/0xd10
[<ffffffffa9702106>] ? ath9k_tasklet+0x1b6/0x230
[<ffffffffa90dcbd1>] ? tasklet_action+0xf1/0x100
[<ffffffffa9a3cb3f>] ? __do_softirq+0xef/0x284
[<ffffffffa90dd22e>] ? irq_exit+0xae/0xb0
[<ffffffffa9a3c89f>] ? do_IRQ+0x4f/0xd0
[<ffffffffa9a3aa42>] ? common_interrupt+0x82/0x82
<EOI> [ 179.703152] [<ffffffffa9a39c1d>] ? poll_idle+0x2d/0x57
[<ffffffffa908c845>] ? sched_clock+0x5/0x10
[<ffffffffa97bc8d6>] ? cpuidle_enter_state+0xf6/0x2d0
[<ffffffffa911988e>] ? cpu_startup_entry+0x14e/0x230
[<ffffffffaa3cdf70>] ? start_kernel+0x461/0x481
[<ffffffffaa3cd120>] ? early_idt_handler_array+0x120/0x120
[<ffffffffaa3cd413>] ? x86_64_start_kernel+0x14c/0x170
Code: 31 db 41 be ff ff ff ff 4c 8b 26 48 8b 6e 08 49 8b 84 24 60 05 00
00 48 8b 00 0f b7 40 04 66 89 44 24 48 eb 11 48 8b 55 40 48 98 <48>
8b 3c c2 e8 ad a0 a4 ff 01 c3 41 8d 56 01 be 00 02 00 00 48
RIP [<ffffffffa973cb3a>] ath_cmn_process_fft+0xea/0x610
RSP <ffff9b43e7003d20>
CR2: 00003a5198a0b910
Fixes: 017c59c042d0 ("relay: Use per CPU constructs for the relay channel buffer pointers")
Cc: Akash Goel <akash.goel@intel.com>
Cc: Nick Kossifidis <mickflemm@gmail.com>
Reported-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
---
drivers/net/wireless/ath/ath9k/common-spectral.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/common-spectral.c b/drivers/net/wireless/ath/ath9k/common-spectral.c
index 789a3dbe8341..0ffa23a61568 100644
--- a/drivers/net/wireless/ath/ath9k/common-spectral.c
+++ b/drivers/net/wireless/ath/ath9k/common-spectral.c
@@ -482,7 +482,7 @@ ath_cmn_is_fft_buf_full(struct ath_spec_scan_priv *spec_priv)
struct rchan *rc = spec_priv->rfs_chan_spec_scan;
for_each_online_cpu(i)
- ret += relay_buf_full(rc->buf[i]);
+ ret += relay_buf_full(*per_cpu_ptr(rc->buf, i));
i = num_online_cpus();
^ permalink raw reply related
* Re: [PATCH] rtl8xxxu: Add (0x2357 0x0107) to the tested devices list.
From: Jes Sorensen @ 2017-02-13 17:47 UTC (permalink / raw)
To: Kalle Valo, Aaryn Coutanche; +Cc: linux-wireless
In-Reply-To: <87o9y6bg9y.fsf@purkki.adurom.net>
On 02/13/2017 04:18 AM, Kalle Valo wrote:
> 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.
>
Aaryn,
I already mentioned the Signed-off-by part to you - please make sure to
always include that.
In general a commit message should have a headline and then a body
message with a little more detail.
Cheers,
Jes
^ permalink raw reply
* Re: VHT 160Mhz and nss related config.
From: Ben Greear @ 2017-02-13 19:21 UTC (permalink / raw)
To: Johannes Berg, linux-wireless@vger.kernel.org, ath10k
In-Reply-To: <1486969571.5142.3.camel@sipsolutions.net>
On 02/12/2017 11:06 PM, Johannes Berg wrote:
> 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
>
I don't have that spec...maybe you could post a patch that adds that flag
and/or other fields to the appropriate header files? I can attempt to
add support to ath10k after that...
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: Adrian Chadd @ 2017-02-13 19:27 UTC (permalink / raw)
To: Ben Greear; +Cc: Johannes Berg, linux-wireless@vger.kernel.org, ath10k
In-Reply-To: <d53a8fac-b4e0-2fb2-c1e1-c537a2c5e8aa@candelatech.com>
.. or give us a legit way to acquire the 2016 spec? :)
Curious implementers want to know!
-a
On 13 February 2017 at 11:21, Ben Greear <greearb@candelatech.com> wrote:
> On 02/12/2017 11:06 PM, Johannes Berg wrote:
>>
>> 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
>>
>
> I don't have that spec...maybe you could post a patch that adds that flag
> and/or other fields to the appropriate header files? I can attempt to
> add support to ath10k after that...
>
>
> 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: Johannes Berg @ 2017-02-13 19:37 UTC (permalink / raw)
To: Ben Greear, linux-wireless@vger.kernel.org, ath10k
In-Reply-To: <d53a8fac-b4e0-2fb2-c1e1-c537a2c5e8aa@candelatech.com>
> > This was recently added to the VHT capabilities in the spec, see
> > Table 9-250 in 802.11-2016.
> I don't have that spec...maybe you could post a patch that adds that
> flag and/or other fields to the appropriate header files? I can
> attempt to add support to ath10k after that...
We're planning to, but it's not the most important thing on my list
right now ... I'll check where that's at now.
I can't even easily explain it, since it's really complicated.
johannes
^ permalink raw reply
* Re: VHT 160Mhz and nss related config.
From: Ben Greear @ 2017-02-13 19:42 UTC (permalink / raw)
To: Johannes Berg, linux-wireless@vger.kernel.org, ath10k
In-Reply-To: <1487014657.19813.3.camel@sipsolutions.net>
On 02/13/2017 11:37 AM, Johannes Berg wrote:
>
>>> This was recently added to the VHT capabilities in the spec, see
>>> Table 9-250 in 802.11-2016.
>
>> I don't have that spec...maybe you could post a patch that adds that
>> flag and/or other fields to the appropriate header files? I can
>> attempt to add support to ath10k after that...
>
> We're planning to, but it's not the most important thing on my list
> right now ... I'll check where that's at now.
>
> I can't even easily explain it, since it's really complicated.
So, think it is worthwhile to use the max-rx-rate as a proxy
until the 'real' spec is implemented? If 2x2 160Mhz is super complicated,
and yields no useful throughput improvement, then likely it will
be a long time before someone implements it properly I'd guess.
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: Johannes Berg @ 2017-02-13 19:51 UTC (permalink / raw)
To: Ben Greear, linux-wireless@vger.kernel.org, ath10k
In-Reply-To: <0f30d7bf-b710-10a8-91e6-bfd75457cf75@candelatech.com>
On Mon, 2017-02-13 at 11:42 -0800, Ben Greear wrote:
> On 02/13/2017 11:37 AM, Johannes Berg wrote:
> >
> > > > This was recently added to the VHT capabilities in the spec,
> > > > see
> > > > Table 9-250 in 802.11-2016.
> > > I don't have that spec...maybe you could post a patch that adds
> > > that
> > > flag and/or other fields to the appropriate header files? I can
> > > attempt to add support to ath10k after that...
> >
> > We're planning to, but it's not the most important thing on my list
> > right now ... I'll check where that's at now.
> >
> > I can't even easily explain it, since it's really complicated.
>
> So, think it is worthwhile to use the max-rx-rate as a proxy
> until the 'real' spec is implemented? If 2x2 160Mhz is super
> complicated, and yields no useful throughput improvement, then likely
> it will be a long time before someone implements it properly I'd
> guess.
I don't know, I haven't really followed that discussion.
I don't think implementing the spec here will be really complicated,
there are just a bunch of cases to consider when parsing the VHT
capabilities. I won't do anything with max rate in mac80211, and I
doubt you really should implement any workarounds for not having the
spec here in the driver itself.
johannes
^ permalink raw reply
* Re: [PATCH - REGRESSION] mwifiex: don't enable/disable IRQ 0 during suspend/resume
From: Rajat Jain @ 2017-02-13 19:54 UTC (permalink / raw)
To: Brian Norris
Cc: Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo, linux-kernel,
linux-wireless
In-Reply-To: <20170210215525.139701-1-briannorris@chromium.org>
On Fri, Feb 10, 2017 at 1:55 PM, Brian Norris <briannorris@chromium.org> wrote:
> If we don't have an out-of-band wakeup IRQ configured through DT (as
> most platforms don't), then we fall out of this function with
> 'irq_wakeup == 0'. Other code (e.g., mwifiex_disable_wake() and
> mwifiex_enable_wake()) treats 'irq_wakeup >= 0' as a valid IRQ, and so
> we end up calling {enable,disable}_irq() on IRQ 0.
>
> That seems bad, so let's not do that.
>
> Same problem as fixed in this patch:
>
> https://patchwork.kernel.org/patch/9531693/
> [PATCH v2 2/3] btmrvl: set irq_bt to -1 when failed to parse it
>
> with the difference that:
> (a) this one is actually a regression and
> (b) this affects both device tree and non-device-tree systems
>
> While fixing the regression, also drop the verbosity on the parse
> failure, so we don't see this when a DT node is present but doesn't have
> an interrupt property (this is perfectly legal):
>
> [ 21.999000] mwifiex_pcie 0000:01:00.0: fail to parse irq_wakeup from device tree
>
> Fixes: 853402a00823 ("mwifiex: Enable WoWLAN for both sdio and pcie")
> Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Rajat Jain <rajatja@google.com>
> ---
> This is a 4.10 regression. Not sure if it's critical to push quickly, or if it
> should just be tagged -stable and pushed in 4.11.
>
> drivers/net/wireless/marvell/mwifiex/main.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
> index e5c3a8aa3929..c246d8efb6fc 100644
> --- a/drivers/net/wireless/marvell/mwifiex/main.c
> +++ b/drivers/net/wireless/marvell/mwifiex/main.c
> @@ -1569,13 +1569,13 @@ static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
> struct device *dev = adapter->dev;
>
> if (!dev->of_node)
> - return;
> + goto err_exit;
>
> adapter->dt_node = dev->of_node;
> adapter->irq_wakeup = irq_of_parse_and_map(adapter->dt_node, 0);
> if (!adapter->irq_wakeup) {
> - dev_info(dev, "fail to parse irq_wakeup from device tree\n");
> - return;
> + dev_dbg(dev, "fail to parse irq_wakeup from device tree\n");
> + goto err_exit;
> }
>
> ret = devm_request_irq(dev, adapter->irq_wakeup,
> @@ -1595,7 +1595,7 @@ static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
> return;
>
> err_exit:
> - adapter->irq_wakeup = 0;
> + adapter->irq_wakeup = -1;
> }
>
> /*
> --
> 2.11.0.483.g087da7b7c-goog
>
^ permalink raw reply
* Re: VHT 160Mhz and nss related config.
From: Ben Greear @ 2017-02-13 19:56 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
Looks like it is working with the hack I posted:
Station 04:f0:21:2e:49:65 (on wlan2)
inactive time: 0 ms
rx bytes: 64902998
rx packets: 37918
tx bytes: 64760298
tx packets: 42239
tx retries: 0
tx failed: 0
signal: -43 dBm
signal avg: -42 dBm
tx bitrate: 1053.0 MBit/s VHT-MCS 6 160MHz VHT-NSS 2
rx bitrate: 1560.0 MBit/s VHT-MCS 8 160MHz short GI VHT-NSS 2
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
connected time: 156 seconds
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-13 21:19 UTC (permalink / raw)
To: Ben Greear, Adrian Chadd; +Cc: linux-wireless@vger.kernel.org, ath10k
In-Reply-To: <36c7dfa2-b39c-ad7a-5e39-3daf8983ed2f@candelatech.com>
Am 13.02.2017 um 20:56 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
>
> Looks like it is working with the hack I posted:
>
> Station 04:f0:21:2e:49:65 (on wlan2)
> inactive time: 0 ms
> rx bytes: 64902998
> rx packets: 37918
> tx bytes: 64760298
> tx packets: 42239
> tx retries: 0
> tx failed: 0
> signal: -43 dBm
> signal avg: -42 dBm
> tx bitrate: 1053.0 MBit/s VHT-MCS 6 160MHz VHT-NSS 2
> rx bitrate: 1560.0 MBit/s VHT-MCS 8 160MHz short GI VHT-NSS 2
> authorized: yes
> authenticated: yes
> preamble: long
> WMM/WME: yes
> MFP: no
> TDLS peer: no
> connected time: 156 seconds
>
> Thanks,
> Ben
cool. let me check it on my devices
>
>
--
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] Make EN2 pin optional in the TRF7970A driver
From: Rob Herring @ 2017-02-13 21:31 UTC (permalink / raw)
To: Heiko Schocher
Cc: netdev, Guan Ben, Mark Jonas, devicetree@vger.kernel.org,
linux-wireless, linux-kernel@vger.kernel.org, Samuel Ortiz,
Lauro Ramos Venancio, Aloisio Almeida Jr, Mark Rutland
In-Reply-To: <58A15454.4030602@denx.de>
On Mon, Feb 13, 2017 at 12:38 AM, Heiko Schocher <hs@denx.de> wrote:
> 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?
I guess if this ever happens, then we just add "ti,enable2-gpios" and
ti,enable-gpios continues to point to EN. We don't need to deprecate
anything (or maybe just deprecate having both GPIOs on single
property).
In that case,
Acked-by: Rob Herring <robh@kernel.org>
>
> "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-13 22:48 UTC (permalink / raw)
To: Ben Greear, Adrian Chadd; +Cc: linux-wireless@vger.kernel.org, ath10k
In-Reply-To: <36c7dfa2-b39c-ad7a-5e39-3daf8983ed2f@candelatech.com>
Am 13.02.2017 um 20:56 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
>
> Looks like it is working with the hack I posted:
>
> Station 04:f0:21:2e:49:65 (on wlan2)
> inactive time: 0 ms
> rx bytes: 64902998
> rx packets: 37918
> tx bytes: 64760298
> tx packets: 42239
> tx retries: 0
> tx failed: 0
> signal: -43 dBm
> signal avg: -42 dBm
> tx bitrate: 1053.0 MBit/s VHT-MCS 6 160MHz VHT-NSS 2
> rx bitrate: 1560.0 MBit/s VHT-MCS 8 160MHz short GI VHT-NSS 2
> authorized: yes
> authenticated: yes
> preamble: long
> WMM/WME: yes
> MFP: no
> TDLS peer: no
> connected time: 156 seconds
>
> Thanks,
> Ben
>
>
the hack you posted crashes the driver for me. i also see that this
patch is based on the CT ath10k source. it doesnt apply clean to ath10k.
needed to merge it manually
--
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
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