Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client

[Kalle Valo]

Andy Gross  writes:

>> > >> This doesn't compile for me:
>> > >>
>> > >
>> > > I thought I mentioned this in the mail, sorry for missing that.
>> > 
>> > Maybe you did and I just forgot, I have a tendency to do that :)
>> > 
>> > > There is a patch for this issue in linux-next already [1] which is
>> > > part of [2], which was part of the pull request to arm-soc for
>> > > inclusion in v4.9.
>> > >
>> > > [1] https://patchwork.kernel.org/patch/9272457/
>> > > [2] 
>> > > https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9
>> > 
>> > So the commit in question is:
>> > 
>> > soc: qcom: smd: Correct compile stub prototypes
>> > https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/commit/?h=qcom-drivers-for-4.9=3a1281848830fcb3202cfd7ffe62d19641471d05
>> > 
>> 
>> Correct
>> 
>> > But that's not obviously in my tree yet, but I should have it after
>> > 4.9-rc1 is released. I think it's easiest that I wait for that before
>> > applying these. Do you agree?
>> > 
>> 
>> Would be nice to have it land sooner rather than later, but I'm okay
>> with this.
>
> We could just treat the tag as immutable.  You can merge the tag in and 
> arm-soc
> can as well.  it'll just get nop'd the second time it is taken.  The only
> downside is if arm-soc doesn't take my merge request.

I take it that you are talking about this tag:

git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git 
qcom-drivers-for-4.9

I did a test pull and there are only 8 commits so in theory that could
work. But my trees go via Dave Miller's net-next so I can't control when
they hit Linus' tree. It might be that Linus pulls the net-next tree
before arm-soc and arm-soc commits coming from net-next might confuse
people. I'm just afraid that the hassle would outweight the benefit.

> Or we can wait till -rc1

To keep things simple I prefer this option. Of course it means waiting
few more extra weeks, but when working with new subsystems that can
happen. The crystall ball[1] says that 4.9-rc1 would be released on
2016-10-16 so it's not that far away.

[1] http://phb-crystal-ball.org/

-- 
Kalle Valo

Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client

[Bjorn Andersson]

On Thu 08 Sep 10:35 PDT 2016, Kalle Valo wrote:

> Bjorn Andersson  writes:
> 
> > On Thu, Sep 8, 2016 at 5:16 AM, Kalle Valo  wrote:
> >> Bjorn Andersson  writes:
> >>
> >>> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
> >>> channel, as such it should be a SMD client. This patch makes this
> >>> transition, now that we have the necessary frameworks available.
> >>>
> >>> Signed-off-by: Bjorn Andersson 
> >>> ---
> >>>
> >>> Changes since v3:
> >>> - Made msg_header const in wcn36xx_smd_rsp_process()
> >>>
> >>> Changes since v2:
> >>> - Correct the call to the new ieee80211_scan_completed()
> >>>
> >>>  drivers/net/wireless/ath/wcn36xx/dxe.c | 16 +++---
> >>>  drivers/net/wireless/ath/wcn36xx/main.c| 79 
> >>> --
> >>>  drivers/net/wireless/ath/wcn36xx/smd.c | 31 +---
> >>>  drivers/net/wireless/ath/wcn36xx/smd.h |  5 ++
> >>>  drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 21 +++-
> >>>  5 files changed, 86 insertions(+), 66 deletions(-)
> >>
> >> This doesn't compile for me:
> >>
> >
> > I thought I mentioned this in the mail, sorry for missing that.
> 
> Maybe you did and I just forgot, I have a tendency to do that :)
> 
> > There is a patch for this issue in linux-next already [1] which is
> > part of [2], which was part of the pull request to arm-soc for
> > inclusion in v4.9.
> >
> > [1] https://patchwork.kernel.org/patch/9272457/
> > [2] 
> > https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9
> 
> So the commit in question is:
> 
> soc: qcom: smd: Correct compile stub prototypes
> https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/commit/?h=qcom-drivers-for-4.9=3a1281848830fcb3202cfd7ffe62d19641471d05
> 

Correct

> But that's not obviously in my tree yet, but I should have it after
> 4.9-rc1 is released. I think it's easiest that I wait for that before
> applying these. Do you agree?
> 

Would be nice to have it land sooner rather than later, but I'm okay
with this.

Regards,
Bjorn

Re: [RFC] mac80211: Dynamically set CoDel parameters per station.

[Felix Fietkau]

On 2016-09-08 21:59, Toke Høiland-Jørgensen wrote:
> CoDel can be too aggressive if a station sends at a very low rate. This
> gets worse the more stations are present, as each station gets more
> bursty the longer the round-robin scheduling between stations takes.
> 
> This is an attempt to dynamically adjust CoDel parameters per station.
> It takes a rather simple approach and uses a simple binary designation
> of a station as 'slow' if it has expected throughput less than eight
> Mbps (i.e. the lowest couple of rates). In this case, CoDel is set to be
> more lenient by adjusting its target to 50 ms and interval to 300 ms.
> There's a built-in hysteresis so a station cannot flip between slow and
> fast more than once every two seconds.
> 
> In this version the check is performed every time a packet is enqueued
> to the intermediate queues; and the overhead of doing this is alleviated
> a bit by caching the result and by the above-mentioned hysteresis. It
> can probably be smarter about both when and how to do the scaling, but
> this seems to alleviate some of the starvation I've seen with very slow
> stations.
Since this is not dealing properly with firmware rate control anyway,
I'd suggest calling the update from rate_control_set_rates in order to
avoid putting more stuff into the tx hot path.

You could add a separate code path to allow firmware rate control
devices to provide a hint at a convenient point in time.

- Felix

[RFC] mac80211: Dynamically set CoDel parameters per station.

[Toke Høiland-Jørgensen]

CoDel can be too aggressive if a station sends at a very low rate. This
gets worse the more stations are present, as each station gets more
bursty the longer the round-robin scheduling between stations takes.

This is an attempt to dynamically adjust CoDel parameters per station.
It takes a rather simple approach and uses a simple binary designation
of a station as 'slow' if it has expected throughput less than eight
Mbps (i.e. the lowest couple of rates). In this case, CoDel is set to be
more lenient by adjusting its target to 50 ms and interval to 300 ms.
There's a built-in hysteresis so a station cannot flip between slow and
fast more than once every two seconds.

In this version the check is performed every time a packet is enqueued
to the intermediate queues; and the overhead of doing this is alleviated
a bit by caching the result and by the above-mentioned hysteresis. It
can probably be smarter about both when and how to do the scaling, but
this seems to alleviate some of the starvation I've seen with very slow
stations.

I'm not sure how this interacts with drivers that do rate-control in
firmware (such as ath10k). I assume they will just not be able to return
an expected rate (and so will be considered 'fast').

Cc: Michal Kazior 
Cc: Felix Fietkau 
Cc: Dave Taht 
Signed-off-by: Toke Høiland-Jørgensen 
---
 net/mac80211/sta_info.c | 37 +
 net/mac80211/sta_info.h | 13 +
 net/mac80211/tx.c   | 14 +-
 3 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 19f14c9..8bc9eba 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 
+#include 
+#include 
 #include 
 #include "ieee80211_i.h"
 #include "driver-ops.h"
@@ -325,6 +327,10 @@ struct sta_info *sta_info_alloc(struct 
ieee80211_sub_if_data *sdata,
INIT_WORK(>drv_deliver_wk, sta_deliver_ps_frames);
INIT_WORK(>ampdu_mlme.work, ieee80211_ba_session_work);
mutex_init(>ampdu_mlme.mtx);
+
+   codel_params_init(>cparams.cparams);
+   sta->cparams.cparams.ecn = true;
+
 #ifdef CONFIG_MAC80211_MESH
if (ieee80211_vif_is_mesh(>vif)) {
sta->mesh = kzalloc(sizeof(*sta->mesh), gfp);
@@ -2314,3 +2320,34 @@ unsigned long ieee80211_sta_last_active(struct sta_info 
*sta)
return stats->last_rx;
return sta->status_stats.last_ack;
 }
+
+void sta_update_codel_params(struct sta_info *sta)
+{
+   u64 now = ktime_get_ns();
+   u32 thr;
+   bool slow;
+
+   if (likely(now - sta->cparams.update_time < STA_CPARAMS_HYSTERESIS))
+   return;
+
+   thr = sta_get_expected_throughput(sta);
+   slow = !!(thr && thr < STA_SLOW_THRESHOLD);
+
+   if (likely(slow == sta->cparams.slow))
+   return;
+
+   net_info_ratelimited("%pM: updating CoDel params - throughput %d slow 
%s\n",
+   sta->addr, thr, slow ? "true" : "false");
+
+   if (slow) {
+   sta->cparams.cparams.target = MS2TIME(50);
+   sta->cparams.cparams.interval = MS2TIME(300);
+   sta->cparams.cparams.ecn = false;
+   } else {
+   sta->cparams.cparams.target = MS2TIME(5);
+   sta->cparams.cparams.interval = MS2TIME(100);
+   sta->cparams.cparams.ecn = true;
+   }
+   sta->cparams.update_time = now;
+   sta->cparams.slow = slow;
+}
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 0556be3..928c52d 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -384,6 +384,16 @@ struct ieee80211_sta_rx_stats {
u64 msdu[IEEE80211_NUM_TIDS + 1];
 };
 
+#define STA_CPARAMS_HYSTERESIS 5 * NSEC_PER_SEC
+#define STA_SLOW_THRESHOLD 8000 /* 8 mbps */
+
+struct sta_codel_params {
+   struct codel_params cparams;
+   u64 update_time;
+   bool slow;
+};
+void sta_update_codel_params(struct sta_info *sta);
+
 /**
  * struct sta_info - STA information
  *
@@ -437,6 +447,7 @@ struct ieee80211_sta_rx_stats {
  * @known_smps_mode: the smps_mode the client thinks we are in. Relevant for
  * AP only.
  * @cipher_scheme: optional cipher scheme for this station
+ * @cparams: CoDel parameters for this station.
  * @reserved_tid: reserved TID (if any, otherwise IEEE80211_TID_UNRESERVED)
  * @fast_tx: TX fastpath information
  * @fast_rx: RX fastpath information
@@ -540,6 +551,8 @@ struct sta_info {
enum ieee80211_smps_mode known_smps_mode;
const struct ieee80211_cipher_scheme *cipher_scheme;
 
+   struct sta_codel_params cparams;
+
u8 reserved_tid;
 
struct cfg80211_chan_def tdls_chandef;
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index efc38e7..3973ab0 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1339,12 +1339,19 @@ static struct sk_buff 

support for QCA9377 SDIO (ath10k or ath6kl)

[Martin Blumenstingl]

Hello,

is there any support for the SDIO chips QCA9377 (and QCA9378) planned?
Would these be supported by ath10k or ath6kl or is a completely new
driver needed?

Some background:
There are some device (Android TV boxes) which are using a QCA9377
wifi chip connected via SDIO. Example: Beelink GT1 (using an Amlogic
S912 SoC) - [0]

The part in question is labeled with AW-CM273SM (could be an AzureWave
module based on the name - but that is pure speculation).
According to some google hits it uses a QCA9377 chip (which would
match with the wifi-fw tarball from Amlogic which recently gained a
"qcom9377" folder).


Regards,
Martin


[0] 
http://forum.xda-developers.com/android-stick--console-computers/amlogic/beelink-gt1-amlogic-912-2-16gb-t3451068

Re: [PATCH 2/2] mwifiex: fix unaligned read in mwifiex_config_scan()

[Kalle Valo]

Amitkumar Karwar  writes:

>> > --- a/drivers/net/wireless/marvell/mwifiex/scan.c
>> > +++ b/drivers/net/wireless/marvell/mwifiex/scan.c
>> > @@ -883,7 +883,8 @@ mwifiex_config_scan(struct mwifiex_private *priv,
>> >sizeof(scan_cfg_out->specific_bssid));
>> >
>> > if (adapter->ext_scan &&
>> > -   !is_zero_ether_addr(scan_cfg_out->specific_bssid))
>> {
>> > +   !is_zero_ether_addr_unaligned(
>> > +   scan_cfg_out->specific_bssid)) {
>> 
>> Any comments? Is this approach of adding
>> is_zero_ether_addr_unaligned() fine? We already have similar routine
>> ether_addr_equal_unaligned().
>> 
>> I don't see much benefit making a local, aligned copy here. It would
>> have to use memcpy w/ byte operations anyways and then still run
>> is_zero_ether_addr().
>> 
>> Amitkumar -- Is it possible to modify struct mwifiex_scan_cmd_config {}
>> and align specific_bssid field to u16 boundary?
>> 
>
> We can’t change the structure. The reason is firmware at receiving end
> expects the variables in the same order.
> is_zero_ether_addr_unaligned() should be fine.

If I understood correctly Dave doesn't like
is_zero_ether_addr_unaligned() so we can't use that either.

-- 
Kalle Valo

Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client

[Kalle Valo]

Bjorn Andersson  writes:

> On Thu, Sep 8, 2016 at 5:16 AM, Kalle Valo  wrote:
>> Bjorn Andersson  writes:
>>
>>> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
>>> channel, as such it should be a SMD client. This patch makes this
>>> transition, now that we have the necessary frameworks available.
>>>
>>> Signed-off-by: Bjorn Andersson 
>>> ---
>>>
>>> Changes since v3:
>>> - Made msg_header const in wcn36xx_smd_rsp_process()
>>>
>>> Changes since v2:
>>> - Correct the call to the new ieee80211_scan_completed()
>>>
>>>  drivers/net/wireless/ath/wcn36xx/dxe.c | 16 +++---
>>>  drivers/net/wireless/ath/wcn36xx/main.c| 79 
>>> --
>>>  drivers/net/wireless/ath/wcn36xx/smd.c | 31 +---
>>>  drivers/net/wireless/ath/wcn36xx/smd.h |  5 ++
>>>  drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 21 +++-
>>>  5 files changed, 86 insertions(+), 66 deletions(-)
>>
>> This doesn't compile for me:
>>
>
> I thought I mentioned this in the mail, sorry for missing that.

Maybe you did and I just forgot, I have a tendency to do that :)

> There is a patch for this issue in linux-next already [1] which is
> part of [2], which was part of the pull request to arm-soc for
> inclusion in v4.9.
>
> [1] https://patchwork.kernel.org/patch/9272457/
> [2] 
> https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9

So the commit in question is:

soc: qcom: smd: Correct compile stub prototypes
https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/commit/?h=qcom-drivers-for-4.9=3a1281848830fcb3202cfd7ffe62d19641471d05

But that's not obviously in my tree yet, but I should have it after
4.9-rc1 is released. I think it's easiest that I wait for that before
applying these. Do you agree?

-- 
Kalle Valo

Re: Stability connection problems in ath9k kernel 4.7

[Kalle Valo]

Valerio Passini  writes:

> On mercoledì 7 settembre 2016 11:32:24 CEST Kalle Valo wrote:
>> Valerio Passini  writes:
>> > I have found some connection problems since 4.7 release using ath9k that
>> > turn the wifi pretty useless, I think it might be something in the power
>> > management because the signal seems really low. Previously, up to kernel
>> > 4.6.7 everything worked very well.
>> > 
>> > This is a sample of dmesg in kernel 4.7.2:
>> >  239.898935] wlp4s0: authenticate with XX:XX:XX:XX:XX:XX
>> > 
>> > [  239.919995] wlp4s0: send auth to XX:XX:XX:XX:XX:XX  (try 1/3)
>> > [  239.931877] wlp4s0: authenticated
>> > [  239.932357] wlp4s0: associate with XX:XX:XX:XX:XX:XX  (try 1/3)
>> > [  239.942171] wlp4s0: RX AssocResp from XX:XX:XX:XX:XX:XX  (capab=0x431
>> > status=0 aid=2)
>> > [  239.942301] wlp4s0: associated
>> > [  244.802853] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x0024
>> > AR_DIAG_SW=0x0220 DMADBG_7=0x
>> > 6100
>> > [  245.931832] wlp4s0: authenticate with XX:XX:XX:XX:XX:XX
>> > [  245.953028] wlp4s0: send auth to XX:XX:XX:XX:XX:XX  (try 1/3)
>> > [  245.958702] wlp4s0: authenticated
>> > [  245.960386] wlp4s0: associate withXX:XX:XX:XX:XX:XX  (try 1/3)
>> > [  245.980543] wlp4s0: RX AssocResp from XX:XX:XX:XX:XX:XX  (capab=0x431
>> > status=0 aid=2)
>> > 
>> > lspci on 4.6.7 kernel:
>> > 04:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network
>> > Adapter (rev 01)
>> > 
>> > Subsystem: AzureWave AR9485 Wireless Network Adapter
>> > Flags: bus master, fast devsel, latency 0, IRQ 18
>> > Memory at f790 (64-bit, non-prefetchable) [size=512K]
>> > Expansion ROM at f798 [disabled] [size=64K]
>> > Capabilities: [40] Power Management version 2
>> > Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
>> > Capabilities: [70] Express Endpoint, MSI 00
>> > Capabilities: [100] Advanced Error Reporting
>> > Capabilities: [140] Virtual Channel
>> > Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
>> > Kernel driver in use: ath9k
>> > Kernel modules: ath9k
>> > 
>> > Probably you need some debugging output, but before recompiling the kernel
>> > I would like to know if you are interested in any kind of help from me
>> > and what steps I should take (I'm able to help in testing patches but I'm
>> > not familiar with git). Thank you
>> 
>> Usually it's really helpful if you can find the commit id which broke
>> it. 'git bisect' is a great tool to do that and this seems to be a nice
>> tutorial how to use it:
>> 
>> http://webchick.net/node/99
>> 
>> Instead of commit ids you can use release tags like v4.6 and v4.7 to
>> make it easier to start the bisect. Just make sure that v4.7 is really
>> broken and v4.6 works before you start the bisection.
>
> Hi Kalle,
>
> I tried to understand the whole procedure related to git and git bisect, and 
> this is the first time I try it, so I can have done some mistake. In the git 
> log you'll find the commit that could be guilty for the behaviour I reported 
> yesterday. Anyhow, the resulting commit doesn't make any sense to me.

So your bisect found this as the bad commit:

commit 9257b4a206fc0229dd5f84b78e4d1ebf3f91d270
Author: Omer Peleg 
Date:   Wed Apr 20 11:34:11 2016 +0300

iommu/iova: introduce per-cpu caching to iova allocation

The ath9k log you provided has a DMA warning and iommu problems can
cause DMA problems but I cannot make any conclusions yet. To confirm
that this commit really is the problem you could try to revert it with
'git revert -n 9257b4a206fc0229dd5f84b78e4d1ebf3f91d270'. For some
reason I got conflicts but if you are good enough with C you could try
to fix those yourself. Another option is that you disable iommu and see
if that helps.

I'm adding more people and mailing lists related to this commit,
hopefully they have better ideas.

This is Valerio's bisect log:

git bisect start
# good: [2dcd0af568b0cf583645c8a317dd12e344b1c72a] Linux 4.6
git bisect good 2dcd0af568b0cf583645c8a317dd12e344b1c72a
# bad: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7
git bisect bad 523d939ef98fd712632d93a5a2b588e477a7565e
# good: [0694f0c9e20c47063e4237e5f6649ae5ce5a369a] radix tree test suite: 
remove dependencies on height
git bisect good 0694f0c9e20c47063e4237e5f6649ae5ce5a369a
# good: [e4f7bdc2ec0d0dcc27f7d70db27a620dfdc1f697] Merge branch 'for-4.7-zac' 
of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata
git bisect good e4f7bdc2ec0d0dcc27f7d70db27a620dfdc1f697
# bad: [049ec1b5a76d34a6980cccdb7c0baeb4eed7a993] Merge tag 'drm-fixes-for-
v4.7-rc2' of git://people.freedesktop.org/~airlied/linux
git bisect bad 049ec1b5a76d34a6980cccdb7c0baeb4eed7a993
# good: [a10c38a4f385f5d7c173a263ff6bb2d36021b3bb] Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client
git bisect 

RE: [PATCH 2/2] mwifiex: fix unaligned read in mwifiex_config_scan()

[Amitkumar Karwar]

Hi Petri,

> -Original Message-
> From: Petri Gynther [mailto:pgynt...@google.com]
> Sent: Tuesday, August 16, 2016 11:17 PM
> To: linux-wireless@vger.kernel.org
> Cc: kv...@codeaurora.org; David Miller; Joe Perches; Amitkumar Karwar;
> Petri Gynther
> Subject: Re: [PATCH 2/2] mwifiex: fix unaligned read in
> mwifiex_config_scan()
> 
> On Fri, Aug 12, 2016 at 8:00 PM, Petri Gynther 
> wrote:
> > $ iwconfig mlan0 essid MySSID
> > [   36.93] Path: /sbin/iwconfig
> > [   36.93] CPU: 0 PID: 203 Comm: iwconfig Not tainted 4.7.0 #2
> > [   36.94] task: 866f83a0 ti: 866a6000 task.ti: 866a6000
> > [   36.94]
> > [ECR   ]: 0x00230400 => Misaligned r/w from 0x8677f403
> > [   36.96] [EFA   ]: 0x8677f403
> > [   36.96] [BLINK ]: mwifiex_scan_networks+0x17a/0x198c [mwifiex]
> > [   36.96] [ERET  ]: mwifiex_scan_networks+0x18a/0x198c [mwifiex]
> > [   36.98] [STAT32]: 0x0206 : K E2 E1
> > [   36.98] BTA: 0x700736e2   SP: 0x866a7d0c  FP: 0x5faddc84
> > [   37.00] LPS: 0x806a37ec  LPE: 0x806a37fa LPC: 0x
> > [   37.00] r00: 0x8677f401  r01: 0x8668aa08 r02: 0x0001
> > r03: 0x r04: 0x8668b600 r05: 0x8677f406
> > r06: 0x8702b600 r07: 0x r08: 0x8702b600
> > r09: 0x r10: 0x870b3b00 r11: 0x
> > r12: 0x
> > [   37.04]
> > [   37.04] Stack Trace:
> > [   37.04]   mwifiex_scan_networks+0x18a/0x198c [mwifiex]
> >
> > Root cause:
> > mwifiex driver calls is_zero_ether_addr() against byte-aligned
> address:
> >
> > drivers/net/wireless/marvell/mwifiex/fw.h:
> > struct mwifiex_scan_cmd_config {
> > /*
> >  *  BSS mode to be sent in the firmware command
> >  */
> > u8 bss_mode;
> >
> > /* Specific BSSID used to filter scan results in the firmware
> */
> > u8 specific_bssid[ETH_ALEN];
> >
> > ...
> > } __packed;
> >
> > drivers/net/wireless/marvell/mwifiex/scan.c:
> > mwifiex_config_scan(..., struct mwifiex_scan_cmd_config *scan_cfg_out,
> ...)
> > ...
> > if (adapter->ext_scan &&
> > !is_zero_ether_addr(scan_cfg_out->specific_bssid)) {
> > ...
> > }
> >
> > Since firmware-related struct mwifiex_scan_cmd_config cannot be
> > changed, we need to use the new function
> is_zero_ether_addr_unaligned() here.
> >
> > This is v2 of the original patch:
> > [PATCH] Modify is_zero_ether_addr() to handle byte-aligned addresses
> >
> > Per Joe's suggestion -- instead of modifying is_zero_ether_addr() --
> > add is_zero_ether_addr_unaligned() and use it where needed.
> >
> > Cc: Kalle Valo 
> > Cc: David S. Miller 
> > Cc: Joe Perches 
> > Cc: Amitkumar Karwar 
> > Signed-off-by: Petri Gynther 
> > ---
> >  drivers/net/wireless/marvell/mwifiex/scan.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c
> > b/drivers/net/wireless/marvell/mwifiex/scan.c
> > index bc5e52c..d648c88 100644
> > --- a/drivers/net/wireless/marvell/mwifiex/scan.c
> > +++ b/drivers/net/wireless/marvell/mwifiex/scan.c
> > @@ -883,7 +883,8 @@ mwifiex_config_scan(struct mwifiex_private *priv,
> >sizeof(scan_cfg_out->specific_bssid));
> >
> > if (adapter->ext_scan &&
> > -   !is_zero_ether_addr(scan_cfg_out->specific_bssid))
> {
> > +   !is_zero_ether_addr_unaligned(
> > +   scan_cfg_out->specific_bssid)) {
> 
> Any comments? Is this approach of adding
> is_zero_ether_addr_unaligned() fine? We already have similar routine
> ether_addr_equal_unaligned().
> 
> I don't see much benefit making a local, aligned copy here. It would
> have to use memcpy w/ byte operations anyways and then still run
> is_zero_ether_addr().
> 
> Amitkumar -- Is it possible to modify struct mwifiex_scan_cmd_config {}
> and align specific_bssid field to u16 boundary?
> 

We can’t change the structure. The reason is firmware at receiving end expects 
the variables in the same order.
is_zero_ether_addr_unaligned() should be fine.

Regards,
Amitkumar

Re: mwifiex: propagate error if IRQ request fails in mwifiex_sdio_of()

[Javier Martinez Canillas]

Hello Amitkumar,

On 09/08/2016 11:55 AM, Amitkumar Karwar wrote:
> Hi Javier,
> 
>> From: Javier Martinez Canillas [mailto:jav...@osg.samsung.com]
>> Sent: Tuesday, September 06, 2016 5:43 PM
>> To: Kalle Valo
>> Cc: linux-ker...@vger.kernel.org; Amitkumar Karwar;
>> net...@vger.kernel.org; linux-wireless@vger.kernel.org; Nishant
>> Sarmukadam; Arend van Spriel
>> Subject: Re: mwifiex: propagate error if IRQ request fails in
>> mwifiex_sdio_of()
>>
>> Hello Kalle,
>>
>> On 09/03/2016 12:35 PM, Kalle Valo wrote:
>>> Javier Martinez Canillas  wrote:
 If request_irq() fails in mwifiex_sdio_probe_of(), only an error
 message is printed but the actual error is not propagated to the
>> caller function.

 Signed-off-by: Javier Martinez Canillas 
>>>
>>> What's the conclusion with this patch? Should I drop it or take it?
>>>
>>> (The discussion is available from the patchwork link in the
>>> signature.)
>>>
>>
>> My understanding is that Arend agrees with the patch and that the
>> question raised was caused by looking at an older kernel version. IOW,
>> the patch is OK and should be picked.
>>
>> I'm adding Arend to cc, so can comment in case I misunderstood him
>> though.
>>
> 
> This error doesn't affect actual wifi functionality. Only thing is wakeup on 
> interrupt when system is in suspended state won't work.
> I think, we can make below change. 
> 
> --
> @@ -122,9 +122,11 @@ static int mwifiex_sdio_probe_of(struct device *dev, 
> struct sdio_mmc_card *card)
>IRQF_TRIGGER_LOW,
>"wifi_wake", cfg);
>if (ret) {
> -dev_err(dev,
> +dev_dbg(dev,
>  "Failed to request irq_wifi %d (%d)\n",
>  cfg->irq_wifi, ret);
> +card->plt_wake_cfg = NULL;
> +return 0;
>  }

I'm OK with that change. Feel free too add my Reviewed-by if you post it.

> disable_irq(cfg->irq_wifi);
> }
> -
> 
> Regards,
> Amitkumar
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

RE: mwifiex: propagate error if IRQ request fails in mwifiex_sdio_of()

[Amitkumar Karwar]

Hi Javier,

> From: Javier Martinez Canillas [mailto:jav...@osg.samsung.com]
> Sent: Tuesday, September 06, 2016 5:43 PM
> To: Kalle Valo
> Cc: linux-ker...@vger.kernel.org; Amitkumar Karwar;
> net...@vger.kernel.org; linux-wireless@vger.kernel.org; Nishant
> Sarmukadam; Arend van Spriel
> Subject: Re: mwifiex: propagate error if IRQ request fails in
> mwifiex_sdio_of()
> 
> Hello Kalle,
> 
> On 09/03/2016 12:35 PM, Kalle Valo wrote:
> > Javier Martinez Canillas  wrote:
> >> If request_irq() fails in mwifiex_sdio_probe_of(), only an error
> >> message is printed but the actual error is not propagated to the
> caller function.
> >>
> >> Signed-off-by: Javier Martinez Canillas 
> >
> > What's the conclusion with this patch? Should I drop it or take it?
> >
> > (The discussion is available from the patchwork link in the
> > signature.)
> >
> 
> My understanding is that Arend agrees with the patch and that the
> question raised was caused by looking at an older kernel version. IOW,
> the patch is OK and should be picked.
> 
> I'm adding Arend to cc, so can comment in case I misunderstood him
> though.
> 

This error doesn't affect actual wifi functionality. Only thing is wakeup on 
interrupt when system is in suspended state won't work.
I think, we can make below change. 

--
@@ -122,9 +122,11 @@ static int mwifiex_sdio_probe_of(struct device *dev, 
struct sdio_mmc_card *card)
   IRQF_TRIGGER_LOW,
   "wifi_wake", cfg);
   if (ret) {
-dev_err(dev,
+dev_dbg(dev,
 "Failed to request irq_wifi %d (%d)\n",
 cfg->irq_wifi, ret);
+card->plt_wake_cfg = NULL;
+return 0;
 }
disable_irq(cfg->irq_wifi);
}
-

Regards,
Amitkumar

Re: rtl8xxxu: fix spelling mistake "firmare" -> "firmware"

[Jes Sorensen]

Kalle Valo  writes:
> Colin Ian King  wrote:
>> From: Colin Ian King 
>> 
>> Trivial fix to spelling mistakes in dev_dbg message.
>> 
>> Signed-off-by: Colin Ian King 
>> Reviewed-by: Julian Calaby 
>
> I assume Jes will take this.

It's on my list, sorry been swamped in LPC stuff and other work the last
couple of days.

Cheers,
Jes

Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client

[Bjorn Andersson]

On Thu, Sep 8, 2016 at 5:16 AM, Kalle Valo  wrote:
> Bjorn Andersson  writes:
>
>> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
>> channel, as such it should be a SMD client. This patch makes this
>> transition, now that we have the necessary frameworks available.
>>
>> Signed-off-by: Bjorn Andersson 
>> ---
>>
>> Changes since v3:
>> - Made msg_header const in wcn36xx_smd_rsp_process()
>>
>> Changes since v2:
>> - Correct the call to the new ieee80211_scan_completed()
>>
>>  drivers/net/wireless/ath/wcn36xx/dxe.c | 16 +++---
>>  drivers/net/wireless/ath/wcn36xx/main.c| 79 
>> --
>>  drivers/net/wireless/ath/wcn36xx/smd.c | 31 +---
>>  drivers/net/wireless/ath/wcn36xx/smd.h |  5 ++
>>  drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 21 +++-
>>  5 files changed, 86 insertions(+), 66 deletions(-)
>
> This doesn't compile for me:
>

I thought I mentioned this in the mail, sorry for missing that.

There is a patch for this issue in linux-next already [1] which is
part of [2], which was part of the pull request to arm-soc for
inclusion in v4.9.

[1] https://patchwork.kernel.org/patch/9272457/
[2] 
https://git.kernel.org/cgit/linux/kernel/git/agross/linux.git/tag/?h=qcom-drivers-for-4.9

Regards,
Bjorn

RE: mwifiex: add PCIe function level reset support

[Amitkumar Karwar]

Hi Kalle,

> From: linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless-
> ow...@vger.kernel.org] On Behalf Of Kalle Valo
> Sent: Saturday, September 03, 2016 9:10 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Amitkumar Karwar
> Subject: Re: mwifiex: add PCIe function level reset support
> 
> Amitkumar Karwar  wrote:
> > This patch implements pre and post FLR handlers to support PCIe FLR
> > functionality. Software cleanup is performed in pre-FLR whereas
> > firmware is downloaded and software is re-initialised in post-FLR
> > handler.
> >
> > Following command triggers FLR.
> > echo "1" > /sys/bus/pci/devices/$NUMBER/reset
> >
> > This feature can be used as a recovery mechanism when firmware gets
> > hang.
> >
> > Signed-off-by: Amitkumar Karwar 
> 
> Doesn't apply anymore, please rebase.
> 
> Applying: mwifiex: add PCIe function level reset support
> fatal: sha1 information is lacking or useless
> (drivers/net/wireless/marvell/mwifiex/main.c).
> Repository lacks necessary blobs to fall back on 3-way merge.
> Cannot fall back to three-way merge.
> Patch failed at 0001 mwifiex: add PCIe function level reset support
> 

It gets applied smoothly if below patches are applied first.
https://patchwork.kernel.org/patch/9310499/ ([v5,1/2] mwifiex: add 
manufacturing mode support)
https://patchwork.kernel.org/patch/9310501/ ([v5,2/2] mwifiex: add cfg80211 
testmode support)

Please let me know if you want me to rebase "PCIe function level reset 
support". In that case I need to rebase and send above 2 patches as well.

Regards,
Amitkumar

Re: Stability connection problems in ath9k kernel 4.7

[Valerio Passini]

On giovedì 8 settembre 2016 16:11:49 CEST Valerio Passini wrote:
I missed a line in copy-paste, sorry.
Valerio

git bisect start
# good: [2dcd0af568b0cf583645c8a317dd12e344b1c72a] Linux 4.6
git bisect good 2dcd0af568b0cf583645c8a317dd12e344b1c72a
# bad: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7
git bisect bad 523d939ef98fd712632d93a5a2b588e477a7565e
# good: [0694f0c9e20c47063e4237e5f6649ae5ce5a369a] radix tree test suite: 
remove dependencies on height
git bisect good 0694f0c9e20c47063e4237e5f6649ae5ce5a369a
# good: [e4f7bdc2ec0d0dcc27f7d70db27a620dfdc1f697] Merge branch 'for-4.7-zac' 
of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata
git bisect good e4f7bdc2ec0d0dcc27f7d70db27a620dfdc1f697
# bad: [049ec1b5a76d34a6980cccdb7c0baeb4eed7a993] Merge tag 'drm-fixes-for-
v4.7-rc2' of git://people.freedesktop.org/~airlied/linux
git bisect bad 049ec1b5a76d34a6980cccdb7c0baeb4eed7a993
# good: [a10c38a4f385f5d7c173a263ff6bb2d36021b3bb] Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client
git bisect good a10c38a4f385f5d7c173a263ff6bb2d36021b3bb
# bad: [9ba55cf7cfbfd12a7e914d0d55b7581e896b3f0d] Merge branch 'for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending
git bisect bad 9ba55cf7cfbfd12a7e914d0d55b7581e896b3f0d
# bad: [c61b49c79e1c1d4bc0c2fdc053ef56e65759b5fd] Merge tag 'drm-fixes-v4.7-
rc1' of git://people.freedesktop.org/~airlied/linux
git bisect bad c61b49c79e1c1d4bc0c2fdc053ef56e65759b5fd
# good: [dc03c0f9d12d85286d5e3623aa96d5c2a271b8e6] Merge branch 'misc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild
git bisect good dc03c0f9d12d85286d5e3623aa96d5c2a271b8e6
# good: [e28e909c36bb5d6319953822d84df00fce7cbd18] Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/virt/kvm/kvm
git bisect good e28e909c36bb5d6319953822d84df00fce7cbd18
# good: [79b3c7164c18e2fe9e69b0dcc0d45bab7ae3c968] Merge branch 'drm-next-4.7' 
of git://people.freedesktop.org/~agd5f/linux into drm-next
git bisect good 79b3c7164c18e2fe9e69b0dcc0d45bab7ae3c968
# bad: [1e8143db755f745a9842984de5e8b423f583aea2] Merge tag 'platform-drivers-
x86-v4.7-1' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86
git bisect bad 1e8143db755f745a9842984de5e8b423f583aea2
# good: [afcedebc6a094224973534f43b396bbbf33fe44e] thinkpad_acpi: save 
kbdlight state on suspend and restore it on resume
git bisect good afcedebc6a094224973534f43b396bbbf33fe44e
# good: [2aac630429d986a43ac59525a4cff47a624dc58e] iommu/vt-d: change intel-
iommu to use IOVA frame numbers
git bisect good 2aac630429d986a43ac59525a4cff47a624dc58e
# bad: [2566278551d3db875bc3bbfc41b42f2e80392108] Merge git://
git.infradead.org/intel-iommu
git bisect bad 2566278551d3db875bc3bbfc41b42f2e80392108
# bad: [22e2f9fa63b092923873fc8a52955151f4d83274] iommu/vt-d: Use per-cpu IOVA 
caching
git bisect bad 22e2f9fa63b092923873fc8a52955151f4d83274
# bad: [9257b4a206fc0229dd5f84b78e4d1ebf3f91d270] iommu/iova: introduce per-
cpu caching to iova allocation
git bisect bad 9257b4a206fc0229dd5f84b78e4d1ebf3f91d270
# first bad commit: [9257b4a206fc0229dd5f84b78e4d1ebf3f91d270] iommu/iova: 
introduce per-cpu caching to iova allocation

Re: Stability connection problems in ath9k kernel 4.7

[Valerio Passini]

On mercoledì 7 settembre 2016 11:32:24 CEST Kalle Valo wrote:
> Valerio Passini  writes:
> > I have found some connection problems since 4.7 release using ath9k that
> > turn the wifi pretty useless, I think it might be something in the power
> > management because the signal seems really low. Previously, up to kernel
> > 4.6.7 everything worked very well.
> > 
> > This is a sample of dmesg in kernel 4.7.2:
> >  239.898935] wlp4s0: authenticate with XX:XX:XX:XX:XX:XX
> > 
> > [  239.919995] wlp4s0: send auth to XX:XX:XX:XX:XX:XX  (try 1/3)
> > [  239.931877] wlp4s0: authenticated
> > [  239.932357] wlp4s0: associate with XX:XX:XX:XX:XX:XX  (try 1/3)
> > [  239.942171] wlp4s0: RX AssocResp from XX:XX:XX:XX:XX:XX  (capab=0x431
> > status=0 aid=2)
> > [  239.942301] wlp4s0: associated
> > [  244.802853] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x0024
> > AR_DIAG_SW=0x0220 DMADBG_7=0x
> > 6100
> > [  245.931832] wlp4s0: authenticate with XX:XX:XX:XX:XX:XX
> > [  245.953028] wlp4s0: send auth to XX:XX:XX:XX:XX:XX  (try 1/3)
> > [  245.958702] wlp4s0: authenticated
> > [  245.960386] wlp4s0: associate withXX:XX:XX:XX:XX:XX  (try 1/3)
> > [  245.980543] wlp4s0: RX AssocResp from XX:XX:XX:XX:XX:XX  (capab=0x431
> > status=0 aid=2)
> > 
> > lspci on 4.6.7 kernel:
> > 04:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network
> > Adapter (rev 01)
> > 
> > Subsystem: AzureWave AR9485 Wireless Network Adapter
> > Flags: bus master, fast devsel, latency 0, IRQ 18
> > Memory at f790 (64-bit, non-prefetchable) [size=512K]
> > Expansion ROM at f798 [disabled] [size=64K]
> > Capabilities: [40] Power Management version 2
> > Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
> > Capabilities: [70] Express Endpoint, MSI 00
> > Capabilities: [100] Advanced Error Reporting
> > Capabilities: [140] Virtual Channel
> > Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
> > Kernel driver in use: ath9k
> > Kernel modules: ath9k
> > 
> > Probably you need some debugging output, but before recompiling the kernel
> > I would like to know if you are interested in any kind of help from me
> > and what steps I should take (I'm able to help in testing patches but I'm
> > not familiar with git). Thank you
> 
> Usually it's really helpful if you can find the commit id which broke
> it. 'git bisect' is a great tool to do that and this seems to be a nice
> tutorial how to use it:
> 
> http://webchick.net/node/99
> 
> Instead of commit ids you can use release tags like v4.6 and v4.7 to
> make it easier to start the bisect. Just make sure that v4.7 is really
> broken and v4.6 works before you start the bisection.

Hi Kalle,

I tried to understand the whole procedure related to git and git bisect, and 
this is the first time I try it, so I can have done some mistake. In the git 
log you'll find the commit that could be guilty for the behaviour I reported 
yesterday. Anyhow, the resulting commit doesn't make any sense to me. If you 
have any request, please send an email in cc to me, because I want to 
unsuscribe this mailing list since it's too high volume for me. Best regards

Valerio

git bisect log

git bisect start
# good: [2dcd0af568b0cf583645c8a317dd12e344b1c72a] Linux 4.6
git bisect good 2dcd0af568b0cf583645c8a317dd12e344b1c72a
# bad: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7
git bisect bad 523d939ef98fd712632d93a5a2b588e477a7565e
# good: [0694f0c9e20c47063e4237e5f6649ae5ce5a369a] radix tree test suite: 
remove dependencies on height
git bisect good 0694f0c9e20c47063e4237e5f6649ae5ce5a369a
# good: [e4f7bdc2ec0d0dcc27f7d70db27a620dfdc1f697] Merge branch 'for-4.7-zac' 
of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata
git bisect good e4f7bdc2ec0d0dcc27f7d70db27a620dfdc1f697
# bad: [049ec1b5a76d34a6980cccdb7c0baeb4eed7a993] Merge tag 'drm-fixes-for-
v4.7-rc2' of git://people.freedesktop.org/~airlied/linux
git bisect bad 049ec1b5a76d34a6980cccdb7c0baeb4eed7a993
# good: [a10c38a4f385f5d7c173a263ff6bb2d36021b3bb] Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client
git bisect good a10c38a4f385f5d7c173a263ff6bb2d36021b3bb
# bad: [9ba55cf7cfbfd12a7e914d0d55b7581e896b3f0d] Merge branch 'for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending
git bisect bad 9ba55cf7cfbfd12a7e914d0d55b7581e896b3f0d
# bad: [c61b49c79e1c1d4bc0c2fdc053ef56e65759b5fd] Merge tag 'drm-fixes-v4.7-
rc1' of git://people.freedesktop.org/~airlied/linux
git bisect bad c61b49c79e1c1d4bc0c2fdc053ef56e65759b5fd
# good: [dc03c0f9d12d85286d5e3623aa96d5c2a271b8e6] Merge branch 'misc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild
git bisect good dc03c0f9d12d85286d5e3623aa96d5c2a271b8e6
# good: [e28e909c36bb5d6319953822d84df00fce7cbd18] Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/virt/kvm/kvm
git 

Re: rtl8xxxu: fix spelling mistake "firmare" -> "firmware"

[Kalle Valo]

Colin Ian King  wrote:
> From: Colin Ian King 
> 
> Trivial fix to spelling mistakes in dev_dbg message.
> 
> Signed-off-by: Colin Ian King 
> Reviewed-by: Julian Calaby 

I assume Jes will take this.

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9312169/

Re: [PATCH v4 2/4] wcn36xx: Transition driver to SMD client

[Kalle Valo]

Bjorn Andersson  writes:

> The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
> channel, as such it should be a SMD client. This patch makes this
> transition, now that we have the necessary frameworks available.
>
> Signed-off-by: Bjorn Andersson 
> ---
>
> Changes since v3:
> - Made msg_header const in wcn36xx_smd_rsp_process()
>
> Changes since v2:
> - Correct the call to the new ieee80211_scan_completed()
>
>  drivers/net/wireless/ath/wcn36xx/dxe.c | 16 +++---
>  drivers/net/wireless/ath/wcn36xx/main.c| 79 
> --
>  drivers/net/wireless/ath/wcn36xx/smd.c | 31 +---
>  drivers/net/wireless/ath/wcn36xx/smd.h |  5 ++
>  drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 21 +++-
>  5 files changed, 86 insertions(+), 66 deletions(-)

This doesn't compile for me:

  CC [M]  drivers/net/wireless/ath/wcn36xx/main.o
  CC [M]  drivers/net/wireless/ath/wcn36xx/dxe.o
  CC [M]  drivers/net/wireless/ath/wcn36xx/txrx.o
  CC [M]  drivers/net/wireless/ath/wcn36xx/smd.o
  CC [M]  drivers/net/wireless/ath/wcn36xx/pmc.o
  CC [M]  drivers/net/wireless/ath/wcn36xx/debug.o
  LD [M]  drivers/net/wireless/ath/wcn36xx/wcn36xx.o
drivers/net/wireless/ath/wcn36xx/smd.o: In function `qcom_smd_get_drvdata':
/home/kvalo/ath10k/src/ath/./include/linux/soc/qcom/smd.h:87: multiple 
definition of `qcom_smd_get_drvdata'
drivers/net/wireless/ath/wcn36xx/main.o:/home/kvalo/ath10k/src/ath/./include/linux/soc/qcom/smd.h:87:
 first defined here
drivers/net/wireless/ath/wcn36xx/smd.o: In function `qcom_smd_set_drvdata':
/home/kvalo/ath10k/src/ath/./include/linux/soc/qcom/smd.h:94: multiple 
definition of `qcom_smd_set_drvdata'
drivers/net/wireless/ath/wcn36xx/main.o:/home/kvalo/ath10k/src/ath/./include/linux/soc/qcom/smd.h:94:
 first defined here
make[5]: *** [drivers/net/wireless/ath/wcn36xx/wcn36xx.o] Error 1

I fixed it with the diff below. Please let me know if it looks ok to
you, the patch is not applied yet so it's easy to make changes. The full
commit in my pending branch:

https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending=dba68ea7a404a9959d0ab44bc13c844187db6d6a

--- a/include/linux/soc/qcom/smd.h
+++ b/include/linux/soc/qcom/smd.h
@@ -83,14 +83,14 @@ qcom_smd_open_channel(struct qcom_smd_channel *channel,
return NULL;
 }
 
-void *qcom_smd_get_drvdata(struct qcom_smd_channel *channel)
+static inline void *qcom_smd_get_drvdata(struct qcom_smd_channel *channel)
 {
/* This shouldn't be possible */
WARN_ON(1);
return NULL;
 }
 
-void qcom_smd_set_drvdata(struct qcom_smd_channel *channel, void *data)
+static inline void qcom_smd_set_drvdata(struct qcom_smd_channel *channel, void 
*data)
 {
/* This shouldn't be possible */
WARN_ON(1);


-- 
Kalle Valo

Re: [PATCH 1/2] ath9k: use ieee80211_tx_status_noskb where possible

[Felix Fietkau]

On 2016-09-08 13:41, Kalle Valo wrote:
> Zefir Kurtisi  writes:
> 
>> On 08/11/2016 09:27 PM, Felix Fietkau wrote:
>>> On 2016-08-11 18:05, Zefir Kurtisi wrote:
 On 08/04/2016 11:49 PM, Felix Fietkau wrote:
> It removes the need for undoing the padding changes to skb->data and it
> improves performance by eliminating one tx status lookup per MPDU in the
> status path. It is also useful for preparing a follow-up fix to better
> handle powersave filtering.
>

 For me, this one introduces a regression to the statistics, e.g.
 'dot11TransmittedFragmentCount' is now accounted differently since it is 
 not
 updated from within ieee80211_tx_status_noskb().
>>> Is this important? I guess it would be possible to make this more
>>> accurate by extending the API, but I wonder if that's worth doing just
>>> for these debugfs counters.
>>> 
>> If you want to support the IEEE802dot11.MIB (dot11mac.dot11CountersTable), 
>> they
>> are important. Not sure though if it is used by others besides us.
>>
>> I think the real issue here is that those counters are regarded as internal 
>> debug
>> values (as the comments or e.g. commit c206ca6709 state) instead of general
>> purpose statistics that is exposed to SNMP. As such, they should be 
>> configurable
>> as a feature independent of debug settings in mac80211.
>>
>>
>> Aside from that consideration, this patch (with the follow up ones) 
>> increased peak
>> performance noticeably (we measure some 5%+ higher peak throughput), which 
>> for
>> sure is worth dropping the counters for most.
>>
>> I am fine handling this internally. A note in the commit message would be 
>> helpful
>> that states that counters dot11TransmittedFragmentCount, 
>> dot11FrameDuplicateCount,
>> dot11ReceivedFragmentCount, and dot11MulticastReceivedFrameCount become 
>> invalid.
> 
> A good idea, I updated the commit log to mention that. Does that look
> ok?
> 
> Author: Felix Fietkau 
> Date:   Fri Sep 2 19:46:12 2016 +0300
> 
> ath9k: use ieee80211_tx_status_noskb where possible
> 
> It removes the need for undoing the padding changes to skb->data and it
> improves performance by eliminating one tx status lookup per MPDU in the
> status path. It is also useful for preparing a follow-up fix to better
> handle powersave filtering.
> 
> A side effect is that these counters, available via debugfs, become now 
> invalid:
> 
> * dot11TransmittedFragmentCount
> * dot11FrameDuplicateCount,
> * dot11ReceivedFragmentCount
> * dot11MulticastReceivedFrameCount
> 
> Signed-off-by: Felix Fietkau 
Looks good to me.

- Felix

Re: [PATCH 1/2] ath9k: use ieee80211_tx_status_noskb where possible

[Kalle Valo]

Zefir Kurtisi  writes:

> On 08/11/2016 09:27 PM, Felix Fietkau wrote:
>> On 2016-08-11 18:05, Zefir Kurtisi wrote:
>>> On 08/04/2016 11:49 PM, Felix Fietkau wrote:
 It removes the need for undoing the padding changes to skb->data and it
 improves performance by eliminating one tx status lookup per MPDU in the
 status path. It is also useful for preparing a follow-up fix to better
 handle powersave filtering.

>>>
>>> For me, this one introduces a regression to the statistics, e.g.
>>> 'dot11TransmittedFragmentCount' is now accounted differently since it is not
>>> updated from within ieee80211_tx_status_noskb().
>> Is this important? I guess it would be possible to make this more
>> accurate by extending the API, but I wonder if that's worth doing just
>> for these debugfs counters.
>> 
> If you want to support the IEEE802dot11.MIB (dot11mac.dot11CountersTable), 
> they
> are important. Not sure though if it is used by others besides us.
>
> I think the real issue here is that those counters are regarded as internal 
> debug
> values (as the comments or e.g. commit c206ca6709 state) instead of general
> purpose statistics that is exposed to SNMP. As such, they should be 
> configurable
> as a feature independent of debug settings in mac80211.
>
>
> Aside from that consideration, this patch (with the follow up ones) increased 
> peak
> performance noticeably (we measure some 5%+ higher peak throughput), which for
> sure is worth dropping the counters for most.
>
> I am fine handling this internally. A note in the commit message would be 
> helpful
> that states that counters dot11TransmittedFragmentCount, 
> dot11FrameDuplicateCount,
> dot11ReceivedFragmentCount, and dot11MulticastReceivedFrameCount become 
> invalid.

A good idea, I updated the commit log to mention that. Does that look
ok?

Author: Felix Fietkau 
Date:   Fri Sep 2 19:46:12 2016 +0300

ath9k: use ieee80211_tx_status_noskb where possible

It removes the need for undoing the padding changes to skb->data and it
improves performance by eliminating one tx status lookup per MPDU in the
status path. It is also useful for preparing a follow-up fix to better
handle powersave filtering.

A side effect is that these counters, available via debugfs, become now 
invalid:

* dot11TransmittedFragmentCount
* dot11FrameDuplicateCount,
* dot11ReceivedFragmentCount
* dot11MulticastReceivedFrameCount

Signed-off-by: Felix Fietkau 
Patchwork-Id: 9264385
[kv...@qca.qualcomm.com: add a note about counters, thanks to Zefir Kurtisi]
Signed-off-by: Kalle Valo 

-- 
Kalle Valo

pull-request: wireless-drivers 2016-09-08

[Kalle Valo]

Hi Dave,

few important, but as can be seen from the diffstat, really small fixes
for 4.8. Please let me know if you have any problems.

Kalle

The following changes since commit bb87f02b7e4ccdb614a83cbf840524de81e9b321:

  Merge ath-current from ath.git (2016-08-29 21:39:04 +0300)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git 
tags/wireless-drivers-for-davem-2016-09-08

for you to fetch changes up to a0714125d11bcf21599b08b25fdaf384c0db6712:

  Merge ath-current from ath.git (2016-09-07 20:16:37 +0300)



wireless-drivers fixes for 4.8

iwlwifi

* fix P2P dump trigger
* prevent a potential null dereference in iwlmvm
* prevent an uninitialized value from being returned in iwlmvm
* advertise support for channel width change in AP mode

ath10k

* fix racy rx status retrieval from htt context
* QCA9887 support is not experimental anymore, remove the warning message

ath9k

* fix regression with led GPIOs
* fix AR5416 GPIO access warning

brcmfmac

* avoid potential stack overflow in brcmf_cfg80211_start_ap()


Arend Van Spriel (1):
  brcmfmac: avoid potential stack overflow in brcmf_cfg80211_start_ap()

Ashok Raj Nagarajan (1):
  ath10k: fix get rx_status from htt context

Emmanuel Grumbach (2):
  iwlwifi: mvm: consider P2p device type for firmware dump triggers
  iwlwifi: mvm: don't use ret when not initialised

Giedrius Statkevičius (1):
  ath9k: bring back direction setting in ath9k_{start_stop}

Kalle Valo (2):
  Merge tag 'iwlwifi-for-kalle-2016-08-29' of 
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
  Merge ath-current from ath.git

Miaoqing Pan (1):
  ath9k: fix AR5416 access GPIO warning

Mohammed Shafi Shajakhan (1):
  ath10k: Remove driver log suggesting QCA9887 support is experimental

Peer, Ilan (1):
  iwlwifi: mvm: Advertise support for AP channel width change

Sharon Dvir (1):
  iwlwifi: mvm: check if vif is NULL before using it

 drivers/net/wireless/ath/ath10k/htt_rx.c   |   10 +-
 drivers/net/wireless/ath/ath10k/pci.c  |1 -
 drivers/net/wireless/ath/ath9k/hw.c|4 ++--
 drivers/net/wireless/ath/ath9k/main.c  |9 +++--
 .../broadcom/brcm80211/brcmfmac/cfg80211.c |2 +-
 drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c|3 ++-
 drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.h|3 ++-
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  |1 +
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h   |2 ++
 9 files changed, 22 insertions(+), 13 deletions(-)

Re: [PATCH v3 1/3] Documentation: dt: net: add mt76 wireless device binding

[Kalle Valo]

Felix Fietkau  writes:

> Signed-off-by: Felix Fietkau 
> ---
>  .../bindings/net/wireless/mediatek,mt76.txt| 26 
> ++
>  1 file changed, 26 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt 
> b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> new file mode 100644
> index 000..d51c35f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.txt
> @@ -0,0 +1,26 @@
> +* MediaTek mt76xx devices
> +
> +This node provides properties for configuring the MediaTek mt76xx wireless
> +device. The node is expected to be specified as a child node of the PCI
> +controller to which the wireless chip is connected.
> +
> +Optional properties:
> +
> +- mac-address: See ethernet.txt in the parent directory
> +- local-mac-address: See ethernet.txt in the parent directory
> +- mediatek,2ghz: Override the 2.4 GHz band capability from EEPROM
> +- mediatek,5ghz: Override the 5 GHz band capability from EEPROM
> +- mediatek,mtd-eeprom: Specify a MTD partition + offset containing EEPROM 
> data
> +
> + {
> + status = "okay";
> +
> + pcie0 {
> + mt76@0,0 {
> + reg = <0x 0 0 0 0>;
> + device_type = "pci";
> + mediatek,mtd-eeprom = < 0x8000>;
> + mediatek,2ghz = <0>;
> + };
> + };
> +};

I need an ack from device tree maintainers, CCing the devicetree list.
Do we need to resend or this ok?

Patchwork link:

https://patchwork.kernel.org/patch/9313309/

-- 
Kalle Valo

Re: [PATCH] rsi: code clean-up

[Kalle Valo]

Arend Van Spriel  writes:

> On 8-9-2016 7:36, Prameela Rani Garnepudi wrote:
>> From: Prameela Rani Garnepudi 
>
> Seems like you missed the essential training on main-line driver
> development :-p
>
> Typically you should split this up in conceptually separate patches so
> it is easier for people to review. A large patch changing things all
> over the place solving different things is taking a lot more time to review.
>
> So go work on branch, make a commit for each issue you want to address,
> and when ready do (using 6 commits as example):
>
> $ git format-patch -s -M --cover-letter -6
>
> The '--cover-letter' results in -...patch file in which you can
> summarize the changes in bullet list so Kalle can reuse that moving the
> patches upstream to networking subsystem.
>
> When done use git to send the patches:
>
> $ git send-email --to='Kalle Valo '
> --cc=linux-wireless@vger.kernel.org *.patch

And write a commit log for each patch. In minimum the commit log should
answer to the question "Why?".

A good way to learn how the this all works is to see how others do it.
For example, you can see all ath9k commits like this:

gitk drivers/net/wireless/ath/ath9k/

or iwlwifi:

gitk drivers/net/wireless/intel/iwlwifi/

-- 
Kalle Valo

Re: [PATCH] rsi: code clean-up

[Arend Van Spriel]

On 8-9-2016 7:36, Prameela Rani Garnepudi wrote:
> From: Prameela Rani Garnepudi 

Seems like you missed the essential training on main-line driver
development :-p

Typically you should split this up in conceptually separate patches so
it is easier for people to review. A large patch changing things all
over the place solving different things is taking a lot more time to review.

So go work on branch, make a commit for each issue you want to address,
and when ready do (using 6 commits as example):

$ git format-patch -s -M --cover-letter -6

The '--cover-letter' results in -...patch file in which you can
summarize the changes in bullet list so Kalle can reuse that moving the
patches upstream to networking subsystem.

When done use git to send the patches:

$ git send-email --to='Kalle Valo '
--cc=linux-wireless@vger.kernel.org *.patch

Regards,
> Signed-off-by: Prameela Rani Garnepudi 
> ---
>  drivers/net/wireless/rsi/rsi_91x_core.c |  18 ++--
>  drivers/net/wireless/rsi/rsi_91x_debugfs.c  |  13 +--
>  drivers/net/wireless/rsi/rsi_91x_mac80211.c |  81 +--
>  drivers/net/wireless/rsi/rsi_91x_main.c |  16 ++-
>  drivers/net/wireless/rsi/rsi_91x_mgmt.c | 155 
> +++-
>  drivers/net/wireless/rsi/rsi_91x_sdio.c |  14 +--
>  drivers/net/wireless/rsi/rsi_91x_sdio_ops.c |  11 +-
>  drivers/net/wireless/rsi/rsi_91x_usb.c  |  34 --
>  drivers/net/wireless/rsi/rsi_common.h   |   2 +-
>  drivers/net/wireless/rsi/rsi_debugfs.h  |   3 +-
>  drivers/net/wireless/rsi/rsi_main.h |  36 ---
>  drivers/net/wireless/rsi/rsi_mgmt.h |  54 +-
>  drivers/net/wireless/rsi/rsi_sdio.h |  18 ++--
>  13 files changed, 228 insertions(+), 227 deletions(-)
> 
> diff --git a/drivers/net/wireless/rsi/rsi_91x_core.c 
> b/drivers/net/wireless/rsi/rsi_91x_core.c
> index f3d3995..c6db8a9 100644
> --- a/drivers/net/wireless/rsi/rsi_91x_core.c
> +++ b/drivers/net/wireless/rsi/rsi_91x_core.c
> @@ -134,7 +134,7 @@ static u8 rsi_core_determine_hal_queue(struct rsi_common 
> *common)
>   bool recontend_queue = false;
>   u32 q_len = 0;
>   u8 q_num = INVALID_QUEUE;
> - u8 ii = 0;
> + u8 ii;
>  
>   if (skb_queue_len(>tx_queue[MGMT_SOFT_Q])) {
>   if (!common->mgmt_q_block)
> @@ -142,8 +142,10 @@ static u8 rsi_core_determine_hal_queue(struct rsi_common 
> *common)
>   return q_num;
>   }
>  
> - if (common->hw_data_qs_blocked)
> + if (common->hw_data_qs_blocked) {
> + rsi_dbg(INFO_ZONE, "%s: data queue blocked\n", __func__);
>   return q_num;
> + }
>  
>   if (common->pkt_cnt != 0) {
>   --common->pkt_cnt;
> @@ -210,6 +212,7 @@ static void rsi_core_queue_pkt(struct rsi_common *common,
>  struct sk_buff *skb)
>  {
>   u8 q_num = skb->priority;
> +
>   if (q_num >= NUM_SOFT_QUEUES) {
>   rsi_dbg(ERR_ZONE, "%s: Invalid Queue Number: q_num = %d\n",
>   __func__, q_num);
> @@ -285,7 +288,7 @@ void rsi_core_qos_processor(struct rsi_common *common)
>   }
>  
>   skb = rsi_core_dequeue_pkt(common, q_num);
> - if (skb == NULL) {
> + if (!skb) {
>   rsi_dbg(ERR_ZONE, "skb null\n");
>   mutex_unlock(>tx_rxlock);
>   break;
> @@ -331,15 +334,16 @@ void rsi_core_xmit(struct rsi_common *common, struct 
> sk_buff *skb)
>   __func__);
>   goto xmit_fail;
>   }
> - info = IEEE80211_SKB_CB(skb);
> - tx_params = (struct skb_info *)info->driver_data;
> - tmp_hdr = (struct ieee80211_hdr *)>data[0];
>  
>   if (common->fsm_state != FSM_MAC_INIT_DONE) {
>   rsi_dbg(ERR_ZONE, "%s: FSM state not open\n", __func__);
>   goto xmit_fail;
>   }
>  
> + info = IEEE80211_SKB_CB(skb);
> + tx_params = (struct skb_info *)info->driver_data;
> + tmp_hdr = (struct ieee80211_hdr *)>data[0];
> +
>   if ((ieee80211_is_mgmt(tmp_hdr->frame_control)) ||
>   (ieee80211_is_ctl(tmp_hdr->frame_control)) ||
>   (ieee80211_is_qos_nullfunc(tmp_hdr->frame_control))) {
> @@ -360,7 +364,7 @@ void rsi_core_xmit(struct rsi_common *common, struct 
> sk_buff *skb)
>  
>   if ((q_num != MGMT_SOFT_Q) &&
>   ((skb_queue_len(>tx_queue[q_num]) + 1) >=
> -  DATA_QUEUE_WATER_MARK)) {
> +  DATA_QUEUE_WATER_MARK)) {
>   rsi_dbg(ERR_ZONE, "%s: sw queue full\n", __func__);
>   if (!ieee80211_queue_stopped(adapter->hw, WME_AC(q_num)))
>   ieee80211_stop_queue(adapter->hw, WME_AC(q_num));
> diff --git a/drivers/net/wireless/rsi/rsi_91x_debugfs.c 
> b/drivers/net/wireless/rsi/rsi_91x_debugfs.c
> index 828a042..5ec7bce 100644
> --- 

Re: [PATCH v3 3/3] mt76: add driver code for MT76x2e

[Sergey Ryazanov]

2016-09-08 11:25 GMT+03:00 Felix Fietkau :
> On 2016-09-08 09:52, Sergey Ryazanov wrote:
>>> +
>>> +int mt76x2_register_device(struct mt76x2_dev *dev)
>>> +{
>>> +   struct ieee80211_hw *hw = mt76_hw(dev);
>>> +   struct wiphy *wiphy = hw->wiphy;
>>> +   void *status_fifo;
>>> +   int fifo_size;
>>> +   int i, ret;
>>> +
>>> +   fifo_size = roundup_pow_of_two(32 * sizeof(struct 
>>> mt76x2_tx_status));
>>> +   status_fifo = devm_kzalloc(dev->mt76.dev, fifo_size, GFP_KERNEL);
>>> +   if (!status_fifo)
>>> +   return -ENOMEM;
>>> +
>>> +   kfifo_init(>txstatus_fifo, status_fifo, fifo_size);
>>> +
>>> +   ret = mt76x2_init_hardware(dev);
>>> +   if (ret)
>>> +   return ret;
>>> +
>>> +   hw->queues = 4;
>>> +   hw->max_rates = 1;
>>> +   hw->max_report_rates = 7;
>>> +   hw->max_rate_tries = 1;
>>> +   hw->extra_tx_headroom = 2;
>>> +
>>> +   hw->sta_data_size = sizeof(struct mt76x2_sta);
>>> +   hw->vif_data_size = sizeof(struct mt76x2_vif);
>>> +
>>> +   for (i = 0; i < ARRAY_SIZE(dev->macaddr_list); i++) {
>>> +   u8 *addr = dev->macaddr_list[i].addr;
>>> +
>>> +   memcpy(addr, dev->mt76.macaddr, ETH_ALEN);
>>> +
>>> +   if (!i)
>>> +   continue;
>>> +
>>> +   addr[0] |= BIT(1);
>>> +   addr[0] ^= ((i - 1) << 2);
>>> +   }
>>> +   wiphy->addresses = dev->macaddr_list;
>>> +   wiphy->n_addresses = ARRAY_SIZE(dev->macaddr_list);
>>> +
>>> +   wiphy->iface_combinations = if_comb;
>>> +   wiphy->n_iface_combinations = ARRAY_SIZE(if_comb);
>>> +
>>> +   wiphy_ext_feature_set(wiphy, NL80211_EXT_FEATURE_VHT_IBSS);
>>> +
>>> +   ieee80211_hw_set(hw, SUPPORTS_HT_CCK_RATES);
>>> +   INIT_DELAYED_WORK(>cal_work, mt76x2_phy_calibrate);
>>> +   INIT_DELAYED_WORK(>mac_work, mt76x2_mac_work);
>>> +
>>> +   dev->mt76.sband_2g.sband.ht_cap.cap |= IEEE80211_HT_CAP_LDPC_CODING;
>>> +   dev->mt76.sband_5g.sband.ht_cap.cap |= IEEE80211_HT_CAP_LDPC_CODING;
>>> +
>>> +   ret = mt76_register_device(>mt76, true, mt76x2_rates,
>>> +  ARRAY_SIZE(mt76x2_rates));
>>> +   if (ret)
>>> +   goto fail;
>>> +
>>> +   mt76x2_init_debugfs(dev);
>>> +
>>> +   return 0;
>>> +
>>> +fail:
>>> +   mt76x2_stop_hardware(dev);
>>> +   return ret;
>>> +}
>>
>> Just curious, almost full chip initialization performed in probe
>> procedure, why not do that in start() callback? In such case we could
>> fully restart chip without module reloading, just with ifdown/ifup
>> circle.
> Last time I tried that I ran into some weird chip quirks. I do think
> it's a good idea but I'd rather see this merged first and try again to
> rework it when I have some more time to figure out what's going on.
>
Got it. Thank you for explanation.

-- 
Sergey

Re: [PATCH v3 3/3] mt76: add driver code for MT76x2e

[Felix Fietkau]

On 2016-09-08 09:52, Sergey Ryazanov wrote:
>> +
>> +int mt76x2_register_device(struct mt76x2_dev *dev)
>> +{
>> +   struct ieee80211_hw *hw = mt76_hw(dev);
>> +   struct wiphy *wiphy = hw->wiphy;
>> +   void *status_fifo;
>> +   int fifo_size;
>> +   int i, ret;
>> +
>> +   fifo_size = roundup_pow_of_two(32 * sizeof(struct mt76x2_tx_status));
>> +   status_fifo = devm_kzalloc(dev->mt76.dev, fifo_size, GFP_KERNEL);
>> +   if (!status_fifo)
>> +   return -ENOMEM;
>> +
>> +   kfifo_init(>txstatus_fifo, status_fifo, fifo_size);
>> +
>> +   ret = mt76x2_init_hardware(dev);
>> +   if (ret)
>> +   return ret;
>> +
>> +   hw->queues = 4;
>> +   hw->max_rates = 1;
>> +   hw->max_report_rates = 7;
>> +   hw->max_rate_tries = 1;
>> +   hw->extra_tx_headroom = 2;
>> +
>> +   hw->sta_data_size = sizeof(struct mt76x2_sta);
>> +   hw->vif_data_size = sizeof(struct mt76x2_vif);
>> +
>> +   for (i = 0; i < ARRAY_SIZE(dev->macaddr_list); i++) {
>> +   u8 *addr = dev->macaddr_list[i].addr;
>> +
>> +   memcpy(addr, dev->mt76.macaddr, ETH_ALEN);
>> +
>> +   if (!i)
>> +   continue;
>> +
>> +   addr[0] |= BIT(1);
>> +   addr[0] ^= ((i - 1) << 2);
>> +   }
>> +   wiphy->addresses = dev->macaddr_list;
>> +   wiphy->n_addresses = ARRAY_SIZE(dev->macaddr_list);
>> +
>> +   wiphy->iface_combinations = if_comb;
>> +   wiphy->n_iface_combinations = ARRAY_SIZE(if_comb);
>> +
>> +   wiphy_ext_feature_set(wiphy, NL80211_EXT_FEATURE_VHT_IBSS);
>> +
>> +   ieee80211_hw_set(hw, SUPPORTS_HT_CCK_RATES);
>> +   INIT_DELAYED_WORK(>cal_work, mt76x2_phy_calibrate);
>> +   INIT_DELAYED_WORK(>mac_work, mt76x2_mac_work);
>> +
>> +   dev->mt76.sband_2g.sband.ht_cap.cap |= IEEE80211_HT_CAP_LDPC_CODING;
>> +   dev->mt76.sband_5g.sband.ht_cap.cap |= IEEE80211_HT_CAP_LDPC_CODING;
>> +
>> +   ret = mt76_register_device(>mt76, true, mt76x2_rates,
>> +  ARRAY_SIZE(mt76x2_rates));
>> +   if (ret)
>> +   goto fail;
>> +
>> +   mt76x2_init_debugfs(dev);
>> +
>> +   return 0;
>> +
>> +fail:
>> +   mt76x2_stop_hardware(dev);
>> +   return ret;
>> +}
> 
> Just curious, almost full chip initialization performed in probe
> procedure, why not do that in start() callback? In such case we could
> fully restart chip without module reloading, just with ifdown/ifup
> circle.
Last time I tried that I ran into some weird chip quirks. I do think
it's a good idea but I'd rather see this merged first and try again to
rework it when I have some more time to figure out what's going on.

- Felix

Re: [PATCH v3 3/3] mt76: add driver code for MT76x2e

[Sergey Ryazanov]

First of all I would like to thank you Felix for this great job!
Please find one simple question below.

2016-09-05 12:51 GMT+03:00 Felix Fietkau :
> From: Felix Fietkau 
>
> This is a 2x2 PCIe 802.11ac chipset by MediaTek
>

[skip]

> +int mt76x2_init_hardware(struct mt76x2_dev *dev)
> +{
> +   static const u16 beacon_offsets[16] = {
> +   /* 1024 byte per beacon */
> +   0xc000,
> +   0xc400,
> +   0xc800,
> +   0xcc00,
> +   0xd000,
> +   0xd400,
> +   0xd800,
> +   0xdc00,
> +
> +   /* BSS idx 8-15 not used for beacons */
> +   0xc000,
> +   0xc000,
> +   0xc000,
> +   0xc000,
> +   0xc000,
> +   0xc000,
> +   0xc000,
> +   0xc000,
> +   };
> +   u32 val;
> +   int ret;
> +
> +   dev->beacon_offsets = beacon_offsets;
> +   tasklet_init(>pre_tbtt_tasklet, mt76x2_pre_tbtt_tasklet,
> +(unsigned long) dev);
> +
> +   dev->chainmask = 0x202;
> +   dev->global_wcid.idx = 255;
> +   dev->global_wcid.hw_key_idx = -1;
> +   dev->slottime = 9;
> +
> +   val = mt76_rr(dev, MT_WPDMA_GLO_CFG);
> +   val &= MT_WPDMA_GLO_CFG_DMA_BURST_SIZE |
> +  MT_WPDMA_GLO_CFG_BIG_ENDIAN |
> +  MT_WPDMA_GLO_CFG_HDR_SEG_LEN;
> +   val |= MT_WPDMA_GLO_CFG_TX_WRITEBACK_DONE;
> +   mt76_wr(dev, MT_WPDMA_GLO_CFG, val);
> +
> +   mt76x2_reset_wlan(dev, true);
> +   mt76x2_power_on(dev);
> +
> +   ret = mt76x2_eeprom_init(dev);
> +   if (ret)
> +   return ret;
> +
> +   ret = mt76x2_mac_reset(dev, true);
> +   if (ret)
> +   return ret;
> +
> +   ret = mt76x2_dma_init(dev);
> +   if (ret)
> +   return ret;
> +
> +   set_bit(MT76_STATE_INITIALIZED, >mt76.state);
> +   ret = mt76x2_mac_start(dev);
> +   if (ret)
> +   return ret;
> +
> +   ret = mt76x2_mcu_init(dev);
> +   if (ret)
> +   return ret;
> +
> +   mt76x2_mac_stop(dev, false);
> +   dev->rxfilter = mt76_rr(dev, MT_RX_FILTR_CFG);
> +
> +   return 0;
> +}

[skip]

> +
> +int mt76x2_register_device(struct mt76x2_dev *dev)
> +{
> +   struct ieee80211_hw *hw = mt76_hw(dev);
> +   struct wiphy *wiphy = hw->wiphy;
> +   void *status_fifo;
> +   int fifo_size;
> +   int i, ret;
> +
> +   fifo_size = roundup_pow_of_two(32 * sizeof(struct mt76x2_tx_status));
> +   status_fifo = devm_kzalloc(dev->mt76.dev, fifo_size, GFP_KERNEL);
> +   if (!status_fifo)
> +   return -ENOMEM;
> +
> +   kfifo_init(>txstatus_fifo, status_fifo, fifo_size);
> +
> +   ret = mt76x2_init_hardware(dev);
> +   if (ret)
> +   return ret;
> +
> +   hw->queues = 4;
> +   hw->max_rates = 1;
> +   hw->max_report_rates = 7;
> +   hw->max_rate_tries = 1;
> +   hw->extra_tx_headroom = 2;
> +
> +   hw->sta_data_size = sizeof(struct mt76x2_sta);
> +   hw->vif_data_size = sizeof(struct mt76x2_vif);
> +
> +   for (i = 0; i < ARRAY_SIZE(dev->macaddr_list); i++) {
> +   u8 *addr = dev->macaddr_list[i].addr;
> +
> +   memcpy(addr, dev->mt76.macaddr, ETH_ALEN);
> +
> +   if (!i)
> +   continue;
> +
> +   addr[0] |= BIT(1);
> +   addr[0] ^= ((i - 1) << 2);
> +   }
> +   wiphy->addresses = dev->macaddr_list;
> +   wiphy->n_addresses = ARRAY_SIZE(dev->macaddr_list);
> +
> +   wiphy->iface_combinations = if_comb;
> +   wiphy->n_iface_combinations = ARRAY_SIZE(if_comb);
> +
> +   wiphy_ext_feature_set(wiphy, NL80211_EXT_FEATURE_VHT_IBSS);
> +
> +   ieee80211_hw_set(hw, SUPPORTS_HT_CCK_RATES);
> +   INIT_DELAYED_WORK(>cal_work, mt76x2_phy_calibrate);
> +   INIT_DELAYED_WORK(>mac_work, mt76x2_mac_work);
> +
> +   dev->mt76.sband_2g.sband.ht_cap.cap |= IEEE80211_HT_CAP_LDPC_CODING;
> +   dev->mt76.sband_5g.sband.ht_cap.cap |= IEEE80211_HT_CAP_LDPC_CODING;
> +
> +   ret = mt76_register_device(>mt76, true, mt76x2_rates,
> +  ARRAY_SIZE(mt76x2_rates));
> +   if (ret)
> +   goto fail;
> +
> +   mt76x2_init_debugfs(dev);
> +
> +   return 0;
> +
> +fail:
> +   mt76x2_stop_hardware(dev);
> +   return ret;
> +}

Just curious, almost full chip initialization performed in probe
procedure, why not do that in start() callback? In such case we could
fully restart chip without module reloading, just with ifdown/ifup
circle.

-- 
Sergey

[PATCH] rsi: code clean-up

[Prameela Rani Garnepudi]

From: Prameela Rani Garnepudi 

Signed-off-by: Prameela Rani Garnepudi 
---
 drivers/net/wireless/rsi/rsi_91x_core.c |  18 ++--
 drivers/net/wireless/rsi/rsi_91x_debugfs.c  |  13 +--
 drivers/net/wireless/rsi/rsi_91x_mac80211.c |  81 +--
 drivers/net/wireless/rsi/rsi_91x_main.c |  16 ++-
 drivers/net/wireless/rsi/rsi_91x_mgmt.c | 155 +++-
 drivers/net/wireless/rsi/rsi_91x_sdio.c |  14 +--
 drivers/net/wireless/rsi/rsi_91x_sdio_ops.c |  11 +-
 drivers/net/wireless/rsi/rsi_91x_usb.c  |  34 --
 drivers/net/wireless/rsi/rsi_common.h   |   2 +-
 drivers/net/wireless/rsi/rsi_debugfs.h  |   3 +-
 drivers/net/wireless/rsi/rsi_main.h |  36 ---
 drivers/net/wireless/rsi/rsi_mgmt.h |  54 +-
 drivers/net/wireless/rsi/rsi_sdio.h |  18 ++--
 13 files changed, 228 insertions(+), 227 deletions(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_core.c 
b/drivers/net/wireless/rsi/rsi_91x_core.c
index f3d3995..c6db8a9 100644
--- a/drivers/net/wireless/rsi/rsi_91x_core.c
+++ b/drivers/net/wireless/rsi/rsi_91x_core.c
@@ -134,7 +134,7 @@ static u8 rsi_core_determine_hal_queue(struct rsi_common 
*common)
bool recontend_queue = false;
u32 q_len = 0;
u8 q_num = INVALID_QUEUE;
-   u8 ii = 0;
+   u8 ii;
 
if (skb_queue_len(>tx_queue[MGMT_SOFT_Q])) {
if (!common->mgmt_q_block)
@@ -142,8 +142,10 @@ static u8 rsi_core_determine_hal_queue(struct rsi_common 
*common)
return q_num;
}
 
-   if (common->hw_data_qs_blocked)
+   if (common->hw_data_qs_blocked) {
+   rsi_dbg(INFO_ZONE, "%s: data queue blocked\n", __func__);
return q_num;
+   }
 
if (common->pkt_cnt != 0) {
--common->pkt_cnt;
@@ -210,6 +212,7 @@ static void rsi_core_queue_pkt(struct rsi_common *common,
   struct sk_buff *skb)
 {
u8 q_num = skb->priority;
+
if (q_num >= NUM_SOFT_QUEUES) {
rsi_dbg(ERR_ZONE, "%s: Invalid Queue Number: q_num = %d\n",
__func__, q_num);
@@ -285,7 +288,7 @@ void rsi_core_qos_processor(struct rsi_common *common)
}
 
skb = rsi_core_dequeue_pkt(common, q_num);
-   if (skb == NULL) {
+   if (!skb) {
rsi_dbg(ERR_ZONE, "skb null\n");
mutex_unlock(>tx_rxlock);
break;
@@ -331,15 +334,16 @@ void rsi_core_xmit(struct rsi_common *common, struct 
sk_buff *skb)
__func__);
goto xmit_fail;
}
-   info = IEEE80211_SKB_CB(skb);
-   tx_params = (struct skb_info *)info->driver_data;
-   tmp_hdr = (struct ieee80211_hdr *)>data[0];
 
if (common->fsm_state != FSM_MAC_INIT_DONE) {
rsi_dbg(ERR_ZONE, "%s: FSM state not open\n", __func__);
goto xmit_fail;
}
 
+   info = IEEE80211_SKB_CB(skb);
+   tx_params = (struct skb_info *)info->driver_data;
+   tmp_hdr = (struct ieee80211_hdr *)>data[0];
+
if ((ieee80211_is_mgmt(tmp_hdr->frame_control)) ||
(ieee80211_is_ctl(tmp_hdr->frame_control)) ||
(ieee80211_is_qos_nullfunc(tmp_hdr->frame_control))) {
@@ -360,7 +364,7 @@ void rsi_core_xmit(struct rsi_common *common, struct 
sk_buff *skb)
 
if ((q_num != MGMT_SOFT_Q) &&
((skb_queue_len(>tx_queue[q_num]) + 1) >=
-DATA_QUEUE_WATER_MARK)) {
+DATA_QUEUE_WATER_MARK)) {
rsi_dbg(ERR_ZONE, "%s: sw queue full\n", __func__);
if (!ieee80211_queue_stopped(adapter->hw, WME_AC(q_num)))
ieee80211_stop_queue(adapter->hw, WME_AC(q_num));
diff --git a/drivers/net/wireless/rsi/rsi_91x_debugfs.c 
b/drivers/net/wireless/rsi/rsi_91x_debugfs.c
index 828a042..5ec7bce 100644
--- a/drivers/net/wireless/rsi/rsi_91x_debugfs.c
+++ b/drivers/net/wireless/rsi/rsi_91x_debugfs.c
@@ -59,7 +59,7 @@ static int rsi_sdio_stats_read(struct seq_file *seq, void 
*data)
 }
 
 /**
- * rsi_sdio_stats_open() - This funtion calls single open function of seq_file
+ * rsi_sdio_stats_open() - This function calls single open function of seq_file
  *to open file and read contents from it.
  * @inode: Pointer to the inode structure.
  * @file: Pointer to the file structure.
@@ -100,7 +100,7 @@ static int rsi_version_read(struct seq_file *seq, void 
*data)
 }
 
 /**
- * rsi_version_open() - This funtion calls single open function of seq_file to
+ * rsi_version_open() - This function calls single open function of seq_file to
  * open file and read contents from it.
  * @inode: Pointer to the inode structure.
  * @file: Pointer to the file structure.
@@ -108,7 +108,7 @@ static int rsi_version_read(struct seq_file *seq,