date:20170218

Re: [PATCH] Fix rtl8187 multicast reception

2017-02-18 Thread Kalle Valo

Larry Finger  writes:

> On 02/18/2017 07:35 PM, Nils Holland wrote:
>> The rtl8187 doesn't seem to receive multicast data, which, among other
>> thinks, make it fail to receive RAs in IPv6 networks.
>>
>> The cause seems to be that the RTL818X_RX_CONF_MULTICAST flag doesn't
>> have any effect at all. Fix this issue by setting
>> RTL818X_RX_CONF_MONITOR instead, which puts the card into monitor mode,
>> and fixes the problem.
>>
>> Signed-off-by: Nils Holland 
>> ---
>> The problem and solution have been tested on an rtl8187b (0bda:8197), but
>> the fix changes behavior on other cards supported by the driver as well
>> (like non-b 8187's). Due to lack of hardware, I unfortunately cannot say
>> if the issue exists on these cards in the first place, or if the fix has
>> any unwanted consequences there.

BTW, this is good info to have in the actual commit log. No need put it
under "---" line.

>> If people consider it a bad idea to just always put the card into monitor
>> mode (for example, for performance reasons), I could imagine rewriting this
>> patch so that a module parameter controls this behavior instead.
>
> I would hate to make such a change in the behavior of the driver, and
> have it be applied without the user having any say. The fact that
> setting RTL818X_RX_CONF_MULTICAST does not have the desired effect may
> be due to a firmware error; however, there is no chance of making a
> change there as these devices have embedded/fixed fw.

Or it could be also a problem how we configure the firmware.

> I would prefer a module parameter that would allow this change to be
> implemented only if the user takes special action. I suspect that you
> will have no difficulty preparing such a change. If that is not true,
> I would be happy to help.

I understand why you prefer having a module parameter but the thing is
that being able to receive multicast frames is really basic
functionality. We should not hide it under a module parameter.

Isn't there any other option, for example does anyone have hw to test
this with other hw? (what exactly?) Or maybe we just take the risk and
take it as is and revert if problems arise?

-- 
Kalle Valo

Re: [PATCH] Fix rtl8187 multicast reception

2017-02-18 Thread Larry Finger


On 02/18/2017 07:35 PM, Nils Holland wrote:

The rtl8187 doesn't seem to receive multicast data, which, among other
thinks, make it fail to receive RAs in IPv6 networks.

The cause seems to be that the RTL818X_RX_CONF_MULTICAST flag doesn't
have any effect at all. Fix this issue by setting
RTL818X_RX_CONF_MONITOR instead, which puts the card into monitor mode,
and fixes the problem.

Signed-off-by: Nils Holland 
---
The problem and solution have been tested on an rtl8187b (0bda:8197), but
the fix changes behavior on other cards supported by the driver as well
(like non-b 8187's). Due to lack of hardware, I unfortunately cannot say
if the issue exists on these cards in the first place, or if the fix has
any unwanted consequences there.

If people consider it a bad idea to just always put the card into monitor
mode (for example, for performance reasons), I could imagine rewriting this
patch so that a module parameter controls this behavior instead.


I would hate to make such a change in the behavior of the driver, and have it be 
applied without the user having any say. The fact that setting 
RTL818X_RX_CONF_MULTICAST does not have the desired effect may be due to a 
firmware error; however, there is no chance of making a change there as these 
devices have embedded/fixed fw.


I would prefer a module parameter that would allow this change to be implemented 
only if the user takes special action. I suspect that you will have no 
difficulty preparing such a change. If that is not true, I would be happy to help.


Larry



 drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c 
b/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
index 231f84db9ab0..56a8686cd367 100644
--- a/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
+++ b/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
@@ -946,8 +946,7 @@ static int rtl8187_start(struct ieee80211_hw *dev)
  (7 << 13 /* RX FIFO threshold NONE */) |
  (7 << 10 /* MAX RX DMA */) |
  RTL818X_RX_CONF_RX_AUTORESETPHY |
- RTL818X_RX_CONF_ONLYERLPKT |
- RTL818X_RX_CONF_MULTICAST;
+ RTL818X_RX_CONF_ONLYERLPKT;
priv->rx_conf = reg;
rtl818x_iowrite32(priv, >map->RX_CONF, reg);

@@ -1319,12 +1318,11 @@ static void rtl8187_configure_filter(struct 
ieee80211_hw *dev,
priv->rx_conf ^= RTL818X_RX_CONF_FCS;
if (changed_flags & FIF_CONTROL)
priv->rx_conf ^= RTL818X_RX_CONF_CTRL;
-   if (changed_flags & FIF_OTHER_BSS)
-   priv->rx_conf ^= RTL818X_RX_CONF_MONITOR;
-   if (*total_flags & FIF_ALLMULTI || multicast > 0)
-   priv->rx_conf |= RTL818X_RX_CONF_MULTICAST;
+   if (*total_flags & FIF_OTHER_BSS ||
+   *total_flags & FIF_ALLMULTI || multicast > 0)
+   priv->rx_conf |= RTL818X_RX_CONF_MONITOR;
else
-   priv->rx_conf &= ~RTL818X_RX_CONF_MULTICAST;
+   priv->rx_conf &= ~RTL818X_RX_CONF_MONITOR;

*total_flags = 0;

@@ -1332,10 +1330,10 @@ static void rtl8187_configure_filter(struct 
ieee80211_hw *dev,
*total_flags |= FIF_FCSFAIL;
if (priv->rx_conf & RTL818X_RX_CONF_CTRL)
*total_flags |= FIF_CONTROL;
-   if (priv->rx_conf & RTL818X_RX_CONF_MONITOR)
+   if (priv->rx_conf & RTL818X_RX_CONF_MONITOR) {
*total_flags |= FIF_OTHER_BSS;
-   if (priv->rx_conf & RTL818X_RX_CONF_MULTICAST)
*total_flags |= FIF_ALLMULTI;
+   }

rtl818x_iowrite32_async(priv, >map->RX_CONF, priv->rx_conf);
 }




--
If I was stranded on an island and the only way to get off
the island was to make a pretty UI, I’d die there.

Linus Torvalds

[PATCH] Fix rtl8187 multicast reception

2017-02-18 Thread Nils Holland

The rtl8187 doesn't seem to receive multicast data, which, among other
thinks, make it fail to receive RAs in IPv6 networks.

The cause seems to be that the RTL818X_RX_CONF_MULTICAST flag doesn't
have any effect at all. Fix this issue by setting
RTL818X_RX_CONF_MONITOR instead, which puts the card into monitor mode,
and fixes the problem.

Signed-off-by: Nils Holland 
---
The problem and solution have been tested on an rtl8187b (0bda:8197), but
the fix changes behavior on other cards supported by the driver as well
(like non-b 8187's). Due to lack of hardware, I unfortunately cannot say
if the issue exists on these cards in the first place, or if the fix has
any unwanted consequences there.

If people consider it a bad idea to just always put the card into monitor
mode (for example, for performance reasons), I could imagine rewriting this
patch so that a module parameter controls this behavior instead.

 drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c 
b/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
index 231f84db9ab0..56a8686cd367 100644
--- a/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
+++ b/drivers/net/wireless/realtek/rtl818x/rtl8187/dev.c
@@ -946,8 +946,7 @@ static int rtl8187_start(struct ieee80211_hw *dev)
  (7 << 13 /* RX FIFO threshold NONE */) |
  (7 << 10 /* MAX RX DMA */) |
  RTL818X_RX_CONF_RX_AUTORESETPHY |
- RTL818X_RX_CONF_ONLYERLPKT |
- RTL818X_RX_CONF_MULTICAST;
+ RTL818X_RX_CONF_ONLYERLPKT;
priv->rx_conf = reg;
rtl818x_iowrite32(priv, >map->RX_CONF, reg);
 
@@ -1319,12 +1318,11 @@ static void rtl8187_configure_filter(struct 
ieee80211_hw *dev,
priv->rx_conf ^= RTL818X_RX_CONF_FCS;
if (changed_flags & FIF_CONTROL)
priv->rx_conf ^= RTL818X_RX_CONF_CTRL;
-   if (changed_flags & FIF_OTHER_BSS)
-   priv->rx_conf ^= RTL818X_RX_CONF_MONITOR;
-   if (*total_flags & FIF_ALLMULTI || multicast > 0)
-   priv->rx_conf |= RTL818X_RX_CONF_MULTICAST;
+   if (*total_flags & FIF_OTHER_BSS ||
+   *total_flags & FIF_ALLMULTI || multicast > 0)
+   priv->rx_conf |= RTL818X_RX_CONF_MONITOR;
else
-   priv->rx_conf &= ~RTL818X_RX_CONF_MULTICAST;
+   priv->rx_conf &= ~RTL818X_RX_CONF_MONITOR;
 
*total_flags = 0;
 
@@ -1332,10 +1330,10 @@ static void rtl8187_configure_filter(struct 
ieee80211_hw *dev,
*total_flags |= FIF_FCSFAIL;
if (priv->rx_conf & RTL818X_RX_CONF_CTRL)
*total_flags |= FIF_CONTROL;
-   if (priv->rx_conf & RTL818X_RX_CONF_MONITOR)
+   if (priv->rx_conf & RTL818X_RX_CONF_MONITOR) {
*total_flags |= FIF_OTHER_BSS;
-   if (priv->rx_conf & RTL818X_RX_CONF_MULTICAST)
*total_flags |= FIF_ALLMULTI;
+   }
 
rtl818x_iowrite32_async(priv, >map->RX_CONF, priv->rx_conf);
 }
-- 
2.11.1

Re: [PATCH] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules

2017-02-18 Thread Ryan Mounce

Hi Sebastian,

There is no explicit channel width restriction in the document,
however the only band in which the current regdb rules permit 160MHz
operation (5490-5710MHz) would result in an overlap with the
restricted weather radar band 5600-5650MHz.

While remaining in compliance with both 802.11 and Australian law,
contiguous 160MHz operation in 5GHz is only permitted between
5170-5330MHz which spans two bands with slightly different
requirements, hence AUTO-BW.

Regards,
Ryan Mounce

r...@mounce.com.au

On 19 February 2017 at 07:15, Sebastian Gottschall
 wrote:
> maybe i'm blind. but you reduced the channel width from 160 to 80 mhz. but i
> can't find any restriction in the document in a quick review
>
> Sebastian
>
>
> Am 18.02.2017 um 07:35 schrieb Ryan Mounce:
>>
>> Sourced from the latest legislation at
>> https://www.legislation.gov.au/Details/F2016C0043
>>
>> The current rules exceed legal limits between 5250-5330MHz, and permit
>> illegal operation in 5600-5650MHz (reserved for weather radar).
>>
>> Signed-off-by: Ryan Mounce 
>> ---
>>   db.txt | 15 ++-
>>   1 file changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/db.txt b/db.txt
>> index 05108e0..b951e0c 100644
>> --- a/db.txt
>> +++ b/db.txt
>> @@ -85,12 +85,17 @@ country AT: DFS-ETSI
>> # 60 GHz band channels 1-4, ref: Etsi En 302 567
>> (57000 - 66000 @ 2160), (40)
>>   +# Source:
>> +# https://www.legislation.gov.au/Details/F2016C00432
>> +# Both DFS-ETSI and DFS-FCC are acceptable per AS/NZS 4268 Appendix B
>>   country AU: DFS-ETSI
>> -   (2402 - 2482 @ 40), (20)
>> -   (5170 - 5250 @ 80), (17), AUTO-BW
>> -   (5250 - 5330 @ 80), (24), DFS, AUTO-BW
>> -   (5490 - 5710 @ 160), (24), DFS
>> -   (5735 - 5835 @ 80), (30)
>> +   (2402 - 2482 @ 40), (36)
>> +   (5170 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
>> +   (5250 - 5330 @ 80), (23), NO-OUTDOOR, AUTO-BW, DFS
>> +   (5490 - 5590 @ 80), (30), DFS
>> +   (5650 - 5730 @ 80), (30), DFS
>> +   (5735 - 5835 @ 80), (36)
>> +   (57000 - 66000 @ 2160), (43), NO-OUTDOOR
>> country AW: DFS-ETSI
>> (2402 - 2482 @ 40), (20)
>
>
>
> --
> Mit freundlichen Grüssen / Regards
>
> Sebastian Gottschall / CTO
>
> NewMedia-NET GmbH - DD-WRT
> Firmensitz:  Berliner Ring 101, 64625 Bensheim
> Registergericht: Amtsgericht Darmstadt, HRB 25473
> Geschäftsführer: Peter Steinhäuser, Christian Scheele
> http://www.dd-wrt.com
> email: s.gottsch...@dd-wrt.com
> Tel.: +496251-582650 / Fax: +496251-5826565
>

Re: [RFC v3 0/8] ath10k sdio support

2017-02-18 Thread Valo, Kalle

Erik Stromdahl  writes:

> I was actually about to email you about this.
>
> I have made a few more updates to the sdio code so I think it would be
> best if I could submit a new series of patches based on this code (v4).
>
> Then you can tweak it (v5).
>
> It is only minor updates to the HIF layer (added QCA9377 support) and
> a setup of some pll registers.

Ok, that sounds good. I'll wait for v4.

> btw, should I still mark them as RFC or should it be PATCH this time?
>
> If I go for PATCH, should the version be v4 or should I start from v1?

v4 would be fine. Thanks.

-- 
Kalle Valo

Re: [RFC v3 0/8] ath10k sdio support

2017-02-18 Thread Erik Stromdahl


Hej Kalle,

I was actually about to email you about this.

I have made a few more updates to the sdio code so I think it would be
best if I could submit a new series of patches based on this code (v4).

Then you can tweak it (v5).

It is only minor updates to the HIF layer (added QCA9377 support) and
a setup of some pll registers.

I will get back to you shortly.

btw, should I still mark them as RFC or should it be PATCH this time?

If I go for PATCH, should the version be v4 or should I start from v1?

/Erik

On 2017-02-18 14:40, Valo, Kalle wrote:

Hej,

Erik Stromdahl  writes:


This is the third version of the sdio RFC patch series.
The actual sdio code (patch 6) has been subject to a massive overhaul,
mainly as a result of Kalle's review comments.
It no longer has any strong resemblance of the original ath6kl code from
which it was originally based upon.

Previous pathes 6 to 10 have been merged into one single patch.

The previous series had a rework of the "HTC fake service" connect
(ep 0 connect) that introduced a race between the actual endpoint
connect and the HTC ready message. This issue has been addressed,
and the current patches (3 and 4) has been rewritten accordingly.

* overview of patches *

Patches 1 to 4 are more or less identical to the previous RFC, with an
exception for patch 3 that changes the "HTC fake service" connect
(mentioned above).

Patch 5 is a squashed version of previous patches 6 to 10.

Patch 6 is the actual sdio patch

Patches 7 to 8 are new and adds special sdio versions of BMI get
target info and HTC ready.

The new version was built and tested against:
tag: ath-201701121109

Erik Stromdahl (8):
  ath10k: htc: made static function public
  ath10k: htc: rx trailer lookahead support
  ath10k: htc: move htc ctrl ep connect to htc_init
  ath10k: htc: refactorization
  ath10k: various sdio related definitions
  ath10k: sdio support
  ath10k: sdio get target info
  ath10k: htc: ready_ext msg support


Sorry for not getting back to you earlier, haven't found time to look
this in detail during the last few weeks.

This is looking quite good now. I have some nitpicks (build warnings,
maybe reorder some patches etc) still but I think it's faster if I fix
those and send v4 as a proper patch (no RFC anymore), naturally
attributing you as the author. Is that ok for you?

Re: [PATCH] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules

2017-02-18 Thread Sebastian Gottschall

maybe i'm blind. but you reduced the channel width from 160 to 80 mhz. 
but i can't find any restriction in the document in a quick review


Sebastian

Am 18.02.2017 um 07:35 schrieb Ryan Mounce:

Sourced from the latest legislation at
https://www.legislation.gov.au/Details/F2016C0043

The current rules exceed legal limits between 5250-5330MHz, and permit
illegal operation in 5600-5650MHz (reserved for weather radar).

Signed-off-by: Ryan Mounce 
---
  db.txt | 15 ++-
  1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/db.txt b/db.txt
index 05108e0..b951e0c 100644
--- a/db.txt
+++ b/db.txt
@@ -85,12 +85,17 @@ country AT: DFS-ETSI
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
  
+# Source:

+# https://www.legislation.gov.au/Details/F2016C00432
+# Both DFS-ETSI and DFS-FCC are acceptable per AS/NZS 4268 Appendix B
  country AU: DFS-ETSI
-   (2402 - 2482 @ 40), (20)
-   (5170 - 5250 @ 80), (17), AUTO-BW
-   (5250 - 5330 @ 80), (24), DFS, AUTO-BW
-   (5490 - 5710 @ 160), (24), DFS
-   (5735 - 5835 @ 80), (30)
+   (2402 - 2482 @ 40), (36)
+   (5170 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
+   (5250 - 5330 @ 80), (23), NO-OUTDOOR, AUTO-BW, DFS
+   (5490 - 5590 @ 80), (30), DFS
+   (5650 - 5730 @ 80), (30), DFS
+   (5735 - 5835 @ 80), (36)
+   (57000 - 66000 @ 2160), (43), NO-OUTDOOR
  
  country AW: DFS-ETSI

(2402 - 2482 @ 40), (20)



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

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

Re: brcmfmac: BCM4343A0 P2P mode problem

2017-02-18 Thread Arend Van Spriel



On 17-2-2017 22:33, Stefan Holzmann wrote:
> Hello,
> 
> I have problems to get WiFi P2P on a Nanopi NEO Air board up and running. The 
> board uses a AP6212 WiFi module with the BCM4343A0 SDIO chipset (ID: 0xa9a6).

Hi Stefan

FYI, SDIO ID: A9A6 is BCM43430.

> Connecting to an AP as normal WiFi client is working without problems.
> 
> I can also discover other WiFi P2P nodes using wpa_cli p2p_peers, but when I 
> try to connect using wpa_cli p2p_connect the connection attempt fails with 
> the following log.
> 
> Are there any known problems with this kernel/wpa_supplicant combination for 
> this chipset? Why the interface type can't be changed to P2P_CLIENT? I also 
> tried to use the "p2pon" driver option but when I try to start wpa_supplicant 
> on the P2P interface I get an kernel crash.

You may need to start wpa_supplicant with '-puse_p2p_group_interface=1'.

The use of p2pon parameter is not recommended on recent kernel and 2.x
wpa_supplicant. It requires specific wpa_supplicant command line.

Regards,
Arend

> Kernel Log:
> 
> [  222.972232] brcmfmac: brcmf_cfg80211_escan_handler: scan not ready, 
> bsscfgidx=1
> [  222.979577] brcmfmac: brcmf_fweh_event_worker: event handler failed (69) 
> 
> [  237.677557] brcmfmac: brcmf_cfg80211_change_iface Enter, bsscfgidx=0, 
> type=8
> [  237.677569] brcmfmac: brcmf_cfg80211_change_iface Exit
> [  237.677641] brcmfmac: brcmf_netdev_open Enter, bsscfgidx=0
> [  237.677648] brcmfmac: brcmf_sdio_bus_txctl Enter
> [  237.677664] brcmfmac: brcmf_sdio_dpc Enter
> [  237.677674] brcmfmac: brcmf_sdio_tx_ctrlframe Enter
> [  237.677716] brcmfmac: brcmf_sdio_bus_rxctl Enter
> [  237.678232] brcmfmac: brcmf_sdio_isr Enter
> [  237.678244] brcmfmac: brcmf_sdio_dpc Enter
> [  237.678288] brcmfmac: brcmf_sdio_readframes Enter
> [  237.678315] brcmfmac: brcmf_sdio_read_control Enter
> [  237.678359] brcmfmac: brcmf_sdio_bus_rxctl resumed on rxctl frame, got 27 
> expected 27
> [  237.678365] brcmfmac: brcmf_fil_cmd_data Failed: BCME_UNSUPPORTED (-23)
> [  237.678370] brcmfmac: brcmf_fil_iovar_data_get ifidx=0, name=toe_ol, len=4
> [  237.678372] brcmutil: data
> [  237.678380] : 84 85 13 c0
>  
> 
> wpa_supplicant Log:
> nl80211: Set mode ifindex 2 iftype 8 (P2P_CLIENT)
> nl80211: Failed to set interface 2 to mode 8: -22 (Invalid argument)
> nl80211: Try mode change after setting interface down
> nl80211: Set mode ifindex 2 iftype 8 (P2P_CLIENT)
> nl80211: Failed to set interface 2 to mode 8: -22 (Invalid argument)
> nl80211: Interface mode change to 8 from 2 failed
>  
> 
> Kernel: 4.10.0-rc5
> wpa_supplicant: v2.6
> WiFI Firmware version = wl0: Jun  6 2014 14:50:39 version 7.10.226.49 (r) 
> FWID 01-8962686a
>  
> 
> Best Regards,
> Stefan Holzmann
>

Re: [RFC v3 0/8] ath10k sdio support

2017-02-18 Thread Valo, Kalle

Hej,

Erik Stromdahl  writes:

> This is the third version of the sdio RFC patch series.
> The actual sdio code (patch 6) has been subject to a massive overhaul,
> mainly as a result of Kalle's review comments.
> It no longer has any strong resemblance of the original ath6kl code from
> which it was originally based upon.
>
> Previous pathes 6 to 10 have been merged into one single patch.
>
> The previous series had a rework of the "HTC fake service" connect
> (ep 0 connect) that introduced a race between the actual endpoint
> connect and the HTC ready message. This issue has been addressed,
> and the current patches (3 and 4) has been rewritten accordingly.
>
> * overview of patches *
>
> Patches 1 to 4 are more or less identical to the previous RFC, with an
> exception for patch 3 that changes the "HTC fake service" connect
> (mentioned above).
>
> Patch 5 is a squashed version of previous patches 6 to 10.
>
> Patch 6 is the actual sdio patch
>
> Patches 7 to 8 are new and adds special sdio versions of BMI get
> target info and HTC ready.
>
> The new version was built and tested against:
> tag: ath-201701121109
>
> Erik Stromdahl (8):
>   ath10k: htc: made static function public
>   ath10k: htc: rx trailer lookahead support
>   ath10k: htc: move htc ctrl ep connect to htc_init
>   ath10k: htc: refactorization
>   ath10k: various sdio related definitions
>   ath10k: sdio support
>   ath10k: sdio get target info
>   ath10k: htc: ready_ext msg support

Sorry for not getting back to you earlier, haven't found time to look
this in detail during the last few weeks.

This is looking quite good now. I have some nitpicks (build warnings,
maybe reorder some patches etc) still but I think it's faster if I fix
those and send v4 as a proper patch (no RFC anymore), naturally
attributing you as the author. Is that ok for you?

-- 
Kalle Valo

Re: [PATCH] Fix rtl8187 multicast reception

Re: [PATCH] Fix rtl8187 multicast reception

[PATCH] Fix rtl8187 multicast reception

Re: [PATCH] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules

Re: [RFC v3 0/8] ath10k sdio support

Re: [RFC v3 0/8] ath10k sdio support

Re: [PATCH] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules

Re: brcmfmac: BCM4343A0 P2P mode problem

Re: [RFC v3 0/8] ath10k sdio support

9 matches

Site Navigation

Mail list logo

Footer information