date:20170219

Re: [PATCH v2] rtl8187: Enable monitor mode to fix multicast reception

2017-02-19 Thread Rafał Miłecki


On 02/20/2017 12:59 AM, Nils Holland wrote:

The rtl8187 cards don't seem to receive multicast frames, which,
among other things, makes them fail to receive RAs in IPv6 networks.
The cause seems to be that the RTL818X_RX_CONF_MULTICAST flag doesn't
have the desired effect.


AFAIU you have RTL8187B chipset card only, but above message describes this as
generic issue (including RTL8187 and RTL8187L).

Larry: were you able to reproduce this problem using RTL8187L? Is this
workaround needed for that chipset as well? I couldn't find clear statement.

Re: [PATCH] ath10k: Update available channel list for 5G radio

2017-02-19 Thread Rafał Miłecki


On 02/20/2017 06:08 AM, c_tr...@qti.qualcomm.com wrote:

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 3029f25..0840efb 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7623,6 +7623,38 @@ static void ath10k_mac_op_sta_pre_rcu_remove(struct 
ieee80211_hw *hw,
CHAN2G(14, 2484, 0),
 };

+static const struct ieee80211_channel ath10k_low_5ghz_channels[] = {
+   CHAN5G(36, 5180, 0),
+   CHAN5G(40, 5200, 0),
+   CHAN5G(44, 5220, 0),
+   CHAN5G(48, 5240, 0),
+   CHAN5G(52, 5260, 0),
+   CHAN5G(56, 5280, 0),
+   CHAN5G(60, 5300, 0),
+   CHAN5G(64, 5320, 0),
+};
+
+static const struct ieee80211_channel ath10k_high_5ghz_channels[] = {
+   CHAN5G(100, 5500, 0),
+   CHAN5G(104, 5520, 0),
+   CHAN5G(108, 5540, 0),
+   CHAN5G(112, 5560, 0),
+   CHAN5G(116, 5580, 0),
+   CHAN5G(120, 5600, 0),
+   CHAN5G(124, 5620, 0),
+   CHAN5G(128, 5640, 0),
+   CHAN5G(132, 5660, 0),
+   CHAN5G(136, 5680, 0),
+   CHAN5G(140, 5700, 0),
+   CHAN5G(144, 5720, 0),
+   CHAN5G(149, 5745, 0),
+   CHAN5G(153, 5765, 0),
+   CHAN5G(157, 5785, 0),
+   CHAN5G(161, 5805, 0),
+   CHAN5G(165, 5825, 0),
+   CHAN5G(169, 5845, 0),
+};


This isn't too flexible. What if one day you'll see hardware that supports
channels 100-144 only?

It should be much better idea to just disable unavailable channels, see what we
did in wiphy_freq_limits_apply (net-next).

Re: [PATCH] ath10k: Update available channel list for 5G radio

2017-02-19 Thread Adrian Chadd

hiya,

we're working on something similar to this, but based on bmi-id.

Why'd you withdraw this patch for now?


-a

Re: [PATCH] Make EN2 pin optional in the TRF7970A driver

2017-02-19 Thread Heiko Schocher


Hello all,

Am 13.02.2017 um 22:31 schrieb Rob Herring:

On Mon, Feb 13, 2017 at 12:38 AM, Heiko Schocher  wrote:

Hello Rob,


Am 10.02.2017 um 16:51 schrieb Rob Herring:


On Tue, Feb 07, 2017 at 06:22:04AM +0100, Heiko Schocher wrote:


From: Guan Ben 

Make the EN2 pin optional. This is useful for boards,
which have this pin fix wired, for example to ground.

Signed-off-by: Guan Ben 
Signed-off-by: Mark Jonas 
Signed-off-by: Heiko Schocher 

---

   .../devicetree/bindings/net/nfc/trf7970a.txt   |  4 ++--
   drivers/nfc/trf7970a.c | 26
--
   2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 32b35a0..5889a3d 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -5,8 +5,8 @@ Required properties:
   - spi-max-frequency: Maximum SPI frequency (<= 200).
   - interrupt-parent: phandle of parent interrupt handler.
   - interrupts: A single interrupt specifier.
-- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on the
-  TRF7970A.
+- ti,enable-gpios: One or two GPIO entries used for 'EN' and 'EN2' pins
on the
+  TRF7970A. EN2 is optional.



Could EN ever be optional/fixed? If so, perhaps deprecate this property
and do 2 properties, one for each pin.



The hardware I have has the EN2 pin fix connected to ground. Looking
into http://www.ti.com/lit/ds/slos743k/slos743k.pdf page 19 table 6-3
and 6-4 the EN2 pin is a don;t core if EN = 1. If EN = 0 EN2 pin
selects between Power Down and Sleep Mode ... I see no reason why
this is not possible/allowed ...

Hmm.. I do not like the idea of deprecating the "ti,enable-gpios"
property into 2 seperate properties ... but if this would be a reason
for not accepting this patch, I can do this ... How should I name
the 2 new properties?


I guess if this ever happens, then we just add "ti,enable2-gpios" and
ti,enable-gpios continues to point to EN. We don't need to deprecate
anything (or maybe just deprecate having both GPIOs on single
property).

In that case,

Acked-by: Rob Herring 


gentle ping.

Are there any more comments to this patch? Is it acceptable as it
is?

Thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[PATCH] ath10k: Update available channel list for 5G radio

2017-02-19 Thread c_traja

From: Tamizh chelvam 

If a 5 GHz radio is calibrated for operation in both
the low band (channels 36 to 64) and
high band(channels 100 to 169), hardware allows operations
in all the listed channels. However, if the chip has been
calibrated only for the low/high band and a high/low band
channel is configured, due to lack of calibration there will
be potentially invalid signal on those non calibrated channels.
To avoid this problem this patch introduces ath10k_low_5ghz_channel
and ath10k_high_5ghz_channel lists as separate arrays.
The channel list will be initialized depending on the low_5ghz_chan
and high_5ghz_chan values which we get from target through
wmi service ready event.

Signed-off-by: Tamizh chelvam 
---
 drivers/net/wireless/ath/ath10k/core.h |2 ++
 drivers/net/wireless/ath/ath10k/mac.c  |   55 +---
 drivers/net/wireless/ath/ath10k/wmi.c  |6 
 drivers/net/wireless/ath/ath10k/wmi.h  |2 ++
 4 files changed, 61 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 88d14be..d07d567 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -774,6 +774,8 @@ struct ath10k {
u32 vht_cap_info;
u32 num_rf_chains;
u32 max_spatial_stream;
+   u32 low_5ghz_chan;
+   u32 high_5ghz_chan;
/* protected by conf_mutex */
bool ani_enabled;
 
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 3029f25..0840efb 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7623,6 +7623,38 @@ static void ath10k_mac_op_sta_pre_rcu_remove(struct 
ieee80211_hw *hw,
CHAN2G(14, 2484, 0),
 };
 
+static const struct ieee80211_channel ath10k_low_5ghz_channels[] = {
+   CHAN5G(36, 5180, 0),
+   CHAN5G(40, 5200, 0),
+   CHAN5G(44, 5220, 0),
+   CHAN5G(48, 5240, 0),
+   CHAN5G(52, 5260, 0),
+   CHAN5G(56, 5280, 0),
+   CHAN5G(60, 5300, 0),
+   CHAN5G(64, 5320, 0),
+};
+
+static const struct ieee80211_channel ath10k_high_5ghz_channels[] = {
+   CHAN5G(100, 5500, 0),
+   CHAN5G(104, 5520, 0),
+   CHAN5G(108, 5540, 0),
+   CHAN5G(112, 5560, 0),
+   CHAN5G(116, 5580, 0),
+   CHAN5G(120, 5600, 0),
+   CHAN5G(124, 5620, 0),
+   CHAN5G(128, 5640, 0),
+   CHAN5G(132, 5660, 0),
+   CHAN5G(136, 5680, 0),
+   CHAN5G(140, 5700, 0),
+   CHAN5G(144, 5720, 0),
+   CHAN5G(149, 5745, 0),
+   CHAN5G(153, 5765, 0),
+   CHAN5G(157, 5785, 0),
+   CHAN5G(161, 5805, 0),
+   CHAN5G(165, 5825, 0),
+   CHAN5G(169, 5845, 0),
+};
+
 static const struct ieee80211_channel ath10k_5ghz_channels[] = {
CHAN5G(36, 5180, 0),
CHAN5G(40, 5200, 0),
@@ -8014,6 +8046,7 @@ int ath10k_mac_register(struct ath10k *ar)
};
struct ieee80211_supported_band *band;
void *channels;
+   int n_channels;
int ret;
 
SET_IEEE80211_PERM_ADDR(ar->hw, ar->mac_addr);
@@ -8049,16 +8082,30 @@ int ath10k_mac_register(struct ath10k *ar)
}
 
if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY) {
-   channels = kmemdup(ath10k_5ghz_channels,
-  sizeof(ath10k_5ghz_channels),
-  GFP_KERNEL);
+   if (ar->high_5ghz_chan <= 5350) {
+   channels = kmemdup(ath10k_low_5ghz_channels,
+  sizeof(ath10k_low_5ghz_channels),
+  GFP_KERNEL);
+   n_channels = ARRAY_SIZE(ath10k_low_5ghz_channels);
+   } else if (ar->low_5ghz_chan >= 5490 &&
+  ar->high_5ghz_chan <= 5885) {
+   channels = kmemdup(ath10k_high_5ghz_channels,
+  sizeof(ath10k_high_5ghz_channels),
+  GFP_KERNEL);
+   n_channels = ARRAY_SIZE(ath10k_high_5ghz_channels);
+   } else {
+   channels = kmemdup(ath10k_5ghz_channels,
+  sizeof(ath10k_5ghz_channels),
+  GFP_KERNEL);
+   n_channels = ARRAY_SIZE(ath10k_5ghz_channels);
+   }
if (!channels) {
ret = -ENOMEM;
goto err_free;
}
 
band = >mac.sbands[NL80211_BAND_5GHZ];
-   band->n_channels = ARRAY_SIZE(ath10k_5ghz_channels);
+   band->n_channels = n_channels;
band->channels = channels;
band->n_bitrates = ath10k_a_rates_size;
band->bitrates = ath10k_a_rates;
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c

RE: [PATCHv2] ath10k: Update available channel list for 5G radio

2017-02-19 Thread Raja, Tamizh Chelvam

Please ignore this patch:(

> -Original Message-
> From: Raja, Tamizh Chelvam
> Sent: Monday, February 20, 2017 10:37 AM
> To: ath...@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org; Raja, Tamizh Chelvam
> 
> Subject: [PATCHv2] ath10k: Update available channel list for 5G radio
> 
> From: Tamizh chelvam 
> 
> If a 5 GHz radio is calibrated for operation in both the low band (channels 
> 36 to
> 64) and high band(channels 100 to 169), hardware allows operations in all the
> listed channels. However, if the chip has been calibrated only for the 
> low/high
> band and a high/low band channel is configured, due to lack of calibration
> there will be potentially invalid signal on those non calibrated channels.
> To avoid this problem this patch introduces ath10k_low_5ghz_channel and
> ath10k_high_5ghz_channel lists as separate arrays.
> The channel list will be initialized depending on the low_5ghz_chan and
> high_5ghz_chan values which we get from target through wmi service ready
> event.
> 
> Signed-off-by: Tamizh chelvam 
> ---
> v2:
>   * Addressed Jouni and Kalle's comments
> 
>  drivers/net/wireless/ath/ath10k/core.h |2 ++
>  drivers/net/wireless/ath/ath10k/mac.c  |   55
> +---
>  drivers/net/wireless/ath/ath10k/wmi.c  |6 
>  drivers/net/wireless/ath/ath10k/wmi.h  |2 ++
>  4 files changed, 61 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath10k/core.h
> b/drivers/net/wireless/ath/ath10k/core.h
> index 88d14be..d07d567 100644
> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -774,6 +774,8 @@ struct ath10k {
>   u32 vht_cap_info;
>   u32 num_rf_chains;
>   u32 max_spatial_stream;
> + u32 low_5ghz_chan;
> + u32 high_5ghz_chan;
>   /* protected by conf_mutex */
>   bool ani_enabled;
> 
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
> b/drivers/net/wireless/ath/ath10k/mac.c
> index 3029f25..0840efb 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -7623,6 +7623,38 @@ static void
> ath10k_mac_op_sta_pre_rcu_remove(struct ieee80211_hw *hw,
>   CHAN2G(14, 2484, 0),
>  };
> 
> +static const struct ieee80211_channel ath10k_low_5ghz_channels[] = {
> + CHAN5G(36, 5180, 0),
> + CHAN5G(40, 5200, 0),
> + CHAN5G(44, 5220, 0),
> + CHAN5G(48, 5240, 0),
> + CHAN5G(52, 5260, 0),
> + CHAN5G(56, 5280, 0),
> + CHAN5G(60, 5300, 0),
> + CHAN5G(64, 5320, 0),
> +};
> +
> +static const struct ieee80211_channel ath10k_high_5ghz_channels[] = {
> + CHAN5G(100, 5500, 0),
> + CHAN5G(104, 5520, 0),
> + CHAN5G(108, 5540, 0),
> + CHAN5G(112, 5560, 0),
> + CHAN5G(116, 5580, 0),
> + CHAN5G(120, 5600, 0),
> + CHAN5G(124, 5620, 0),
> + CHAN5G(128, 5640, 0),
> + CHAN5G(132, 5660, 0),
> + CHAN5G(136, 5680, 0),
> + CHAN5G(140, 5700, 0),
> + CHAN5G(144, 5720, 0),
> + CHAN5G(149, 5745, 0),
> + CHAN5G(153, 5765, 0),
> + CHAN5G(157, 5785, 0),
> + CHAN5G(161, 5805, 0),
> + CHAN5G(165, 5825, 0),
> + CHAN5G(169, 5845, 0),
> +};
> +
>  static const struct ieee80211_channel ath10k_5ghz_channels[] = {
>   CHAN5G(36, 5180, 0),
>   CHAN5G(40, 5200, 0),
> @@ -8014,6 +8046,7 @@ int ath10k_mac_register(struct ath10k *ar)
>   };
>   struct ieee80211_supported_band *band;
>   void *channels;
> + int n_channels;
>   int ret;
> 
>   SET_IEEE80211_PERM_ADDR(ar->hw, ar->mac_addr); @@ -8049,16
> +8082,30 @@ int ath10k_mac_register(struct ath10k *ar)
>   }
> 
>   if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY) {
> - channels = kmemdup(ath10k_5ghz_channels,
> -sizeof(ath10k_5ghz_channels),
> -GFP_KERNEL);
> + if (ar->high_5ghz_chan <= 5350) {
> + channels = kmemdup(ath10k_low_5ghz_channels,
> +sizeof(ath10k_low_5ghz_channels),
> +GFP_KERNEL);
> + n_channels = ARRAY_SIZE(ath10k_low_5ghz_channels);
> + } else if (ar->low_5ghz_chan >= 5490 &&
> +ar->high_5ghz_chan <= 5885) {
> + channels = kmemdup(ath10k_high_5ghz_channels,
> +sizeof(ath10k_high_5ghz_channels),
> +GFP_KERNEL);
> + n_channels =
> ARRAY_SIZE(ath10k_high_5ghz_channels);
> + } else {
> + channels = kmemdup(ath10k_5ghz_channels,
> +sizeof(ath10k_5ghz_channels),
> +GFP_KERNEL);
> + n_channels = ARRAY_SIZE(ath10k_5ghz_channels);
> + }
>   if (!channels) {
>

[PATCHv2] ath10k: Update available channel list for 5G radio

2017-02-19 Thread c_traja

From: Tamizh chelvam 

If a 5 GHz radio is calibrated for operation in both
the low band (channels 36 to 64) and
high band(channels 100 to 169), hardware allows operations
in all the listed channels. However, if the chip has been
calibrated only for the low/high band and a high/low band
channel is configured, due to lack of calibration there will
be potentially invalid signal on those non calibrated channels.
To avoid this problem this patch introduces ath10k_low_5ghz_channel
and ath10k_high_5ghz_channel lists as separate arrays.
The channel list will be initialized depending on the low_5ghz_chan
and high_5ghz_chan values which we get from target through
wmi service ready event.

Signed-off-by: Tamizh chelvam 
---
v2:
  * Addressed Jouni and Kalle's comments

 drivers/net/wireless/ath/ath10k/core.h |2 ++
 drivers/net/wireless/ath/ath10k/mac.c  |   55 +---
 drivers/net/wireless/ath/ath10k/wmi.c  |6 
 drivers/net/wireless/ath/ath10k/wmi.h  |2 ++
 4 files changed, 61 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 88d14be..d07d567 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -774,6 +774,8 @@ struct ath10k {
u32 vht_cap_info;
u32 num_rf_chains;
u32 max_spatial_stream;
+   u32 low_5ghz_chan;
+   u32 high_5ghz_chan;
/* protected by conf_mutex */
bool ani_enabled;
 
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 3029f25..0840efb 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7623,6 +7623,38 @@ static void ath10k_mac_op_sta_pre_rcu_remove(struct 
ieee80211_hw *hw,
CHAN2G(14, 2484, 0),
 };
 
+static const struct ieee80211_channel ath10k_low_5ghz_channels[] = {
+   CHAN5G(36, 5180, 0),
+   CHAN5G(40, 5200, 0),
+   CHAN5G(44, 5220, 0),
+   CHAN5G(48, 5240, 0),
+   CHAN5G(52, 5260, 0),
+   CHAN5G(56, 5280, 0),
+   CHAN5G(60, 5300, 0),
+   CHAN5G(64, 5320, 0),
+};
+
+static const struct ieee80211_channel ath10k_high_5ghz_channels[] = {
+   CHAN5G(100, 5500, 0),
+   CHAN5G(104, 5520, 0),
+   CHAN5G(108, 5540, 0),
+   CHAN5G(112, 5560, 0),
+   CHAN5G(116, 5580, 0),
+   CHAN5G(120, 5600, 0),
+   CHAN5G(124, 5620, 0),
+   CHAN5G(128, 5640, 0),
+   CHAN5G(132, 5660, 0),
+   CHAN5G(136, 5680, 0),
+   CHAN5G(140, 5700, 0),
+   CHAN5G(144, 5720, 0),
+   CHAN5G(149, 5745, 0),
+   CHAN5G(153, 5765, 0),
+   CHAN5G(157, 5785, 0),
+   CHAN5G(161, 5805, 0),
+   CHAN5G(165, 5825, 0),
+   CHAN5G(169, 5845, 0),
+};
+
 static const struct ieee80211_channel ath10k_5ghz_channels[] = {
CHAN5G(36, 5180, 0),
CHAN5G(40, 5200, 0),
@@ -8014,6 +8046,7 @@ int ath10k_mac_register(struct ath10k *ar)
};
struct ieee80211_supported_band *band;
void *channels;
+   int n_channels;
int ret;
 
SET_IEEE80211_PERM_ADDR(ar->hw, ar->mac_addr);
@@ -8049,16 +8082,30 @@ int ath10k_mac_register(struct ath10k *ar)
}
 
if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY) {
-   channels = kmemdup(ath10k_5ghz_channels,
-  sizeof(ath10k_5ghz_channels),
-  GFP_KERNEL);
+   if (ar->high_5ghz_chan <= 5350) {
+   channels = kmemdup(ath10k_low_5ghz_channels,
+  sizeof(ath10k_low_5ghz_channels),
+  GFP_KERNEL);
+   n_channels = ARRAY_SIZE(ath10k_low_5ghz_channels);
+   } else if (ar->low_5ghz_chan >= 5490 &&
+  ar->high_5ghz_chan <= 5885) {
+   channels = kmemdup(ath10k_high_5ghz_channels,
+  sizeof(ath10k_high_5ghz_channels),
+  GFP_KERNEL);
+   n_channels = ARRAY_SIZE(ath10k_high_5ghz_channels);
+   } else {
+   channels = kmemdup(ath10k_5ghz_channels,
+  sizeof(ath10k_5ghz_channels),
+  GFP_KERNEL);
+   n_channels = ARRAY_SIZE(ath10k_5ghz_channels);
+   }
if (!channels) {
ret = -ENOMEM;
goto err_free;
}
 
band = >mac.sbands[NL80211_BAND_5GHZ];
-   band->n_channels = ARRAY_SIZE(ath10k_5ghz_channels);
+   band->n_channels = n_channels;
band->channels = channels;
band->n_bitrates = ath10k_a_rates_size;
band->bitrates = ath10k_a_rates;
diff --git

Re: [PATCH v2] rtl8187: Enable monitor mode to fix multicast reception

2017-02-19 Thread Larry Finger


On 02/19/2017 05:59 PM, Nils Holland wrote:

The rtl8187 cards don't seem to receive multicast frames, which,
among other things, makes them fail to receive RAs in IPv6 networks.
The cause seems to be that the RTL818X_RX_CONF_MULTICAST flag doesn't
have the desired effect.

Fix the issue by setting RTL818X_RX_CONF_MONITOR instead, which puts the
card into monitor mode and resolves the problem so that multicast frames
are sucessfully passed to the kernel.

The existence of the problem and the effectiveness of the solution has
originally been confirmed on an 8187B based card with the USB id of
0bda:8197. Subsequent testing by Larry Finger on an 8187L based card,
which follows the second (8187, i.e. "non-b") code path in the driver,
has confirmed that the fix does not cause any noticeable regresssions
there either.

Signed-off-by: Nils Holland 


Acked-by: Larry Finger 

Thanks,

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);
 }

[PATCH v2] rtl8187: Enable monitor mode to fix multicast reception

2017-02-19 Thread Nils Holland

The rtl8187 cards don't seem to receive multicast frames, which,
among other things, makes them fail to receive RAs in IPv6 networks.
The cause seems to be that the RTL818X_RX_CONF_MULTICAST flag doesn't
have the desired effect.

Fix the issue by setting RTL818X_RX_CONF_MONITOR instead, which puts the
card into monitor mode and resolves the problem so that multicast frames
are sucessfully passed to the kernel.

The existence of the problem and the effectiveness of the solution has
originally been confirmed on an 8187B based card with the USB id of
0bda:8197. Subsequent testing by Larry Finger on an 8187L based card,
which follows the second (8187, i.e. "non-b") code path in the driver,
has confirmed that the fix does not cause any noticeable regresssions
there either.

Signed-off-by: Nils Holland 
---
 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] Fix rtl8187 multicast reception

2017-02-19 Thread Larry Finger


On 02/19/2017 12:53 PM, Nils Holland wrote:

On Sun, Feb 19, 2017 at 12:11:50PM -0600, Larry Finger wrote:

On 02/19/2017 07:29 AM, Kalle Valo wrote:

Nils Holland  writes:


On Sun, Feb 19, 2017 at 09:46:16AM +0200, Kalle Valo wrote:

Larry Finger  writes:


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

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.


Well, this is a tough question, I have to admit that I have a somewhat
weird feeling making a change that also applies to other hardware that
I cannot test on, so I don't know about any negative consequences that
might arise there, especially when the change isn't based on some
official information from some documentation, but rather a result of
trial & error. So I can fully understand Larry's concerns and do in
fact think that a module parameter could be a nice solution, so that
by default the behavior if the driver does not change.


There are lots of hardware variations that cannot be tested when a patch
is commited. If we followed the same methdology with all patches we
would have thousands of module parameters in kernel in no time :)


From an end-user standpoint, it's probably always worse to see
something break which has always worked before than it is to have
something not work properly right from the start, but being able to
easily find some parameter to fix this.


Sure. But if there's a report about this patch breaking something, it's
easy to revert it.


On the other hand, use of this particular USB wifi card is probably
not so common these days so relatively few people would notice at all.
Tough! I guess I'll submit a module parameter based v2 of the patch
later today, just as Larry suggested!


Also remember to add a prefix to the title:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#subject


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?


Of course, if someone has other hw, more testing would be nice! Any
situation where the card is supposed to receive multicast frames
should be suitable as a test case - in my case, just connecting to my
local network and expecting to see the card pick up RAs and acquire an
IPv6 address is the easiest test case. This works nicely on several
other machines with completely different wifi hardware as well as
wired machines, but fails without the fix on the rtl8187b. It would,
for example, be interesting to see if a non-b 8187 behaves the same or
if things work there out of the box.


I'm not familiar with the driver so when you say "non-b 8187" what do
you mean exactly? What kind of hardware are we talking about? How many
different hardware versions are there that this patch affects? Is the
firmware/hardware really so different that the chances are high that
this breaks something?


In that case, instead of doing a module parameter, I could also change
the fix so that it only does something different on the b-variants of
the card and doesn't change behavior at all on non-b.


Now that's much better option than adding a module parameter.


There are three variants of the chip, the RTL8187, RTL8187L, and RTL8187B.
Programming for the first two are the same. The RTL8187B has a number of newer
features such as priority queues and a more complete set of parameters in the
descriptors.

OK, for the moment I agree to this patch with a respin of the commit message. I
will test with my 8187L device. If those fail, I will request that it be limited
to the 8187B.


Sounds good, so I guess I'll wait for your report regarding behavior
on your 8187l. Then, I'll either re-submit the patch as a v2 with a
reworked commit message and proper tag in the title, or, if the fix
as-is causes problems on the 8187l, re-submit the patch with limiting
the scope of its change to the 8187b only. Sounds good? :-)


The 8187L is working as expected. The only downside of your patch is that the 
NIC is put into monitor mode silently, which is probably a security hole. As 
Kalle is opposed to a module parameter, then I guess that is an acceptable risk. 
Go ahead with V2 with the revised tag and commit message.


Larry

RE: brcmfmac: BCM4343A0 P2P mode problem

2017-02-19 Thread Stefan Holzmann

Hello Arend,

I tried already the firmware file from the linux-firmware repo, but this 
firmware doesn't work. I get SDIO communication timeouts after the firmware 
file is loaded.

Here the requested Kernel Log:
[1.503423] brcmfmac: brcmf_sdio_probe Enter
[1.504311] brcmfmac: F1 signature read @0x1800=0x1540a9a6
[1.504574] brcmfmac: brcmf_chip_recognition found AXI chip: BCM43430, rev=0
[1.506798] brcmfmac: brcmf_chip_cores_check  [1 ] core 0x800:49 base 
0x1800 wrap 0x1810
[1.506809] brcmfmac: brcmf_chip_cores_check  [2 ] core 0x812:39 base 
0x18001000 wrap 0x18101000
[1.506816] brcmfmac: brcmf_chip_cores_check  [3 ] core 0x829:21 base 
0x18002000 wrap 0x18102000
[1.506822] brcmfmac: brcmf_chip_cores_check  [4 ] core 0x82a:9  base 
0x18003000 wrap 0x18103000
[1.506828] brcmfmac: brcmf_chip_cores_check  [5 ] core 0x80e:22 base 
0x18004000 wrap 0x18104000
[1.506833] brcmfmac: brcmf_chip_cores_check  [6 ] core 0x135:0  base 
0x wrap 0x18105000
[1.506839] brcmfmac: brcmf_chip_cores_check  [7 ] core 0x240:0  base 
0x wrap 0x18106000
[1.506843] brcmfmac: brcmf_chip_set_passive Enter
[1.507832] brcmfmac: brcmf_chip_get_raminfo RAM: base=0x0 size=524288 
(0x8) sr=65536 (0x1)
[1.507954] brcmfmac: brcmf_chip_setup ccrev=49, pmurev=24, 
pmucaps=0x39d25f18
[1.507961] brcmfmac: brcmf_get_module_param Enter, bus=0, chip=43430, rev=0
[1.508022] brcmfmac: brcmf_sdiod_sgtable_alloc nents=35
[1.508032] brcmfmac: brcmf_sdio_kso_init Enter
[1.508061] brcmfmac: brcmf_sdio_drivestrengthinit No SDIO driver strength 
init needed for chip 43430 rev 0 pmurev 24
[1.508337] brcmfmac: brcmf_attach Enter
[1.508385] brcmfmac: brcmf_fweh_register event handler registered for 
PSM_WATCHDOG
[1.508389] brcmfmac: brcmf_proto_attach Enter
[1.508408] brcmfmac: brcmf_sdiod_sgtable_alloc nents=35
[1.508491] brcmfmac: brcmf_sdio_probe completed!!
[1.508503] brcmfmac: brcmf_fw_get_firmwares_pcie enter: dev=mmc1:0001:1
[1.509610] brcmfmac: brcmf_fw_request_code_done enter: dev=mmc1:0001:1
[1.509748] brcmfmac: brcmf_fw_request_nvram_done enter: dev=mmc1:0001:1
[1.509814] brcmfmac: brcmf_sdio_firmware_callback Enter: dev=mmc1:0001:1
[1.509933] brcmfmac: brcmf_sdio_download_code_file Enter
[1.530047] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl & ul at 
0x; size=342904
[1.564544] brcmfmac: brcmf_sdio_download_nvram Enter
[1.564707] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl & ul at 
0x0007fdd8; size=552
[1.564856] brcmfmac: brcmf_chip_set_active Enter
[1.623164] brcmfmac: brcmf_sdio_firmware_callback enable F2: err=0
[1.623226] brcmfmac: brcmf_chip_sr_capable Enter
[1.623269] brcmfmac: brcmf_sdiod_change_state 0 -> 1
[1.623276] brcmfmac: brcmf_bus_change_state 0 -> 1
[1.623318] brcmfmac: brcmf_sdio_isr Enter
[1.623369] brcmfmac: brcmf_sdio_dpc Enter
[1.623417] brcmfmac: brcmf_bus_start 
[1.623425] brcmfmac: brcmf_add_if Enter, bsscfgidx=0, ifidx=0
[1.623429] brcmfmac: brcmf_add_if allocate netdev interface
[1.623465] brcmfmac: brcmf_add_if   pid:27, if:wlan%d 
(00:00:00:00:00:00) created ===
[1.623509] brcmfmac: brcmf_bus_change_state 1 -> 1
[1.623521] brcmfmac: brcmf_sdio_bus_txctl Enter
[1.623571] brcmfmac: brcmf_sdio_isr Enter
[1.623648] brcmfmac: brcmf_chip_sr_capable Enter
[1.623777] brcmfmac: brcmf_sdio_readshared sdpcm_shared address 0x0003614C
[1.623876] brcmfmac: brcmf_sdio_dpc Dongle reports CHIPACTIVE
[1.623880] brcmfmac: brcmf_sdio_readframes Enter
[1.623944] brcmfmac: brcmf_sdio_tx_ctrlframe Enter
[1.623993] brcmfmac: brcmf_sdio_dpc Enter
[1.624002] brcmfmac: brcmf_sdio_bus_rxctl Enter
[1.624123] brcmfmac: brcmf_chip_sr_capable Enter
[1.624234] brcmfmac: brcmf_sdio_readshared sdpcm_shared address 0x0003614C
[1.624426] brcmfmac: brcmf_sdio_isr Enter
[1.624448] brcmfmac: brcmf_sdio_dpc Enter
[1.624516] brcmfmac: brcmf_sdio_readframes Enter
[1.624544] brcmfmac: brcmf_sdio_read_control Enter
[1.624608] brcmfmac: brcmf_sdio_bus_rxctl resumed on rxctl frame, got 36 
expected 36
[1.624615] brcmfmac: brcmf_fil_iovar_data_get ifidx=0, name=cur_etheraddr, 
len=6
[1.624618] brcmutil: data
[1.624630] : 94 a1 a2 a3 9b 96..
[1.624636] brcmfmac: brcmf_sdio_bus_txctl Enter
[1.624651] brcmfmac: brcmf_sdio_dpc Enter
[1.624658] brcmfmac: brcmf_sdio_tx_ctrlframe Enter
[1.624699] brcmfmac: brcmf_sdio_bus_rxctl Enter
[1.624872] brcmfmac: brcmf_sdio_isr Enter
[1.624909] brcmfmac: brcmf_sdio_dpc Enter
[1.624960] brcmfmac: brcmf_sdio_readframes Enter
[1.624998] brcmfmac: brcmf_sdio_read_control Enter
[1.625059] brcmfmac: brcmf_sdio_bus_rxctl resumed on rxctl frame, got 84 
expected 84
[1.625067] brcmfmac: brcmf_fil_cmd_data_get ifidx=0, cmd=98, len=68
[1.625069] brcmutil: data

Re: brcmfmac: BCM4343A0 P2P mode problem

2017-02-19 Thread Arend Van Spriel

On 19-2-2017 20:00, Stefan Holzmann wrote:
> Hello,
> 
> I think my problem was just a firmware version issue. When I use the firmware 
> file "fw_bcm4343.bin" from here 
> https://android.googlesource.com/platform/hardware/broadcom/wlan I'am able 
> establish a P2P connection.
> Is this the latest/recommended firmware version for the chipset?
> 
> Firmware version = wl0: Jul  1 2016 18:02:40 version 7.10.1 (A0 Station/P2P 
> feature) FWID 01-bae8afee

I would suggest looking in linux-firmware repo on kernel.org for
upstream firmware instead of using AOSP firmware. However, I am not
entirely sure whether we have the firmware in place for your chipset.

Could you insert the driver module with parameter debug=0x1416 and send
me dmesg output.

Regards,
Arend

Re: brcmfmac: BCM4343A0 P2P mode problem

2017-02-19 Thread Stefan Holzmann

Hello,

I think my problem was just a firmware version issue. When I use the firmware 
file "fw_bcm4343.bin" from here 
https://android.googlesource.com/platform/hardware/broadcom/wlan I'am able 
establish a P2P connection.
Is this the latest/recommended firmware version for the chipset?

Firmware version = wl0: Jul  1 2016 18:02:40 version 7.10.1 (A0 Station/P2P 
feature) FWID 01-bae8afee


>Thank you for your support. Yes, correct SDIO 0xA9A6 is BCM43430 I was 
>confused by 
>the naming of some firmware files.

>What firmware version/file shall be used for this chipset/driver combination?
>Currently I'am using the firmware file "fw_bcm43438a0_p2p.bin" from here 
>https://github.com/BPI-SINOVOIP/BPI_WiFi_Firmware/tree/master/ap6212.

>I have set the driver parameter "use_p2p_group_interface=1" as you 
>recommended, and 
>now I see following error messages at the kernel log when I try to setup a P2P 
>connection.
>
>[   59.593565] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 
>0x40012
>[   62.163452] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
>[   62.169542] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
>[   62.175839] brcmfmac: brcmf_cfg80211_add_iface: add iface p2p-wlan0-0 type 
>8 
>failed: err=-110

Re: [PATCH] Fix rtl8187 multicast reception

2017-02-19 Thread Nils Holland

On Sun, Feb 19, 2017 at 12:11:50PM -0600, Larry Finger wrote:
> On 02/19/2017 07:29 AM, Kalle Valo wrote:
> > Nils Holland  writes:
> >
> >> On Sun, Feb 19, 2017 at 09:46:16AM +0200, Kalle Valo wrote:
> >>> Larry Finger  writes:
> >>>
>  On 02/18/2017 07:35 PM, Nils Holland wrote:
> 
>  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.
> >>
> >> Well, this is a tough question, I have to admit that I have a somewhat
> >> weird feeling making a change that also applies to other hardware that
> >> I cannot test on, so I don't know about any negative consequences that
> >> might arise there, especially when the change isn't based on some
> >> official information from some documentation, but rather a result of
> >> trial & error. So I can fully understand Larry's concerns and do in
> >> fact think that a module parameter could be a nice solution, so that
> >> by default the behavior if the driver does not change.
> >
> > There are lots of hardware variations that cannot be tested when a patch
> > is commited. If we followed the same methdology with all patches we
> > would have thousands of module parameters in kernel in no time :)
> >
> >> From an end-user standpoint, it's probably always worse to see
> >> something break which has always worked before than it is to have
> >> something not work properly right from the start, but being able to
> >> easily find some parameter to fix this.
> >
> > Sure. But if there's a report about this patch breaking something, it's
> > easy to revert it.
> >
> >> On the other hand, use of this particular USB wifi card is probably
> >> not so common these days so relatively few people would notice at all.
> >> Tough! I guess I'll submit a module parameter based v2 of the patch
> >> later today, just as Larry suggested!
> >
> > Also remember to add a prefix to the title:
> >
> > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#subject
> >
> >>> 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?
> >>
> >> Of course, if someone has other hw, more testing would be nice! Any
> >> situation where the card is supposed to receive multicast frames
> >> should be suitable as a test case - in my case, just connecting to my
> >> local network and expecting to see the card pick up RAs and acquire an
> >> IPv6 address is the easiest test case. This works nicely on several
> >> other machines with completely different wifi hardware as well as
> >> wired machines, but fails without the fix on the rtl8187b. It would,
> >> for example, be interesting to see if a non-b 8187 behaves the same or
> >> if things work there out of the box.
> >
> > I'm not familiar with the driver so when you say "non-b 8187" what do
> > you mean exactly? What kind of hardware are we talking about? How many
> > different hardware versions are there that this patch affects? Is the
> > firmware/hardware really so different that the chances are high that
> > this breaks something?
> >
> >> In that case, instead of doing a module parameter, I could also change
> >> the fix so that it only does something different on the b-variants of
> >> the card and doesn't change behavior at all on non-b.
> >
> > Now that's much better option than adding a module parameter.
> 
> There are three variants of the chip, the RTL8187, RTL8187L, and RTL8187B. 
> Programming for the first two are the same. The RTL8187B has a number of 
> newer 
> features such as priority queues and a more complete set of parameters in the 
> descriptors.
> 
> OK, for the moment I agree to this patch with a respin of the commit message. 
> I 
> will test with my 8187L device. If those fail, I will request that it be 
> limited 
> to the 8187B.

Sounds good, so I guess I'll wait for your report regarding behavior
on your 8187l. Then, I'll either re-submit the patch as a v2 with a
reworked commit message and proper tag in the title, or, if the fix
as-is causes problems on the 8187l, re-submit the patch with limiting
the scope of its change to the 8187b only. Sounds good? :-)

Greetings
Nils

Re: [PATCH] Fix rtl8187 multicast reception

2017-02-19 Thread Larry Finger


On 02/19/2017 07:29 AM, Kalle Valo wrote:

Nils Holland  writes:


On Sun, Feb 19, 2017 at 09:46:16AM +0200, Kalle Valo wrote:

Larry Finger  writes:


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

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.


Well, this is a tough question, I have to admit that I have a somewhat
weird feeling making a change that also applies to other hardware that
I cannot test on, so I don't know about any negative consequences that
might arise there, especially when the change isn't based on some
official information from some documentation, but rather a result of
trial & error. So I can fully understand Larry's concerns and do in
fact think that a module parameter could be a nice solution, so that
by default the behavior if the driver does not change.


There are lots of hardware variations that cannot be tested when a patch
is commited. If we followed the same methdology with all patches we
would have thousands of module parameters in kernel in no time :)


From an end-user standpoint, it's probably always worse to see
something break which has always worked before than it is to have
something not work properly right from the start, but being able to
easily find some parameter to fix this.


Sure. But if there's a report about this patch breaking something, it's
easy to revert it.


On the other hand, use of this particular USB wifi card is probably
not so common these days so relatively few people would notice at all.
Tough! I guess I'll submit a module parameter based v2 of the patch
later today, just as Larry suggested!


Also remember to add a prefix to the title:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#subject


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?


Of course, if someone has other hw, more testing would be nice! Any
situation where the card is supposed to receive multicast frames
should be suitable as a test case - in my case, just connecting to my
local network and expecting to see the card pick up RAs and acquire an
IPv6 address is the easiest test case. This works nicely on several
other machines with completely different wifi hardware as well as
wired machines, but fails without the fix on the rtl8187b. It would,
for example, be interesting to see if a non-b 8187 behaves the same or
if things work there out of the box.


I'm not familiar with the driver so when you say "non-b 8187" what do
you mean exactly? What kind of hardware are we talking about? How many
different hardware versions are there that this patch affects? Is the
firmware/hardware really so different that the chances are high that
this breaks something?


In that case, instead of doing a module parameter, I could also change
the fix so that it only does something different on the b-variants of
the card and doesn't change behavior at all on non-b.


Now that's much better option than adding a module parameter.


There are three variants of the chip, the RTL8187, RTL8187L, and RTL8187B. 
Programming for the first two are the same. The RTL8187B has a number of newer 
features such as priority queues and a more complete set of parameters in the 
descriptors.


OK, for the moment I agree to this patch with a respin of the commit message. I 
will test with my 8187L device. If those fail, I will request that it be limited 
to the 8187B.


If we later get complaints, then we can decide to revert the patch, or add a 
module parameter to selectively disable it.


Larry

[PATCH] wcn36xx: Fix error handling

2017-02-19 Thread Christophe JAILLET

Reorder 'out_free_dxe_pool' and 'out_free_dxe_ctl' error handling labels
in order to match the way resources have been allocated.

Signed-off-by: Christophe JAILLET 
---
 drivers/net/wireless/ath/wcn36xx/main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
b/drivers/net/wireless/ath/wcn36xx/main.c
index cee4f655bf36..6436235bc265 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -337,10 +337,10 @@ static int wcn36xx_start(struct ieee80211_hw *hw)
wcn36xx_smd_stop(wcn);
 out_free_smd_buf:
kfree(wcn->hal_buf);
-out_free_dxe_pool:
-   wcn36xx_dxe_free_mem_pools(wcn);
 out_free_dxe_ctl:
wcn36xx_dxe_free_ctl_blks(wcn);
+out_free_dxe_pool:
+   wcn36xx_dxe_free_mem_pools(wcn);
 out_smd_close:
wcn36xx_smd_close(wcn);
 out_err:
-- 
2.9.3

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

2017-02-19 Thread Valo, Kalle

Erik Stromdahl  writes:

> Ok, I'll do another round of checkpatch before I submit anything.
> I couldn't find the script you mentioned though (ath10k-check).

Did you check the link I gave you:

https://wireless.wiki.kernel.org/en/users/drivers/ath10k/codingstyle#checking_code

> Is it some kind of checkpatch wrapper?

It runs various tests (gcc, sparse, checkpatch), sets some checkpatch
settings (like line length) and filters out warnings we don't care
about.

> Anyway, I have a few warnings related to 'line over 80 chars' that
> is really hard to get rid of (without breaking indentation etc.) so
> I won't do anything about those for now.
>
> Then there are some other warnings about the BIT macro being preferred
> over (1 << x). I have used (1 << x) in some files despite the checkpatch
> warning in order to keep the patches consistent with the existing code.
> I think the best approach is to have a separate round of cleanup-patches
> replacing all (1 << x) with BIT(x).

These are all disabled by ath10k-check. I think it's easiest that you
forget ath10k-check for now and let me fix those in the next round.

-- 
Kalle Valo

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

2017-02-19 Thread Erik Stromdahl




On 2017-02-19 15:05, Valo, Kalle wrote:

Erik Stromdahl  writes:


I just noticed that Ryan Hsu submitted two patches containing similar
functionality to what I have in my tree on github. They have not been
integrated in the ath master yet, but they have been added to master-pending.

Below are the commits I am talking about

bc1054a15be3c962c83aa22476a3e9c1266da792 ath10k: improve the firmware
download time for QCA9377
db5af2a25bd8c1410ec4456d1d4f4e6ded2649ca ath10k: improve the firmware
download time for QCA6174

Since some of my patches overlap with these I think it would be best if
I add these to my tree and rewrite my patches.

If they haven't made it into master before I submit my updated patch series
I will include them in my set.

Is this OK?

If they will be added to master soon there is no issue since I will of course
rebase to the latest ath-MMDDHHmm before I submit anything.


That's ok, just mention this in the cover letter.

Even better is that if you can use master-pending from ath.git as the
baseline (compared to the master branch normally recommended), Ryan's
patches are there now. That way you don't need to apply anything extra
to your tree. But I'm hoping to apply Ryan's patches soon anyway.



Ok, I'll make it so.

Re: [PATCH] Fix rtl8187 multicast reception

2017-02-19 Thread Nils Holland

On Sun, Feb 19, 2017 at 03:29:12PM +0200, Kalle Valo wrote:
> Nils Holland  writes:
> 
> > On Sun, Feb 19, 2017 at 09:46:16AM +0200, Kalle Valo wrote:
> >> Larry Finger  writes:
> >> 
> >> > On 02/18/2017 07:35 PM, Nils Holland wrote:
> >> >
> >> > 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.
> >
> > Well, this is a tough question, I have to admit that I have a somewhat
> > weird feeling making a change that also applies to other hardware that
> > I cannot test on, so I don't know about any negative consequences that
> > might arise there, especially when the change isn't based on some
> > official information from some documentation, but rather a result of
> > trial & error. So I can fully understand Larry's concerns and do in
> > fact think that a module parameter could be a nice solution, so that
> > by default the behavior if the driver does not change.
> 
> There are lots of hardware variations that cannot be tested when a patch
> is commited. If we followed the same methdology with all patches we
> would have thousands of module parameters in kernel in no time :)

Right, that's certainly true as well, and would be a problem, so too
much should be avoided.

> > On the other hand, use of this particular USB wifi card is probably
> > not so common these days so relatively few people would notice at all.
> > Tough! I guess I'll submit a module parameter based v2 of the patch
> > later today, just as Larry suggested!
> 
> Also remember to add a prefix to the title:
> 
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#subject

Another helpful hint! Thanks, will keep that in mind for the next
submission! :-)

> >> 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?
> >
> > Of course, if someone has other hw, more testing would be nice! Any
> > situation where the card is supposed to receive multicast frames
> > should be suitable as a test case - in my case, just connecting to my
> > local network and expecting to see the card pick up RAs and acquire an
> > IPv6 address is the easiest test case. This works nicely on several
> > other machines with completely different wifi hardware as well as
> > wired machines, but fails without the fix on the rtl8187b. It would,
> > for example, be interesting to see if a non-b 8187 behaves the same or
> > if things work there out of the box.
> 
> I'm not familiar with the driver so when you say "non-b 8187" what do
> you mean exactly? What kind of hardware are we talking about? How many
> different hardware versions are there that this patch affects? Is the
> firmware/hardware really so different that the chances are high that
> this breaks something?

The driver in question seems to apply to, all in all, 21 different usb
ids, so 21 different USB wifi cards. The existing code classifies
these into two different categories: rtl8187 and rtl8187b, which seem
to be different versions / revisions of a realtek usb wifi chip.
Depending on this classification - if a card is a rtl8187 or rtl8187b
- the existing code does things a bit different in several cases, for
example during initialization of the card (however, not during the
routine that sets the filters and where I've made my changes).

The card I have here and on which I noticed the problem and verified
the fix is one that the driver classifies as rtl8187b. All such
classified cards should use the same chip and thus likely behave the
same regarding the problem and fix. But as far as those cards
classified as rtl8187 are concerned, I don't have an idea how they
behave in practice. All I know is that my current patch would change
behavior on them as well.

If this sounds good to Larry, too, I might in fact - instead of using
a module parameter - change the patch in such a way that it only
changes behavior on cards classified as rtl8187b, which should behave
like mine and thus benefit from the change, and leave the code
affecting rtl8187 cards, which I honestly cannot say anything about,
alone. Probably sounds like a safer thing to do.

Greetings
Nils

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

2017-02-19 Thread Erik Stromdahl


Ok, I'll do another round of checkpatch before I submit anything.
I couldn't find the script you mentioned though (ath10k-check).
Is it some kind of checkpatch wrapper?

Anyway, I have a few warnings related to 'line over 80 chars' that
is really hard to get rid of (without breaking indentation etc.) so
I won't do anything about those for now.

Then there are some other warnings about the BIT macro being preferred
over (1 << x). I have used (1 << x) in some files despite the checkpatch
warning in order to keep the patches consistent with the existing code.
I think the best approach is to have a separate round of cleanup-patches
replacing all (1 << x) with BIT(x).

--
Erik

On 2017-02-19 14:59, Valo, Kalle wrote:

Kalle Valo  writes:


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.


Forgot to mention can you run ath10k-check before submitting them, it
shows few problems:

https://wireless.wiki.kernel.org/en/users/drivers/ath10k/codingstyle#checking_code

But if you wonder what this is about it's checkpatch warning about camel
case (doesn't like the lower case x character):

drivers/net/wireless/ath/ath10k/sdio.h:68: 

I guess I have a bug in the script when it parses checkpatch output.

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

2017-02-19 Thread Valo, Kalle

Erik Stromdahl  writes:

> I just noticed that Ryan Hsu submitted two patches containing similar
> functionality to what I have in my tree on github. They have not been
> integrated in the ath master yet, but they have been added to master-pending.
>
> Below are the commits I am talking about
>
> bc1054a15be3c962c83aa22476a3e9c1266da792 ath10k: improve the firmware
> download time for QCA9377
> db5af2a25bd8c1410ec4456d1d4f4e6ded2649ca ath10k: improve the firmware
> download time for QCA6174
>
> Since some of my patches overlap with these I think it would be best if
> I add these to my tree and rewrite my patches.
>
> If they haven't made it into master before I submit my updated patch series
> I will include them in my set.
>
> Is this OK?
>
> If they will be added to master soon there is no issue since I will of course
> rebase to the latest ath-MMDDHHmm before I submit anything.

That's ok, just mention this in the cover letter.

Even better is that if you can use master-pending from ath.git as the
baseline (compared to the master branch normally recommended), Ryan's
patches are there now. That way you don't need to apply anything extra
to your tree. But I'm hoping to apply Ryan's patches soon anyway.

-- 
Kalle Valo

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

2017-02-19 Thread Erik Stromdahl


Hej,

I just noticed that Ryan Hsu submitted two patches containing similar
functionality to what I have in my tree on github. They have not been
integrated in the ath master yet, but they have been added to master-pending.

Below are the commits I am talking about

bc1054a15be3c962c83aa22476a3e9c1266da792 ath10k: improve the firmware download 
time for QCA9377
db5af2a25bd8c1410ec4456d1d4f4e6ded2649ca ath10k: improve the firmware download 
time for QCA6174

Since some of my patches overlap with these I think it would be best if
I add these to my tree and rewrite my patches.

If they haven't made it into master before I submit my updated patch series
I will include them in my set.

Is this OK?

If they will be added to master soon there is no issue since I will of course
rebase to the latest ath-MMDDHHmm before I submit anything.

/Erik

On 2017-02-19 00:57, Valo, Kalle wrote:

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.

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

2017-02-19 Thread Valo, Kalle

Kalle Valo  writes:

> 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.

Forgot to mention can you run ath10k-check before submitting them, it
shows few problems:

https://wireless.wiki.kernel.org/en/users/drivers/ath10k/codingstyle#checking_code

But if you wonder what this is about it's checkpatch warning about camel
case (doesn't like the lower case x character):

drivers/net/wireless/ath/ath10k/sdio.h:68: 

I guess I have a bug in the script when it parses checkpatch output.

-- 
Kalle Valo

Re: [PATCH] Fix rtl8187 multicast reception

2017-02-19 Thread Kalle Valo

Nils Holland  writes:

> On Sun, Feb 19, 2017 at 09:46:16AM +0200, Kalle Valo wrote:
>> Larry Finger  writes:
>> 
>> > On 02/18/2017 07:35 PM, Nils Holland wrote:
>> >
>> > 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.
>
> Well, this is a tough question, I have to admit that I have a somewhat
> weird feeling making a change that also applies to other hardware that
> I cannot test on, so I don't know about any negative consequences that
> might arise there, especially when the change isn't based on some
> official information from some documentation, but rather a result of
> trial & error. So I can fully understand Larry's concerns and do in
> fact think that a module parameter could be a nice solution, so that
> by default the behavior if the driver does not change.

There are lots of hardware variations that cannot be tested when a patch
is commited. If we followed the same methdology with all patches we
would have thousands of module parameters in kernel in no time :)

> From an end-user standpoint, it's probably always worse to see
> something break which has always worked before than it is to have
> something not work properly right from the start, but being able to
> easily find some parameter to fix this.

Sure. But if there's a report about this patch breaking something, it's
easy to revert it.

> On the other hand, use of this particular USB wifi card is probably
> not so common these days so relatively few people would notice at all.
> Tough! I guess I'll submit a module parameter based v2 of the patch
> later today, just as Larry suggested!

Also remember to add a prefix to the title:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#subject

>> 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?
>
> Of course, if someone has other hw, more testing would be nice! Any
> situation where the card is supposed to receive multicast frames
> should be suitable as a test case - in my case, just connecting to my
> local network and expecting to see the card pick up RAs and acquire an
> IPv6 address is the easiest test case. This works nicely on several
> other machines with completely different wifi hardware as well as
> wired machines, but fails without the fix on the rtl8187b. It would,
> for example, be interesting to see if a non-b 8187 behaves the same or
> if things work there out of the box.

I'm not familiar with the driver so when you say "non-b 8187" what do
you mean exactly? What kind of hardware are we talking about? How many
different hardware versions are there that this patch affects? Is the
firmware/hardware really so different that the chances are high that
this breaks something?

> In that case, instead of doing a module parameter, I could also change
> the fix so that it only does something different on the b-variants of
> the card and doesn't change behavior at all on non-b.

Now that's much better option than adding a module parameter.

-- 
Kalle Valo

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

2017-02-19 Thread Erik Stromdahl


Hej,

I just noticed that Ryan Hsu submitted two patches containing similar
functionality to what I have in my tree on github. They have not been
integrated in the ath master yet, but they have been added to master-pending.

Below are the commits I am talking about

bc1054a15be3c962c83aa22476a3e9c1266da792 ath10k: improve the firmware download 
time for QCA9377
db5af2a25bd8c1410ec4456d1d4f4e6ded2649ca ath10k: improve the firmware download 
time for QCA6174

Since some of my patches overlap with these I think it would be best if
I add these to my tree and rewrite my patches.

If they haven't made it into master before I submit my updated patch series
I will include them in my set.

Is this OK?

If they will be added to master soon there is no issue since I will of course
rebase to the latest ath-MMDDHHmm before I submit anything.

/Erik

On 2017-02-19 00:57, Valo, Kalle wrote:

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.

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

2017-02-19 Thread Ryan Mounce

Australian regulations differ from most of Europe, the USA and even
New Zealand (which shares AS/NZS 4268) in that any unlicensed
operation between 5600-5650MHz is prohibited outright, rather than
being allowed after an extended DFS channel availability check.

The situation appears to be similar in Canada, the regdb has
previously been amended to reflect this.

https://git.kernel.org/cgit/linux/kernel/git/sforshee/wireless-regdb.git/commit/db.txt?id=ce7697d3def48f87427b3a3c285b46241af3b79d

On 19 February 2017 at 22:46, Sebastian Gottschall
 wrote:
> Am 19.02.2017 um 01:01 schrieb 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.
>
> thats the case for all countries, so this couldnt be a argument. dfs should
> handle this
>
>>
>> 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
>>>
>
>
> --
> 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: [PATCH] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules

2017-02-19 Thread Sebastian Gottschall


Am 19.02.2017 um 01:01 schrieb 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.
thats the case for all countries, so this couldnt be a argument. dfs 
should handle this


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




--
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

[PATCH] NFC: st21nfca: Fix potential memory leak

2017-02-19 Thread Christophe JAILLET

If all bits of 'dev_mask' are already set, there is a memory leak because
'info' should be freed before returning.

While fixing it, 'return -ENOMEM' directly if the first kzalloc fails.
This makes the code more readable.

Signed-off-by: Christophe JAILLET 
---
 drivers/nfc/st21nfca/core.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/nfc/st21nfca/core.c b/drivers/nfc/st21nfca/core.c
index dacb9166081b..50be3b788f1c 100644
--- a/drivers/nfc/st21nfca/core.c
+++ b/drivers/nfc/st21nfca/core.c
@@ -959,10 +959,8 @@ int st21nfca_hci_probe(void *phy_id, struct nfc_phy_ops 
*phy_ops,
unsigned long quirks = 0;
 
info = kzalloc(sizeof(struct st21nfca_hci_info), GFP_KERNEL);
-   if (!info) {
-   r = -ENOMEM;
-   goto err_alloc_hdev;
-   }
+   if (!info)
+   return -ENOMEM;
 
info->phy_ops = phy_ops;
info->phy_id = phy_id;
@@ -978,8 +976,10 @@ int st21nfca_hci_probe(void *phy_id, struct nfc_phy_ops 
*phy_ops,
 * persistent info to discriminate 2 identical chips
 */
dev_num = find_first_zero_bit(dev_mask, ST21NFCA_NUM_DEVICES);
-   if (dev_num >= ST21NFCA_NUM_DEVICES)
-   return -ENODEV;
+   if (dev_num >= ST21NFCA_NUM_DEVICES) {
+   r = -ENODEV;
+   goto err_alloc_hdev;
+   }
 
set_bit(dev_num, dev_mask);
 
-- 
2.9.3

RE: [RFC 2/5] iwlwifi: fix request_module() use

2017-02-19 Thread Grumbach, Emmanuel

> 
> The return value of request_module() being 0 does not mean that the driver
> which was requested has loaded. To properly check that the driver was
> loaded each driver can use internal mechanisms to vet the driver is now
> present. The helper try_then_request_module() was added to help with
> this, allowing drivers to specify their own validation as the first argument.
> 
> On iwlwifi the use case is a bit more complicated given that the value we
> need to check for is protected with a mutex later used on the
> module_init() of the module we are asking for. If we were to lock and
> request_module() we'd deadlock. iwlwifi needs its own wrapper then so it
> can handle its special locking requirements.
> 
> Signed-off-by: Luis R. Rodriguez 

I don't see the problem with the current code. We don't assume that everything 
has been
loaded immediately after request_module returns. We just free the intermediate 
firmware
structures that won't be using anymore. What happens here is that after 
request_module
returns, we patiently wait until it is loaded, and when that happens, 
iwl{d,m}vm's init function
will be called. That one is the one that continues the flow by calling:

ret = iwl_opmode_register("iwlmvm", _mvm_ops);

(for the iwlmvm case).

Where am I wrong here?


> ---
>  drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 34 ---
> -
>  1 file changed, 25 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> index e198d6f5fcea..6beb92d19ea7 100644
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> @@ -1231,6 +1231,29 @@ static void _iwl_op_mode_stop(struct iwl_drv
> *drv)
>   }
>  }
> 
> +static void iwlwifi_try_load_op(struct iwlwifi_opmode_table *op,
> + struct iwl_drv *drv)
> +{
> + int ret = 0;
> +
> + ret = request_module("%s", op->name);
> + if (ret)
> + goto out;
> +
> + mutex_lock(_opmode_table_mtx);
> + if (!op->ops)
> + ret = -ENOENT;
> + mutex_unlock(_opmode_table_mtx);
> +
> +out:
> +#ifdef CONFIG_IWLWIFI_OPMODE_MODULAR
> + if (ret)
> + IWL_ERR(drv,
> + "failed to load module %s (error %d), is dynamic
> loading enabled?\n",
> + op->name, ret);
> +#endif
> +}
> +
>  /**
>   * iwl_req_fw_callback - callback when firmware was loaded
>   *
> @@ -1471,15 +1494,8 @@ static void iwl_req_fw_callback(const struct
> firmware *ucode_raw, void *context)
>* else from proceeding if the module fails to load
>* or hangs loading.
>*/
> - if (load_module) {
> - err = request_module("%s", op->name);
> -#ifdef CONFIG_IWLWIFI_OPMODE_MODULAR
> - if (err)
> - IWL_ERR(drv,
> - "failed to load module %s (error %d), is
> dynamic loading enabled?\n",
> - op->name, err);
> -#endif
> - }
> + if (load_module)
> + iwlwifi_try_load_op(op, drv);
>   goto free;
> 
>   try_again:
> --
> 2.11.0

Re: [PATCH] Fix rtl8187 multicast reception

2017-02-19 Thread Nils Holland

On Sun, Feb 19, 2017 at 09:46:16AM +0200, Kalle Valo wrote:
> 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.

Thanks for the hint, I'll do that better the next time! :-)

> > 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.

Well, this is a tough question, I have to admit that I have a somewhat
weird feeling making a change that also applies to other hardware that
I cannot test on, so I don't know about any negative consequences that
might arise there, especially when the change isn't based on some
official information from some documentation, but rather a result of
trial & error. So I can fully understand Larry's concerns and do in
fact think that a module parameter could be a nice solution, so that
by default the behavior if the driver does not change. From an
end-user standpoint, it's probably always worse to see something break
which has always worked before than it is to have something not work
properly right from the start, but being able to easily find some
parameter to fix this. On the other hand, use of this particular USB
wifi card is probably not so common these days so relatively few
people would notice at all. Tough! I guess I'll submit a module
parameter based v2 of the patch later today, just as Larry suggested!

> 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?

Of course, if someone has other hw, more testing would be nice! Any
situation where the card is supposed to receive multicast frames
should be suitable as a test case - in my case, just connecting to my
local network and expecting to see the card pick up RAs and acquire an
IPv6 address is the easiest test case. This works nicely on several
other machines with completely different wifi hardware as well as
wired machines, but fails without the fix on the rtl8187b. It would,
for example, be interesting to see if a non-b 8187 behaves the same or
if things work there out of the box. In that case, instead of doing a
module parameter, I could also change the fix so that it only does
something different on the b-variants of the card and doesn't change
behavior at all on non-b.

Greetings
Nils

RE: [RFC 1/5] iwlwifi: fix drv cleanup on opmode registration failure

2017-02-19 Thread Grumbach, Emmanuel

Hi Luis,

> 
> The firmware async callback handles the device's opmode start call, but
> optionally also allows opmode registration to take care of its opmode start. 
> If
> the firmware callback handles it its error path in case of opmode start 
> failure
> has a few pieces of code missing from the opmode registration. The opmode
> registration hanlder has no cleanup at all. Sync both error paths.
> 
> This should in theory fix a detangled drv from the drv list should either of 
> the
> opmode modules loaded and handled registration for the drv.
> 
> The path of having the opmode registration deal with the drv opmode start is
> actually the more common path. The other path, from the async callback is
> rathe rare (1/8 or so times for me) -- it happens when the the opmode
> driver's init routine completed prior to the driver's async callback opmode
> start call.

I'd claim it should never happen unless you have several devices on the system 
using the same
opmode, or unless you do:
modprobe iwlwifi  #which will load iwl{d,m}vm
rmmod iwl{d,m}vm #and do _not_ remove iwlwifi
modprobe iwlwifi



> 
> Signed-off-by: Luis R. Rodriguez 
> ---

Luca is OOO,  but this looks fine to me.


>  drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> index be466a074c1d..e198d6f5fcea 100644
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> @@ -1611,8 +1611,13 @@ int iwl_opmode_register(const char *name, const
> struct iwl_op_mode_ops *ops)
>   continue;
>   op->ops = ops;
>   /* TODO: need to handle exceptional case */
> - list_for_each_entry(drv, >drv, list)
> + list_for_each_entry(drv, >drv, list) {
>   drv->op_mode = _iwl_op_mode_start(drv, op);
> + if (!drv->op_mode) {
> + complete(
> >request_firmware_complete);
> + device_release_driver(drv->trans->dev);
> + }
> + }
> 
>   mutex_unlock(_opmode_table_mtx);
>   return 0;
> --
> 2.11.0

Re: brcmfmac: BCM4343A0 P2P mode problem

2017-02-19 Thread Stefan Holzmann

Thank you for your support. Yes, correct SDIO 0xA9A6 is BCM43430 I was confused 
by the naming of some firmware files.

What firmware version/file shall be used for this chipset/driver combination?
Currently I'am using the firmware file "fw_bcm43438a0_p2p.bin" from here 
https://github.com/BPI-SINOVOIP/BPI_WiFi_Firmware/tree/master/ap6212.

I have set the driver parameter "use_p2p_group_interface=1" as you recommended, 
and now I see following error messages at the kernel log when I try to setup a 
P2P connection.

[   59.593565] brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 
0x40012
[   62.163452] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[   62.169542] brcmfmac: brcmf_sdio_checkdied: firmware trap in dongle
[   62.175839] brcmfmac: brcmf_cfg80211_add_iface: add iface p2p-wlan0-0 type 8 
failed: err=-110

Re: [PATCH v2] rtl8187: Enable monitor mode to fix multicast reception

Re: [PATCH] ath10k: Update available channel list for 5G radio

Re: [PATCH] ath10k: Update available channel list for 5G radio

Re: [PATCH] Make EN2 pin optional in the TRF7970A driver

[PATCH] ath10k: Update available channel list for 5G radio

RE: [PATCHv2] ath10k: Update available channel list for 5G radio

[PATCHv2] ath10k: Update available channel list for 5G radio

Re: [PATCH v2] rtl8187: Enable monitor mode to fix multicast reception

[PATCH v2] rtl8187: Enable monitor mode to fix multicast reception

Re: [PATCH] Fix rtl8187 multicast reception

RE: brcmfmac: BCM4343A0 P2P mode problem

Re: brcmfmac: BCM4343A0 P2P mode problem

Re: brcmfmac: BCM4343A0 P2P mode problem

Re: [PATCH] Fix rtl8187 multicast reception

Re: [PATCH] Fix rtl8187 multicast reception

[PATCH] wcn36xx: Fix error handling

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

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

Re: [PATCH] Fix rtl8187 multicast reception

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

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

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

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

Re: [PATCH] Fix rtl8187 multicast reception

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

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

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

[PATCH] NFC: st21nfca: Fix potential memory leak

RE: [RFC 2/5] iwlwifi: fix request_module() use

Re: [PATCH] Fix rtl8187 multicast reception

RE: [RFC 1/5] iwlwifi: fix drv cleanup on opmode registration failure

Re: brcmfmac: BCM4343A0 P2P mode problem

32 matches

Site Navigation

Mail list logo

Footer information