* Re: [PATCH 0/3] hostap: Fine-tuning for a few functions
From: Joe Perches @ 2016-08-22 16:18 UTC (permalink / raw)
To: Kalle Valo, Arend van Spriel
Cc: SF Markus Elfring, linux-wireless, netdev, Jouni Malinen, LKML,
kernel-janitors, Julia Lawall
In-Reply-To: <87shtwvm63.fsf@kamboji.qca.qualcomm.com>
On Mon, 2016-08-22 at 18:49 +0300, Kalle Valo wrote:
> Arend van Spriel <arend.vanspriel@broadcom.com> writes:
[]
> But yeah, not really sure what to do with these obsolete drivers like
> hostap, ray_cs and wl3501.
Maybe marking sections obsolete in MAINTAINERS could
flag some "shouldn't touch this" warning for old code
in checkpatch.pl and/or get_maintainer.pl
^ permalink raw reply
* Re: [PATCH v4] ath9k: Switch to using mac80211 intermediate software queues.
From: Toke Høiland-Jørgensen @ 2016-08-22 16:16 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless, make-wifi-fast, ath9k-devel, Tim Shepard,
Felix Fietkau
In-Reply-To: <87mvk44xmt.fsf@purkki.adurom.net>
Kalle Valo <kvalo@codeaurora.org> writes:
> Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> writes:
>
>> This switches ath9k over to using the mac80211 intermediate software
>> queueing mechanism for data packets. It removes the queueing inside the
>> driver, except for the retry queue, and instead pulls from mac80211 when
>> a packet is needed. The retry queue is used to store a packet that was
>> pulled but can't be sent immediately.
>>
>> The old code path in ath_tx_start that would queue packets has been
>> removed completely, as has the qlen limit tunables (since there's no
>> longer a queue in the driver to limit).
>>
>> Based on Tim's original patch set, but reworked quite thoroughly.
>>
>> Cc: Tim Shepard <shep@alum.mit.edu>
>> Cc: Felix Fietkau <nbd@nbd.name>
>> Signed-off-by: Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk>
>> ---
>> Changes since v3 (most due to Felix; thanks!):
>> - Correctly notify mac80211 when there are packets in the retry queue
>> on powersave start/stop.
>> - Get rid of ath_tx_aggr_resume().
>> - Some readability changes and additional WARN_ON/BUG_ON in
>> appropriate places.
>
> This is great work but due to the regressions I'm not sure if this
> will be ready for 4.9. To get more testing time I wonder if we should
> wait for 4.10? IMHO applying this in the end of the cycle is too risky
> and we should try to maximise the time linux-next by applying this
> just after -rc1 is released.
>
> Thoughts?
Well, now that we understand what is causing the throughput regressions,
fixing them should be fairly straight forward (yeah, famous last words,
but still...). I already have a patch for the fast path and will go poke
at the slow path next. It'll probably require another workaround or two,
so I guess it won't be the architecturally clean ideal solution; but it
would make it possible to have something that works for 4.9 and then
iterate for a cleaner design for 4.10.
-Toke
^ permalink raw reply
* Re: [4.8] ath9k: fix using sta->drv_priv before initializing it
From: Kalle Valo @ 2016-08-22 16:08 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, kvalo
In-Reply-To: <20160802110322.38359-1-nbd@nbd.name>
Felix Fietkau <nbd@nbd.name> wrote:
> A station pointer can be passed to the driver on tx, before it has been
> marked as associated. Since ath9k_sta_state was initializing the entry
> too late, it resulted in some spurious crashes.
>
> Fixes: df3c6eb34da5 ("ath9k: Use sta_state() callback")
> Cc: stable@vger.kernel.org
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Thanks, 1 patch applied to ath-current branch of ath.git:
7711aaf08ad3 ath9k: fix using sta->drv_priv before initializing it
--
Sent by pwcli
https://patchwork.kernel.org/patch/9255463/
^ permalink raw reply
* Re: [PATCH] wlcore: mesh: add zone time sync support
From: Kalle Valo @ 2016-08-22 15:56 UTC (permalink / raw)
To: Mishol, Guy; +Cc: Pedersen, Thomas, linux-wireless@vger.kernel.org
In-Reply-To: <97207D90F0289D498537011312FCAD1138F55E66@DFRE01.ent.ti.com>
"Mishol, Guy" <guym@ti.com> writes:
> Kalle/Thomas,
> Thanks for your feedback.
Please don't top most, it makes using patchwork difficult and is
annoying to the readers.
> This time sync support is different from the one that mac80211
> maintains with mesh peers. This time sync is mostly used by upper
> layers for several applications (like audio). In this case we allow
> the user to configure for each zone who will be the synchronizer. You
> can refer to the following Application Report (chapter 6) for more
> information: http://www.ti.com/lit/an/swaa166/swaa166.pdf
I didn't fully understand what this does, but debugfs doesn't sound (no
pun intended) like a suitable interface for something like this. nl80211
is more likely candidate.
--
Kalle Valo
^ permalink raw reply
* Re: ath9k: fix client mode beacon configuration
From: Kalle Valo @ 2016-08-22 16:05 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, kvalo, benjamin.berg
In-Reply-To: <20160726062923.98555-1-nbd@nbd.name>
Felix Fietkau <nbd@nbd.name> wrote:
> For pure station mode, iter_data.primary_beacon_vif was used and passed
> to ath_beacon_config, but not set to the station vif.
> This was causing the following warning:
>
> [ 100.310919] ------------[ cut here ]------------
> [ 100.315683] WARNING: CPU: 0 PID: 7 at compat-wireless-2016-06-20/drivers/net/wireless/ath/ath9k/beacon.c:642 ath9k_calculate_summary_state+0x250/0x60c [ath9k]()
> [ 100.402028] CPU: 0 PID: 7 Comm: kworker/u2:1 Tainted: G W 4.4.15 #5
> [ 100.409676] Workqueue: phy0 ieee80211_ibss_leave [mac80211]
> [ 100.415351] Stack : 8736e98c 870b4b20 87a25b54 800a6800 8782a080 80400d63 8039b96c 00000007
> [ 100.415351] 803c5edc 87875914 80400000 800a47cc 87a25b54 800a6800 803a0fd8 80400000
> [ 100.415351] 00000003 87875914 80400000 80094ae0 87a25b54 8787594c 00000000 801ef308
> [ 100.415351] 803ffe70 801ef300 87193d58 87b3a400 87b3ad00 70687930 00000000 00000000
> [ 100.415351] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 100.415351] ...
> [ 100.451703] Call Trace:
> [ 100.454235] [<800a6800>] vprintk_default+0x24/0x30
> [ 100.459110] [<800a47cc>] printk+0x2c/0x38
> [ 100.463190] [<800a6800>] vprintk_default+0x24/0x30
> [ 100.468072] [<80094ae0>] print_worker_info+0x148/0x174
> [ 100.473378] [<801ef308>] serial8250_console_putchar+0x0/0x44
> [ 100.479122] [<801ef300>] wait_for_xmitr+0xc4/0xcc
> [ 100.484014] [<87193d58>] ieee80211_ibss_leave+0xb90/0x1900 [mac80211]
> [ 100.490590] [<80081604>] warn_slowpath_common+0xa0/0xd0
> [ 100.495922] [<801a359c>] dump_stack+0x14/0x28
> [ 100.500350] [<80071a00>] show_stack+0x50/0x84
> [ 100.504784] [<80081604>] warn_slowpath_common+0xa0/0xd0
> [ 100.510106] [<87024c60>] ath9k_calculate_summary_state+0x250/0x60c [ath9k]
> [ 100.517105] [<800816b8>] warn_slowpath_null+0x18/0x24
> [ 100.522256] [<87024c60>] ath9k_calculate_summary_state+0x250/0x60c [ath9k]
> [ 100.529273] [<87025418>] ath9k_set_txpower+0x148/0x498 [ath9k]
> [ 100.535302] [<871d2c64>] cleanup_module+0xa74/0xd4c [mac80211]
> [ 100.541237] [<801ef308>] serial8250_console_putchar+0x0/0x44
> [ 100.547042] [<800a5d18>] wake_up_klogd+0x54/0x68
> [ 100.551730] [<800a6650>] vprintk_emit+0x404/0x43c
> [ 100.556623] [<871b9db8>] ieee80211_sta_rx_notify+0x258/0x32c [mac80211]
> [ 100.563475] [<871ba6a4>] ieee80211_sta_rx_queued_mgmt+0x63c/0x734 [mac80211]
> [ 100.570693] [<871aa49c>] ieee80211_tx_prepare_skb+0x210/0x230 [mac80211]
> [ 100.577609] [<800af5d4>] mod_timer+0x15c/0x190
> [ 100.582220] [<871ba8b8>] ieee80211_sta_work+0xfc/0xe1c [mac80211]
> [ 100.588539] [<871940b4>] ieee80211_ibss_leave+0xeec/0x1900 [mac80211]
> [ 100.595122] [<8009ec84>] dequeue_task_fair+0x44/0x130
> [ 100.600281] [<80092a34>] process_one_work+0x1f8/0x334
> [ 100.605454] [<80093830>] worker_thread+0x2b4/0x408
> [ 100.610317] [<8009357c>] worker_thread+0x0/0x408
> [ 100.615019] [<8009357c>] worker_thread+0x0/0x408
> [ 100.619705] [<80097b68>] kthread+0xdc/0xe8
> [ 100.623886] [<80097a8c>] kthread+0x0/0xe8
> [ 100.627961] [<80060878>] ret_from_kernel_thread+0x14/0x1c
> [ 100.633448]
> [ 100.634956] ---[ end trace aafbe57e9ae6862f ]---
>
> Fixes: cfda2d8e2314 ("ath9k: Fix beacon configuration for addition/removal of interfaces")
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Thanks, 1 patch applied to ath-current branch of ath.git:
05860bed491b ath9k: fix client mode beacon configuration
--
Sent by pwcli
https://patchwork.kernel.org/patch/9247699/
^ permalink raw reply
* Re: [PATCH 0/3] hostap: Fine-tuning for a few functions
From: Kalle Valo @ 2016-08-22 15:49 UTC (permalink / raw)
To: Arend van Spriel
Cc: SF Markus Elfring, linux-wireless, netdev, Jouni Malinen, LKML,
kernel-janitors, Julia Lawall
In-Reply-To: <3b3c91ad-3225-3483-bb58-fdee33bf2290@broadcom.com>
Arend van Spriel <arend.vanspriel@broadcom.com> writes:
> On 20-08-16 18:43, SF Markus Elfring wrote:
>> From: Markus Elfring <elfring@users.sourceforge.net>
>> Date: Sat, 20 Aug 2016 18:35:43 +0200
>>
>> A few update suggestions were taken into account
>> from static source code analysis.
>
> Is it worth touching this old stuff especially when you are not making
> any functional changes.
On the other hand if these patches break something this might be a good
way to get feedback if someone is really using this driver ;)
But yeah, not really sure what to do with these obsolete drivers like
hostap, ray_cs and wl3501.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v4] ath9k: Switch to using mac80211 intermediate software queues.
From: Kalle Valo @ 2016-08-22 15:43 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: linux-wireless, make-wifi-fast, ath9k-devel, Tim Shepard,
Felix Fietkau
In-Reply-To: <20160805160346.10545-1-toke@toke.dk>
Toke Høiland-Jørgensen <toke@toke.dk> writes:
> This switches ath9k over to using the mac80211 intermediate software
> queueing mechanism for data packets. It removes the queueing inside the
> driver, except for the retry queue, and instead pulls from mac80211 when
> a packet is needed. The retry queue is used to store a packet that was
> pulled but can't be sent immediately.
>
> The old code path in ath_tx_start that would queue packets has been
> removed completely, as has the qlen limit tunables (since there's no
> longer a queue in the driver to limit).
>
> Based on Tim's original patch set, but reworked quite thoroughly.
>
> Cc: Tim Shepard <shep@alum.mit.edu>
> Cc: Felix Fietkau <nbd@nbd.name>
> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
> ---
> Changes since v3 (most due to Felix; thanks!):
> - Correctly notify mac80211 when there are packets in the retry queue
> on powersave start/stop.
> - Get rid of ath_tx_aggr_resume().
> - Some readability changes and additional WARN_ON/BUG_ON in
> appropriate places.
This is great work but due to the regressions I'm not sure if this will
be ready for 4.9. To get more testing time I wonder if we should wait
for 4.10? IMHO applying this in the end of the cycle is too risky and we
should try to maximise the time linux-next by applying this just after
-rc1 is released.
Thoughts?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] rtlwifi: Fix missing country code for Great Britain
From: Kalle Valo @ 2016-08-22 15:36 UTC (permalink / raw)
To: Larry Finger; +Cc: devel, linux-wireless, Stable
In-Reply-To: <1471619674-29439-1-git-send-email-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> Some RTL8821AE devices sold in Great Britain have the country code of
> 0x25 encoded in their EEPROM. This value is not tested in the routine
> that establishes the regulatory info for the chip. The fix is to set
> this code to have the same capabilities as the EU countries.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable <stable@vger.kernel.org>
[...]
> --- a/drivers/net/wireless/realtek/rtlwifi/regd.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/regd.c
> @@ -345,9 +345,9 @@ static const struct ieee80211_regdomain *_rtl_regdomain_select(
> return &rtl_regdom_no_midband;
> case COUNTRY_CODE_IC:
> return &rtl_regdom_11;
> - case COUNTRY_CODE_ETSI:
> case COUNTRY_CODE_TELEC_NETGEAR:
> return &rtl_regdom_60_64;
> + case COUNTRY_CODE_ETSI:
> case COUNTRY_CODE_SPAIN:
> case COUNTRY_CODE_FRANCE:
> case COUNTRY_CODE_ISRAEL:
I didn't check the full source, but here you seem to be changing also
the content of ETSI regdomain. The commit log doesn't mention anything
about that so I want to double check that this is really intentionally.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/5] ath9k: Set the "big endian" bit of the AR9003 EEPROM templates
From: Arnd Bergmann @ 2016-08-22 15:31 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: kvalo, ath9k-devel, linux-wireless, ath9k-devel, devicetree,
robh+dt, mark.rutland, chunkeey, nbd
In-Reply-To: <CAFBinCBdv9poKwjsDeGue30x0B9aUjxdkb5BHZcBgouOMAGWMQ@mail.gmail.com>
On Monday, August 22, 2016 1:56:46 PM CEST Martin Blumenstingl wrote:
> On Mon, Aug 22, 2016 at 1:47 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Sunday, August 21, 2016 4:49:03 PM CEST Martin Blumenstingl wrote:
> >> We will default to the system's native endianness for the eepmisc value.
> >> This may be overwritten by the actual calibration data. If it is not
> >> overwritten we interpret the template data in it's native endianness,
> >> meaning that no swapping is required.
> >
> > I'm still skeptical about this one. What is the significance of "native
> > endianess" here? You are keying the endianess of the eeprom tables off the
> > way the CPU operates, but for a PCI device there is no correlation between
> > those two.
> (the ar9003 eeprom format and handling is different compared to 9287,
> def and 4k)
> ar9003_eeprom.c contains EEPROM templates -> these are compiled into
> the ath9k kernel module. Values from these templates can be
> overwritten by the EEPROM found on the actual hardware.
> This change tries to handle the case where the values in the hardware
> EEPROM do not override any of the template values (means final EEPROM
> data = template data). In this case the we can simply rely on the
> endianness which was used to compile ath9k.ko.
Ok, I see what you mean now. However, looking at the source now, I
also see
#define LE16(x) cpu_to_le16(x)
#define LE32(x) cpu_to_le32(x)
.baseEepHeader = {
.regDmn = { LE16(0), LE16(0x1f) },
suggesting that the fields are meant to be little-endian in object
code, and your patch does not change that. In fact, Felix's
ffdc4cbe5b17 ("ath9k_hw: clean up EEPROM endian handling on AR9003")
seems to have corrected this already.
Arnd
^ permalink raw reply
* Re: [Make-wifi-fast] [PATCH v2] mac80211: Move crypto IV generation to after TXQ dequeue.
From: Toke Høiland-Jørgensen @ 2016-08-22 14:47 UTC (permalink / raw)
To: Johannes Berg; +Cc: Dave Taht, make-wifi-fast, linux-wireless, Felix Fietkau
In-Reply-To: <1471466600.5173.21.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
>> well, we're getting there. the results of both patch attempts were
>> really nice, and brought encrypted performance with fq back into line
>> with unencrypted. Still running crypted tests as I write...
>>
>> So fixing TKIP would be next, forcing the AP to use that? What other
>> scenarios do we have to worry about? WDS?
>>
>
> I don't think there's anything else, I just don't really feel it's
> getting anywhere. This is a mere symptom of the design.
>
> Felix had worked around the SN assignment in a similar way, but I feel
> that perhaps the whole thing isn't quite the right architecture. Why
> are we applying FQ after the wifi conversion, when clearly that doesn't
> work well? Seems to me that it would make more sense to let the frames
> sit on the queues as they come in, and do most of the wifi handling
> only when needed (obviously, things like control port would still have
> to be done).
I suppose that could be a way to do it (i.e. have ieee80211_tx_dequeue
call all the TX hooks etc), but am not sure whether there would be
problems doing all this work in the loop that's building aggregates
(which is what would happen for ath9k at least).
An alternative could be to split the process up in two: An "early" and
"late" stage, where the early stage does everything that is not
sensitive to reordering and the occasional drop, and the late stage is
everything that is. Then the queueing step could happen in-between the
two stages, and the non-queueing path could just call both stages at
once. In effect, this would just make the current work-arounds be more
explicit in the structure, rather than being marked as exceptions.
> We even count those packets that are dropped for TX statistics, which
> would seem to be a big behavioural difference vs. applying a qdisc.
While you're right in principle, in practice I don't think this has too
big of an impact. In normal operation, CoDel drops (at most) dozens of
packets per *minute*, so it's not going to skew the statistics too much.
> Now, it's unlikely to be that simple - fragmentation, for example,
> might mess this up.
>
> Overall though, I'm definitely wondering if it should be this way,
> since all the special cases just add complexity.
I agree that the work-arounds are iffy, but I do also think it's
important to keep in mind that we are improving latency by orders of
magnitude here. A few special cases is worth it to achieve that, IMO.
And then iterating towards a design that don't need them, of course :)
-Toke
^ permalink raw reply
* Re: linux-4.8-rc3/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c:3533: pointless test ?
From: Greg KH @ 2016-08-22 14:30 UTC (permalink / raw)
To: David Binderman
Cc: Larry.Finger, Jes.Sorensen, linux-wireless, devel,
Linux Kernel Mailing List, dcb314
In-Reply-To: <CAMzoamY0HSt4af8EeJpt73FD++q1MZ7iHJFa4NDBtzzQrNMjbg@mail.gmail.com>
On Mon, Aug 22, 2016 at 03:07:44PM +0100, David Binderman wrote:
> Hello there,
>
> linux-4.8-rc3/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c:3533]:
> (style) Condition 'pBtMgnt.ExtConfig.HCIExtensionVer>=1' is always
> true
>
> Source code is
>
> if (pBtMgnt->ExtConfig.HCIExtensionVer < 1) {
> ....
> } else if (pBtMgnt->ExtConfig.HCIExtensionVer >= 1) {
>
> Suggest remove second test.
patches are always welcome :)
^ permalink raw reply
* linux-4.8-rc3/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c:3533: pointless test ?
From: David Binderman @ 2016-08-22 14:07 UTC (permalink / raw)
To: Larry.Finger, Jes.Sorensen, gregkh, linux-wireless, devel,
Linux Kernel Mailing List, dcb314
Hello there,
linux-4.8-rc3/drivers/staging/rtl8723au/hal/rtl8723a_bt-coexist.c:3533]:
(style) Condition 'pBtMgnt.ExtConfig.HCIExtensionVer>=1' is always
true
Source code is
if (pBtMgnt->ExtConfig.HCIExtensionVer < 1) {
....
} else if (pBtMgnt->ExtConfig.HCIExtensionVer >= 1) {
Suggest remove second test.
Regards
David Binderman
^ permalink raw reply
* [PATCH 1/3 v3] mac80211: RX BA support for sta max_rx_aggregation_subframes
From: Maxim Altshul @ 2016-08-22 14:14 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, johannes, Maxim Altshul
The ability to change the max_rx_aggregation frames is useful
in cases of IOP.
There exist some devices (latest mobile phones and some AP's)
that tend to not respect a BA sessions maximum size (in Kbps).
These devices won't respect the AMPDU size that was negotiated during
associasion (even though they do respect the maximal number of packets).
This violation is characterized by a valid number of packets in
a single AMPDU. Even so, the total size will exceed the size negotiated
during association.
Eventually, this will cause some undefined behavior, which in turn
causes the hw to drop packets, causing the throughput to plummet.
This patch will make the subframe limitation to be held by each station,
instead of being held only by hw.
Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
---
No need to change the lock, since the driver changes the value of
sta->sta.max_rx_aggregation_subframes without locking.
Add the station's address to debug, and change the commit message
a little bit.
include/net/mac80211.h | 4 ++++
net/mac80211/agg-rx.c | 7 +++++--
net/mac80211/sta_info.c | 3 +++
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index cca510a..a1457ca 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1735,6 +1735,9 @@ struct ieee80211_sta_rates {
* @supp_rates: Bitmap of supported rates (per band)
* @ht_cap: HT capabilities of this STA; restricted to our own capabilities
* @vht_cap: VHT capabilities of this STA; restricted to our own capabilities
+ * @max_rx_aggregation_subframes: maximal amount of frames in a single AMPDU
+ * that this station is allowed to transmit to us.
+ * Can be modified by driver.
* @wme: indicates whether the STA supports QoS/WME (if local devices does,
* otherwise always false)
* @drv_priv: data area for driver use, will always be aligned to
@@ -1775,6 +1778,7 @@ struct ieee80211_sta {
u16 aid;
struct ieee80211_sta_ht_cap ht_cap;
struct ieee80211_sta_vht_cap vht_cap;
+ u8 max_rx_aggregation_subframes;
bool wme;
u8 uapsd_queues;
u8 max_sp;
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index a9aff60..bcf8a7e 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -298,10 +298,13 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta,
buf_size = IEEE80211_MAX_AMPDU_BUF;
/* make sure the size doesn't exceed the maximum supported by the hw */
- if (buf_size > local->hw.max_rx_aggregation_subframes)
- buf_size = local->hw.max_rx_aggregation_subframes;
+ if (buf_size > sta->sta.max_rx_aggregation_subframes)
+ buf_size = sta->sta.max_rx_aggregation_subframes;
params.buf_size = buf_size;
+ ht_dbg(sta->sdata, "AddBA Req buf_size=%d for %pM\n",
+ buf_size, sta->sta.addr);
+
/* examine state machine */
mutex_lock(&sta->ampdu_mlme.mtx);
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 19f14c9..5e70fa5 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -340,6 +340,9 @@ struct sta_info *sta_info_alloc(struct ieee80211_sub_if_data *sdata,
memcpy(sta->addr, addr, ETH_ALEN);
memcpy(sta->sta.addr, addr, ETH_ALEN);
+ sta->sta.max_rx_aggregation_subframes =
+ local->hw.max_rx_aggregation_subframes;
+
sta->local = local;
sta->sdata = sdata;
sta->rx_stats.last_rx = jiffies;
--
2.9.0
^ permalink raw reply related
* Re: TCP data throughput for BCM43362
From: Jörg Krause @ 2016-08-22 13:37 UTC (permalink / raw)
To: Arend van Spriel, Franky Lin
Cc: Brett Rudley, brcm80211-dev-list, Hante Meuleman, Franky Lin,
linux-wireless, Arend van Spriel
In-Reply-To: <6cdbbae7-8a56-6778-e886-68eeea7add15@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 7785 bytes --]
Hi all,
I am back from vacation and I'd like to do more investigations about
this issue. Please see my comments below...
On Sun, 2016-08-07 at 13:41 +0200, Arend van Spriel wrote:
> On 06-08-16 16:12, Jörg Krause wrote:
> >
> > Hi all,
>
> A bit weird email format making it a bit hard to determine where your
> last reply starts...
>
> >
> > On Fr, 2016-08-05 at 17:56 -0700, Franky Lin wrote:
> >
> > On Fri, Aug 5, 2016 at 2:29 PM, Jörg Krause <joerg.krause@embedded.
> > ro
> > cks>
> > wrote:
> >
> >
> >
> >
> >
> > Am 5. August 2016 23:01:10 MESZ, schrieb Arend Van Spriel <
> > arend.vanspriel@broadcom.com>:
> >
> >
> > Op 5 aug. 2016 22:46 schreef "Jörg Krause"
> > <joerg.krause@embedded.rocks>:
> >
> >
> >
> > Hi,
> >
> > I'm using a custom ARM board with an BCM43362 wifi chip from
> >
> > Broadcom.
> >
> >
> > The wifi chip is attached via SDIO to the controller with a
> > clock of
> > 48MHz. Linux kernel version is 4.7.
> >
> > When measuring the network bandwidth with iperf3 I get a
> > bandwith of
> > only around 5 Mbps. I found a similar thread at the Broadcom
> >
> > community
> >
> >
> > [1] where the test was done with a M4 CPU + BCM43362 and an
> > average
> > result of 3.3 Mbps.
> >
> > Interestingly, a BCM43362 Wi-Fi Dev Kit [2] notes a TCP data
> >
> > throughput
> >
> >
> > greater than 20 Mbps.
> >
> > Why is the throughput I measured much lower? Note that I
> > measured
> > several times with almost no neighbor devices or networks.
> >
> > This is a test sample measured with iperf3:
> >
> > $ iperf3 -c 192.168.2.1 -i 1 -t 10
> > Connecting to host 192.168.2.1, port 5201
> > [ 4] local 192.168.2.155 port 36442 connected to
> > 192.168.2.1
> >
> > port
> >
> >
> > 5201
> > [ ID]
> > Interval Transfer Bandwidth Retr Cwnd
> > [ 4] 0.00-1.00 sec 615 KBytes 5.04
> > Mbits/sec 0 56.6
> > KBytes
> > [ 4] 1.00-2.00 sec 622 KBytes 5.10
> > Mbits/sec 0 84.8
> > KBytes
> > [ 4] 2.00-3.00 sec 625 KBytes 5.12
> > Mbits/sec 0 113
> > KBytes
> > [ 4] 3.00-4.00 sec 571 KBytes 4.68
> > Mbits/sec 0 140
> > KBytes
> > [ 4] 4.00-5.00 sec 594 KBytes 4.87
> > Mbits/sec 0 167
> > KBytes
> > [ 4] 5.00-6.00 sec 628 KBytes 5.14
> > Mbits/sec 0 195
> > KBytes
> > [ 4] 6.00-7.00 sec 619 KBytes 5.07
> > Mbits/sec 0 202
> > KBytes
> > [ 4] 7.00-8.00 sec 608 KBytes 4.98
> > Mbits/sec 0 202
> > KBytes
> > [ 4] 8.00-9.00 sec 602 KBytes 4.93
> > Mbits/sec 0 202
> > KBytes
> > [ 4] 9.00-10.00 sec 537 KBytes 4.40
> > Mbits/sec 0 202
> > KBytes
> > - - - - - - - - - - - - - - - - - - - - - - - - -
> > [ ID] Interval Transfer Bandwidth Retr
> > [ 4] 0.00-10.00 sec 5.88 MBytes 4.93
> > Mbits/sec 0 sender
> > [ 4] 0.00-10.00 sec 5.68 MBytes 4.76
> > Mbits/sec receiver
> >
> >
> > Not overly familiar with iperf3. Do these lines mean you are
> > doing
> > bidirectional test, ie. upstream and downstream at the same time.
> > Another
> > thing affecting tput could be power-save.
> >
> >
> > No, iperf3 does not support bidrectional test. Power-save is turned
> > off.
> >
> > What does iw link say?
> >
>
> but I guess it starts here!
>
> >
> > I compared the results with a Cubietruck I have:
> >
> > # iperf3 -s
> > -----------------------------------------------------------
> > Server listening on 5201
> > -----------------------------------------------------------
> > Accepted connection from 192.168.178.46, port 42906
> > [ 5] local 192.168.178.38 port 5201 connected to 192.168.178.46
> > port
> > 42908
> > [ ID] Interval Transfer Bandwidth
> > [ 5] 0.00-1.00 sec 2.29 MBytes 19.2
> > Mbits/sec
> > [ 5] 1.00-2.00 sec 2.21 MBytes 18.5
> > Mbits/sec
> > [ 5] 2.00-3.00 sec 2.17 MBytes 18.2
> > Mbits/sec
> > [ 5] 3.00-4.00 sec 2.09 MBytes 17.6
> > Mbits/sec
> > [ 5] 4.00-5.00 sec 2.20 MBytes 18.5
> > Mbits/sec
> > [ 5] 5.00-6.00 sec 2.64 MBytes 22.1
> > Mbits/sec
> > [ 5] 6.00-7.00 sec 2.67 MBytes 22.4
> > Mbits/sec
> > [ 5] 7.00-8.00 sec 2.62 MBytes 22.0
> > Mbits/sec
> > [ 5] 8.00-9.00 sec 2.35 MBytes 19.8
> > Mbits/sec
> > [ 5] 9.00-10.00 sec 2.30 MBytes 19.3
> > Mbits/sec
> > [ 5] 10.00-10.03 sec 83.4 KBytes 23.5
> > Mbits/sec
> > - - - - - - - - - - - - - - - - - - - - - - - - -
> > [ ID] Interval Transfer Bandwidth Retr
> > [ 5] 0.00-10.03 sec 23.9 MBytes 20.0
> > Mbits/sec 0 sender
> > [ 5] 0.00-10.03 sec 23.6 MBytes 19.8
> > Mbits/sec receiver
> >
> > # iw dev wlan0 link
> > Connected to xx:xx:xx:xx:xx (on wlan0)
> > SSID: xxx
> > freq: 2437
> > tx bitrate: 65.0 MBit/s
> >
> > bss flags: short-preamble short-slot-time
> > dtim period: 1
> > beacon int: 100
>
> Too bad RSSI is not in the output above. That may be due to a
> regression
> in our driver which has been fixed by commit 94abd778a7bb ("brcmfmac:
> add fallback for devices that do not report per-chain values").
> However,
> the tx bitrate seems within the same range as the other platform.
>
> >
> > The Cubietruck works also with the brcmfmac driver.
> >
> > May it depend on the NVRAM file?
>
> Not sure. Can you tell me a bit more about the custom ARM board. Does
> it
> use the same wifi module as Cubietruck, ie. the AMPAK AP6210? If you
> can
> make a wireshark sniff we can check the actual bitrate and medium
> density in terms of packets. Another thing to look at is the SDIO
> host
> controller. In brcmf_sdiod_sgtable_alloc() some key values are used
> from
> the host controller. It only logs the number of entries of the
> scatter-gather table, but could you add the other values in this
> function that are used to determine the number of entries.
My board uses the BCM43362 chip solely (no Bluetooth) attached to the
SDIO interface of a NXP i.MX28 processor.
I added some additional printk() to brcmf_sdiod_sgtable_alloc(). These
are the values printed after modprobe brcmfmac:
[ 8.926657] sg_support=1
[ 8.929440] max_blocks=511
[ 8.932213] max_request_size=261632
[ 8.935741] max_segment_count=52
[ 8.939005] max_segment_size=65280
[ 8.946095] nents=35
Additionally I attached a xz compresses wireshark sniff while running
iper3 between the BCM43362 running as in AP mode with iperf3 as a
server and a PC in station mode running iperf3 as a client.
Best regards
Jörg Krause
[-- Attachment #2: bcm43362.pcapng.xz --]
[-- Type: application/x-xz, Size: 190004 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3 v2] mac80211: RX BA support for sta max_rx_aggregation_subframes
From: Johannes Berg @ 2016-08-22 13:37 UTC (permalink / raw)
To: Maxim Altshul, linux-wireless; +Cc: kvalo
In-Reply-To: <20160821112425.11302-1-maxim.altshul@ti.com>
> + /* examine state machine */
> + mutex_lock(&sta->ampdu_mlme.mtx);
> +
> /* make sure the size doesn't exceed the maximum supported
> by the hw */
> - if (buf_size > local->hw.max_rx_aggregation_subframes)
> - buf_size = local->hw.max_rx_aggregation_subframes;
> + if (buf_size > sta->sta.max_rx_aggregation_subframes)
> + buf_size = sta->sta.max_rx_aggregation_subframes;
> params.buf_size = buf_size;
>
Since the driver is updating this value without any locking, is there
any point in changing the locking?
> + ht_dbg(sta->sdata, "AddBA Req buf_size=%d\n", buf_size);
I think the station address should be in there.
johannes
^ permalink raw reply
* Re: ath9k: Fix beacon configuration assertion failure
From: Kalle Valo @ 2016-08-22 13:35 UTC (permalink / raw)
To: Benjamin Berg
Cc: Adi Ratiu, linux-wireless, ath9k-devel, ath9k-devel, linux-kernel,
Felix Fietkau
In-Reply-To: <1471855240.16921.6.camel@open-mesh.com>
Benjamin Berg <benjamin.berg@open-mesh.com> writes:
> On Fr, 2016-08-19 at 13:03 +0300, Kalle Valo wrote:
>> Actually, I see two patches which might be related but not identical:
>>
>> ath9k: fix client mode beacon configuration
>> https://patchwork.kernel.org/patch/9247699/
>>
>> ath9k: Fix beacon configuration assertion failure
>> https://patchwork.kernel.org/patch/9281191/
>>
>> Felix (CCed) & Benjamin: please take a look and advice which one I
>> should take.
>
> Yes, both patches are designed to fix the same issue in my patch.
>
> Felix solution looks entirely correct to me, the second solution seems
> slightly wrong because it prevents the call to ath9k_beacon_config from
> happening instead of ensuring the correct parameter value.
> ath9k_beacon_config needs to be called even if iter_data.beacons is
> false as it disables the interrupts.
Ok, I'll the patch from Felix then. Thanks.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/1] brcmfmac: fix pmksa->bssid usage
From: Rafał Miłecki @ 2016-08-22 13:10 UTC (permalink / raw)
To: Nicolas Iooss
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Network Development, Linux Kernel Mailing List
In-Reply-To: <96ea6e57-79d7-d4ff-1228-6f22addd4996@m4x.org>
On 22 August 2016 at 15:03, Nicolas Iooss <nicolas.iooss_linux@m4x.org> wrote:
> After I sent the following patch a few weeks ago, I have not received
> any feedback. Could you please review it and tell me what I may have
> done wrong?
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#checking_state_of_patches_from_patchwork
https://patchwork.kernel.org/patch/9265733/
^ permalink raw reply
* Re: [PATCH 1/1] brcmfmac: fix pmksa->bssid usage
From: Nicolas Iooss @ 2016-08-22 13:03 UTC (permalink / raw)
To: Arend van Spriel, Franky Lin, Hante Meuleman, linux-wireless,
brcm80211-dev-list.pdl
Cc: netdev, linux-kernel
In-Reply-To: <20160805203418.32162-1-nicolas.iooss_linux@m4x.org>
Hello,
After I sent the following patch a few weeks ago, I have not received
any feedback. Could you please review it and tell me what I may have
done wrong?
Thanks,
Nicolas
On 05/08/16 22:34, Nicolas Iooss wrote:
> The struct cfg80211_pmksa defines its bssid field as:
>
> const u8 *bssid;
>
> contrary to struct brcmf_pmksa, which uses:
>
> u8 bssid[ETH_ALEN];
>
> Therefore in brcmf_cfg80211_del_pmksa(), &pmksa->bssid takes the address
> of this field (of type u8**), not the one of its content (which would be
> u8*). Remove the & operator to make brcmf_dbg("%pM") and memcmp()
> behave as expected.
>
> This bug have been found using a custom static checker (which checks the
> usage of %p... attributes at build time). It has been introduced in
> commit 6c404f34f2bd ("brcmfmac: Cleanup pmksa cache handling code"),
> which replaced pmksa->bssid by &pmksa->bssid while refactoring the code,
> without modifying struct cfg80211_pmksa definition.
>
> Fixes: 6c404f34f2bd ("brcmfmac: Cleanup pmksa cache handling code")
> Cc: stable@ger.kernel.org
> Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
> ---
>
> scripts/checkpatch.pl reports a warning: "Prefer ether_addr_equal() or
> ether_addr_equal_unaligned() over memcmp()". Because some files in
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/ still use memcmp()
> to compare addresses and because I do not know whether pmksa->bssid is
> always aligned, I did not follow this warning.
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 2628d5e12c64..aceab77cd95a 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -3884,11 +3884,11 @@ brcmf_cfg80211_del_pmksa(struct wiphy *wiphy, struct net_device *ndev,
> if (!check_vif_up(ifp->vif))
> return -EIO;
>
> - brcmf_dbg(CONN, "del_pmksa - PMK bssid = %pM\n", &pmksa->bssid);
> + brcmf_dbg(CONN, "del_pmksa - PMK bssid = %pM\n", pmksa->bssid);
>
> npmk = le32_to_cpu(cfg->pmk_list.npmk);
> for (i = 0; i < npmk; i++)
> - if (!memcmp(&pmksa->bssid, &pmk[i].bssid, ETH_ALEN))
> + if (!memcmp(pmksa->bssid, &pmk[i].bssid, ETH_ALEN))
> break;
>
> if ((npmk > 0) && (i < npmk)) {
>
^ permalink raw reply
* Re: [PATCH 2/5] ath9k: Set the "big endian" bit of the AR9003 EEPROM templates
From: Martin Blumenstingl @ 2016-08-22 11:56 UTC (permalink / raw)
To: Arnd Bergmann
Cc: kvalo, ath9k-devel, linux-wireless, ath9k-devel, devicetree,
robh+dt, mark.rutland, chunkeey, nbd
In-Reply-To: <3744898.ltfZjZgAjj@wuerfel>
On Mon, Aug 22, 2016 at 1:47 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Sunday, August 21, 2016 4:49:03 PM CEST Martin Blumenstingl wrote:
>> We will default to the system's native endianness for the eepmisc value.
>> This may be overwritten by the actual calibration data. If it is not
>> overwritten we interpret the template data in it's native endianness,
>> meaning that no swapping is required.
>
> I'm still skeptical about this one. What is the significance of "native
> endianess" here? You are keying the endianess of the eeprom tables off the
> way the CPU operates, but for a PCI device there is no correlation between
> those two.
(the ar9003 eeprom format and handling is different compared to 9287,
def and 4k)
ar9003_eeprom.c contains EEPROM templates -> these are compiled into
the ath9k kernel module. Values from these templates can be
overwritten by the EEPROM found on the actual hardware.
This change tries to handle the case where the values in the hardware
EEPROM do not override any of the template values (means final EEPROM
data = template data). In this case the we can simply rely on the
endianness which was used to compile ath9k.ko.
I also noted that this is missing a signed-off-by tag as well (sorry
for that, I will re-send it together with the other patch next
weekend)
^ permalink raw reply
* Re: [PATCH 5/5] ath9k: Make EEPROM endianness swapping configurable via devicetree
From: Arnd Bergmann @ 2016-08-22 11:52 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: kvalo, ath9k-devel, linux-wireless, ath9k-devel, devicetree,
robh+dt, mark.rutland, chunkeey, nbd
In-Reply-To: <20160821144906.30984-6-martin.blumenstingl@googlemail.com>
On Sunday, August 21, 2016 4:49:06 PM CEST Martin Blumenstingl wrote:
> +- qca,check-eeprom-endianness: When enabled, the driver checks if the
> + endianness of the EEPROM (using two checks,
> + one is based on the two magic bytes at the
> + start of the EEPROM and a second one which
> + relies on a flag within the EEPROM data)
> + matches the host system's native endianness.
> + The data will be swapped accordingly if there
> + is a mismatch.
> + Leaving this disabled means that the EEPROM
> + data will always be interpreted in the
> + system's native endianness.
> + Enable this option only when the EEPROMs
> + endianness identifiers are known to be
> + correct, because otherwise the EEPROM data
> + may be swapped and thus interpreted
> + incorrectly.
The property should not describe the driver behavior, but instead
describe what the hardware is like.
A default of "system's native endianess" should not be specified
in a binding, as the same DTB can be used with both big-endian or
little-endian kernels on some architectures (ARM and PowerPC among
others), so disabling the property means that it is guaranteed to
be broken on one of the two.
If we have no reliable way to check the endianess in all combinations,
could we have two properties "eeprom-big-endian" and
"eeprom-little-endian" and mandate that one of them is always used
when discovering the device using DT?
Arnd
^ permalink raw reply
* Re: [PATCH 2/5] ath9k: Set the "big endian" bit of the AR9003 EEPROM templates
From: Arnd Bergmann @ 2016-08-22 11:47 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: kvalo, ath9k-devel, linux-wireless, ath9k-devel, devicetree,
robh+dt, mark.rutland, chunkeey, nbd
In-Reply-To: <20160821144906.30984-3-martin.blumenstingl@googlemail.com>
On Sunday, August 21, 2016 4:49:03 PM CEST Martin Blumenstingl wrote:
> We will default to the system's native endianness for the eepmisc value.
> This may be overwritten by the actual calibration data. If it is not
> overwritten we interpret the template data in it's native endianness,
> meaning that no swapping is required.
I'm still skeptical about this one. What is the significance of "native
endianess" here? You are keying the endianess of the eeprom tables off the
way the CPU operates, but for a PCI device there is no correlation between
those two.
Arnd
^ permalink raw reply
* Re: [PATCH 1/5] ath9k: Add a #define for the EEPROM "eepmisc" endianness bit
From: Arnd Bergmann @ 2016-08-22 11:42 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: kvalo, ath9k-devel, linux-wireless, ath9k-devel, devicetree,
robh+dt, mark.rutland, chunkeey, nbd
In-Reply-To: <20160821144906.30984-2-martin.blumenstingl@googlemail.com>
On Sunday, August 21, 2016 4:49:02 PM CEST Martin Blumenstingl wrote:
> This replaces a magic number with a named #define. Additionally it
> removes two "eeprom format" specific #defines for the "big endianness"
> bit which are the same on all eeprom formats.
>
Looks good, but missing a Signed-off-by: tag.
Arnd
^ permalink raw reply
* Re: [PATCHv7 4/4] mt7601u: use linux/bitfield.h
From: Jakub Kicinski @ 2016-08-22 10:52 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: Kalle Valo, Linux Wireless List
In-Reply-To: <161e3391-9a95-6388-6b93-99a5b12a2036@broadcom.com>
On Fri, 19 Aug 2016 21:02:02 +0200, Arend Van Spriel wrote:
> On 19-8-2016 18:44, Jakub Kicinski wrote:
> > Use the newly added linux/bitfield.h.
> >
> > Reviewed-by: Dinan Gunawardena <dinan.gunawardena@netronome.com>
> > Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> > ---
> > drivers/net/wireless/mediatek/mt7601u/dma.c | 2 +-
> > drivers/net/wireless/mediatek/mt7601u/dma.h | 10 ++--
> > drivers/net/wireless/mediatek/mt7601u/eeprom.c | 12 ++--
> > drivers/net/wireless/mediatek/mt7601u/init.c | 10 ++--
> > drivers/net/wireless/mediatek/mt7601u/mac.c | 38 ++++++------
> > drivers/net/wireless/mediatek/mt7601u/mcu.c | 20 +++----
> > drivers/net/wireless/mediatek/mt7601u/mt7601u.h | 4 +-
> > drivers/net/wireless/mediatek/mt7601u/phy.c | 44 +++++++-------
> > drivers/net/wireless/mediatek/mt7601u/tx.c | 19 +++---
> > drivers/net/wireless/mediatek/mt7601u/util.h | 77 -------------------------
> > 10 files changed, 81 insertions(+), 155 deletions(-)
> > delete mode 100644 drivers/net/wireless/mediatek/mt7601u/util.h
> >
> > diff --git a/drivers/net/wireless/mediatek/mt7601u/dma.c b/drivers/net/wireless/mediatek/mt7601u/dma.c
> > index 57a80cfa39b1..a8bc064bc14f 100644
> > --- a/drivers/net/wireless/mediatek/mt7601u/dma.c
> > +++ b/drivers/net/wireless/mediatek/mt7601u/dma.c
> > @@ -103,7 +103,7 @@ static void mt7601u_rx_process_seg(struct mt7601u_dev *dev, u8 *data,
> >
> > if (unlikely(rxwi->zero[0] || rxwi->zero[1] || rxwi->zero[2]))
> > dev_err_once(dev->dev, "Error: RXWI zero fields are set\n");
> > - if (unlikely(MT76_GET(MT_RXD_INFO_TYPE, fce_info)))
> > + if (unlikely(FIELD_GET(MT_RXD_INFO_TYPE, fce_info)))
> > dev_err_once(dev->dev, "Error: RX path seen a non-pkt urb\n");
> >
> > trace_mt_rx(dev, rxwi, fce_info);
> > diff --git a/drivers/net/wireless/mediatek/mt7601u/dma.h b/drivers/net/wireless/mediatek/mt7601u/dma.h
> > index 978e8a90b87f..270d126880c0 100644
> > --- a/drivers/net/wireless/mediatek/mt7601u/dma.h
> > +++ b/drivers/net/wireless/mediatek/mt7601u/dma.h
> > @@ -18,8 +18,6 @@
> > #include <asm/unaligned.h>
> > #include <linux/skbuff.h>
> >
> > -#include "util.h"
> > -
> > #define MT_DMA_HDR_LEN 4
> > #define MT_RX_INFO_LEN 4
> > #define MT_FCE_INFO_LEN 4
> > @@ -79,9 +77,9 @@ static inline int mt7601u_dma_skb_wrap(struct sk_buff *skb,
> > */
> >
> > info = flags |
> > - MT76_SET(MT_TXD_INFO_LEN, round_up(skb->len, 4)) |
> > - MT76_SET(MT_TXD_INFO_D_PORT, d_port) |
> > - MT76_SET(MT_TXD_INFO_TYPE, type);
> > + FIELD_PREP(MT_TXD_INFO_LEN, round_up(skb->len, 4)) |
> > + FIELD_PREP(MT_TXD_INFO_D_PORT, d_port) |
> > + FIELD_PREP(MT_TXD_INFO_TYPE, type);
>
> So what are those flags? Is there no field definition for those.
>
> > put_unaligned_le32(info, skb_push(skb, sizeof(info)));
> > return skb_put_padto(skb, round_up(skb->len, 4) + 4);
> > @@ -90,7 +88,7 @@ static inline int mt7601u_dma_skb_wrap(struct sk_buff *skb,
> > static inline int
> > mt7601u_dma_skb_wrap_pkt(struct sk_buff *skb, enum mt76_qsel qsel, u32 flags)
> > {
> > - flags |= MT76_SET(MT_TXD_PKT_INFO_QSEL, qsel);
> > + flags |= FIELD_PREP(MT_TXD_PKT_INFO_QSEL, qsel);
>
> Ah. This is the flags being ORed in above. I suppose there are more
> callsites to mt7601u_dma_skb_wrap().
Yes, the field layout differs slightly between data and MCU commands.
Additionally some packet flags depend on mac80211 info and I didn't
want to pollute dma.h with mac80211 info so I just pass those flags
as opaque u32.
> > return mt7601u_dma_skb_wrap(skb, WLAN_PORT, DMA_PACKET, flags);
> > }
> >
> > diff --git a/drivers/net/wireless/mediatek/mt7601u/eeprom.c b/drivers/net/wireless/mediatek/mt7601u/eeprom.c
> > index 8d8ee0344f7b..da6faea092d6 100644
> > --- a/drivers/net/wireless/mediatek/mt7601u/eeprom.c
> > +++ b/drivers/net/wireless/mediatek/mt7601u/eeprom.c
> > @@ -45,8 +45,8 @@ mt7601u_efuse_read(struct mt7601u_dev *dev, u16 addr, u8 *data,
> > val = mt76_rr(dev, MT_EFUSE_CTRL);
> > val &= ~(MT_EFUSE_CTRL_AIN |
> > MT_EFUSE_CTRL_MODE);
> > - val |= MT76_SET(MT_EFUSE_CTRL_AIN, addr & ~0xf) |
> > - MT76_SET(MT_EFUSE_CTRL_MODE, mode) |
> > + val |= FIELD_PREP(MT_EFUSE_CTRL_AIN, addr & ~0xf) |
> > + FIELD_PREP(MT_EFUSE_CTRL_MODE, mode) |
> > MT_EFUSE_CTRL_KICK;
>
> MT_EFUSE_CTRL_KICK is probably a 1-bit field in MT_EFUSE_CTRL register.
> It looks like you did not want to go all the way although you do give an
> example in bitfield.h, ie. + * #define REG_FIELD_B BIT(7).
True, I just wanted to show in the examples that BIT() is OK to use.
My feeling is that ORing in always set flags is acceptable, or at least
it was my feeling when I wrote this code ;)
^ permalink raw reply
* [PATCH 3/4] wil6210: extract firmware capabilities from FW file
From: Maya Erez @ 2016-08-22 9:42 UTC (permalink / raw)
To: Kalle Valo; +Cc: Lior David, linux-wireless, wil6210, Maya Erez
In-Reply-To: <1471858942-23766-1-git-send-email-qca_merez@qca.qualcomm.com>
From: Lior David <qca_liord@qca.qualcomm.com>
When driver is loaded, extract a capabilities record
from the FW file. This record contains bits indicating
which optional features are supported by this FW.
The driver can use this information to determine
which functionality to support and/or expose to user
space.
The extraction is done before wiphy structure is
registered, because the capabilities can affect
information published by the this structure.
Signed-off-by: Lior David <qca_liord@qca.qualcomm.com>
Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
---
drivers/net/wireless/ath/wil6210/debugfs.c | 25 +++++++++
drivers/net/wireless/ath/wil6210/fw.h | 11 +++-
drivers/net/wireless/ath/wil6210/fw_inc.c | 85 +++++++++++++++++++++--------
drivers/net/wireless/ath/wil6210/main.c | 4 +-
drivers/net/wireless/ath/wil6210/pcie_bus.c | 4 ++
drivers/net/wireless/ath/wil6210/wil6210.h | 4 +-
6 files changed, 106 insertions(+), 27 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/debugfs.c b/drivers/net/wireless/ath/wil6210/debugfs.c
index a8098b4..a244a36 100644
--- a/drivers/net/wireless/ath/wil6210/debugfs.c
+++ b/drivers/net/wireless/ath/wil6210/debugfs.c
@@ -1553,6 +1553,30 @@ static const struct file_operations fops_led_blink_time = {
.open = simple_open,
};
+/*---------FW capabilities------------*/
+static int wil_fw_capabilities_debugfs_show(struct seq_file *s, void *data)
+{
+ struct wil6210_priv *wil = s->private;
+
+ seq_printf(s, "fw_capabilities : %*pb\n", WMI_FW_CAPABILITY_MAX,
+ wil->fw_capabilities);
+
+ return 0;
+}
+
+static int wil_fw_capabilities_seq_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, wil_fw_capabilities_debugfs_show,
+ inode->i_private);
+}
+
+static const struct file_operations fops_fw_capabilities = {
+ .open = wil_fw_capabilities_seq_open,
+ .release = single_release,
+ .read = seq_read,
+ .llseek = seq_lseek,
+};
+
/*----------------*/
static void wil6210_debugfs_init_blobs(struct wil6210_priv *wil,
struct dentry *dbg)
@@ -1603,6 +1627,7 @@ static const struct {
{"recovery", S_IRUGO | S_IWUSR, &fops_recovery},
{"led_cfg", S_IRUGO | S_IWUSR, &fops_led_cfg},
{"led_blink_time", S_IRUGO | S_IWUSR, &fops_led_blink_time},
+ {"fw_capabilities", S_IRUGO, &fops_fw_capabilities},
};
static void wil6210_debugfs_init_files(struct wil6210_priv *wil,
diff --git a/drivers/net/wireless/ath/wil6210/fw.h b/drivers/net/wireless/ath/wil6210/fw.h
index 7a2c6c1..c3191c6 100644
--- a/drivers/net/wireless/ath/wil6210/fw.h
+++ b/drivers/net/wireless/ath/wil6210/fw.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2014 Qualcomm Atheros, Inc.
+ * Copyright (c) 2014,2016 Qualcomm Atheros, Inc.
*
* Permission to use, copy, modify, and/or distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
@@ -58,6 +58,15 @@ struct wil_fw_record_comment { /* type == wil_fw_type_comment */
u8 data[0]; /* free-form data [data_size], see above */
} __packed;
+/* FW capabilities encoded inside a comment record */
+#define WIL_FW_CAPABILITIES_MAGIC (0xabcddcba)
+struct wil_fw_record_capabilities { /* type == wil_fw_type_comment */
+ /* identifies capabilities record */
+ __le32 magic;
+ /* capabilities (variable size), see enum wmi_fw_capability */
+ u8 capabilities[0];
+};
+
/* perform action
* data_size = @head.size - offsetof(struct wil_fw_record_action, data)
*/
diff --git a/drivers/net/wireless/ath/wil6210/fw_inc.c b/drivers/net/wireless/ath/wil6210/fw_inc.c
index d30657e..3860238 100644
--- a/drivers/net/wireless/ath/wil6210/fw_inc.c
+++ b/drivers/net/wireless/ath/wil6210/fw_inc.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2014-2015 Qualcomm Atheros, Inc.
+ * Copyright (c) 2014-2016 Qualcomm Atheros, Inc.
*
* Permission to use, copy, modify, and/or distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
@@ -118,6 +118,12 @@ static int wil_fw_verify(struct wil6210_priv *wil, const u8 *data, size_t size)
return (int)dlen;
}
+static int fw_ignore_section(struct wil6210_priv *wil, const void *data,
+ size_t size)
+{
+ return 0;
+}
+
static int fw_handle_comment(struct wil6210_priv *wil, const void *data,
size_t size)
{
@@ -126,6 +132,27 @@ static int fw_handle_comment(struct wil6210_priv *wil, const void *data,
return 0;
}
+static int
+fw_handle_capabilities(struct wil6210_priv *wil, const void *data,
+ size_t size)
+{
+ const struct wil_fw_record_capabilities *rec = data;
+ size_t capa_size;
+
+ if (size < sizeof(*rec) ||
+ le32_to_cpu(rec->magic) != WIL_FW_CAPABILITIES_MAGIC)
+ return 0;
+
+ capa_size = size - offsetof(struct wil_fw_record_capabilities,
+ capabilities);
+ bitmap_zero(wil->fw_capabilities, WMI_FW_CAPABILITY_MAX);
+ memcpy(wil->fw_capabilities, rec->capabilities,
+ min(sizeof(wil->fw_capabilities), capa_size));
+ wil_hex_dump_fw("CAPA", DUMP_PREFIX_OFFSET, 16, 1,
+ rec->capabilities, capa_size, false);
+ return 0;
+}
+
static int fw_handle_data(struct wil6210_priv *wil, const void *data,
size_t size)
{
@@ -383,42 +410,51 @@ static int fw_handle_gateway_data4(struct wil6210_priv *wil, const void *data,
static const struct {
int type;
- int (*handler)(struct wil6210_priv *wil, const void *data, size_t size);
+ int (*load_handler)(struct wil6210_priv *wil, const void *data,
+ size_t size);
+ int (*parse_handler)(struct wil6210_priv *wil, const void *data,
+ size_t size);
} wil_fw_handlers[] = {
- {wil_fw_type_comment, fw_handle_comment},
- {wil_fw_type_data, fw_handle_data},
- {wil_fw_type_fill, fw_handle_fill},
+ {wil_fw_type_comment, fw_handle_comment, fw_handle_capabilities},
+ {wil_fw_type_data, fw_handle_data, fw_ignore_section},
+ {wil_fw_type_fill, fw_handle_fill, fw_ignore_section},
/* wil_fw_type_action */
/* wil_fw_type_verify */
- {wil_fw_type_file_header, fw_handle_file_header},
- {wil_fw_type_direct_write, fw_handle_direct_write},
- {wil_fw_type_gateway_data, fw_handle_gateway_data},
- {wil_fw_type_gateway_data4, fw_handle_gateway_data4},
+ {wil_fw_type_file_header, fw_handle_file_header,
+ fw_handle_file_header},
+ {wil_fw_type_direct_write, fw_handle_direct_write, fw_ignore_section},
+ {wil_fw_type_gateway_data, fw_handle_gateway_data, fw_ignore_section},
+ {wil_fw_type_gateway_data4, fw_handle_gateway_data4,
+ fw_ignore_section},
};
static int wil_fw_handle_record(struct wil6210_priv *wil, int type,
- const void *data, size_t size)
+ const void *data, size_t size, bool load)
{
int i;
- for (i = 0; i < ARRAY_SIZE(wil_fw_handlers); i++) {
+ for (i = 0; i < ARRAY_SIZE(wil_fw_handlers); i++)
if (wil_fw_handlers[i].type == type)
- return wil_fw_handlers[i].handler(wil, data, size);
- }
+ return load ?
+ wil_fw_handlers[i].load_handler(
+ wil, data, size) :
+ wil_fw_handlers[i].parse_handler(
+ wil, data, size);
wil_err_fw(wil, "unknown record type: %d\n", type);
return -EINVAL;
}
/**
- * wil_fw_load - load FW into device
- *
- * Load the FW and uCode code and data to the corresponding device
- * memory regions
+ * wil_fw_process - process section from FW file
+ * if load is true: Load the FW and uCode code and data to the
+ * corresponding device memory regions,
+ * otherwise only parse and look for capabilities
*
* Return error code
*/
-static int wil_fw_load(struct wil6210_priv *wil, const void *data, size_t size)
+static int wil_fw_process(struct wil6210_priv *wil, const void *data,
+ size_t size, bool load)
{
int rc = 0;
const struct wil_fw_record_head *hdr;
@@ -437,7 +473,7 @@ static int wil_fw_load(struct wil6210_priv *wil, const void *data, size_t size)
return -EINVAL;
}
rc = wil_fw_handle_record(wil, le16_to_cpu(hdr->type),
- &hdr[1], hdr_sz);
+ &hdr[1], hdr_sz, load);
if (rc)
return rc;
}
@@ -456,13 +492,16 @@ static int wil_fw_load(struct wil6210_priv *wil, const void *data, size_t size)
}
/**
- * wil_request_firmware - Request firmware and load to device
+ * wil_request_firmware - Request firmware
*
- * Request firmware image from the file and load it to device
+ * Request firmware image from the file
+ * If load is true, load firmware to device, otherwise
+ * only parse and extract capabilities
*
* Return error code
*/
-int wil_request_firmware(struct wil6210_priv *wil, const char *name)
+int wil_request_firmware(struct wil6210_priv *wil, const char *name,
+ bool load)
{
int rc, rc1;
const struct firmware *fw;
@@ -482,7 +521,7 @@ int wil_request_firmware(struct wil6210_priv *wil, const char *name)
rc = rc1;
goto out;
}
- rc = wil_fw_load(wil, d, rc1);
+ rc = wil_fw_process(wil, d, rc1, load);
if (rc < 0)
goto out;
}
diff --git a/drivers/net/wireless/ath/wil6210/main.c b/drivers/net/wireless/ath/wil6210/main.c
index 7b7619c..7198c86 100644
--- a/drivers/net/wireless/ath/wil6210/main.c
+++ b/drivers/net/wireless/ath/wil6210/main.c
@@ -894,10 +894,10 @@ int wil_reset(struct wil6210_priv *wil, bool load_fw)
wil_halt_cpu(wil);
/* Loading f/w from the file */
- rc = wil_request_firmware(wil, WIL_FW_NAME);
+ rc = wil_request_firmware(wil, WIL_FW_NAME, true);
if (rc)
return rc;
- rc = wil_request_firmware(wil, WIL_FW2_NAME);
+ rc = wil_request_firmware(wil, WIL_FW2_NAME, true);
if (rc)
return rc;
diff --git a/drivers/net/wireless/ath/wil6210/pcie_bus.c b/drivers/net/wireless/ath/wil6210/pcie_bus.c
index 5b7a9d2..44746ca 100644
--- a/drivers/net/wireless/ath/wil6210/pcie_bus.c
+++ b/drivers/net/wireless/ath/wil6210/pcie_bus.c
@@ -39,6 +39,7 @@ void wil_set_capabilities(struct wil6210_priv *wil)
u32 rev_id = wil_r(wil, RGF_USER_JTAG_DEV_ID);
bitmap_zero(wil->hw_capabilities, hw_capability_last);
+ bitmap_zero(wil->fw_capabilities, WMI_FW_CAPABILITY_MAX);
switch (rev_id) {
case JTAG_DEV_ID_SPARROW_B0:
@@ -52,6 +53,9 @@ void wil_set_capabilities(struct wil6210_priv *wil)
}
wil_info(wil, "Board hardware is %s\n", wil->hw_name);
+
+ /* extract FW capabilities from file without loading the FW */
+ wil_request_firmware(wil, WIL_FW_NAME, false);
}
void wil_disable_irq(struct wil6210_priv *wil)
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h b/drivers/net/wireless/ath/wil6210/wil6210.h
index 1eb7fe7..979536c 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -580,6 +580,7 @@ struct wil6210_priv {
u32 hw_version;
const char *hw_name;
DECLARE_BITMAP(hw_capabilities, hw_capability_last);
+ DECLARE_BITMAP(fw_capabilities, WMI_FW_CAPABILITY_MAX);
u8 n_mids; /* number of additional MIDs as reported by FW */
u32 recovery_count; /* num of FW recovery attempts in a short time */
u32 recovery_state; /* FW recovery state machine */
@@ -895,7 +896,8 @@ void wil6210_unmask_irq_rx(struct wil6210_priv *wil);
int wil_iftype_nl2wmi(enum nl80211_iftype type);
int wil_ioctl(struct wil6210_priv *wil, void __user *data, int cmd);
-int wil_request_firmware(struct wil6210_priv *wil, const char *name);
+int wil_request_firmware(struct wil6210_priv *wil, const char *name,
+ bool load);
int wil_can_suspend(struct wil6210_priv *wil, bool is_runtime);
int wil_suspend(struct wil6210_priv *wil, bool is_runtime);
--
1.9.1
^ permalink raw reply related
* [PATCH 2/4] wil6210: align to latest auto generated wmi.h
From: Maya Erez @ 2016-08-22 9:42 UTC (permalink / raw)
To: Kalle Valo; +Cc: Lior David, linux-wireless, wil6210, Maya Erez
In-Reply-To: <1471858942-23766-1-git-send-email-qca_merez@qca.qualcomm.com>
From: Lior David <qca_liord@qca.qualcomm.com>
Align to latest version of the auto generated wmi file
describing the interface with FW.
Signed-off-by: Lior David <qca_liord@qca.qualcomm.com>
Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
---
drivers/net/wireless/ath/wil6210/wmi.h | 292 +++++++++++++++++++++++++++++++++
1 file changed, 292 insertions(+)
diff --git a/drivers/net/wireless/ath/wil6210/wmi.h b/drivers/net/wireless/ath/wil6210/wmi.h
index 349510c..f430e8a 100644
--- a/drivers/net/wireless/ath/wil6210/wmi.h
+++ b/drivers/net/wireless/ath/wil6210/wmi.h
@@ -46,6 +46,16 @@ enum wmi_mid {
MID_BROADCAST = 0xFF,
};
+/* FW capability IDs
+ * Each ID maps to a bit in a 32-bit bitmask value provided by the FW to
+ * the host
+ */
+enum wmi_fw_capability {
+ WMI_FW_CAPABILITY_FTM = 0,
+ WMI_FW_CAPABILITY_PS_CONFIG = 1,
+ WMI_FW_CAPABILITY_MAX,
+};
+
/* WMI_CMD_HDR */
struct wmi_cmd_hdr {
u8 mid;
@@ -170,6 +180,13 @@ enum wmi_command_id {
/* Not supported yet */
WMI_PS_MID_CFG_READ_CMDID = 0x920,
WMI_RS_CFG_CMDID = 0x921,
+ WMI_GET_DETAILED_RS_RES_CMDID = 0x922,
+ WMI_AOA_MEAS_CMDID = 0x923,
+ WMI_TOF_SESSION_START_CMDID = 0x991,
+ WMI_TOF_GET_CAPABILITIES_CMDID = 0x992,
+ WMI_TOF_SET_LCR_CMDID = 0x993,
+ WMI_TOF_SET_LCI_CMDID = 0x994,
+ WMI_TOF_CHANNEL_INFO_CMDID = 0x995,
WMI_SET_MAC_ADDRESS_CMDID = 0xF003,
WMI_ABORT_SCAN_CMDID = 0xF007,
WMI_SET_PROMISCUOUS_MODE_CMDID = 0xF041,
@@ -843,6 +860,88 @@ struct wmi_pmc_cmd {
__le64 mem_base;
} __packed;
+enum wmi_aoa_meas_type {
+ WMI_AOA_PHASE_MEAS = 0x00,
+ WMI_AOA_PHASE_AMP_MEAS = 0x01,
+};
+
+/* WMI_AOA_MEAS_CMDID */
+struct wmi_aoa_meas_cmd {
+ u8 mac_addr[WMI_MAC_LEN];
+ /* channels IDs:
+ * 0 - 58320 MHz
+ * 1 - 60480 MHz
+ * 2 - 62640 MHz
+ */
+ u8 channel;
+ /* enum wmi_aoa_meas_type */
+ u8 aoa_meas_type;
+ __le32 meas_rf_mask;
+} __packed;
+
+enum wmi_tof_burst_duration {
+ WMI_TOF_BURST_DURATION_250_USEC = 2,
+ WMI_TOF_BURST_DURATION_500_USEC = 3,
+ WMI_TOF_BURST_DURATION_1_MSEC = 4,
+ WMI_TOF_BURST_DURATION_2_MSEC = 5,
+ WMI_TOF_BURST_DURATION_4_MSEC = 6,
+ WMI_TOF_BURST_DURATION_8_MSEC = 7,
+ WMI_TOF_BURST_DURATION_16_MSEC = 8,
+ WMI_TOF_BURST_DURATION_32_MSEC = 9,
+ WMI_TOF_BURST_DURATION_64_MSEC = 10,
+ WMI_TOF_BURST_DURATION_128_MSEC = 11,
+ WMI_TOF_BURST_DURATION_NO_PREFERENCES = 15,
+};
+
+enum wmi_tof_session_start_flags {
+ WMI_TOF_SESSION_START_FLAG_SECURED = 0x1,
+ WMI_TOF_SESSION_START_FLAG_ASAP = 0x2,
+ WMI_TOF_SESSION_START_FLAG_LCI_REQ = 0x4,
+ WMI_TOF_SESSION_START_FLAG_LCR_REQ = 0x8,
+};
+
+/* WMI_TOF_SESSION_START_CMDID */
+struct wmi_ftm_dest_info {
+ u8 channel;
+ /* wmi_tof_session_start_flags_e */
+ u8 flags;
+ u8 initial_token;
+ u8 num_of_ftm_per_burst;
+ u8 num_of_bursts_exp;
+ /* wmi_tof_burst_duration_e */
+ u8 burst_duration;
+ /* Burst Period indicate interval between two consecutive burst
+ * instances, in units of 100 ms
+ */
+ __le16 burst_period;
+ u8 dst_mac[WMI_MAC_LEN];
+ __le16 reserved;
+} __packed;
+
+/* WMI_TOF_SESSION_START_CMDID */
+struct wmi_tof_session_start_cmd {
+ __le32 session_id;
+ u8 num_of_aoa_measures;
+ u8 aoa_type;
+ __le16 num_of_dest;
+ u8 reserved[4];
+ struct wmi_ftm_dest_info ftm_dest_info[0];
+} __packed;
+
+enum wmi_tof_channel_info_report_type {
+ WMI_TOF_CHANNEL_INFO_TYPE_CIR = 0x1,
+ WMI_TOF_CHANNEL_INFO_TYPE_RSSI = 0x2,
+ WMI_TOF_CHANNEL_INFO_TYPE_SNR = 0x4,
+ WMI_TOF_CHANNEL_INFO_TYPE_DEBUG_DATA = 0x8,
+ WMI_TOF_CHANNEL_INFO_TYPE_VENDOR_SPECIFIC = 0x10,
+};
+
+/* WMI_TOF_CHANNEL_INFO_CMDID */
+struct wmi_tof_channel_info_cmd {
+ /* wmi_tof_channel_info_report_type_e */
+ __le32 channel_info_report_request;
+} __packed;
+
/* WMI Events
* List of Events (target to host)
*/
@@ -934,6 +1033,14 @@ enum wmi_event_id {
/* Not supported yet */
WMI_PS_MID_CFG_READ_EVENTID = 0x1920,
WMI_RS_CFG_DONE_EVENTID = 0x1921,
+ WMI_GET_DETAILED_RS_RES_EVENTID = 0x1922,
+ WMI_AOA_MEAS_EVENTID = 0x1923,
+ WMI_TOF_SESSION_END_EVENTID = 0x1991,
+ WMI_TOF_GET_CAPABILITIES_EVENTID = 0x1992,
+ WMI_TOF_SET_LCR_EVENTID = 0x1993,
+ WMI_TOF_SET_LCI_EVENTID = 0x1994,
+ WMI_TOF_FTM_PER_DEST_RES_EVENTID = 0x1995,
+ WMI_TOF_CHANNEL_INFO_EVENTID = 0x1996,
WMI_SET_CHANNEL_EVENTID = 0x9000,
WMI_ASSOC_REQ_EVENTID = 0x9001,
WMI_EAPOL_RX_EVENTID = 0x9002,
@@ -1003,6 +1110,13 @@ struct wmi_fw_ver_event {
__le32 bl_minor;
__le32 bl_subminor;
__le32 bl_build;
+ /* The number of entries in the FW capabilies array */
+ u8 fw_capabilities_len;
+ u8 reserved[3];
+ /* FW capabilities info
+ * Must be the last member of the struct
+ */
+ __le32 fw_capabilities[0];
} __packed;
/* WMI_GET_RF_STATUS_EVENTID */
@@ -1565,6 +1679,41 @@ struct wmi_rs_cfg_done_event {
u8 reserved[2];
} __packed;
+/* WMI_GET_DETAILED_RS_RES_CMDID */
+struct wmi_get_detailed_rs_res_cmd {
+ /* connection id */
+ u8 cid;
+ u8 reserved[3];
+} __packed;
+
+/* RS results status */
+enum wmi_rs_results_status {
+ WMI_RS_RES_VALID = 0x00,
+ WMI_RS_RES_INVALID = 0x01,
+};
+
+/* Rate search results */
+struct wmi_rs_results {
+ /* number of sent MPDUs */
+ u8 num_of_tx_pkt[WMI_NUM_MCS];
+ /* number of non-acked MPDUs */
+ u8 num_of_non_acked_pkt[WMI_NUM_MCS];
+ /* RS timestamp */
+ __le32 tsf;
+ /* RS selected MCS */
+ u8 mcs;
+} __packed;
+
+/* WMI_GET_DETAILED_RS_RES_EVENTID */
+struct wmi_get_detailed_rs_res_event {
+ u8 cid;
+ /* enum wmi_rs_results_status */
+ u8 status;
+ /* detailed rs results */
+ struct wmi_rs_results rs_results;
+ u8 reserved[3];
+} __packed;
+
/* broadcast connection ID */
#define WMI_LINK_MAINTAIN_CFG_CID_BROADCAST (0xFFFFFFFF)
@@ -1892,4 +2041,147 @@ struct wmi_ps_mid_cfg_read_event {
__le32 status;
} __packed;
+#define WMI_AOA_MAX_DATA_SIZE (128)
+
+enum wmi_aoa_meas_status {
+ WMI_AOA_MEAS_SUCCESS = 0x00,
+ WMI_AOA_MEAS_PEER_INCAPABLE = 0x01,
+ WMI_AOA_MEAS_FAILURE = 0x02,
+};
+
+/* WMI_AOA_MEAS_EVENTID */
+struct wmi_aoa_meas_event {
+ u8 mac_addr[WMI_MAC_LEN];
+ /* channels IDs:
+ * 0 - 58320 MHz
+ * 1 - 60480 MHz
+ * 2 - 62640 MHz
+ */
+ u8 channel;
+ /* enum wmi_aoa_meas_type */
+ u8 aoa_meas_type;
+ /* Measurments are from RFs, defined by the mask */
+ __le32 meas_rf_mask;
+ /* enum wmi_aoa_meas_status */
+ u8 meas_status;
+ u8 reserved;
+ /* Length of meas_data in bytes */
+ __le16 length;
+ u8 meas_data[WMI_AOA_MAX_DATA_SIZE];
+} __packed;
+
+/* WMI_TOF_GET_CAPABILITIES_EVENTID */
+struct wmi_tof_get_capabilities_event {
+ u8 ftm_capability;
+ /* maximum supported number of destination to start TOF */
+ u8 max_num_of_dest;
+ /* maximum supported number of measurements per burst */
+ u8 max_num_of_meas_per_burst;
+ u8 reserved;
+ /* maximum supported multi bursts */
+ __le16 max_multi_bursts_sessions;
+ /* maximum supported FTM burst duration , wmi_tof_burst_duration_e */
+ __le16 max_ftm_burst_duration;
+ /* AOA supported types */
+ __le32 aoa_supported_types;
+} __packed;
+
+enum wmi_tof_session_end_status {
+ WMI_TOF_SESSION_END_NO_ERROR = 0x00,
+ WMI_TOF_SESSION_END_FAIL = 0x01,
+ WMI_TOF_SESSION_END_PARAMS_ERROR = 0x02,
+ WMI_TOF_SESSION_END_ABORTED = 0x03,
+};
+
+/* WMI_TOF_SESSION_END_EVENTID */
+struct wmi_tof_session_end_event {
+ /* FTM session ID */
+ __le32 session_id;
+ /* wmi_tof_session_end_status_e */
+ u8 status;
+ u8 reserved[3];
+} __packed;
+
+/* Responder FTM Results */
+struct wmi_responder_ftm_res {
+ u8 t1[6];
+ u8 t2[6];
+ u8 t3[6];
+ u8 t4[6];
+ __le16 tod_err;
+ __le16 toa_err;
+ __le16 tod_err_initiator;
+ __le16 toa_err_initiator;
+} __packed;
+
+enum wmi_tof_ftm_per_dest_res_status {
+ WMI_PER_DEST_RES_NO_ERROR = 0x00,
+ WMI_PER_DEST_RES_TX_RX_FAIL = 0x01,
+ WMI_PER_DEST_RES_PARAM_DONT_MATCH = 0x02,
+};
+
+enum wmi_tof_ftm_per_dest_res_flags {
+ WMI_PER_DEST_RES_REQ_START = 0x01,
+ WMI_PER_DEST_RES_BURST_REPORT_END = 0x02,
+ WMI_PER_DEST_RES_REQ_END = 0x04,
+ WMI_PER_DEST_RES_PARAM_UPDATE = 0x08,
+};
+
+/* WMI_TOF_FTM_PER_DEST_RES_EVENTID */
+struct wmi_tof_ftm_per_dest_res_event {
+ /* FTM session ID */
+ __le32 session_id;
+ /* destination MAC address */
+ u8 dst_mac[WMI_MAC_LEN];
+ /* wmi_tof_ftm_per_dest_res_flags_e */
+ u8 flags;
+ /* wmi_tof_ftm_per_dest_res_status_e */
+ u8 status;
+ /* responder ASAP */
+ u8 responder_asap;
+ /* responder number of FTM per burst */
+ u8 responder_num_ftm_per_burst;
+ /* responder number of FTM burst exponent */
+ u8 responder_num_ftm_bursts_exp;
+ /* responder burst duration ,wmi_tof_burst_duration_e */
+ u8 responder_burst_duration;
+ /* responder burst period, indicate interval between two consecutive
+ * burst instances, in units of 100 ms
+ */
+ __le16 responder_burst_period;
+ /* receive burst counter */
+ __le16 bursts_cnt;
+ /* tsf of responder start burst */
+ __le32 tsf_sync;
+ /* actual received ftm per burst */
+ u8 actual_ftm_per_burst;
+ u8 reserved0[7];
+ struct wmi_responder_ftm_res responder_ftm_res[0];
+} __packed;
+
+enum wmi_tof_channel_info_type {
+ WMI_TOF_CHANNEL_INFO_AOA = 0x00,
+ WMI_TOF_CHANNEL_INFO_LCI = 0x01,
+ WMI_TOF_CHANNEL_INFO_LCR = 0x02,
+ WMI_TOF_CHANNEL_INFO_VENDOR_SPECIFIC = 0x03,
+ WMI_TOF_CHANNEL_INFO_CIR = 0x04,
+ WMI_TOF_CHANNEL_INFO_RSSI = 0x05,
+ WMI_TOF_CHANNEL_INFO_SNR = 0x06,
+ WMI_TOF_CHANNEL_INFO_DEBUG = 0x07,
+};
+
+/* WMI_TOF_CHANNEL_INFO_EVENTID */
+struct wmi_tof_channel_info_event {
+ /* FTM session ID */
+ __le32 session_id;
+ /* destination MAC address */
+ u8 dst_mac[WMI_MAC_LEN];
+ /* wmi_tof_channel_info_type_e */
+ u8 type;
+ /* data report length */
+ u8 len;
+ /* data report payload */
+ u8 report[0];
+} __packed;
+
#endif /* __WILOCITY_WMI_H__ */
--
1.9.1
^ permalink raw reply related
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