Re: A good way to get CSI info to user-space?

2017-10-23 Thread Johannes Berg 
On Mon, 2017-10-23 at 13:59 -0700, Ben Greear wrote:

> > The CSI data has variable length [1] but it's fundamentally always tied
> > to a specific frame and as such we've always attached it to that frame
> > using a radiotap vendor namespace.
> > 
> > You can easily implement that in a mac80211 driver since it has support
> > for that via RX_FLAG_RADIOTAP_VENDOR_DATA and the associated struct
> > ieee80211_vendor_radiotap that you put into the skb's head.
> > 
> > Why should anything else be needed?
> 
> So this would only show up in user-space in something like a pkt-capture?

Sure. But since you can easily add virtual monitor interfaces at any
time, that doesn't really mean anything.

johannes

Re: [PATCH] ath10k: rebuild crypto header in RX data frames

2017-10-23 Thread Kalle Valo 
Jasmine Strong  writes:

> That's what I saw.  A bcom client was able to associate and not pass
> any traffic.  This is on all three of 9882, 9888 and 4019.

Thanks for the report, we'll investigate it. And I see that your email
was now succesfully delivered to the list:

http://lists.infradead.org/pipermail/ath10k/2017-October/010325.html

-- 
Kalle Valo

[PATCH] rtlwifi: Remove seq_number from rtl_tid_data

2017-10-23 Thread pkshih 
From: Ping-Ke Shih 

Since mac80211 maintains the sequence number for each STA/TID,
driver doesn't need to maintain a copy.

Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/base.c |  6 ++
 drivers/net/wireless/realtek/rtlwifi/pci.c  | 17 -
 drivers/net/wireless/realtek/rtlwifi/usb.c  | 17 -
 drivers/net/wireless/realtek/rtlwifi/wifi.h |  1 -
 4 files changed, 2 insertions(+), 39 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c 
b/drivers/net/wireless/realtek/rtlwifi/base.c
index 0b34886321f1..9f35b25bddf2 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -1618,9 +1618,8 @@ int rtl_tx_agg_start(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
 
RT_TRACE(rtlpriv, COMP_SEND, DBG_DMESG,
 "on ra = %pM tid = %d seq:%d\n", sta->addr, tid,
-tid_data->seq_number);
+*ssn);
 
-   *ssn = tid_data->seq_number;
tid_data->agg.agg_state = RTL_AGG_START;
 
ieee80211_start_tx_ba_cb_irqsafe(vif, sta->addr, tid);
@@ -1679,8 +1678,7 @@ int rtl_rx_agg_start(struct ieee80211_hw *hw,
tid_data = _entry->tids[tid];
 
RT_TRACE(rtlpriv, COMP_RECV, DBG_DMESG,
-"on ra = %pM tid = %d seq:%d\n", sta->addr, tid,
-tid_data->seq_number);
+"on ra = %pM tid = %d\n", sta->addr, tid);
 
tid_data->agg.rx_agg_state = RTL_RX_AGG_START;
return 0;
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c 
b/drivers/net/wireless/realtek/rtlwifi/pci.c
index b9a6d23364be..eb12818b46b3 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -1623,7 +1623,6 @@ static int rtl_pci_tx(struct ieee80211_hw *hw,
  struct rtl_tcb_desc *ptcb_desc)
 {
struct rtl_priv *rtlpriv = rtl_priv(hw);
-   struct rtl_sta_info *sta_entry = NULL;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct rtl8192_tx_ring *ring;
struct rtl_tx_desc *pdesc;
@@ -1635,9 +1634,6 @@ static int rtl_pci_tx(struct ieee80211_hw *hw,
__le16 fc = rtl_get_fc(skb);
u8 *pda_addr = hdr->addr1;
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
-   /*ssn */
-   u8 tid = 0;
-   u16 seq_number = 0;
u8 own;
u8 temp_one = 1;
 
@@ -1699,19 +1695,6 @@ static int rtl_pci_tx(struct ieee80211_hw *hw,
return skb->len;
}
 
-   if (ieee80211_is_data_qos(fc)) {
-   tid = rtl_get_tid(skb);
-   if (sta) {
-   sta_entry = (struct rtl_sta_info *)sta->drv_priv;
-   seq_number = (le16_to_cpu(hdr->seq_ctrl) &
- IEEE80211_SCTL_SEQ) >> 4;
-   seq_number += 1;
-
-   if (!ieee80211_has_morefrags(hdr->frame_control))
-   sta_entry->tids[tid].seq_number = seq_number;
-   }
-   }
-
if (ieee80211_is_data(fc))
rtlpriv->cfg->ops->led_control(hw, LED_CTL_TX);
 
diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c 
b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 5590d07d0918..39b033b3b53a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -952,17 +952,12 @@ static void _rtl_usb_tx_preprocess(struct ieee80211_hw 
*hw,
   u16 hw_queue)
 {
struct rtl_priv *rtlpriv = rtl_priv(hw);
-   struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct rtl_tx_desc *pdesc = NULL;
struct rtl_tcb_desc tcb_desc;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)(skb->data);
__le16 fc = hdr->frame_control;
u8 *pda_addr = hdr->addr1;
-   /* ssn */
-   u8 *qc = NULL;
-   u8 tid = 0;
-   u16 seq_number = 0;
 
memset(_desc, 0, sizeof(struct rtl_tcb_desc));
if (ieee80211_is_auth(fc)) {
@@ -983,20 +978,8 @@ static void _rtl_usb_tx_preprocess(struct ieee80211_hw *hw,
rtlpriv->stats.txbytesbroadcast += skb->len;
else
rtlpriv->stats.txbytesunicast += skb->len;
-   if (ieee80211_is_data_qos(fc)) {
-   qc = ieee80211_get_qos_ctl(hdr);
-   tid = qc[0] & IEEE80211_QOS_CTL_TID_MASK;
-   seq_number = (le16_to_cpu(hdr->seq_ctrl) &
-IEEE80211_SCTL_SEQ) >> 4;
-   seq_number += 1;
-   seq_number <<= 4;
-   }
rtlpriv->cfg->ops->fill_tx_desc(hw, hdr, (u8 *)pdesc, NULL, info, sta, 
skb,
hw_queue, _desc);
-   if (!ieee80211_has_morefrags(hdr->frame_control)) {
-   if (qc)
-

[PATCH] rtlwifi: rtl8821ae: Fix typo in variable name

2017-10-23 Thread Nik Nyby 
In _rtl8821ae_dbi_write(), wrtie_addr should be write_addr.

Signed-off-by: Nik Nyby 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
index 1d431d4bf6d2..6a9d8ee0ae9f 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c
@@ -1130,13 +1130,13 @@ static u8 _rtl8821ae_dbi_read(struct rtl_priv *rtlpriv, 
u16 addr)
 static void _rtl8821ae_dbi_write(struct rtl_priv *rtlpriv, u16 addr, u8 data)
 {
u8 tmp = 0, count = 0;
-   u16 wrtie_addr, remainder = addr % 4;
+   u16 write_addr, remainder = addr % 4;
 
-   wrtie_addr = REG_DBI_WDATA + remainder;
-   rtl_write_byte(rtlpriv, wrtie_addr, data);
+   write_addr = REG_DBI_WDATA + remainder;
+   rtl_write_byte(rtlpriv, write_addr, data);
 
-   wrtie_addr = (addr & 0xfffc) | (BIT(0) << (remainder + 12));
-   rtl_write_word(rtlpriv, REG_DBI_ADDR, wrtie_addr);
+   write_addr = (addr & 0xfffc) | (BIT(0) << (remainder + 12));
+   rtl_write_word(rtlpriv, REG_DBI_ADDR, write_addr);
 
rtl_write_byte(rtlpriv, REG_DBI_FLAG, 0x1);
 
-- 
2.14.2

Re: elce linux conference 2017

2017-10-23 Thread Sergey Matyukevich 
> Hi all,
> 
> are there any one of WiFi devs on ELCE?
> Will be good to meet you. For example:
> Table 1 - Networking Area, Level LL, Outside Roma.


Hello Oleksij,

I am here on ELCE till Wednesday evening. Feel free to ping me via conferenece
app or email.

Regards,
Sergey

Re: A good way to get CSI info to user-space?

2017-10-23 Thread Ben Greear 

On 10/23/2017 01:30 PM, Johannes Berg wrote:

Hi,


I have been poking at ath10k to get some CSI reporting working.
The CSI reports are a bit over 2k bytes in length, and they could
happen quite often.  As far as I can tell, there is no good way in
the kernel to make this available.

I was thinking maybe a callback into the mac80211 stack, which would
then send a netlink event might be a useful way to implement this?


The CSI data has variable length [1] but it's fundamentally always tied
to a specific frame and as such we've always attached it to that frame
using a radiotap vendor namespace.

You can easily implement that in a mac80211 driver since it has support
for that via RX_FLAG_RADIOTAP_VENDOR_DATA and the associated struct
ieee80211_vendor_radiotap that you put into the skb's head.

Why should anything else be needed?


So this would only show up in user-space in something like a pkt-capture?

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: A good way to get CSI info to user-space?

2017-10-23 Thread Johannes Berg 
Hi,

> I have been poking at ath10k to get some CSI reporting working.
> The CSI reports are a bit over 2k bytes in length, and they could
> happen quite often.  As far as I can tell, there is no good way in
> the kernel to make this available.
> 
> I was thinking maybe a callback into the mac80211 stack, which would
> then send a netlink event might be a useful way to implement this?

The CSI data has variable length [1] but it's fundamentally always tied
to a specific frame and as such we've always attached it to that frame
using a radiotap vendor namespace.

You can easily implement that in a mac80211 driver since it has support
for that via RX_FLAG_RADIOTAP_VENDOR_DATA and the associated struct
ieee80211_vendor_radiotap that you put into the skb's head.

Why should anything else be needed?

johannes

[1] mostly depending on the bandwidth

Re: [PATCH] ath10k: rebuild crypto header in RX data frames

2017-10-23 Thread Sebastian Gottschall 

Am 23.10.2017 um 16:24 schrieb Vasanthakumar Thiagarajan:

On Saturday 21 October 2017 01:41 AM, Sebastian Gottschall wrote:

i suggest the following patch on top of yours. please tell me if my thoughts 
are correct here. its mainly a guess

I agree we need to take care of this for newly added ciphers as well. How about 
making it as a separate patch
to make the patch bit smaller and to reduce the difficulties in back porting it 
for ciphers supported for long
time?
the patch for these both ciphers doesnt make it bigger. just a few 
lines. the main problem right now is that the original patch without my 
enhancements isnt working. it breaks encryption

Vasanth



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

elce linux conference 2017

2017-10-23 Thread Oleksij Rempel 
Hi all,

are there any one of WiFi devs on ELCE?
Will be good to meet you. For example:
Table 1 - Networking Area, Level LL, Outside Roma.

Please contact me if you are here :)
-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

A good way to get CSI info to user-space?

2017-10-23 Thread Ben Greear 

Hello,

I have been poking at ath10k to get some CSI reporting working.
The CSI reports are a bit over 2k bytes in length, and they could
happen quite often.  As far as I can tell, there is no good way in
the kernel to make this available.

I was thinking maybe a callback into the mac80211 stack, which would
then send a netlink event might be a useful way to implement this?

Any other suggestions on this?

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH] ath10k: rebuild crypto header in RX data frames

2017-10-23 Thread Vasanthakumar Thiagarajan 
On Saturday 21 October 2017 01:41 AM, Sebastian Gottschall wrote:
> i suggest the following patch on top of yours. please tell me if my thoughts 
> are correct here. its mainly a guess

I agree we need to take care of this for newly added ciphers as well. How about 
making it as a separate patch 
to make the patch bit smaller and to reduce the difficulties in back porting it 
for ciphers supported for long 
time?

Vasanth

Re: [PATCH] staging: wilc1000: replace redundant computations with 0

2017-10-23 Thread Dan Carpenter 

On Tue, Oct 10, 2017 at 03:05:48PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Shifting and masking strHostIfSetMulti->enabled is redundant since
> enabled is a bool and so all the shifted and masked values will be
> zero. Replace them with zero to simplify the code.
> 
> Detected by CoverityScan, CID#1339458 ("Bad shift operation") and
> CID#1339506 ("Operands don't affect result").
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/staging/wilc1000/host_interface.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/wilc1000/host_interface.c 
> b/drivers/staging/wilc1000/host_interface.c
> index 7b620658ec38..94477dd08c85 100644
> --- a/drivers/staging/wilc1000/host_interface.c
> +++ b/drivers/staging/wilc1000/host_interface.c
> @@ -2417,9 +2417,9 @@ static void Handle_SetMulticastFilter(struct wilc_vif 
> *vif,
>  
>   pu8CurrByte = wid.val;
>   *pu8CurrByte++ = (strHostIfSetMulti->enabled & 0xFF);
> - *pu8CurrByte++ = ((strHostIfSetMulti->enabled >> 8) & 0xFF);
> - *pu8CurrByte++ = ((strHostIfSetMulti->enabled >> 16) & 0xFF);
> - *pu8CurrByte++ = ((strHostIfSetMulti->enabled >> 24) & 0xFF);
> + *pu8CurrByte++ = 0;
> + *pu8CurrByte++ = 0;
> + *pu8CurrByte++ = 0;

This is harder to understand now.  I would be better to solve this by
declaring a struct with the right format and using cpu_to_be32().

regards,
dan carpenter

Re: [PATCH v2 31/37] mac80211_hwsim: Replace hrtimer tasklet with softirq hrtimer

2017-10-23 Thread Johannes Berg 

> > I guess you mean you *can* build it? Surely you're introducing the new
> > HR timer modes in some patch that I didn't see? :-)
> 
> Sorry, we did not want to expose you to 30 patches fiddling with the core
> code. They are on LKML though.

Sure, no worries. I just didn't even realize I shouldn't be applying
the patch (myself) :-)

> > Right. Then again, why even pass it to init() and start()? Can you
> > start without going through start()?
> 
> There is a subtle magic with CLOCK_REALTIME timers.
> 
> CLOCK_REALTIME timers differentiate between ABS and REL modes. ABS timers
> are exposed to clock modifications (settimeofday() ...), REL timers are
> not. We solve that by associating them to different clock bases, which has
> to be done at init time, but the start function needs the REL/ABS
> information as well.
> 
> For CLOCK_MONOTONIC this is not really required, but the function is used
> for all clock bases, so we require the mode bits for all.

Hmm. Couldn't you just store that then from init to use in start?

If you don't store it, yet don't verify that you passed the same 
thing, do you at least check that it's compatible? Sounds like
something will totally go wrong if I pass CLOCK_REALTIME/ABS first and
then use REL for start, or vice versa?

Also, in the code I see only checking

if (mode != HRTIMER_MODE_ABS) {
// change clock ID:
// realtime -> monotonic
// realtime_soft -> monotonic_soft
}

but you're passing HRTIMER_MODE_ABS_SOFT too, isn't that considered an
ABS mode?

But then, looking at the code again, I don't even see
HRTIMER_MODE_ABS_SOFT existing, it sounds like it should be

hrtimer_init(..., CLOCK_REALTIME_SOFT, HRTIMER_MODE_REL);

then?

At least then the code I mentioned above makes sense, but it still
feels pretty dangerous to not just store the mode and use it in start,
but to require passing it again. You even just introduced the same bug,
it just happened to not matter in this case since the clock isn't
realtime.

Or am I completely confused now?

johannes

Re: [PATCH v2 31/37] mac80211_hwsim: Replace hrtimer tasklet with softirq hrtimer

2017-10-23 Thread Thomas Gleixner 
On Mon, 23 Oct 2017, Johannes Berg wrote:
> On Mon, 2017-10-23 at 12:23 +0200, Thomas Gleixner wrote:
> > On Mon, 23 Oct 2017, Johannes Berg wrote:
> > 
> > > On Sun, 2017-10-22 at 23:40 +0200, Anna-Maria Gleixner wrote:
> > > > From: Thomas Gleixner 
> > > > 
> > > > Switch the timer to HRTIMER_MODE_SOFT, which executed the timer
> > > > callback in softirq context and remove the hrtimer_tasklet.
> > 
> > I can't build as its part of the whole hrtimer rework series.
> 
> I guess you mean you *can* build it? Surely you're introducing the new
> HR timer modes in some patch that I didn't see? :-)

Sorry, we did not want to expose you to 30 patches fiddling with the core
code. They are on LKML though.

> > > > +   hrtimer_init(>beacon_timer, CLOCK_MONOTONIC,
> > > > +HRTIMER_MODE_ABS_SOFT);
> > 
> > Sure, though it does not matter in that case. Will fix that up.
> 
> Right. Then again, why even pass it to init() and start()? Can you
> start without going through start()?

There is a subtle magic with CLOCK_REALTIME timers.

CLOCK_REALTIME timers differentiate between ABS and REL modes. ABS timers
are exposed to clock modifications (settimeofday() ...), REL timers are
not. We solve that by associating them to different clock bases, which has
to be done at init time, but the start function needs the REL/ABS
information as well.

For CLOCK_MONOTONIC this is not really required, but the function is used
for all clock bases, so we require the mode bits for all.

Thanks,

tglx

Re: [PATCH v2 31/37] mac80211_hwsim: Replace hrtimer tasklet with softirq hrtimer

2017-10-23 Thread Johannes Berg 
On Mon, 2017-10-23 at 12:23 +0200, Thomas Gleixner wrote:
> On Mon, 23 Oct 2017, Johannes Berg wrote:
> 
> > On Sun, 2017-10-22 at 23:40 +0200, Anna-Maria Gleixner wrote:
> > > From: Thomas Gleixner 
> > > 
> > > Switch the timer to HRTIMER_MODE_SOFT, which executed the timer
> > > callback in softirq context and remove the hrtimer_tasklet.
> 
> I can't build as its part of the whole hrtimer rework series.

I guess you mean you *can* build it? Surely you're introducing the new
HR timer modes in some patch that I didn't see? :-)

> > > +   hrtimer_init(>beacon_timer, CLOCK_MONOTONIC,
> > > +HRTIMER_MODE_ABS_SOFT);
> 
> Sure, though it does not matter in that case. Will fix that up.

Right. Then again, why even pass it to init() and start()? Can you
start without going through start()?

johannes

Re: [PATCH v2 31/37] mac80211_hwsim: Replace hrtimer tasklet with softirq hrtimer

2017-10-23 Thread Thomas Gleixner 
On Mon, 23 Oct 2017, Johannes Berg wrote:

> On Sun, 2017-10-22 at 23:40 +0200, Anna-Maria Gleixner wrote:
> > From: Thomas Gleixner 
> > 
> > Switch the timer to HRTIMER_MODE_SOFT, which executed the timer
> > callback in softirq context and remove the hrtimer_tasklet.

I can't build as its part of the whole hrtimer rework series.

> This doesn't build on my tree, due to HRTIMER_MODE_REL_SOFT not
> existing. Neither does HRTIMER_MODE_SOFT mentioned above, but that's
> just a commit log mistake.

Oops.

> (It also didn't apply on my tree, but that was a trivial context
> change.)
> 
> I don't understand why you initialize it with HRTIMER_MODE_ABS_SOFT
> either though:
> 
> > +   hrtimer_init(>beacon_timer, CLOCK_MONOTONIC,
> > +HRTIMER_MODE_ABS_SOFT);

Sure, though it does not matter in that case. Will fix that up.

Thanks,

tglx

Re: [PATCH v2 31/37] mac80211_hwsim: Replace hrtimer tasklet with softirq hrtimer

2017-10-23 Thread Johannes Berg 
On Sun, 2017-10-22 at 23:40 +0200, Anna-Maria Gleixner wrote:
> From: Thomas Gleixner 
> 
> Switch the timer to HRTIMER_MODE_SOFT, which executed the timer
> callback in softirq context and remove the hrtimer_tasklet.

This doesn't build on my tree, due to HRTIMER_MODE_REL_SOFT not
existing. Neither does HRTIMER_MODE_SOFT mentioned above, but that's
just a commit log mistake.

(It also didn't apply on my tree, but that was a trivial context
change.)

I don't understand why you initialize it with HRTIMER_MODE_ABS_SOFT
either though:

> +   hrtimer_init(>beacon_timer, CLOCK_MONOTONIC,
> +HRTIMER_MODE_ABS_SOFT);

shouldn't that already be REL?

johannes

Re: [PATCH] net: wireless: mark expected switch fall-throughs

2017-10-23 Thread Johannes Berg 
On Fri, 2017-10-20 at 12:21 -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
> This code was tested by compilation only (GCC 7.2.0 was used).
> Please, verify if the actual intention of the code is to fall through.

Please, if you're proposing patches, do that yourself.

johannes

Re: [PATCH V6 1/5] mac80211: Enable TDLS peer buffer STA feature

2017-10-23 Thread Johannes Berg 
On Fri, 2017-10-20 at 03:34 +, Yingying Tang wrote:
> Hi Johannes,
> 
> I have built and tested it, it can work

No, you haven't, at least not comprehensively. Try to enable debugfs.

johannes