Re: pull-request: mac80211-next 2018-02-22

[David Miller]

From: Johannes Berg 
Date: Fri, 23 Feb 2018 12:29:39 +0100

> On Thu, 2018-02-22 at 15:19 -0500, David Miller wrote:
>> 
>> Pulled, thank you!
> 
> Thanks. I just realized that I have a patch pending for -next that
> depends another commit in net/mac80211 (or would otherwise conflict
> badly while applying, and again while merging later), could I ask you
> to pull net into net-next at some point now?

I'll get that to happen in the next day or two.  Pablo asked for this
as well.

Re: [PATCH v8] ath10k: add LED and GPIO controlling support for various chipsets

[kbuild test robot]

Hi Sebastian,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on v4.16-rc2 next-20180223]
[cannot apply to ath6kl/ath-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/s-gottschall-dd-wrt-com/ath10k-add-LED-and-GPIO-controlling-support-for-various-chipsets/20180221-134523
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
config: i386-randconfig-b0-02231423 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/net//wireless/ath/ath10k/core.c: In function 'ath10k_attach_led':
>> drivers/net//wireless/ath/ath10k/core.c:2331:3: error: implicit declaration 
>> of function 'ath10k_add_led' [-Werror=implicit-function-declaration]
  ath10k_add_led(ar, >gpio->wifi_led);
  ^
   cc1: some warnings being treated as errors

vim +/ath10k_add_led +2331 drivers/net//wireless/ath/ath10k/core.c

  2322  
  2323  static void ath10k_attach_led(struct ath10k *ar)
  2324  {
  2325  if (!ar->gpio_attached) {
  2326  ar->gpio->wifi_led.active_low = 1;
  2327  ar->gpio->wifi_led.gpio = ar->hw_params.led_pin;
  2328  ar->gpio->wifi_led.name = ar->gpio->label;
  2329  ar->gpio->wifi_led.default_state = 
LEDS_GPIO_DEFSTATE_KEEP;
  2330  
> 2331  ath10k_add_led(ar, >gpio->wifi_led);
  2332  }
  2333  ath10k_reset_led_pin(ar); /* initially we need to configure the 
led pin to output */
  2334  }
  2335  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: brcmfmac signal/interference issues

[Daniel Drake]

Hi,

On Wed, Feb 21, 2018 at 12:39 PM, Daniel Drake  wrote:
> Thanks for looking into this. Here is the brcmfmac43455-sdio.txt file
> we are using:
> https://gist.github.com/dsd/d7ee3caa6dfd77f0bcd16cf272b20298
> This is identical to the 4345r6nvram.txt file from windows.

I checked Windows again and it seems to be using a firmware file
4345r6rtecdc.bin alongside this nvram data.
This firmware is different from the one in linux-firmware. I've
uploaded it here:
https://drive.google.com/open?id=1MUsiaoozslJb8SCYOR-FNbJFuD-h4PY_

I was hoping to try this on Linux to see if it makes any difference to
the issue seen here.
However, with thisi firmware in place, I can't connect to the network
at all. It associates, wpa_supplicant never sees the first WPA2 key
message sent from the AP - even though wireshark on a separate monitor
shows that the key message was sent, and that the STA acked it.

I turned off WPA2 to make it an open network instead, and now I am
unable to complete the DHCP conversation. According to the monitor
station, the STA succesfully transmits DHCPDISCOVER and the AP
responds with DHCPOFFER. The offer is acked, but dhclient never sees
it, and eventually times out.

Any ideas why this firmware may not be working at all on linux?

Thanks,
Daniel

Re: [PATCH v2] cfg80211/nl80211: add DFS offload flag

[Dmitry Lebed]

23.02.2018 14:32, Johannes Berg wrote:

On Thu, 2018-02-22 at 12:15 +0300, Sergey Matyukevich wrote:

+ * @NL80211_EXT_FEATURE_DFS_OFFLOAD: HW/driver will offload DFS actions.
+ * Device or driver will do all DFS-related actions by itself,
+ * informing user-space about CAC progress, radar detection event,
+ * channel change triggered by radar detection event.
+ * No need to start CAC from user-space, no need to react to
+ * "radar detected" event.

The "channel change" part bothers me a bit - isn't normally hostapd
very much in control of the channel? How does it even get notified of
the new channel? How can you configure the parameters like how many
beacons to include the (E)CSA IE for, and whether to add ECSA or not
etc?

johannes


hostapd will be notified with NL80211_CMD_CH_SWITCH_NOTIFY event
and it already has a handler for this event and looks like it works as 
expected.
In case of radar detection, userspace (hostapd) should receive two 
events (with DFS offload enabled):

1. RADAR_DETECT - and in case of DFS_OFFLOAD flag turned on don't do any CSA
2. CH_SWITCH_NOTIFY - at the moment when HW will switch channel as a 
reaction

    to radar event

Currently, all CSA will be sent with default parameters. If it's crucial 
to tune e.g. TBTT
count, then let's add it with a separate commit later, when DFS offload 
will be

implemented in the whole SW stack (driver/kernel/userspace).

DFS offload should be quite useful and should fix some issues in a 
repeater configuration.
There are a number of issues which are hard to fix without DFS offload 
feature:
e.g. if repeater has detected a radar and sent radar report frame to 
master AP,
master AP will reply with CSA, but hostapd will try to change channel to 
different channel.


Regards,
Dmitry

[PATCH 4.4 180/193] nl80211: Sanitize array index in parse_txq_params

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Dan Williams 

(cherry picked from commit 259d8c1e984318497c84eef547bbb6b1d9f4eb05)

Wireless drivers rely on parse_txq_params to validate that txq_params->ac
is less than NL80211_NUM_ACS by the time the low-level driver's ->conf_tx()
handler is called. Use a new helper, array_index_nospec(), to sanitize
txq_params->ac with respect to speculation. I.e. ensure that any
speculation into ->conf_tx() handlers is done with a value of
txq_params->ac that is within the bounds of [0, NL80211_NUM_ACS).

Reported-by: Christian Lamparter 
Reported-by: Elena Reshetova 
Signed-off-by: Dan Williams 
Signed-off-by: Thomas Gleixner 
Acked-by: Johannes Berg 
Cc: linux-a...@vger.kernel.org
Cc: kernel-harden...@lists.openwall.com
Cc: gre...@linuxfoundation.org
Cc: linux-wireless@vger.kernel.org
Cc: torva...@linux-foundation.org
Cc: "David S. Miller" 
Cc: a...@linux.intel.com
Link: 
https://lkml.kernel.org/r/151727419584.33451.7700736761686184303.st...@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: David Woodhouse 
[jwang: cherry pick to 4.4]
Signed-off-by: Jack Wang 
Signed-off-by: Greg Kroah-Hartman 
---
 net/wireless/nl80211.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1879,20 +1880,22 @@ static const struct nla_policy txq_param
 static int parse_txq_params(struct nlattr *tb[],
struct ieee80211_txq_params *txq_params)
 {
+   u8 ac;
+
if (!tb[NL80211_TXQ_ATTR_AC] || !tb[NL80211_TXQ_ATTR_TXOP] ||
!tb[NL80211_TXQ_ATTR_CWMIN] || !tb[NL80211_TXQ_ATTR_CWMAX] ||
!tb[NL80211_TXQ_ATTR_AIFS])
return -EINVAL;
 
-   txq_params->ac = nla_get_u8(tb[NL80211_TXQ_ATTR_AC]);
+   ac = nla_get_u8(tb[NL80211_TXQ_ATTR_AC]);
txq_params->txop = nla_get_u16(tb[NL80211_TXQ_ATTR_TXOP]);
txq_params->cwmin = nla_get_u16(tb[NL80211_TXQ_ATTR_CWMIN]);
txq_params->cwmax = nla_get_u16(tb[NL80211_TXQ_ATTR_CWMAX]);
txq_params->aifs = nla_get_u8(tb[NL80211_TXQ_ATTR_AIFS]);
 
-   if (txq_params->ac >= NL80211_NUM_ACS)
+   if (ac >= NL80211_NUM_ACS)
return -EINVAL;
-
+   txq_params->ac = array_index_nospec(ac, NL80211_NUM_ACS);
return 0;
 }
 

Re: [PATCH 4/4] mac80211: support station 4-addr mode fast-rx

[Johannes Berg]

On Fri, 2018-02-23 at 10:06 +0100, Felix Fietkau wrote:
> Signed-off-by: Felix Fietkau 
> ---
>  net/mac80211/cfg.c |  2 --
>  net/mac80211/rx.c  | 11 +++
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
> index 6f9d5beec73e..72b5a2ec4e94 100644
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -160,7 +160,6 @@ static int ieee80211_change_iface(struct wiphy *wiphy,
>   if (type == NL80211_IFTYPE_AP_VLAN &&
>   params && params->use_4addr == 0) {
>   RCU_INIT_POINTER(sdata->u.vlan.sta, NULL);
> - ieee80211_check_fast_rx_iface(sdata);
>   } else if (type == NL80211_IFTYPE_STATION &&
>  params && params->use_4addr >= 0) {
>   sdata->u.mgd.use_4addr = params->use_4addr;
> @@ -1575,7 +1574,6 @@ static int ieee80211_change_station(struct wiphy *wiphy,
>   }
>  
>   rcu_assign_pointer(vlansdata->u.vlan.sta, sta);
> - __ieee80211_check_fast_rx_iface(vlansdata);
>   }
>  
>   if (sta->sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&

I'm not convinced this is right - don't you have to recheck to modify
the station data? Otherwise you'd just drop all the frames to the
slowpath again due to the first patch in the series, no?

johannes

Re: [PATCH 3/4] mac80211: support fast-rx with incompatible PS capabilities when PS is disabled

[Johannes Berg]

I've applied 1 to mac80211, and 2/3 to mac80211-next, so please only
resend 4, unless you can convince me it's OK as is :-)

johannes

Re: pull-request: mac80211-next 2018-02-22

[Johannes Berg]

On Thu, 2018-02-22 at 15:19 -0500, David Miller wrote:
> 
> Pulled, thank you!

Thanks. I just realized that I have a patch pending for -next that
depends another commit in net/mac80211 (or would otherwise conflict
badly while applying, and again while merging later), could I ask you
to pull net into net-next at some point now?

Thanks,
johannes

Re: [PATCH v2] cfg80211/nl80211: add DFS offload flag

[Johannes Berg]

On Thu, 2018-02-22 at 12:15 +0300, Sergey Matyukevich wrote:
> From: Dmitry Lebed 
> 
> Add wiphy EXT_FEATURE flag to indicate that HW or driver does
> all DFS actions by itself.
> User-space functionality already implemented in hostapd using
> vendor-specific (QCA) OUI to advertise DFS offload support.
> Need to introduce generic flag to inform about DFS offload support.
> For deivces with DFS_OFFLOAD flag set user-space will no longer
> need to issue CAC or do any actions in response to
> "radar detected" events. HW will do everything by itself and send
> events to user-space to indicate that CAC was started/finished, etc.
> 
> + * @NL80211_EXT_FEATURE_DFS_OFFLOAD: HW/driver will offload DFS actions.
> + *   Device or driver will do all DFS-related actions by itself,
> + *   informing user-space about CAC progress, radar detection event,
> + *   channel change triggered by radar detection event.
> + *   No need to start CAC from user-space, no need to react to
> + *   "radar detected" event.

The "channel change" part bothers me a bit - isn't normally hostapd
very much in control of the channel? How does it even get notified of
the new channel? How can you configure the parameters like how many
beacons to include the (E)CSA IE for, and whether to add ECSA or not
etc?

johannes

[PATCH] ath: fix false radar detection in JP region

[srirrama]

From: Sriram R 

This fixes false radar detection (of radar type 7)
in Japan region by correcting the radar pulse type
to Chirp as per specification.

Signed-off-by: Sriram R 
---
 drivers/net/wireless/ath/dfs_pattern_detector.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.c 
b/drivers/net/wireless/ath/dfs_pattern_detector.c
index 4100ffd..448b83e 100644
--- a/drivers/net/wireless/ath/dfs_pattern_detector.c
+++ b/drivers/net/wireless/ath/dfs_pattern_detector.c
@@ -115,7 +115,7 @@ static const struct radar_detector_specs 
jp_radar_ref_types[] = {
JP_PATTERN(4, 0, 5, 150, 230, 1, 23, 50, false),
JP_PATTERN(5, 6, 10, 200, 500, 1, 16, 50, false),
JP_PATTERN(6, 11, 20, 200, 500, 1, 12, 50, false),
-   JP_PATTERN(7, 50, 100, 1000, 2000, 1, 3, 50, false),
+   JP_PATTERN(7, 50, 100, 1000, 2000, 1, 3, 50, true),
JP_PATTERN(5, 0, 1, 333, 333, 1, 9, 50, false),
 };
 
-- 
2.7.4

Re: [PATCH 2/3] mwifiex: support sysfs initiated device coredump

[Arend van Spriel]

+ Johannes (for devcoredump documentation question).

On 2/22/2018 8:35 PM, Brian Norris wrote:

Hi Arend,

On Thu, Feb 22, 2018 at 01:17:56PM +0100, Arend van Spriel wrote:

On 2/21/2018 11:59 PM, Brian Norris wrote:

On Wed, Feb 21, 2018 at 11:50:19AM +0100, Arend van Spriel wrote:

Since commit 3c47d19ff4dc ("drivers: base: add coredump driver ops")
it is possible to initiate a device coredump from user-space. This
patch adds support for it adding the .coredump() driver callback.
As there is no longer a need to initiate it through debugfs remove
that code.

Signed-off-by: Arend van Spriel 
---
   drivers/net/wireless/marvell/mwifiex/debugfs.c | 31 
+-
   drivers/net/wireless/marvell/mwifiex/pcie.c| 19 ++--
   drivers/net/wireless/marvell/mwifiex/sdio.c| 13 +++
   drivers/net/wireless/marvell/mwifiex/usb.c | 14 
   4 files changed, 45 insertions(+), 32 deletions(-)


The documentation doesn't really say [1], but is the coredump supposed
to happen synchronously? Because the mwifiex implementation is
asynchronous, whereas it looks like the brcmfmac one is synchronous.


Well, that depends on the eye of the beholder I guess. From user-space
perspective it is asynchronous regardless. A write access to the coredump
sysfs file eventually results in a uevent when the devcoredump entry is
created, ie. after driver has made a dev_coredump API call. Whether the
driver does that synchronously or asynchronously is irrelevant as far as
user-space is concerned.


Is it really? The driver infrastructure seems to guarantee that the
entirety of a driver's ->coredump() will complete before returning from
the write. So it might be reasonable for some user to assume (based on
implementation details, e.g., of brcmfmac) that the devcoredump will be
ready by the time the write() syscall returns, absent documentation that
says otherwise. But then, that's not how mwifiex works right now, so
they might be surprised if they switch drivers.


Ok. I already agreed that the uevent behavior should be documented. The 
error handling you are bringing up below was something I realized as 
well. I am not familiar with mwifiex to determine what it can say about 
the coredump succeeding before scheduling the work.



Anyway, *I'm* already personally used to these dumps being asynchronous,
and writing tooling to listen for the uevent instead. But that doesn't
mean everyone will be.

Also, due to the differences in async/sync, mwifiex doesn't really
provide you much chance for error handling, because most errors would be
asynchronous. So brcmfmac's "coredump" has more chance for user programs
to error-check than mwifiex's (due to the asynchronous nature) [1].

BTW, I push on this mostly because this is migrating from a debugfs
feature (that is easy to hand-wave off as not really providing a
consistent/stable API, etc., etc.) to a documented sysfs feature. If it
were left to rot in debugfs, I probably wouldn't be as bothered ;)


I appreciate it. The documentation is not in the stable ABI folder yet 
so I welcome any and all improvements. Might learn a thing or two from it.



Brian

[1] In fact, the ABI documentation really just describes kernel
internals, rather than documenting any user-facing details, from what I
can tell.


You are right. Clearly I did not reach the end my learning curve here. I
assumed referring to the existing dev_coredump facility was sufficient, but
maybe it is worth a patch to be more explicit and mention the uevent
behavior. Also dev_coredump facility may be disabled upon which the trigger
will have no effect in sysfs. In the kernel the data passed by the driver is
simply freed by dev_coredump facility.


Is there any other documentation for the coredump feature? I don't
really see much.


Any other than the code itself you mean? I am not sure. Maybe Johannes 
knows.



Brian

[1] Oh wait, but I see that while ->coredump() has an integer return
code...the caller ignores it:

static ssize_t coredump_store(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
device_lock(dev);
if (dev->driver->coredump)
dev->driver->coredump(dev);
device_unlock(dev);

return count;
}
static DEVICE_ATTR_WO(coredump);

Is that a bug or a feature?


Yeah. Let's call it a bug. Just not sure what to go for. Return the 
error or change coredump callback to void return type.


Regards,
Arend

Re: [PATCH 2/3] mwifiex: support sysfs initiated device coredump

[Johannes Berg]

Hey,

Hadn't really followed this discussion much due to other fires
elsewhere :-)

On Fri, 2018-02-23 at 11:39 +0100, Arend van Spriel wrote:

> > > Well, that depends on the eye of the beholder I guess. From user-space
> > > perspective it is asynchronous regardless. A write access to the coredump
> > > sysfs file eventually results in a uevent when the devcoredump entry is
> > > created, ie. after driver has made a dev_coredump API call. Whether the
> > > driver does that synchronously or asynchronously is irrelevant as far as
> > > user-space is concerned.
> > 
> > Is it really? The driver infrastructure seems to guarantee that the
> > entirety of a driver's ->coredump() will complete before returning from
> > the write. So it might be reasonable for some user to assume (based on
> > implementation details, e.g., of brcmfmac) that the devcoredump will be
> > ready by the time the write() syscall returns, absent documentation that
> > says otherwise. But then, that's not how mwifiex works right now, so
> > they might be surprised if they switch drivers.

I can see how you might want to have that kind of behaviour, but you'd
have to jump through some hoops to see if the coredump you saw is
actually the right one - you probably want an asynchronous coredump
"collector" and then wait for it to show up (with some reasonable
timeout) on the actual filesystem, not on sysfs?

Otherwise you have to trawl sysfs for the right coredump I guess, which
too is possible.

> > > You are right. Clearly I did not reach the end my learning curve here. I
> > > assumed referring to the existing dev_coredump facility was sufficient, 
> > > but
> > > maybe it is worth a patch to be more explicit and mention the uevent
> > > behavior. Also dev_coredump facility may be disabled upon which the 
> > > trigger
> > > will have no effect in sysfs. In the kernel the data passed by the driver 
> > > is
> > > simply freed by dev_coredump facility.
> > 
> > Is there any other documentation for the coredump feature? I don't
> > really see much.
> 
> Any other than the code itself you mean? I am not sure. Maybe Johannes 
> knows.

There isn't really, it originally was really simple, but then somebody
(Kees perhaps?) requested a way to turn it off forever for security or
privacy concerns and it became more complicated.

> > static ssize_t coredump_store(struct device *dev, struct device_attribute 
> > *attr,
> > const char *buf, size_t count)
> > {
> > device_lock(dev);
> > if (dev->driver->coredump)
> > dev->driver->coredump(dev);
> > device_unlock(dev);
> > 
> > return count;
> > }
> > static DEVICE_ATTR_WO(coredump);
> > 
> > Is that a bug or a feature?
> 
> Yeah. Let's call it a bug. Just not sure what to go for. Return the 
> error or change coredump callback to void return type.

I'm not sure it matters all that much - the underlying devcoredump
calls all have no return value (void), and given the above complexities
with the ability to turn off devcoredumping entirely you cannot rely on
this return value to tell you if a dump was created or not, at least
not without much more infrastructure work.

johannes

Re: brcmfmac signal/interference issues

[Arend van Spriel]

On 2/23/2018 9:26 AM, Daniel Drake wrote:

Hi,

On Wed, Feb 21, 2018 at 12:39 PM, Daniel Drake  wrote:

Thanks for looking into this. Here is the brcmfmac43455-sdio.txt file
we are using:
https://gist.github.com/dsd/d7ee3caa6dfd77f0bcd16cf272b20298
This is identical to the 4345r6nvram.txt file from windows.


I checked Windows again and it seems to be using a firmware file
4345r6rtecdc.bin alongside this nvram data.
This firmware is different from the one in linux-firmware. I've
uploaded it here:
https://drive.google.com/open?id=1MUsiaoozslJb8SCYOR-FNbJFuD-h4PY_

I was hoping to try this on Linux to see if it makes any difference to
the issue seen here.
However, with thisi firmware in place, I can't connect to the network
at all. It associates, wpa_supplicant never sees the first WPA2 key
message sent from the AP - even though wireshark on a separate monitor
shows that the key message was sent, and that the STA acked it.

I turned off WPA2 to make it an open network instead, and now I am
unable to complete the DHCP conversation. According to the monitor
station, the STA succesfully transmits DHCPDISCOVER and the AP
responds with DHCPOFFER. The offer is acked, but dhclient never sees
it, and eventually times out.

Any ideas why this firmware may not be working at all on linux?


Yup. Windows firmware talks NDIS. If you run 'strings 4345r6rtecdc.bin | 
tail -1' you can see the firmware build target and it likely has 'ndis' 
in it.


Now are you using BT as well on this device? Another suggestion I got is 
to disable transmit beamforming which brcmfmac enables by default. Not 
sure if this device supports it, but could you try the patch below.


Regards,
Arend

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c

index 9be0b05..512ea57 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -363,9 +363,6 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
goto done;
}

-   /* Enable tx beamforming, errors can be ignored (not supported) */
-   (void)brcmf_fil_iovar_int_set(ifp, "txbf", 1);
-
/* do bus specific preinit here */
err = brcmf_bus_preinit(ifp->drvr->bus_if);
 done:

[PATCH 1/4] mac80211: drop frames with unexpected DS bits from fast-rx to slow path

[Felix Fietkau]

Fixes rx for 4-addr packets in AP mode

Signed-off-by: Felix Fietkau 
---
 net/mac80211/rx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 3dc162ddc3a6..1c947e005434 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -3937,7 +3937,7 @@ static bool ieee80211_invoke_fast_rx(struct 
ieee80211_rx_data *rx,
if ((hdr->frame_control & cpu_to_le16(IEEE80211_FCTL_FROMDS |
  IEEE80211_FCTL_TODS)) !=
fast_rx->expected_ds_bits)
-   goto drop;
+   return false;
 
/* assign the key to drop unencrypted frames (later)
 * and strip the IV/MIC if necessary
-- 
2.14.2

[PATCH 2/4] mac80211: support AP 4-addr mode fast-rx

[Felix Fietkau]

Signed-off-by: Felix Fietkau 
---
 net/mac80211/rx.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 1c947e005434..bef83c6bf50c 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -3783,6 +3783,15 @@ void ieee80211_check_fast_rx(struct sta_info *sta)
!(sdata->flags & IEEE80211_SDATA_DONT_BRIDGE_PACKETS) &&
(sdata->vif.type != NL80211_IFTYPE_AP_VLAN ||
 !sdata->u.vlan.sta);
+
+   if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
+   sdata->u.vlan.sta) {
+   fastrx.expected_ds_bits |=
+   cpu_to_le16(IEEE80211_FCTL_FROMDS);
+   fastrx.sa_offs = offsetof(struct ieee80211_hdr, addr4);
+   fastrx.internal_forward = 0;
+   }
+
break;
default:
goto clear;
-- 
2.14.2

[PATCH 4/4] mac80211: support station 4-addr mode fast-rx

[Felix Fietkau]

Signed-off-by: Felix Fietkau 
---
 net/mac80211/cfg.c |  2 --
 net/mac80211/rx.c  | 11 +++
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 6f9d5beec73e..72b5a2ec4e94 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -160,7 +160,6 @@ static int ieee80211_change_iface(struct wiphy *wiphy,
if (type == NL80211_IFTYPE_AP_VLAN &&
params && params->use_4addr == 0) {
RCU_INIT_POINTER(sdata->u.vlan.sta, NULL);
-   ieee80211_check_fast_rx_iface(sdata);
} else if (type == NL80211_IFTYPE_STATION &&
   params && params->use_4addr >= 0) {
sdata->u.mgd.use_4addr = params->use_4addr;
@@ -1575,7 +1574,6 @@ static int ieee80211_change_station(struct wiphy *wiphy,
}
 
rcu_assign_pointer(vlansdata->u.vlan.sta, sta);
-   __ieee80211_check_fast_rx_iface(vlansdata);
}
 
if (sta->sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 6e2506a84586..6944705c5258 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -3747,10 +3747,6 @@ void ieee80211_check_fast_rx(struct sta_info *sta)
 
switch (sdata->vif.type) {
case NL80211_IFTYPE_STATION:
-   /* 4-addr is harder to deal with, later maybe */
-   if (sdata->u.mgd.use_4addr)
-   goto clear;
-
if (sta->sta.tdls) {
fastrx.da_offs = offsetof(struct ieee80211_hdr, addr1);
fastrx.sa_offs = offsetof(struct ieee80211_hdr, addr2);
@@ -3763,6 +3759,13 @@ void ieee80211_check_fast_rx(struct sta_info *sta)
cpu_to_le16(IEEE80211_FCTL_FROMDS);
}
 
+   if (sdata->u.mgd.use_4addr && !sta->sta.tdls) {
+   fastrx.expected_ds_bits |=
+   cpu_to_le16(IEEE80211_FCTL_TODS);
+   fastrx.da_offs = offsetof(struct ieee80211_hdr, addr3);
+   fastrx.sa_offs = offsetof(struct ieee80211_hdr, addr4);
+   }
+
if (!sdata->u.mgd.powersave)
break;
 
-- 
2.14.2

[PATCH 3/4] mac80211: support fast-rx with incompatible PS capabilities when PS is disabled

[Felix Fietkau]

When powersave is disabled for the interface, we can do fast-rx anyway.

Signed-off-by: Felix Fietkau 
---
 net/mac80211/cfg.c |  1 +
 net/mac80211/rx.c  | 17 +++--
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 46028e12e216..6f9d5beec73e 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2685,6 +2685,7 @@ static int ieee80211_set_power_mgmt(struct wiphy *wiphy, 
struct net_device *dev,
 
ieee80211_recalc_ps(local);
ieee80211_recalc_ps_vif(sdata);
+   ieee80211_check_fast_rx_iface(sdata);
 
return 0;
 }
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index bef83c6bf50c..6e2506a84586 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -3750,12 +3750,7 @@ void ieee80211_check_fast_rx(struct sta_info *sta)
/* 4-addr is harder to deal with, later maybe */
if (sdata->u.mgd.use_4addr)
goto clear;
-   /* software powersave is a huge mess, avoid all of it */
-   if (ieee80211_hw_check(>hw, PS_NULLFUNC_STACK))
-   goto clear;
-   if (ieee80211_hw_check(>hw, SUPPORTS_PS) &&
-   !ieee80211_hw_check(>hw, SUPPORTS_DYNAMIC_PS))
-   goto clear;
+
if (sta->sta.tdls) {
fastrx.da_offs = offsetof(struct ieee80211_hdr, addr1);
fastrx.sa_offs = offsetof(struct ieee80211_hdr, addr2);
@@ -3767,6 +3762,16 @@ void ieee80211_check_fast_rx(struct sta_info *sta)
fastrx.expected_ds_bits =
cpu_to_le16(IEEE80211_FCTL_FROMDS);
}
+
+   if (!sdata->u.mgd.powersave)
+   break;
+
+   /* software powersave is a huge mess, avoid all of it */
+   if (ieee80211_hw_check(>hw, PS_NULLFUNC_STACK))
+   goto clear;
+   if (ieee80211_hw_check(>hw, SUPPORTS_PS) &&
+   !ieee80211_hw_check(>hw, SUPPORTS_DYNAMIC_PS))
+   goto clear;
break;
case NL80211_IFTYPE_AP_VLAN:
case NL80211_IFTYPE_AP:
-- 
2.14.2

Re: [PATCH] rtlwifi: rtl8723be: Fix loss of signal

[Kalle Valo]

Larry Finger  writes:

> In commit c713fb071edc ("rtlwifi: rtl8821ae: Fix connection lost problem
> correctly") a problem in rtl8821ae that caused loss of signal was fixed.
> That same problem has now been reported for rtl8723be. Accordingly,
> the ASPM L1 latency has been increased from 0 to 7 to fix the instability.
>
> Signed-off-by: Larry Finger 
> Cc: Stable 
> ---
> Kalle,
>
> This patch should be sent to 4.16.

Ok, I'll queue this for 4.16.

-- 
Kalle Valo

[stable 4.4 17/29] nl80211: Sanitize array index in parse_txq_params

[Jack Wang]

From: Dan Williams 

(cherry picked from commit 259d8c1e984318497c84eef547bbb6b1d9f4eb05)

Wireless drivers rely on parse_txq_params to validate that txq_params->ac
is less than NL80211_NUM_ACS by the time the low-level driver's ->conf_tx()
handler is called. Use a new helper, array_index_nospec(), to sanitize
txq_params->ac with respect to speculation. I.e. ensure that any
speculation into ->conf_tx() handlers is done with a value of
txq_params->ac that is within the bounds of [0, NL80211_NUM_ACS).

Reported-by: Christian Lamparter 
Reported-by: Elena Reshetova 
Signed-off-by: Dan Williams 
Signed-off-by: Thomas Gleixner 
Acked-by: Johannes Berg 
Cc: linux-a...@vger.kernel.org
Cc: kernel-harden...@lists.openwall.com
Cc: gre...@linuxfoundation.org
Cc: linux-wireless@vger.kernel.org
Cc: torva...@linux-foundation.org
Cc: "David S. Miller" 
Cc: a...@linux.intel.com
Link: 
https://lkml.kernel.org/r/151727419584.33451.7700736761686184303.st...@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: David Woodhouse 
Signed-off-by: Greg Kroah-Hartman 
[jwang: cherry pick to 4.4]
Signed-off-by: Jack Wang 
---
 net/wireless/nl80211.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 7950506..b0b58d1 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1879,20 +1880,22 @@ static const struct nla_policy 
txq_params_policy[NL80211_TXQ_ATTR_MAX + 1] = {
 static int parse_txq_params(struct nlattr *tb[],
struct ieee80211_txq_params *txq_params)
 {
+   u8 ac;
+
if (!tb[NL80211_TXQ_ATTR_AC] || !tb[NL80211_TXQ_ATTR_TXOP] ||
!tb[NL80211_TXQ_ATTR_CWMIN] || !tb[NL80211_TXQ_ATTR_CWMAX] ||
!tb[NL80211_TXQ_ATTR_AIFS])
return -EINVAL;
 
-   txq_params->ac = nla_get_u8(tb[NL80211_TXQ_ATTR_AC]);
+   ac = nla_get_u8(tb[NL80211_TXQ_ATTR_AC]);
txq_params->txop = nla_get_u16(tb[NL80211_TXQ_ATTR_TXOP]);
txq_params->cwmin = nla_get_u16(tb[NL80211_TXQ_ATTR_CWMIN]);
txq_params->cwmax = nla_get_u16(tb[NL80211_TXQ_ATTR_CWMAX]);
txq_params->aifs = nla_get_u8(tb[NL80211_TXQ_ATTR_AIFS]);
 
-   if (txq_params->ac >= NL80211_NUM_ACS)
+   if (ac >= NL80211_NUM_ACS)
return -EINVAL;
-
+   txq_params->ac = array_index_nospec(ac, NL80211_NUM_ACS);
return 0;
 }
 
-- 
2.7.4

Re: brcmfmac signal/interference issues

[Daniel Drake]

On Fri, Feb 23, 2018 at 12:54 PM, Arend van Spriel
 wrote:
> Yup. Windows firmware talks NDIS. If you run 'strings 4345r6rtecdc.bin |
> tail -1' you can see the firmware build target and it likely has 'ndis' in
> it.

43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf

Yes, ndis. So no easy way to run the same firmware on the 2 OSes.

> Now are you using BT as well on this device? Another suggestion I got is to
> disable transmit beamforming which brcmfmac enables by default. Not sure if
> this device supports it, but could you try the patch below.

Thanks for the ideas. I had already tried with the bluetooth disabled
- no change there.
Also reproduced the problem after applying your patch.

Daniel

[v8 2/8] rsi: add bluetooth rx endpoint

[Amitkumar Karwar]

From: Siva Rebbagondla 

USB endpoint 1 is used for WLAN which is presently in use.
USB endpoint 2 is introduced for BT Rx traffic. Enumeration
of Rx BT endpoint and submitting Rx BT URB are added.

>From /sys/kernel/debug/usb/devices,
Ad=81(I) is for WLAN EP IN and Ad=01(O) is for Wlan EP OUT.
Ad=82(I) is for BT EP IN and Ad=02(O) is for BT EP OUT.

T:  Bus=01 Lev=01 Prnt=01 Port=09 Cnt=03 Dev#=  4 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1618 ProdID=9113 Rev= 0.02
S:  Manufacturer=Redpine Signals, Inc.
S:  Product=Wireless USB Network Module
S:  SerialNumber=0001
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  2mA
I:* If#= 0 Alt= 0 #EPs= 6 Cls=00(>ifc ) Sub=00 Prot=00 Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Signed-off-by: Siva Rebbagondla 
Signed-off-by: Prameela Rani Garnepudi 
Signed-off-by: Amitkumar Karwar 
---
v8: Same as previos revisions
v2: Included '/sys/kernel/debug/usb/devices' info in patch description(Marcel)
---
 drivers/net/wireless/rsi/rsi_91x_usb.c | 37 --
 drivers/net/wireless/rsi/rsi_usb.h |  6 +++---
 2 files changed, 25 insertions(+), 18 deletions(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_usb.c 
b/drivers/net/wireless/rsi/rsi_91x_usb.c
index bbce809..9ab86fb 100644
--- a/drivers/net/wireless/rsi/rsi_91x_usb.c
+++ b/drivers/net/wireless/rsi/rsi_91x_usb.c
@@ -103,41 +103,42 @@ static int rsi_find_bulk_in_and_out_endpoints(struct 
usb_interface *interface,
struct usb_host_interface *iface_desc;
struct usb_endpoint_descriptor *endpoint;
__le16 buffer_size;
-   int ii, bep_found = 0;
+   int ii, bin_found = 0, bout_found = 0;
 
iface_desc = &(interface->altsetting[0]);
 
for (ii = 0; ii < iface_desc->desc.bNumEndpoints; ++ii) {
endpoint = &(iface_desc->endpoint[ii].desc);
 
-   if ((!(dev->bulkin_endpoint_addr)) &&
+   if (!dev->bulkin_endpoint_addr[bin_found] &&
(endpoint->bEndpointAddress & USB_DIR_IN) &&
-   ((endpoint->bmAttributes &
-   USB_ENDPOINT_XFERTYPE_MASK) ==
+   ((endpoint->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) ==
USB_ENDPOINT_XFER_BULK)) {
buffer_size = endpoint->wMaxPacketSize;
-   dev->bulkin_size = buffer_size;
-   dev->bulkin_endpoint_addr =
+   dev->bulkin_size[bin_found] = buffer_size;
+   dev->bulkin_endpoint_addr[bin_found] =
endpoint->bEndpointAddress;
+   bin_found++;
}
 
-   if (!dev->bulkout_endpoint_addr[bep_found] &&
+   if (!dev->bulkout_endpoint_addr[bout_found] &&
!(endpoint->bEndpointAddress & USB_DIR_IN) &&
((endpoint->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) ==
- USB_ENDPOINT_XFER_BULK)) {
-   dev->bulkout_endpoint_addr[bep_found] =
+   USB_ENDPOINT_XFER_BULK)) {
+   buffer_size = endpoint->wMaxPacketSize;
+   dev->bulkout_endpoint_addr[bout_found] =
endpoint->bEndpointAddress;
buffer_size = endpoint->wMaxPacketSize;
-   dev->bulkout_size[bep_found] = buffer_size;
-   bep_found++;
+   dev->bulkout_size[bout_found] = buffer_size;
+   bout_found++;
}
 
-   if (bep_found >= MAX_BULK_EP)
+   if (bin_found >= MAX_BULK_EP || bout_found >= MAX_BULK_EP)
break;
}
 
-   if (!(dev->bulkin_endpoint_addr) &&
-   (dev->bulkout_endpoint_addr[0]))
+   if (!(dev->bulkin_endpoint_addr[0]) &&
+   dev->bulkout_endpoint_addr[0])
return -EINVAL;
 
return 0;
@@ -273,7 +274,7 @@ static int rsi_rx_urb_submit(struct rsi_hw *adapter, u8 
ep_num)
usb_fill_bulk_urb(urb,
  dev->usbdev,
  usb_rcvbulkpipe(dev->usbdev,
-   dev->bulkin_endpoint_addr),
+ dev->bulkin_endpoint_addr[ep_num - 1]),
  urb->transfer_buffer,
  3000,
  rsi_rx_done_handler,
@@ -745,6 +746,12 @@ static int rsi_probe(struct usb_interface *pfunction,
if (status)
goto err1;
 
+   if (adapter->priv->coex_mode 

[v8 4/8] rsi: add coex support

[Amitkumar Karwar]

From: Prameela Rani Garnepudi 

With BT support, driver has to handle two streams of data
(i.e. wlan and BT). Actual coex implementation is in firmware.
Coex module just schedule the packets to firmware by taking them
from the corresponding paths.

Structures for module and protocol operations are introduced for
this purpose. Protocol operations structure is global structure
which can be shared among different modules. Move initialization
of coex and operating mode values to rsi_91x_init().

Signed-off-by: Prameela Rani Garnepudi 
Signed-off-by: Siva Rebbagondla 
Signed-off-by: Amitkumar Karwar 
---
v8: Resolve error reported by 'kbuild test robot' by moving header
file code under CONFIG_RSI_COEX flag
v7: Use mutex instead of semaphore (Kalle)
v6: Rename semaphore tx_bus_lock to tx_bus_sema. Modified coex
scheduling loop to avoid while(1) (Kalle)
v5: Same as earlier versions
---
 drivers/net/wireless/rsi/Kconfig|   9 ++
 drivers/net/wireless/rsi/Makefile   |   1 +
 drivers/net/wireless/rsi/rsi_91x_coex.c | 177 
 drivers/net/wireless/rsi/rsi_91x_hal.c  |  17 +--
 drivers/net/wireless/rsi/rsi_91x_main.c |  30 +-
 drivers/net/wireless/rsi/rsi_91x_mgmt.c |   2 +-
 drivers/net/wireless/rsi/rsi_91x_sdio.c |   1 +
 drivers/net/wireless/rsi/rsi_91x_usb.c  |   2 +
 drivers/net/wireless/rsi/rsi_coex.h |  37 +++
 drivers/net/wireless/rsi/rsi_main.h |   6 ++
 drivers/net/wireless/rsi/rsi_mgmt.h |   3 +
 include/net/rsi_91x.h   |  20 
 12 files changed, 295 insertions(+), 10 deletions(-)
 create mode 100644 drivers/net/wireless/rsi/rsi_91x_coex.c
 create mode 100644 drivers/net/wireless/rsi/rsi_coex.h

diff --git a/drivers/net/wireless/rsi/Kconfig b/drivers/net/wireless/rsi/Kconfig
index 7c5e4ca..e6135ee 100644
--- a/drivers/net/wireless/rsi/Kconfig
+++ b/drivers/net/wireless/rsi/Kconfig
@@ -42,4 +42,13 @@ config RSI_USB
  This option enables the USB bus support in rsi drivers.
  Select M (recommended), if you have a RSI 1x1 wireless module.
 
+config RSI_COEX
+   bool "Redpine Signals WLAN BT Coexistence support"
+   depends on BT_HCIRSI && RSI_91X
+   default y
+   ---help---
+ This option enables the WLAN BT coex support in rsi drivers.
+ Select M (recommended), if you have want to use this feature
+ and you have RS9113 module.
+
 endif # WLAN_VENDOR_RSI
diff --git a/drivers/net/wireless/rsi/Makefile 
b/drivers/net/wireless/rsi/Makefile
index 47c4590..ff87121a 100644
--- a/drivers/net/wireless/rsi/Makefile
+++ b/drivers/net/wireless/rsi/Makefile
@@ -5,6 +5,7 @@ rsi_91x-y   += rsi_91x_mac80211.o
 rsi_91x-y  += rsi_91x_mgmt.o
 rsi_91x-y  += rsi_91x_hal.o
 rsi_91x-y  += rsi_91x_ps.o
+rsi_91x-$(CONFIG_RSI_COEX) += rsi_91x_coex.o
 rsi_91x-$(CONFIG_RSI_DEBUGFS)  += rsi_91x_debugfs.o
 
 rsi_usb-y  += rsi_91x_usb.o rsi_91x_usb_ops.o
diff --git a/drivers/net/wireless/rsi/rsi_91x_coex.c 
b/drivers/net/wireless/rsi/rsi_91x_coex.c
new file mode 100644
index 000..c07e839
--- /dev/null
+++ b/drivers/net/wireless/rsi/rsi_91x_coex.c
@@ -0,0 +1,177 @@
+/**
+ * Copyright (c) 2018 Redpine Signals 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
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include "rsi_main.h"
+#include "rsi_coex.h"
+#include "rsi_mgmt.h"
+#include "rsi_hal.h"
+
+static enum rsi_coex_queues rsi_coex_determine_coex_q
+   (struct rsi_coex_ctrl_block *coex_cb)
+{
+   enum rsi_coex_queues q_num = RSI_COEX_Q_INVALID;
+
+   if (skb_queue_len(_cb->coex_tx_qs[RSI_COEX_Q_COMMON]) > 0)
+   q_num = RSI_COEX_Q_COMMON;
+   if (skb_queue_len(_cb->coex_tx_qs[RSI_COEX_Q_BT]) > 0)
+   q_num = RSI_COEX_Q_BT;
+   if (skb_queue_len(_cb->coex_tx_qs[RSI_COEX_Q_WLAN]) > 0)
+   q_num = RSI_COEX_Q_WLAN;
+
+   return q_num;
+}
+
+static void rsi_coex_sched_tx_pkts(struct rsi_coex_ctrl_block *coex_cb)
+{
+   enum rsi_coex_queues coex_q = RSI_COEX_Q_INVALID;
+   struct sk_buff *skb;
+
+   do {
+   coex_q = 

[v8 5/8] Bluetooth: btrsi: add new rsi bluetooth driver

[Amitkumar Karwar]

From: Prameela Rani Garnepudi 

Redpine bluetooth driver is a thin driver which depends on
'rsi_91x' driver for transmitting and receiving packets
to/from device. It creates hci interface when attach() is
called from 'rsi_91x' module.

Signed-off-by: Prameela Rani Garnepudi 
Signed-off-by: Siva Rebbagondla 
Acked-by: Marcel Holtmann 
Reviewed-by: Marcel Holtmann 
Signed-off-by: Amitkumar Karwar 
---
v8: Resolve 'kbuild test robot' reported error. Used asm/unaligned.h
header file instead of linux/unaligned/le_byteshift.h 
v7: Same as v6
v6: Renamed CONFIG_BT_RSI to CONFIG_BT_HCIRSI (Marcel)
v5: Addressed review comments from Marcel.
Removed reduntant switch case code from rsi_hci_recv_pkt()
Changed bt_cb(skb)->pkt_type to hci_skb_pkt_type(skb)
Removed reduntant '\n' from BT_ERR and redundant BT_INFO messages
Changed u8 *pkt to const u8 *pkt in rsi_hci_recv_pkt()
v4: Removed rsi_hci.h file. Made the functions static(Marcel)
v3: Made BT_RSI module by default off(Marcel)
Removed redundant exported function rsi_get_hci_ops()(Marcel)
v2: Addressed review comments from Marcel
Removed unnecessary 'depends on BT && BT_RFOMM' line in Kconfig
Removed redundant BT_INFO messages
h_adapter initialization and declaration in a single line.
Removed unnecessary error checks for HCI_RUNNING and fsm_state
Allocated new skb with skb_realloc_headroom() API if headroom is not 
sufficient
Used get_unaligned_le16 helpers
Moved a structure and union from header file to btrsi.c file
---
 drivers/bluetooth/Kconfig  |  12 +++
 drivers/bluetooth/Makefile |   2 +
 drivers/bluetooth/btrsi.c  | 188 +
 include/net/rsi_91x.h  |   4 +-
 4 files changed, 205 insertions(+), 1 deletion(-)
 create mode 100644 drivers/bluetooth/btrsi.c

diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 07e55cd..d8bbd66 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -392,4 +392,16 @@ config BT_QCOMSMD
  Say Y here to compile support for HCI over Qualcomm SMD into the
  kernel or say M to compile as a module.
 
+config BT_HCIRSI
+   tristate "Redpine HCI support"
+   default n
+   select RSI_COEX
+   help
+ Redpine BT driver.
+ This driver handles BT traffic from upper layers and pass
+ to the RSI_91x coex module for further scheduling to device
+
+ Say Y here to compile support for HCI over Redpine into the
+ kernel or say M to compile as a module.
+
 endmenu
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 4e4e44d..03cfc1b 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -28,6 +28,8 @@ obj-$(CONFIG_BT_QCA)  += btqca.o
 
 obj-$(CONFIG_BT_HCIUART_NOKIA) += hci_nokia.o
 
+obj-$(CONFIG_BT_HCIRSI)+= btrsi.o
+
 btmrvl-y   := btmrvl_main.o
 btmrvl-$(CONFIG_DEBUG_FS)  += btmrvl_debugfs.o
 
diff --git a/drivers/bluetooth/btrsi.c b/drivers/bluetooth/btrsi.c
new file mode 100644
index 000..5034325
--- /dev/null
+++ b/drivers/bluetooth/btrsi.c
@@ -0,0 +1,188 @@
+/**
+ * Copyright (c) 2017 Redpine Signals 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
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RSI_HEADROOM_FOR_BT_HAL16
+#define RSI_FRAME_DESC_SIZE16
+
+struct rsi_hci_adapter {
+   void *priv;
+   struct rsi_proto_ops *proto_ops;
+   struct hci_dev *hdev;
+};
+
+static int rsi_hci_open(struct hci_dev *hdev)
+{
+   return 0;
+}
+
+static int rsi_hci_close(struct hci_dev *hdev)
+{
+   return 0;
+}
+
+static int rsi_hci_flush(struct hci_dev *hdev)
+{
+   return 0;
+}
+
+static int rsi_hci_send_pkt(struct hci_dev *hdev, struct sk_buff *skb)
+{
+   struct rsi_hci_adapter *h_adapter = hci_get_drvdata(hdev);
+   struct sk_buff *new_skb = NULL;
+
+   switch (hci_skb_pkt_type(skb)) {
+   case HCI_COMMAND_PKT:
+   hdev->stat.cmd_tx++;
+   break;
+   case HCI_ACLDATA_PKT:
+   

[v8 7/8] rsi: add module parameter operating mode

[Amitkumar Karwar]

From: Prameela Rani Garnepudi 

Operating mode determines the support for other protocols.
This is made as module parameter for better usage.

Signed-off-by: Prameela Rani Garnepudi 
Signed-off-by: Siva Rebbagondla 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/rsi/rsi_91x_main.c | 48 ++---
 drivers/net/wireless/rsi/rsi_91x_sdio.c | 10 ++-
 drivers/net/wireless/rsi/rsi_91x_usb.c  | 10 ++-
 drivers/net/wireless/rsi/rsi_common.h   |  2 +-
 drivers/net/wireless/rsi/rsi_hal.h  | 11 
 5 files changed, 74 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_main.c 
b/drivers/net/wireless/rsi/rsi_91x_main.c
index b3e7d75..1485a0c 100644
--- a/drivers/net/wireless/rsi/rsi_91x_main.c
+++ b/drivers/net/wireless/rsi/rsi_91x_main.c
@@ -70,8 +70,24 @@ EXPORT_SYMBOL_GPL(rsi_dbg);
 static char *opmode_str(int oper_mode)
 {
switch (oper_mode) {
-   case RSI_DEV_OPMODE_WIFI_ALONE:
+   case DEV_OPMODE_WIFI_ALONE:
return "Wi-Fi alone";
+   case DEV_OPMODE_BT_ALONE:
+   return "BT EDR alone";
+   case DEV_OPMODE_BT_LE_ALONE:
+   return "BT LE alone";
+   case DEV_OPMODE_BT_DUAL:
+   return "BT Dual";
+   case DEV_OPMODE_STA_BT:
+   return "Wi-Fi STA + BT EDR";
+   case DEV_OPMODE_STA_BT_LE:
+   return "Wi-Fi STA + BT LE";
+   case DEV_OPMODE_STA_BT_DUAL:
+   return "Wi-Fi STA + BT DUAL";
+   case DEV_OPMODE_AP_BT:
+   return "Wi-Fi AP + BT EDR";
+   case DEV_OPMODE_AP_BT_DUAL:
+   return "Wi-Fi AP + BT DUAL";
}
 
return "Unknown";
@@ -278,7 +294,7 @@ void rsi_set_bt_context(void *priv, void *bt_context)
  *
  * Return: Pointer to the adapter structure on success, NULL on failure .
  */
-struct rsi_hw *rsi_91x_init(void)
+struct rsi_hw *rsi_91x_init(u16 oper_mode)
 {
struct rsi_hw *adapter = NULL;
struct rsi_common *common = NULL;
@@ -321,9 +337,33 @@ struct rsi_hw *rsi_91x_init(void)
timer_setup(>roc_timer, rsi_roc_timeout, 0);
init_completion(>wlan_init_completion);
common->init_done = true;
+   adapter->device_model = RSI_DEV_9113;
+   common->oper_mode = oper_mode;
+
+   /* Determine coex mode */
+   switch (common->oper_mode) {
+   case DEV_OPMODE_STA_BT_DUAL:
+   case DEV_OPMODE_STA_BT:
+   case DEV_OPMODE_STA_BT_LE:
+   case DEV_OPMODE_BT_ALONE:
+   case DEV_OPMODE_BT_LE_ALONE:
+   case DEV_OPMODE_BT_DUAL:
+   common->coex_mode = 2;
+   break;
+   case DEV_OPMODE_AP_BT_DUAL:
+   case DEV_OPMODE_AP_BT:
+   common->coex_mode = 4;
+   break;
+   case DEV_OPMODE_WIFI_ALONE:
+   common->coex_mode = 1;
+   break;
+   default:
+   common->oper_mode = 1;
+   common->coex_mode = 1;
+   }
+   rsi_dbg(INFO_ZONE, "%s: oper_mode = %d, coex_mode = %d\n",
+   __func__, common->oper_mode, common->coex_mode);
 
-   common->coex_mode = RSI_DEV_COEX_MODE_WIFI_ALONE;
-   common->oper_mode = RSI_DEV_OPMODE_WIFI_ALONE;
adapter->device_model = RSI_DEV_9113;
 #ifdef CONFIG_RSI_COEX
if (common->coex_mode > 1) {
diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c 
b/drivers/net/wireless/rsi/rsi_91x_sdio.c
index ba38c6d..5722736 100644
--- a/drivers/net/wireless/rsi/rsi_91x_sdio.c
+++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c
@@ -21,6 +21,14 @@
 #include "rsi_coex.h"
 #include "rsi_hal.h"
 
+/* Default operating mode is wlan STA + BT */
+static u16 dev_oper_mode = DEV_OPMODE_STA_BT_DUAL;
+module_param(dev_oper_mode, ushort, 0444);
+MODULE_PARM_DESC(dev_oper_mode,
+"1[Wi-Fi], 4[BT], 8[BT LE], 5[Wi-Fi STA + BT classic]\n"
+"9[Wi-Fi STA + BT LE], 13[Wi-Fi STA + BT classic + BT LE]\n"
+"6[AP + BT classic], 14[AP + BT classic + BT LE]");
+
 /**
  * rsi_sdio_set_cmd52_arg() - This function prepares cmd 52 read/write arg.
  * @rw: Read/write
@@ -926,7 +934,7 @@ static int rsi_probe(struct sdio_func *pfunction,
 
rsi_dbg(INIT_ZONE, "%s: Init function called\n", __func__);
 
-   adapter = rsi_91x_init();
+   adapter = rsi_91x_init(dev_oper_mode);
if (!adapter) {
rsi_dbg(ERR_ZONE, "%s: Failed to init os intf ops\n",
__func__);
diff --git a/drivers/net/wireless/rsi/rsi_91x_usb.c 
b/drivers/net/wireless/rsi/rsi_91x_usb.c
index b33a05f..0a50cff 100644
--- a/drivers/net/wireless/rsi/rsi_91x_usb.c
+++ b/drivers/net/wireless/rsi/rsi_91x_usb.c
@@ -21,6 +21,14 @@
 #include "rsi_hal.h"
 #include "rsi_coex.h"
 
+/* Default operating mode is wlan STA + BT */
+static u16 dev_oper_mode = DEV_OPMODE_STA_BT_DUAL;
+module_param(dev_oper_mode, ushort, 

[v8 0/8] rsi: add bluetooth and coex support

[Amitkumar Karwar]

From: Amitkumar Karwar 

This patch series adds new bluetooth driver and coex enhancments
in existing wlan driver for RSI chipsets.
As per our architecture, both wlan and bluetooth drivers talk
over same SDIO interface to device. Separate endpoint will be
used in case of USB interface.

Change in v8: 4/8, 5/8 are modified
Change in v7: 4/8 is modified
Changes in v6: 1/8, 3/8, 4/8, 5/8, 6/8 are modified
Changes in v5: 5/8 is modified
Changes in v4: 5/8 is modified
Changes in v3: 4/8, 5/8 and 6/8 patches are modified
Changes in v2: 2/8, 5/8 and 6/8 patches are modified

Prameela Rani Garnepudi (6):
  rsi: add rx control block to handle rx packets in USB
  rsi: add header file rsi_91x
  rsi: add coex support
  Bluetooth: btrsi: add new rsi bluetooth driver
  rsi: add module parameter operating mode
  rsi: sdio changes to support BT

Siva Rebbagondla (2):
  rsi: add bluetooth rx endpoint
  rsi: handle BT traffic in driver

 drivers/bluetooth/Kconfig   |  12 ++
 drivers/bluetooth/Makefile  |   2 +
 drivers/bluetooth/btrsi.c   | 188 
 drivers/net/wireless/rsi/Kconfig|   9 ++
 drivers/net/wireless/rsi/Makefile   |   1 +
 drivers/net/wireless/rsi/rsi_91x_coex.c | 179 ++
 drivers/net/wireless/rsi/rsi_91x_core.c |  20 ++-
 drivers/net/wireless/rsi/rsi_91x_hal.c  |  56 +++--
 drivers/net/wireless/rsi/rsi_91x_main.c | 129 ++-
 drivers/net/wireless/rsi/rsi_91x_mgmt.c |   2 +-
 drivers/net/wireless/rsi/rsi_91x_sdio.c |  13 +-
 drivers/net/wireless/rsi/rsi_91x_sdio_ops.c |   5 +-
 drivers/net/wireless/rsi/rsi_91x_usb.c  | 124 +-
 drivers/net/wireless/rsi/rsi_91x_usb_ops.c  |  35 --
 drivers/net/wireless/rsi/rsi_coex.h |  37 ++
 drivers/net/wireless/rsi/rsi_common.h   |   5 +-
 drivers/net/wireless/rsi/rsi_hal.h  |  21 
 drivers/net/wireless/rsi/rsi_main.h |  21 ++--
 drivers/net/wireless/rsi/rsi_mgmt.h |   3 +
 drivers/net/wireless/rsi/rsi_usb.h  |  16 ++-
 include/net/rsi_91x.h   |  56 +
 21 files changed, 852 insertions(+), 82 deletions(-)
 create mode 100644 drivers/bluetooth/btrsi.c
 create mode 100644 drivers/net/wireless/rsi/rsi_91x_coex.c
 create mode 100644 drivers/net/wireless/rsi/rsi_coex.h
 create mode 100644 include/net/rsi_91x.h

-- 
2.7.4

[v8 1/8] rsi: add rx control block to handle rx packets in USB

[Amitkumar Karwar]

From: Prameela Rani Garnepudi 

Rx bluetooth endpoint shall be added in further patches. Rx control
block is introduced here to handle Rx packets properly. Separate
function is written to initialize the RX control blocks.

Signed-off-by: Prameela Rani Garnepudi 
Signed-off-by: Siva Rebbagondla 
Signed-off-by: Amitkumar Karwar 
---
v8: Same as v6, v7
v6: Removed unnecessary GFP_DMA flag for kzalloc(Kalle)
v5: Same as earlier version
---
 drivers/net/wireless/rsi/rsi_91x_main.c |  4 +-
 drivers/net/wireless/rsi/rsi_91x_sdio_ops.c |  2 +-
 drivers/net/wireless/rsi/rsi_91x_usb.c  | 75 +++--
 drivers/net/wireless/rsi/rsi_91x_usb_ops.c  | 35 +-
 drivers/net/wireless/rsi/rsi_common.h   |  2 +-
 drivers/net/wireless/rsi/rsi_main.h |  2 +-
 drivers/net/wireless/rsi/rsi_usb.h  | 10 +++-
 7 files changed, 96 insertions(+), 34 deletions(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_main.c 
b/drivers/net/wireless/rsi/rsi_91x_main.c
index 0cb8e68..0413af8 100644
--- a/drivers/net/wireless/rsi/rsi_91x_main.c
+++ b/drivers/net/wireless/rsi/rsi_91x_main.c
@@ -137,7 +137,7 @@ static struct sk_buff *rsi_prepare_skb(struct rsi_common 
*common,
  *
  * Return: 0 on success, -1 on failure.
  */
-int rsi_read_pkt(struct rsi_common *common, s32 rcv_pkt_len)
+int rsi_read_pkt(struct rsi_common *common, u8 *rx_pkt, s32 rcv_pkt_len)
 {
u8 *frame_desc = NULL, extended_desc = 0;
u32 index, length = 0, queueno = 0;
@@ -146,7 +146,7 @@ int rsi_read_pkt(struct rsi_common *common, s32 rcv_pkt_len)
 
index = 0;
do {
-   frame_desc = >rx_data_pkt[index];
+   frame_desc = _pkt[index];
actual_length = *(u16 *)_desc[0];
offset = *(u16 *)_desc[2];
 
diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c 
b/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c
index 8e2a95c..9fbc0ef 100644
--- a/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c
+++ b/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c
@@ -118,7 +118,7 @@ static int rsi_process_pkt(struct rsi_common *common)
goto fail;
}
 
-   status = rsi_read_pkt(common, rcv_pkt_len);
+   status = rsi_read_pkt(common, common->rx_data_pkt, rcv_pkt_len);
 
 fail:
kfree(common->rx_data_pkt);
diff --git a/drivers/net/wireless/rsi/rsi_91x_usb.c 
b/drivers/net/wireless/rsi/rsi_91x_usb.c
index 8f84438..bbce809 100644
--- a/drivers/net/wireless/rsi/rsi_91x_usb.c
+++ b/drivers/net/wireless/rsi/rsi_91x_usb.c
@@ -247,12 +247,13 @@ static int rsi_usb_reg_write(struct usb_device *usbdev,
  */
 static void rsi_rx_done_handler(struct urb *urb)
 {
-   struct rsi_hw *adapter = urb->context;
-   struct rsi_91x_usbdev *dev = (struct rsi_91x_usbdev *)adapter->rsi_dev;
+   struct rx_usb_ctrl_block *rx_cb = urb->context;
+   struct rsi_91x_usbdev *dev = (struct rsi_91x_usbdev *)rx_cb->data;
 
if (urb->status)
return;
 
+   rx_cb->pend = 1;
rsi_set_event(>rx_thread.event);
 }
 
@@ -262,10 +263,11 @@ static void rsi_rx_done_handler(struct urb *urb)
  *
  * Return: 0 on success, a negative error code on failure.
  */
-static int rsi_rx_urb_submit(struct rsi_hw *adapter)
+static int rsi_rx_urb_submit(struct rsi_hw *adapter, u8 ep_num)
 {
struct rsi_91x_usbdev *dev = (struct rsi_91x_usbdev *)adapter->rsi_dev;
-   struct urb *urb = dev->rx_usb_urb[0];
+   struct rx_usb_ctrl_block *rx_cb = >rx_cb[ep_num - 1];
+   struct urb *urb = rx_cb->rx_urb;
int status;
 
usb_fill_bulk_urb(urb,
@@ -275,7 +277,7 @@ static int rsi_rx_urb_submit(struct rsi_hw *adapter)
  urb->transfer_buffer,
  3000,
  rsi_rx_done_handler,
- adapter);
+ rx_cb);
 
status = usb_submit_urb(urb, GFP_KERNEL);
if (status)
@@ -484,14 +486,54 @@ static struct rsi_host_intf_ops usb_host_intf_ops = {
  */
 static void rsi_deinit_usb_interface(struct rsi_hw *adapter)
 {
+   u8 idx;
+
struct rsi_91x_usbdev *dev = (struct rsi_91x_usbdev *)adapter->rsi_dev;
 
rsi_kill_thread(>rx_thread);
-   usb_free_urb(dev->rx_usb_urb[0]);
+
+   for (idx = 0; idx < MAX_RX_URBS; idx++) {
+   usb_free_urb(dev->rx_cb[idx].rx_urb);
+   kfree(dev->rx_cb[idx].rx_buffer);
+   }
+
kfree(adapter->priv->rx_data_pkt);
kfree(dev->tx_buffer);
 }
 
+static int rsi_usb_init_rx(struct rsi_hw *adapter)
+{
+   struct rsi_91x_usbdev *dev = (struct rsi_91x_usbdev *)adapter->rsi_dev;
+   struct rx_usb_ctrl_block *rx_cb;
+   u8 idx;
+
+   for (idx = 0; idx < MAX_RX_URBS; idx++) {
+   rx_cb = >rx_cb[idx];
+
+   rx_cb->rx_buffer = kzalloc(RSI_USB_BUF_SIZE * 2,
+   

[v8 8/8] rsi: sdio changes to support BT

[Amitkumar Karwar]

From: Prameela Rani Garnepudi 

Queue number is correctly updated for BT traffic. Also, kzalloc
instead of kmalloc is used for Rx packet allocation.

Signed-off-by: Prameela Rani Garnepudi 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/rsi/rsi_91x_sdio.c | 2 ++
 drivers/net/wireless/rsi/rsi_91x_sdio_ops.c | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c 
b/drivers/net/wireless/rsi/rsi_91x_sdio.c
index 5722736..beb18d0 100644
--- a/drivers/net/wireless/rsi/rsi_91x_sdio.c
+++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c
@@ -763,6 +763,8 @@ static int rsi_sdio_host_intf_write_pkt(struct rsi_hw 
*adapter,
int status;
 
queueno = ((pkt[1] >> 4) & 0xf);
+   if (queueno == RSI_BT_MGMT_Q || queueno == RSI_BT_DATA_Q)
+   queueno = RSI_BT_Q;
 
num_blocks = len / block_size;
 
diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c 
b/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c
index 169c981..6e74261 100644
--- a/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c
+++ b/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c
@@ -103,7 +103,7 @@ static int rsi_process_pkt(struct rsi_common *common)
 
rcv_pkt_len = (num_blks * 256);
 
-   common->rx_data_pkt = kmalloc(rcv_pkt_len, GFP_KERNEL);
+   common->rx_data_pkt = kzalloc(rcv_pkt_len, GFP_KERNEL);
if (!common->rx_data_pkt) {
rsi_dbg(ERR_ZONE, "%s: Failed in memory allocation\n",
__func__);
-- 
2.7.4

[v8 6/8] rsi: handle BT traffic in driver

[Amitkumar Karwar]

From: Siva Rebbagondla 

BT frames are passed through coex and hal modules to BUS.
After firmware is loaded, based on the operating mode CARD
READY frame comes for each protocol. When BT card ready is
received, BT attach is called.
Protocol operations are exchanged between the modules
at initialization time.
Build flag CONFIG_RSI_COEX is introduced to enable coex support
if CONFIG_BT_RSIHCI is enabled. Coex operations are valid if
coex mode is greater than 1 only.

Signed-off-by: Siva Rebbagondla 
Signed-off-by: Prameela Rani Garnepudi 
Signed-off-by: Amitkumar Karwar 
---
v8: Same as v6, v7
v6: Removed CONFIG_BT_HCIRSI flag dependency on RSI_91x. Introduced
CONFIG_RSI_COEX for coex code. (Kalle)
v5: Same as v3, v4
v3: bt_ops need not be present structure g_proto_ops. It is removed.
v2: WLAN module depends on BT module. Updated in Kconfig
---
 drivers/net/wireless/rsi/rsi_91x_coex.c |  4 +-
 drivers/net/wireless/rsi/rsi_91x_core.c | 20 +++---
 drivers/net/wireless/rsi/rsi_91x_hal.c  | 39 
 drivers/net/wireless/rsi/rsi_91x_main.c | 57 +++--
 drivers/net/wireless/rsi/rsi_91x_sdio_ops.c |  1 +
 drivers/net/wireless/rsi/rsi_common.h   |  1 +
 drivers/net/wireless/rsi/rsi_hal.h  | 10 +
 drivers/net/wireless/rsi/rsi_main.h |  3 ++
 8 files changed, 126 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_coex.c 
b/drivers/net/wireless/rsi/rsi_91x_coex.c
index c07e839..d055099 100644
--- a/drivers/net/wireless/rsi/rsi_91x_coex.c
+++ b/drivers/net/wireless/rsi/rsi_91x_coex.c
@@ -43,8 +43,10 @@ static void rsi_coex_sched_tx_pkts(struct 
rsi_coex_ctrl_block *coex_cb)
coex_q = rsi_coex_determine_coex_q(coex_cb);
rsi_dbg(INFO_ZONE, "queue = %d\n", coex_q);
 
-   if (coex_q == RSI_COEX_Q_BT)
+   if (coex_q == RSI_COEX_Q_BT) {
skb = skb_dequeue(_cb->coex_tx_qs[RSI_COEX_Q_BT]);
+   rsi_send_bt_pkt(coex_cb->priv, skb);
+   }
} while (coex_q != RSI_COEX_Q_INVALID);
 }
 
diff --git a/drivers/net/wireless/rsi/rsi_91x_core.c 
b/drivers/net/wireless/rsi/rsi_91x_core.c
index d0d2201..5dafd2e 100644
--- a/drivers/net/wireless/rsi/rsi_91x_core.c
+++ b/drivers/net/wireless/rsi/rsi_91x_core.c
@@ -17,6 +17,7 @@
 #include "rsi_mgmt.h"
 #include "rsi_common.h"
 #include "rsi_hal.h"
+#include "rsi_coex.h"
 
 /**
  * rsi_determine_min_weight_queue() - This function determines the queue with
@@ -301,14 +302,23 @@ void rsi_core_qos_processor(struct rsi_common *common)
mutex_unlock(>tx_lock);
break;
}
-
-   if (q_num == MGMT_SOFT_Q) {
-   status = rsi_send_mgmt_pkt(common, skb);
-   } else if (q_num == MGMT_BEACON_Q) {
+   if (q_num == MGMT_BEACON_Q) {
status = rsi_send_pkt_to_bus(common, skb);
dev_kfree_skb(skb);
} else {
-   status = rsi_send_data_pkt(common, skb);
+#ifdef CONFIG_RSI_COEX
+   if (common->coex_mode > 1) {
+   status = rsi_coex_send_pkt(common, skb,
+  RSI_WLAN_Q);
+   } else {
+#endif
+   if (q_num == MGMT_SOFT_Q)
+   status = rsi_send_mgmt_pkt(common, skb);
+   else
+   status = rsi_send_data_pkt(common, skb);
+#ifdef CONFIG_RSI_COEX
+   }
+#endif
}
 
if (status) {
diff --git a/drivers/net/wireless/rsi/rsi_91x_hal.c 
b/drivers/net/wireless/rsi/rsi_91x_hal.c
index 151d228..de608ae 100644
--- a/drivers/net/wireless/rsi/rsi_91x_hal.c
+++ b/drivers/net/wireless/rsi/rsi_91x_hal.c
@@ -15,6 +15,7 @@
  */
 
 #include 
+#include 
 #include "rsi_mgmt.h"
 #include "rsi_hal.h"
 #include "rsi_sdio.h"
@@ -24,6 +25,7 @@
 static struct ta_metadata metadata_flash_content[] = {
{"flash_content", 0x0001},
{"rsi/rs9113_wlan_qspi.rps", 0x0001},
+   {"rsi/rs9113_wlan_bt_dual_mode.rps", 0x0001},
 };
 
 int rsi_send_pkt_to_bus(struct rsi_common *common, struct sk_buff *skb)
@@ -357,6 +359,43 @@ int rsi_send_mgmt_pkt(struct rsi_common *common,
return status;
 }
 
+int rsi_send_bt_pkt(struct rsi_common *common, struct sk_buff *skb)
+{
+   int status = -EINVAL;
+   u8 header_size = 0;
+   struct rsi_bt_desc *bt_desc;
+   u8 queueno = ((skb->data[1] >> 4) & 0xf);
+
+   if (queueno == RSI_BT_MGMT_Q) {
+   status = rsi_send_pkt_to_bus(common, skb);
+   if (status)
+   rsi_dbg(ERR_ZONE, 

[v8 3/8] rsi: add header file rsi_91x

[Amitkumar Karwar]

From: Prameela Rani Garnepudi 

The common parameters used by wlan and bt modules are add
to a new header file "rsi_91x.h" defined in 'include/net'

Signed-off-by: Prameela Rani Garnepudi 
Signed-off-by: Siva Rebbagondla 
Signed-off-by: Amitkumar Karwar 
---
v8: Same as v6, v7
v6: Renamed rsi_header.h to rsi_91x.h and moved to include/net
from include/linux(Kalle)
v5: Same as earlier versions
---
 drivers/net/wireless/rsi/rsi_main.h | 12 ++--
 include/net/rsi_91x.h   | 34 ++
 2 files changed, 36 insertions(+), 10 deletions(-)
 create mode 100644 include/net/rsi_91x.h

diff --git a/drivers/net/wireless/rsi/rsi_main.h 
b/drivers/net/wireless/rsi/rsi_main.h
index ee469dc..b0f4e2c 100644
--- a/drivers/net/wireless/rsi/rsi_main.h
+++ b/drivers/net/wireless/rsi/rsi_main.h
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct rsi_sta {
struct ieee80211_sta *sta;
@@ -85,10 +86,6 @@ extern __printf(2, 3) void rsi_dbg(u32 zone, const char 
*fmt, ...);
 #define MGMT_HW_Q  10
 #define BEACON_HW_Q11
 
-/* Queue information */
-#define RSI_COEX_Q 0x0
-#define RSI_WIFI_MGMT_Q 0x4
-#define RSI_WIFI_DATA_Q 0x5
 #define IEEE80211_MGMT_FRAME0x00
 #define IEEE80211_CTL_FRAME 0x04
 
@@ -293,11 +290,6 @@ struct rsi_common {
struct ieee80211_vif *roc_vif;
 };
 
-enum host_intf {
-   RSI_HOST_INTF_SDIO = 0,
-   RSI_HOST_INTF_USB
-};
-
 struct eepromrw_info {
u32 offset;
u32 length;
@@ -322,7 +314,7 @@ struct rsi_hw {
struct device *device;
u8 sc_nvifs;
 
-   enum host_intf rsi_host_intf;
+   enum rsi_host_intf rsi_host_intf;
u16 block_size;
enum ps_state ps_state;
struct rsi_ps_info ps_info;
diff --git a/include/net/rsi_91x.h b/include/net/rsi_91x.h
new file mode 100644
index 000..16a447b
--- /dev/null
+++ b/include/net/rsi_91x.h
@@ -0,0 +1,34 @@
+/**
+ * Copyright (c) 2017 Redpine Signals 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
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#ifndef __RSI_HEADER_H__
+#define __RSI_HEADER_H__
+
+/* HAL queue information */
+#define RSI_COEX_Q 0x0
+#define RSI_BT_Q   0x2
+#define RSI_WLAN_Q  0x3
+#define RSI_WIFI_MGMT_Q 0x4
+#define RSI_WIFI_DATA_Q 0x5
+#define RSI_BT_MGMT_Q  0x6
+#define RSI_BT_DATA_Q  0x7
+
+enum rsi_host_intf {
+   RSI_HOST_INTF_SDIO = 0,
+   RSI_HOST_INTF_USB
+};
+
+#endif
-- 
2.7.4

Re: [PATCH 4/4] mac80211: support station 4-addr mode fast-rx

[Felix Fietkau]

On 2018-02-23 12:24, Johannes Berg wrote:
> On Fri, 2018-02-23 at 10:06 +0100, Felix Fietkau wrote:
>> Signed-off-by: Felix Fietkau 
>> ---
>>  net/mac80211/cfg.c |  2 --
>>  net/mac80211/rx.c  | 11 +++
>>  2 files changed, 7 insertions(+), 6 deletions(-)
>> 
>> diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
>> index 6f9d5beec73e..72b5a2ec4e94 100644
>> --- a/net/mac80211/cfg.c
>> +++ b/net/mac80211/cfg.c
>> @@ -160,7 +160,6 @@ static int ieee80211_change_iface(struct wiphy *wiphy,
>>  if (type == NL80211_IFTYPE_AP_VLAN &&
>>  params && params->use_4addr == 0) {
>>  RCU_INIT_POINTER(sdata->u.vlan.sta, NULL);
>> -ieee80211_check_fast_rx_iface(sdata);
>>  } else if (type == NL80211_IFTYPE_STATION &&
>> params && params->use_4addr >= 0) {
>>  sdata->u.mgd.use_4addr = params->use_4addr;
>> @@ -1575,7 +1574,6 @@ static int ieee80211_change_station(struct wiphy 
>> *wiphy,
>>  }
>>  
>>  rcu_assign_pointer(vlansdata->u.vlan.sta, sta);
>> -__ieee80211_check_fast_rx_iface(vlansdata);
>>  }
>>  
>>  if (sta->sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
> 
> I'm not convinced this is right - don't you have to recheck to modify
> the station data? Otherwise you'd just drop all the frames to the
> slowpath again due to the first patch in the series, no?You're right and I 
> forgot to take those out before sending. Will
resubmit this one.

Thanks,

- Felix

[PATCH v2] mac80211: support station 4-addr mode fast-rx

[Felix Fietkau]

Signed-off-by: Felix Fietkau 
---
 net/mac80211/rx.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 6e2506a84586..6944705c5258 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -3747,10 +3747,6 @@ void ieee80211_check_fast_rx(struct sta_info *sta)
 
switch (sdata->vif.type) {
case NL80211_IFTYPE_STATION:
-   /* 4-addr is harder to deal with, later maybe */
-   if (sdata->u.mgd.use_4addr)
-   goto clear;
-
if (sta->sta.tdls) {
fastrx.da_offs = offsetof(struct ieee80211_hdr, addr1);
fastrx.sa_offs = offsetof(struct ieee80211_hdr, addr2);
@@ -3763,6 +3759,13 @@ void ieee80211_check_fast_rx(struct sta_info *sta)
cpu_to_le16(IEEE80211_FCTL_FROMDS);
}
 
+   if (sdata->u.mgd.use_4addr && !sta->sta.tdls) {
+   fastrx.expected_ds_bits |=
+   cpu_to_le16(IEEE80211_FCTL_TODS);
+   fastrx.da_offs = offsetof(struct ieee80211_hdr, addr3);
+   fastrx.sa_offs = offsetof(struct ieee80211_hdr, addr4);
+   }
+
if (!sdata->u.mgd.powersave)
break;
 
-- 
2.14.2

[PATCH] brcm80211: remove duplicated bit-wise or of IEEE80211_CHAN_NO_IR

[Colin King]

From: Colin Ian King 

Bit pattern IEEE80211_CHAN_NO_IR is being bit-wise or'd twice;
remove the redundant 2nd IEEE80211_CHAN_NO_IR

Signed-off-by: Colin Ian King 
---
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/channel.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/channel.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/channel.c
index 3a03287fa912..db783e94f929 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/channel.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/channel.c
@@ -652,7 +652,6 @@ static void brcms_reg_apply_radar_flags(struct wiphy *wiphy)
 */
if (!(ch->flags & IEEE80211_CHAN_DISABLED))
ch->flags |= IEEE80211_CHAN_RADAR |
-IEEE80211_CHAN_NO_IR |
 IEEE80211_CHAN_NO_IR;
}
 }
-- 
2.15.1

Re: [PATCH] rtlwifi: rtl8723be: Fix loss of signal

[Larry Finger]

On 02/23/2018 03:18 AM, Kalle Valo wrote:

Larry Finger  writes:


In commit c713fb071edc ("rtlwifi: rtl8821ae: Fix connection lost problem
correctly") a problem in rtl8821ae that caused loss of signal was fixed.
That same problem has now been reported for rtl8723be. Accordingly,
the ASPM L1 latency has been increased from 0 to 7 to fix the instability.

Signed-off-by: Larry Finger 
Cc: Stable 
---
Kalle,

This patch should be sent to 4.16.


Ok, I'll queue this for 4.16.


Thanks,

Larry