Re: [PATCH 33/35] wireless: realtek: rtl8192cu: constify usb_device_id

[Larry Finger]

On 08/08/2017 11:05 AM, Arvind Yadav wrote:

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---


Acked-by: Larry Finger 

Thanks,

Larry


  drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
index 96c923b..e673bc2 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
@@ -275,7 +275,7 @@ static struct rtl_hal_cfg rtl92cu_hal_cfg = {
  #define USB_VENDER_ID_REALTEK 0x0bda
  
  /* 2010-10-19 DID_USB_V3.4 */

-static struct usb_device_id rtl8192c_usb_ids[] = {
+static const struct usb_device_id rtl8192c_usb_ids[] = {
  
  	/*=== Realtek demoboard ===*/

/* Default ID */

[PATCH] mwifiex: uap: enable 11d based on userspace configruation

[Xinming Hu]

From: Xinming Hu 

This patch check whether userspace beacon data include country
ie, if so then download command to enable 11d setup in firmeare
accordingly.

Signed-off-by: Xinming Hu 
Signed-off-by: Cathy Luo 
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c |  2 ++
 drivers/net/wireless/marvell/mwifiex/main.h |  3 +++
 drivers/net/wireless/marvell/mwifiex/uap_cmd.c  | 34 -
 3 files changed, 27 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index c4382d0..2aa5adc 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -2018,6 +2018,8 @@ static int mwifiex_cfg80211_start_ap(struct wiphy *wiphy,
priv->state_11h.is_11h_active = false;
}
 
+   mwifiex_config_uap_11d(priv, >beacon);
+
if (mwifiex_config_start_uap(priv, bss_cfg)) {
mwifiex_dbg(priv->adapter, ERROR,
"Failed to start AP\n");
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index 84be38e..ee8876a 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1565,6 +1565,9 @@ int mwifiex_config_start_uap(struct mwifiex_private *priv,
 void mwifiex_uap_del_sta_data(struct mwifiex_private *priv,
  struct mwifiex_sta_node *node);
 
+void mwifiex_config_uap_11d(struct mwifiex_private *priv,
+   struct cfg80211_beacon_data *beacon_data);
+
 void mwifiex_init_11h_params(struct mwifiex_private *priv);
 int mwifiex_is_11h_active(struct mwifiex_private *priv);
 int mwifiex_11h_activate(struct mwifiex_private *priv, bool flag);
diff --git a/drivers/net/wireless/marvell/mwifiex/uap_cmd.c 
b/drivers/net/wireless/marvell/mwifiex/uap_cmd.c
index 477c29c..18f7d9b 100644
--- a/drivers/net/wireless/marvell/mwifiex/uap_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/uap_cmd.c
@@ -444,6 +444,28 @@ void mwifiex_set_sys_config_invalid_data(struct 
mwifiex_uap_bss_param *config)
return;
 }
 
+/* This function enable 11D if userspace set the country IE.
+ */
+void mwifiex_config_uap_11d(struct mwifiex_private *priv,
+   struct cfg80211_beacon_data *beacon_data)
+{
+   enum state_11d_t state_11d;
+   const u8 *country_ie;
+
+   country_ie = cfg80211_find_ie(WLAN_EID_COUNTRY, beacon_data->tail,
+ beacon_data->tail_len);
+   if (country_ie) {
+   /* Send cmd to FW to enable 11D function */
+   state_11d = ENABLE_11D;
+   if (mwifiex_send_cmd(priv, HostCmd_CMD_802_11_SNMP_MIB,
+HostCmd_ACT_GEN_SET, DOT11D_I,
+_11d, true)) {
+   mwifiex_dbg(priv->adapter, ERROR,
+   "11D: failed to enable 11D\n");
+   }
+   }
+}
+
 /* This function parses BSS related parameters from structure
  * and prepares TLVs. These TLVs are appended to command buffer.
 */
@@ -848,8 +870,6 @@ void mwifiex_uap_set_channel(struct mwifiex_private *priv,
 int mwifiex_config_start_uap(struct mwifiex_private *priv,
 struct mwifiex_uap_bss_param *bss_cfg)
 {
-   enum state_11d_t state_11d;
-
if (mwifiex_send_cmd(priv, HostCmd_CMD_UAP_SYS_CONFIG,
 HostCmd_ACT_GEN_SET,
 UAP_BSS_PARAMS_I, bss_cfg, true)) {
@@ -858,16 +878,6 @@ int mwifiex_config_start_uap(struct mwifiex_private *priv,
return -1;
}
 
-   /* Send cmd to FW to enable 11D function */
-   state_11d = ENABLE_11D;
-   if (mwifiex_send_cmd(priv, HostCmd_CMD_802_11_SNMP_MIB,
-HostCmd_ACT_GEN_SET, DOT11D_I,
-_11d, true)) {
-   mwifiex_dbg(priv->adapter, ERROR,
-   "11D: failed to enable 11D\n");
-   return -1;
-   }
-
if (mwifiex_send_cmd(priv, HostCmd_CMD_UAP_BSS_START,
 HostCmd_ACT_GEN_SET, 0, NULL, true)) {
mwifiex_dbg(priv->adapter, ERROR,
-- 
1.9.1

Re: wireless drivers fail to report link speed?

[Dan Williams]

On Tue, 2017-08-08 at 16:25 -0600, James Feeney wrote:
> Hey Dan
> 
> > ...
> > So one second the wifi might be the "best" link and then when
> > somebody
> > turns on a microwave oven or a baby monitor, it may be the "worst"
> > until the microwave's duty cycle completes a few seconds later then
> > it'll become the "best" again for a couple seconds then "worst"
> > again,
> > repeat until your Easy Mac is nice and warm and creamy.
> > 
> > Furthermore, for some drivers IIRC when there isn't any traffic,
> > they
> > might drop the link rate very low because there's no reason keep
> > powering blocks when you're not transmitting/receiving any
> > data.  IIRC
> > the Intel drivers used to do that a couple years ago.
> 
> Yes, thanks, but, while all of that is true, it has nothing to do
> with the
> question asked.

It's very relevant to the question.  Because if the speed is actually
not useful for the requested purpose, there is no real point in having
it reported it via ethtool.  Same for duplex.  Wifi is only "half
duplex", and so the property is actually meaningless for WiFi.

The bonding driver is requiring completely irrelevant information, or
at least information that simply doesn't make sense for some
communication mechanisms.  There's no way the bonding driver can make a
useful decision if the speed *intentionally* changes regularly.  At
worst, your bonding link will flip-flop between slaves every second or
two.  At best, bonding won't do anything differently than if the speed
was just faked to some fake lowest common denominator number so that
your wired link was always faster.

Sure, somebody could do a patch (like Ben has) that plumbs all this
stuff through.  But that's not solving the *actual* problem, which is
that this bonding change makes assumptions of slave devices that simply
don't match how those devices work.

Dan

> The question is, regardless that the wireless speed may be constantly
> changing,
> why is it that the kernel ethtool returns an error on get_settings(),
> instead of
> returning the current wireless speed, whatever that link speed might
> be at the
> moment?
> 
> > Also, "duplex" doesn't mean anything in wireless land.  So no clue
> > what
> > bonding is expecting them to say here.  I would say the
> > modifications
> > to the bonding core made assumptions that simply aren't applicable
> > to
> > mediums other than wired ones.
> 
> Since, as Ben mentions,
> 
> > Well, wifi acts half-duplex in that only one side can transmit at
> > once.
> 
> then the wireless drivers would be expected to simply report "half-
> duplex".
> 
> Again, the issue is not that wireless is half-duplex or full-duplex,
> but rather,
> why does the kernel ethtool return an error on get_settings()?
> 
> And, why is it that it seems get_settings() returns an error with
> multiple
> wireless drivers?  Is there some assumption, or convention, that
> causes the
> kernel ethtool to fail with *all* the wireless drivers?
> 
> I see that, on bugzilla, Florian is suggesting that wireless network
> devices
> *cannot* report a speed/duplex, simply because the wireless speed
> changes on a
> per-packet basis, but that does not seem to me to be a persuasive
> argument.  A
> wireless connection *does* always have a current speed, even if that
> speed
> changes frequently.  The kernel ethtool get_settings() should simply
> report that
> speed, not throw an error, yes?
> 
> 
> Thanks
> James
> 

Re: wireless drivers fail to report link speed?

[James Feeney]

Hey Dan

> ...
> So one second the wifi might be the "best" link and then when somebody
> turns on a microwave oven or a baby monitor, it may be the "worst"
> until the microwave's duty cycle completes a few seconds later then
> it'll become the "best" again for a couple seconds then "worst" again,
> repeat until your Easy Mac is nice and warm and creamy.
> 
> Furthermore, for some drivers IIRC when there isn't any traffic, they
> might drop the link rate very low because there's no reason keep
> powering blocks when you're not transmitting/receiving any data.  IIRC
> the Intel drivers used to do that a couple years ago.

Yes, thanks, but, while all of that is true, it has nothing to do with the
question asked.

The question is, regardless that the wireless speed may be constantly changing,
why is it that the kernel ethtool returns an error on get_settings(), instead of
returning the current wireless speed, whatever that link speed might be at the
moment?

> Also, "duplex" doesn't mean anything in wireless land.  So no clue what
> bonding is expecting them to say here.  I would say the modifications
> to the bonding core made assumptions that simply aren't applicable to
> mediums other than wired ones.

Since, as Ben mentions,

> Well, wifi acts half-duplex in that only one side can transmit at once.

then the wireless drivers would be expected to simply report "half-duplex".

Again, the issue is not that wireless is half-duplex or full-duplex, but rather,
why does the kernel ethtool return an error on get_settings()?

And, why is it that it seems get_settings() returns an error with multiple
wireless drivers?  Is there some assumption, or convention, that causes the
kernel ethtool to fail with *all* the wireless drivers?

I see that, on bugzilla, Florian is suggesting that wireless network devices
*cannot* report a speed/duplex, simply because the wireless speed changes on a
per-packet basis, but that does not seem to me to be a persuasive argument.  A
wireless connection *does* always have a current speed, even if that speed
changes frequently.  The kernel ethtool get_settings() should simply report that
speed, not throw an error, yes?


Thanks
James

Re: wireless drivers fail to report link speed?

[Dan Williams]

On Tue, 2017-08-08 at 13:07 -0600, James Feeney wrote:
> Hello All
> 
> Would you please look at kernel bug report "Since 4.12 - bonding
> module not
> working with wireless drivers", and tell me if you know why the
> kernel ethtool
> does not receive a speed report from the wireless drivers?
> 
>  https://bugzilla.kernel.org/show_bug.cgi?id=196547
> 
> It seems that Mahesh Bandewar became annoyed that some network
> drivers do not
> report speed and duplex to the bonding module properly, so that it
> becomes
> impossible to make "best connection" decisions.  A patch was applied
> to the
> bonding module in linux 4.12 which now disables any network interface
> that does
> not successfully report its speed and duplex.  In practice, this
> seems to
> include every wireless network driver I've tried, the ath5k, ath9k,
> the
> rtl8192ce and RTL8188CUS.  Of course, this new behavior breaks
> wireless bonding!
> 
> Do you know if there is some general reason why the wireless drivers
> do not work
> with the kernel ethtool?  Is this something that can be fixed?  Can
> you tell if
> this reporting failure would be the fault of the kernel ethtool?  Or
> the
> wireless driver?  Or the bonding module?

Because the "speed" (whatever that means) can and sometimes does change
with every packet.  The driver dynamically adjusts the link rate based
on all kinds of things.  But mainly the current radio environment; how
many other APs are around, how much interference there is, how many
other clients are trying to talk, that kind of thing.

So one second the wifi might be the "best" link and then when somebody
turns on a microwave oven or a baby monitor, it may be the "worst"
until the microwave's duty cycle completes a few seconds later then
it'll become the "best" again for a couple seconds then "worst" again,
repeat until your Easy Mac is nice and warm and creamy.

Furthermore, for some drivers IIRC when there isn't any traffic, they
might drop the link rate very low because there's no reason keep
powering blocks when you're not transmitting/receiving any data.  IIRC
the Intel drivers used to do that a couple years ago.

Also, "duplex" doesn't mean anything in wireless land.  So no clue what
bonding is expecting them to say here.  I would say the modifications
to the bonding core made assumptions that simply aren't applicable to
mediums other than wired ones.

Dan

Re: [PATCH v4 10/10] wil6210: make debugfs compilation optional

[Kalle Valo]

Lior David  writes:

> On 8/8/2017 2:03 PM, Kalle Valo wrote:
>> Maya Erez  writes:
>> 
>>> From: Gidon Studinski 
>>>
>>> Since debugfs is a kernel configuration option, enable the driver to
>>> compile without debugfs.
>>>
>>> Signed-off-by: Gidon Studinski 
>>> Signed-off-by: Maya Erez 

[...]

>>> +#if defined(CONFIG_DEBUG_FS)
>>>  int wil6210_debugfs_init(struct wil6210_priv *wil);
>>>  void wil6210_debugfs_remove(struct wil6210_priv *wil);
>>> +#else
>>> +static inline int wil6210_debugfs_init(struct wil6210_priv *wil) { return 
>>> 0; }
>>> +static inline void wil6210_debugfs_remove(struct wil6210_priv *wil) {}
>>> +#endif
>> 
>> I was thinking more that should we have CONFIG_WIL6210_DEBUGFS, just
>> like we have CONFIG_ATH10K_DEBUGFS and CONFIG_ATH9K_DEBUGFS? This way it
>> can be controlled per driver if debugfs interface is available or not.
>> 
> Hi Kalle, I am answering instead of Maya, she is currently on holiday.
> We will consider this and resend the patch.

Ok, no rush.

> Is it possible to apply the other patches in the v4 series except this one and
> patch #2 (the scan timeout module parameter)?

I was actually planning to do exactly that. I was just waiting for
kbuild bot results because I had to fix a trivial conflict after
removing patch 2.

-- 
Kalle Valo

RTS threshold not being obeyed

[Jacobo Pantoja]

Hi,

I'm having a hard time to figure out why RTS/CTS are happening in my network.
In a nutshell, I'm using two identical OpenWRT routers to stablish a
WDS link (4address mode) in 5GHz, with no other client nor AP in 5GHz.
The problem is, a great amount of bandwidth is being consumed by
RTS/CTSs.

The point is, I'm pretty sure RTS threshold is disabled (set to -1);
I've checked in hostapd configuration, as well as in the debugfs of
the phy itself, being reported as -1.

The device in question is TPLINK WDR4300, radio device AR9582
(168c:0033, subsystem 168c:a120), using driver ath9k. I'm using
current LEDE 17.01.2, r3435-65eec8bd5f, kernel 4.4.71.

I'm able to see RTS/CTS over the air (using Wireshark in a third
device), but i can as well see an increasing number in
/sys/kernel/debug/ieee80211/phy1/statistics/dot11RTSSuccessCount
If I set RTS threshold (using iw, checking its value in debugfs) to a
very low number (e.g. 50) I can see the counter increasing quite
faster.

I'm not sure if this is the expected behaviour (e.g. the underlying
hardware is deciding by its own to do some RTS/CTS) or it is a bug.

Can I make some further testing to clarify this?

Thanks!
JPantoja

Re: [PATCH v4 10/10] wil6210: make debugfs compilation optional

[Lior David]

On 8/8/2017 2:03 PM, Kalle Valo wrote:
> Maya Erez  writes:
> 
>> From: Gidon Studinski 
>>
>> Since debugfs is a kernel configuration option, enable the driver to
>> compile without debugfs.
>>
>> Signed-off-by: Gidon Studinski 
>> Signed-off-by: Maya Erez 
>> ---
>>  drivers/net/wireless/ath/wil6210/Makefile  | 2 +-
>>  drivers/net/wireless/ath/wil6210/wil6210.h | 6 ++
>>  2 files changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ath/wil6210/Makefile 
>> b/drivers/net/wireless/ath/wil6210/Makefile
>> index 4ae21da..63a751a 100644
>> --- a/drivers/net/wireless/ath/wil6210/Makefile
>> +++ b/drivers/net/wireless/ath/wil6210/Makefile
>> @@ -4,7 +4,7 @@ wil6210-y := main.o
>>  wil6210-y += netdev.o
>>  wil6210-y += cfg80211.o
>>  wil6210-y += pcie_bus.o
>> -wil6210-y += debugfs.o
>> +wil6210-$(CONFIG_DEBUG_FS) += debugfs.o
>>  wil6210-y += wmi.o
>>  wil6210-y += interrupt.o
>>  wil6210-y += txrx.o
>> diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h 
>> b/drivers/net/wireless/ath/wil6210/wil6210.h
>> index cf20a8c..d7b1e03 100644
>> --- a/drivers/net/wireless/ath/wil6210/wil6210.h
>> +++ b/drivers/net/wireless/ath/wil6210/wil6210.h
>> @@ -940,8 +940,14 @@ int wil_cfg80211_mgmt_tx(struct wiphy *wiphy, struct 
>> wireless_dev *wdev,
>>   struct cfg80211_mgmt_tx_params *params,
>>   u64 *cookie);
>>  
>> +#if defined(CONFIG_DEBUG_FS)
>>  int wil6210_debugfs_init(struct wil6210_priv *wil);
>>  void wil6210_debugfs_remove(struct wil6210_priv *wil);
>> +#else
>> +static inline int wil6210_debugfs_init(struct wil6210_priv *wil) { return 
>> 0; }
>> +static inline void wil6210_debugfs_remove(struct wil6210_priv *wil) {}
>> +#endif
> 
> I was thinking more that should we have CONFIG_WIL6210_DEBUGFS, just
> like we have CONFIG_ATH10K_DEBUGFS and CONFIG_ATH9K_DEBUGFS? This way it
> can be controlled per driver if debugfs interface is available or not.
> 
Hi Kalle, I am answering instead of Maya, she is currently on holiday.
We will consider this and resend the patch.
Is it possible to apply the other patches in the v4 series except this one and
patch #2 (the scan timeout module parameter)?

Thanks,
Lior

[PATCH 22/35] wireless: intersil: orinoco: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/intersil/orinoco/orinoco_usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intersil/orinoco/orinoco_usb.c 
b/drivers/net/wireless/intersil/orinoco/orinoco_usb.c
index c84fd84..56f6e3b 100644
--- a/drivers/net/wireless/intersil/orinoco/orinoco_usb.c
+++ b/drivers/net/wireless/intersil/orinoco/orinoco_usb.c
@@ -210,7 +210,7 @@ struct ezusb_packet {
 } __packed;
 
 /* Table of devices that work or may work with this driver */
-static struct usb_device_id ezusb_table[] = {
+static const struct usb_device_id ezusb_table[] = {
{USB_DEVICE(USB_COMPAQ_VENDOR_ID, USB_COMPAQ_WL215_ID)},
{USB_DEVICE(USB_COMPAQ_VENDOR_ID, USB_HP_WL215_ID)},
{USB_DEVICE(USB_COMPAQ_VENDOR_ID, USB_COMPAQ_W200_ID)},
-- 
2.7.4

[PATCH 23/35] wireless: intersil: p54: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/intersil/p54/p54usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intersil/p54/p54usb.c 
b/drivers/net/wireless/intersil/p54/p54usb.c
index 043bd1c..b0b86f7 100644
--- a/drivers/net/wireless/intersil/p54/p54usb.c
+++ b/drivers/net/wireless/intersil/p54/p54usb.c
@@ -41,7 +41,7 @@ MODULE_FIRMWARE("isl3887usb");
  * whenever you add a new device.
  */
 
-static struct usb_device_id p54u_table[] = {
+static const struct usb_device_id p54u_table[] = {
/* Version 1 devices (pci chip + net2280) */
{USB_DEVICE(0x0411, 0x0050)},   /* Buffalo WLI2-USB2-G54 */
{USB_DEVICE(0x045e, 0x00c2)},   /* Microsoft MN-710 */
-- 
2.7.4

[PATCH 24/35] wireless: marvell: libertas: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/marvell/libertas/if_usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/libertas/if_usb.c 
b/drivers/net/wireless/marvell/libertas/if_usb.c
index e53025e..16e54c7 100644
--- a/drivers/net/wireless/marvell/libertas/if_usb.c
+++ b/drivers/net/wireless/marvell/libertas/if_usb.c
@@ -52,7 +52,7 @@ static const struct lbs_fw_table fw_table[] = {
{ MODEL_8682, "libertas/usb8682.bin", NULL }
 };
 
-static struct usb_device_id if_usb_table[] = {
+static const struct usb_device_id if_usb_table[] = {
/* Enter the device signature inside */
{ USB_DEVICE(0x1286, 0x2001), .driver_info = MODEL_8388 },
{ USB_DEVICE(0x05a3, 0x8388), .driver_info = MODEL_8388 },
-- 
2.7.4

[PATCH 33/35] wireless: realtek: rtl8192cu: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
index 96c923b..e673bc2 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c
@@ -275,7 +275,7 @@ static struct rtl_hal_cfg rtl92cu_hal_cfg = {
 #define USB_VENDER_ID_REALTEK  0x0bda
 
 /* 2010-10-19 DID_USB_V3.4 */
-static struct usb_device_id rtl8192c_usb_ids[] = {
+static const struct usb_device_id rtl8192c_usb_ids[] = {
 
/*=== Realtek demoboard ===*/
/* Default ID */
-- 
2.7.4

[PATCH 25/35] wireless: marvell: libertas_tf: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/marvell/libertas_tf/if_usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/libertas_tf/if_usb.c 
b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
index e0ade40..e9104ec 100644
--- a/drivers/net/wireless/marvell/libertas_tf/if_usb.c
+++ b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
@@ -31,7 +31,7 @@ module_param_named(fw_name, lbtf_fw_name, charp, 0644);
 
 MODULE_FIRMWARE("lbtf_usb.bin");
 
-static struct usb_device_id if_usb_table[] = {
+static const struct usb_device_id if_usb_table[] = {
/* Enter the device signature inside */
{ USB_DEVICE(0x1286, 0x2001) },
{ USB_DEVICE(0x05a3, 0x8388) },
-- 
2.7.4

[PATCH 35/35] wireless: zydas: zd1211rw: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/zydas/zd1211rw/zd_usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/zydas/zd1211rw/zd_usb.c 
b/drivers/net/wireless/zydas/zd1211rw/zd_usb.c
index 01ca1d5..c30bf11 100644
--- a/drivers/net/wireless/zydas/zd1211rw/zd_usb.c
+++ b/drivers/net/wireless/zydas/zd1211rw/zd_usb.c
@@ -35,7 +35,7 @@
 #include "zd_mac.h"
 #include "zd_usb.h"
 
-static struct usb_device_id usb_ids[] = {
+static const struct usb_device_id usb_ids[] = {
/* ZD1211 */
{ USB_DEVICE(0x0105, 0x145f), .driver_info = DEVICE_ZD1211 },
{ USB_DEVICE(0x0586, 0x3401), .driver_info = DEVICE_ZD1211 },
-- 
2.7.4

[PATCH 34/35] wireless: zydas: zd1201: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/zydas/zd1201.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/zydas/zd1201.c 
b/drivers/net/wireless/zydas/zd1201.c
index 7f586d7..581e857 100644
--- a/drivers/net/wireless/zydas/zd1201.c
+++ b/drivers/net/wireless/zydas/zd1201.c
@@ -25,7 +25,7 @@
 #include 
 #include "zd1201.h"
 
-static struct usb_device_id zd1201_table[] = {
+static const struct usb_device_id zd1201_table[] = {
{USB_DEVICE(0x0586, 0x3400)}, /* Peabird Wireless USB Adapter */
{USB_DEVICE(0x0ace, 0x1201)}, /* ZyDAS ZD1201 Wireless USB Adapter */
{USB_DEVICE(0x050d, 0x6051)}, /* Belkin F5D6051 usb  adapter */
-- 
2.7.4

[PATCH 28/35] wireless: ralink: rt2500usb: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/ralink/rt2x00/rt2500usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2500usb.c 
b/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
index 529e059..f4b48b7 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
@@ -1911,7 +1911,7 @@ static const struct rt2x00_ops rt2500usb_ops = {
 /*
  * rt2500usb module information.
  */
-static struct usb_device_id rt2500usb_device_table[] = {
+static const struct usb_device_id rt2500usb_device_table[] = {
/* ASUS */
{ USB_DEVICE(0x0b05, 0x1706) },
{ USB_DEVICE(0x0b05, 0x1707) },
-- 
2.7.4

[PATCH 32/35] wireless: realtek: rtl8xxxu: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 21e5ef0..7806a4d 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -6190,7 +6190,7 @@ static void rtl8xxxu_disconnect(struct usb_interface 
*interface)
ieee80211_free_hw(hw);
 }
 
-static struct usb_device_id dev_table[] = {
+static const struct usb_device_id dev_table[] = {
 {USB_DEVICE_AND_INTERFACE_INFO(USB_VENDOR_ID_REALTEK, 0x8724, 0xff, 0xff, 
0xff),
.driver_info = (unsigned long)_fops},
 {USB_DEVICE_AND_INTERFACE_INFO(USB_VENDOR_ID_REALTEK, 0x1724, 0xff, 0xff, 
0xff),
-- 
2.7.4

[PATCH 30/35] wireless: ralink: rt73usb: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/ralink/rt2x00/rt73usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt73usb.c 
b/drivers/net/wireless/ralink/rt2x00/rt73usb.c
index fd91322..9a21282 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt73usb.c
@@ -2408,7 +2408,7 @@ static const struct rt2x00_ops rt73usb_ops = {
 /*
  * rt73usb module information.
  */
-static struct usb_device_id rt73usb_device_table[] = {
+static const struct usb_device_id rt73usb_device_table[] = {
/* AboCom */
{ USB_DEVICE(0x07b8, 0xb21b) },
{ USB_DEVICE(0x07b8, 0xb21c) },
-- 
2.7.4

[PATCH 26/35] wireless: marvell: mwifiex: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/marvell/mwifiex/usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/usb.c 
b/drivers/net/wireless/marvell/mwifiex/usb.c
index cb1753e..821a77b 100644
--- a/drivers/net/wireless/marvell/mwifiex/usb.c
+++ b/drivers/net/wireless/marvell/mwifiex/usb.c
@@ -24,7 +24,7 @@
 
 static struct mwifiex_if_ops usb_ops;
 
-static struct usb_device_id mwifiex_usb_table[] = {
+static const struct usb_device_id mwifiex_usb_table[] = {
/* 8766 */
{USB_DEVICE(USB8XXX_VID, USB8766_PID_1)},
{USB_DEVICE_AND_INTERFACE_INFO(USB8XXX_VID, USB8766_PID_2,
-- 
2.7.4

[PATCH 27/35] wireless: mediatek: mt7601u: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/mediatek/mt7601u/usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt7601u/usb.c 
b/drivers/net/wireless/mediatek/mt7601u/usb.c
index 416c604..b9e4f67 100644
--- a/drivers/net/wireless/mediatek/mt7601u/usb.c
+++ b/drivers/net/wireless/mediatek/mt7601u/usb.c
@@ -19,7 +19,7 @@
 #include "usb.h"
 #include "trace.h"
 
-static struct usb_device_id mt7601u_device_table[] = {
+static const struct usb_device_id mt7601u_device_table[] = {
{ USB_DEVICE(0x0b05, 0x17d3) },
{ USB_DEVICE(0x0e8d, 0x760a) },
{ USB_DEVICE(0x0e8d, 0x760b) },
-- 
2.7.4

[PATCH 21/35] wireless: broadcom: brcm80211: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
index 0eea48e..51562b0 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
@@ -1463,7 +1463,7 @@ static int brcmf_usb_reset_resume(struct usb_interface 
*intf)
 #define LINKSYS_USB_DEVICE(dev_id) \
{ USB_DEVICE(BRCM_USB_VENDOR_ID_LINKSYS, dev_id) }
 
-static struct usb_device_id brcmf_usb_devid_table[] = {
+static const struct usb_device_id brcmf_usb_devid_table[] = {
BRCMF_USB_DEVICE(BRCM_USB_43143_DEVICE_ID),
BRCMF_USB_DEVICE(BRCM_USB_43236_DEVICE_ID),
BRCMF_USB_DEVICE(BRCM_USB_43242_DEVICE_ID),
-- 
2.7.4

[PATCH 20/35] wireless: atmel: at76c50x: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/atmel/at76c50x-usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/atmel/at76c50x-usb.c 
b/drivers/net/wireless/atmel/at76c50x-usb.c
index 09defbc..94bf01f 100644
--- a/drivers/net/wireless/atmel/at76c50x-usb.c
+++ b/drivers/net/wireless/atmel/at76c50x-usb.c
@@ -130,7 +130,7 @@ MODULE_FIRMWARE("atmel_at76c505amx-rfmd.bin");
 
 #define USB_DEVICE_DATA(__ops) .driver_info = (kernel_ulong_t)(__ops)
 
-static struct usb_device_id dev_table[] = {
+static const struct usb_device_id dev_table[] = {
/*
 * at76c503-i3861
 */
-- 
2.7.4

[PATCH 19/35] wireless: ath: carl9170: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/ath/carl9170/usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/carl9170/usb.c 
b/drivers/net/wireless/ath/carl9170/usb.c
index 99ab203..e7c3f3b 100644
--- a/drivers/net/wireless/ath/carl9170/usb.c
+++ b/drivers/net/wireless/ath/carl9170/usb.c
@@ -64,7 +64,7 @@ MODULE_ALIAS("arusb_lnx");
  * http://wireless.kernel.org/en/users/Drivers/ar9170/devices ),
  * whenever you add a new device.
  */
-static struct usb_device_id carl9170_usb_ids[] = {
+static const struct usb_device_id carl9170_usb_ids[] = {
/* Atheros 9170 */
{ USB_DEVICE(0x0cf3, 0x9170) },
/* Atheros TG121N */
-- 
2.7.4

[PATCH 18/35] wireless: ath: ath9k: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c 
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 0d9687a..c5f4dd8 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -20,7 +20,7 @@
 MODULE_FIRMWARE(HTC_7010_MODULE_FW);
 MODULE_FIRMWARE(HTC_9271_MODULE_FW);
 
-static struct usb_device_id ath9k_hif_usb_ids[] = {
+static const struct usb_device_id ath9k_hif_usb_ids[] = {
{ USB_DEVICE(0x0cf3, 0x9271) }, /* Atheros */
{ USB_DEVICE(0x0cf3, 0x1006) }, /* Atheros */
{ USB_DEVICE(0x0846, 0x9030) }, /* Netgear N150 */
-- 
2.7.4

[PATCH 16/35] wireless: ath: ar5523: constify usb_device_id

[Arvind Yadav]

usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by  work with
const usb_device_id. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/ath/ar5523/ar5523.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ar5523/ar5523.c 
b/drivers/net/wireless/ath/ar5523/ar5523.c
index 106d6f8..68f0463 100644
--- a/drivers/net/wireless/ath/ar5523/ar5523.c
+++ b/drivers/net/wireless/ath/ar5523/ar5523.c
@@ -1749,7 +1749,7 @@ static void ar5523_disconnect(struct usb_interface *intf)
{ USB_DEVICE((vendor), (device) + 1), \
.driver_info = AR5523_FLAG_ABG|AR5523_FLAG_PRE_FIRMWARE }
 
-static struct usb_device_id ar5523_id_table[] = {
+static const struct usb_device_id ar5523_id_table[] = {
AR5523_DEVICE_UG(0x168c, 0x0001),   /* Atheros / AR5523 */
AR5523_DEVICE_UG(0x0cf3, 0x0001),   /* Atheros2 / AR5523_1 */
AR5523_DEVICE_UG(0x0cf3, 0x0003),   /* Atheros2 / AR5523_2 */
-- 
2.7.4

Re: [PATCH 30/34] brcmfmac: Correctly handle accesses to SDIO func0

[Arend van Spriel]

On 26-07-17 22:25, Ian Molton wrote:
> Rather than workaround the restrictions on func0 addressing in the
> driver, set MMC_QUIRK_LENIENT_FN0

A quirk sounds like a workaround to me, but as it is provided by the mmc
stack it trumps a driver solution.

Acked-by: Arend van Spriel 
> Signed-off-by: Ian Molton 
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 4 
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h   | 4 ++--
>  2 files changed, 6 insertions(+), 2 deletions(-)

Re: [PATCH 31/34] brcmfmac: Remove func0 from function array

[Arend van Spriel]

On 08-08-17 13:27, Ian Molton wrote:
> On 08/08/17 12:19, Arend van Spriel wrote:
> 
>>>  #define brcmf_sdiod_func0_rb(sdiodev, addr, r) \
>>> -   sdio_f0_readb((sdiodev)->func[0], (addr), (r))
>>> +   sdio_f0_readb((sdiodev)->func[1], (addr), (r))
>>
>> There is no reason to keep these any longer as these do not provide any
>> functionality over the core sdio function unless you consider the
>> sdiodev dereference.
>>
> 
> I tend to agree, although they're fairly readable anyway. I was trying
> to keep the changes small and incremental.
> 
> I'll knock up a patch and see how it looks with them converted to the
> actual functions when I get back from hoiliday.

Enjoy the holiday. Glad to see I am not the only one checking email when
he is not supposed to work ;-)

Regards,
Arend

Re: [PATCH 34/34] brcmfmac: Reduce the noise from repeatedly dereferencing common pointers

[Arend van Spriel]

On 26-07-17 22:25, Ian Molton wrote:
> This introduces no functional changes, but makes the code drastically more
> readable, reducing the amount of dereferencing performed inside functions
> throughout the SDIO core.
> 
> For example, reduce:
>   sdio_release_host(bus->sdiodev->func1);
> to:
>   sdio_release_host(func1);
> 
> Fixup a few inconsistently named pointers whilst we are at it ie.
> 
> sdiod -> sdiodev

Last but not least so to speak. I think "drastically" is a bit
overstated. In terms of readability it can go either way at far as I am
concerned. At least the above example does. In terms of instructions it
depends. Both dereferencing and helper variables on stack have their
price. So I (try to) use some soft limits when it comes to
dereferencing. The depth should not be more than 2, ie.:

bus->sdiodev->func1 is ok, bus->sdiodev->func1->card is not.

The number of dereferences within a particular code path in the function
should not be more than 3.

Also there are some places where you add both func1 and func2 to the
stack, but if you look at it you could do with just one of them.

>From this series I reviewed patches 1 upto and including patch 15, and
patches 29 through 34. Please rework those as requested and resubmit
them. Please also resubmit the remaining patch after that and consider
splitting it up file based. For example below could be a patch series
for chip.c related changes:

$ git log gerrit/brcm-wl-master..HEAD --reverse --oneline --
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
4c75cf9 brcmfmac: Rename SOC_AI to SOC_AXI
acf9f33 brcmfmac: Get rid of chip_priv and core_priv structs
57cef44 brcmfmac: Whitespace patch
fe23a50 brcmfmac: Simplify chip probe routine
89e5bb5 brcmfmac: Rename axi functions for clarity.
a6352d7 brcmfmac: HUGE cleanup of IO access functions.
ee7ea4f brcmfmac: Rename chip.ctx -> chip.bus_priv

Reviewed-by: Arend van Spriel 
> Signed-off-by: Ian Molton 

comments below...

> # Conflicts:
> # drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> # drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> ---
>  .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c  | 140 +++
>  .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 409 
> +++--
>  2 files changed, 294 insertions(+), 255 deletions(-)

[...]

>  int brcmf_sdio_sleep(struct brcmf_sdio *bus, bool sleep)
>  {
> + struct brcmf_sdio_dev *sdiodev = bus->sdiodev;
> + struct sdio_func *func1 = sdiodev->func1;

Actually only wanted to explicitly mention this one. Probably the
compiler is smart enough to keep sdiodev from the stack, but I would say
it is a variable you do not really need and also in terms of readability
it seems clear enough to do it in one assignment.

>   int ret;
>  
> - sdio_claim_host(bus->sdiodev->func1);
> + sdio_claim_host(func1);
>   ret = brcmf_sdio_bus_sleep(bus, sleep, false);
> - sdio_release_host(bus->sdiodev->func1);
> + sdio_release_host(func1);
>  
>   return ret;
>  }
> 

Re: [PATCH 33/34] brcmfmac: Remove array of functions

[Arend van Spriel]

On 26-07-17 22:25, Ian Molton wrote:
> Replace the array of functions with a pair of pointers to the
>  relevant functions.

Acked-by: Arend van Spriel 
> Signed-off-by: Ian Molton 
> 
> # Conflicts:
> # drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> # drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> ---
>  .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c  | 117 +++
>  .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 166 
> ++---
>  .../wireless/broadcom/brcm80211/brcmfmac/sdio.h|  15 +-
>  3 files changed, 146 insertions(+), 152 deletions(-)

Re: [PATCH 32/34] brcmfmac: Replace function index with function pointer

[Arend van Spriel]

On 26-07-17 22:25, Ian Molton wrote:
> In preparation for removing the function array, remove all code that
> refers to function by index and replace with pointers to the function
> itself.

Reviewed-by: Arend van Spriel 
> Signed-off-by: Ian Molton 

comments below...

> # Conflicts:
> # drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> ---
>  .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c  | 86 
> --
>  .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 14 ++--
>  .../wireless/broadcom/brcm80211/brcmfmac/sdio.h| 14 ++--
>  3 files changed, 61 insertions(+), 53 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> index da0654c50db9..5787348003d9 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> @@ -148,7 +148,8 @@ int brcmf_sdiod_intr_register(struct brcmf_sdio_dev 
> *sdiodev)
>  
>   /* must configure SDIO_CCCR_IENx to enable irq */
>   data = brcmf_sdiod_func0_rb(sdiodev, SDIO_CCCR_IENx, );
> - data |= 1 << SDIO_FUNC_1 | 1 << SDIO_FUNC_2 | 1;
> + data |= SDIO_CCCR_IEN_FUNC1 | SDIO_CCCR_IEN_FUNC2 |
> + SDIO_CCCR_IEN_BIT0;

This is not really related except that you are doing away with the
SDIO_FUNC_{1,2} defintions. Please use separate patch for this. The BIT0
should basically be FUNC0.

>   brcmf_sdiod_func0_wb(sdiodev, SDIO_CCCR_IENx, data, );
>  
>   /* redirect, configure and enable io for interrupt signal */

[...]

> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
> index 227c90198a8e..3d41bd94f97c 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
> @@ -24,9 +24,6 @@
>  /* Maximum number of I/O funcs */
>  #define NUM_SDIO_FUNCS   3
>  
> -#define SDIO_FUNC_1  1
> -#define SDIO_FUNC_2  2
> -
>  #define SDIOD_FBR_SIZE   0x100
>  
>  /* io_en */
> @@ -45,11 +42,13 @@
>  #define REG_F0_REG_MASK  0x7FF
>  #define REG_F1_MISC_MASK 0x1
>  
> -/* as of sdiod rev 0, supports 3 functions */
> -#define SBSDIO_NUM_FUNCTION  3
> -
>  /* function 0 vendor specific CCCR registers */
>  
> +/* Interrupt enable bits for func 1 and 2 */
> +#define SDIO_CCCR_IEN_BIT0   BIT(0)

Better change BIT0 to FUNC0 in separate patch as mentioned above.

> +#define SDIO_CCCR_IEN_FUNC1  BIT(1)
> +#define SDIO_CCCR_IEN_FUNC2  BIT(2)
> +

Re: [v3] rt2x00: Fix MMIC Countermeasures

[Kalle Valo]

Michael Skeffington  wrote:

> Set RX_FLAG_DECRYPTED in case of MMIC failure so that
> ieee80211_rx_h_decrypt() doesnt drop the frame before getting to
> ieee80211_rx_h_michael_mic_verify().
> 
> Signed-off-by: Michael Skeffington 
> Acked-by: Stanislaw Gruszka 

Patch applied to wireless-drivers-next.git, thanks.

2db3aaba0a9f rt2x00: Fix MMIC Countermeasures

-- 
https://patchwork.kernel.org/patch/9885839/

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

Re: [v2] rtlwifi: constify rate_control_ops structure

[Kalle Valo]

Bhumika Goyal  wrote:

> rate_control_ops structure is only passed as an argument to the
> function ieee80211_rate_control_{register/unregister}. This argument
> is of type const, so declare the structure as const.
> 
> Signed-off-by: Bhumika Goyal 

Patch applied to wireless-drivers-next.git, thanks.

cb1b82625de7 rtlwifi: constify rate_control_ops structure

-- 
https://patchwork.kernel.org/patch/9884393/

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

Re: [1/2] wlcore: add const to bin_attribute structure

[Kalle Valo]

Bhumika Goyal  wrote:

> Add const to bin_attribute structure as it is only passed to the
> functions sysfs_{remove/create}_bin_file. The corresponding arguments
> are of type const, so declare the structure to be const.
> 
> Signed-off-by: Bhumika Goyal 

Patch applied to wireless-drivers-next.git, thanks.

4f2949febc22 wlcore: add const to bin_attribute structure

-- 
https://patchwork.kernel.org/patch/9877341/

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

Re: brcmfmac: add setting carrier state ON for successful roaming

[Kalle Valo]

Wright Feng  wrote:

> From: Chung-Hsien Hsu 
> 
> After association, ping is not working when sweeping the channel at the
> AP side. It is caused by having incorrect carrier state (OFF) for the STA
> in successful roaming. This patch sets the carrier state ON for the case.
> 
> Signed-off-by: Chung-Hsien Hsu 
> Acked-by: Arend van Spriel 

Patch applied to wireless-drivers-next.git, thanks.

8b943e36e24a brcmfmac: add setting carrier state ON for successful roaming

-- 
https://patchwork.kernel.org/patch/9884669/

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

Re: [v2, 1/3] brcmfmac: set wpa_auth to WPA_AUTH_DISABLED in AP/OPEN security mode

[Kalle Valo]

Wright Feng  wrote:

> When setting wpa_auth to WPA_AUTH_NONE(1) in AP mode with WEP security,
> firmware will set privacy bit and add WPA OUI in VENDOR IE in beacon and
> probe response. The security type in softAP beacons confuse the
> supplicant in client side, and the user client will see [WPA-?] in
> supplicant scan result. So we set WPA_AUTH_DISABLED in softAP mode with 
> OPEN security.
> 
> Signed-off-by: Wright Feng 
> Acked-by: Arend van Spriel 

3 patches applied to wireless-drivers-next.git, thanks.

fdfb0f94bfb7 brcmfmac: set wpa_auth to WPA_AUTH_DISABLED in AP/OPEN security 
mode
0ec9eb90feec brcmfmac: Add support for CYW4373 SDIO/USB chipset
99976fc08412 brcmfmac: fix wrong num_different_channels when mchan feature 
enabled

-- 
https://patchwork.kernel.org/patch/9878545/

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

Re: [v2] mwifiex: p2p: use separate device address

[Kalle Valo]

Xinming Hu  wrote:

> From: Xinming Hu 
> 
> Per below statement about p2p device address in WFA P2P
> spec $2.4.3:
> 
> The P2P Device Address of a P2P Device shall be its globally
> administered MAC address, or its globally administered MAC
> address with the locally administered bit set.
> 
> This patch follow above statement, using a separate device
> address for p2p interface
> 
> Signed-off-by: Xinming Hu 
> Signed-off-by: Cathy Luo 
> Signed-off-by: Ganapathi Bhat 

Patch applied to wireless-drivers-next.git, thanks.

4ba28f93948d mwifiex: p2p: use separate device address

-- 
https://patchwork.kernel.org/patch/9884203/

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

Re: [1/2] mwifiex: Do not change bss_num in change_virtual_intf

[Kalle Valo]

Xinming Hu  wrote:

> From: Xinming Hu 
> 
> Commit 4d7ab36f0c47 ("mwifiex: Do not change bss_type in
> change_virtual_intf") kept original bss_type unchanged. bss_num should
> keep the same style, in this way. Unique tuple (bss_type, bss_num) will
> be able to locate the right priv structure.
> 
> Signed-off-by: Xinming Hu 
> Signed-off-by: Cathy Luo 
> Signed-off-by: Ganapathi Bhat 

2 patches applied to wireless-drivers-next.git, thanks.

2d33140f90e8 mwifiex: Do not change bss_num in change_virtual_intf
20e5476d6c30 mwifiex: wrapper wps ie in pass through tlv

-- 
https://patchwork.kernel.org/patch/9878505/

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

Re: mwifiex: replace netif_carrier_on/off by netif_device_attach/dettach

[Kalle Valo]

Ganapathi Bhat  wrote:

> Driver is doing netif_carrier_off during suspend, which will set
> the IFF_LOWER_UP flag to 0. As a result certain applications
> will think this as a real carrier down and behave accordingly.
> This will cause issues like loss of IP address, for example. To
> fix this use netif_device_dettach during suspend.
> 
> Fixes: 0026b32d723e ('mwifiex: fix Tx timeout issue during suspend test')
> 
> Signed-off-by: Cathy Luo 
> Signed-off-by: Ganapathi Bhat 

Patch applied to wireless-drivers-next.git, thanks.

bd69cddcdf47 mwifiex: replace netif_carrier_on/off by 
netif_device_attach/dettach

-- 
https://patchwork.kernel.org/patch/9877467/

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

Re: [v2,1/8] rsi: add support for rf-kill functionality

[Kalle Valo]

Amitkumar Karwar  wrote:

> From: Pavani Muthyala 
> 
> This patch implements rfkill_poll handler. Also, necessary changes
> are done in interface up and down handler to support rfkill
> functionality.
> 
> Signed-off-by: Pavani Muthyala 
> Signed-off-by: Amitkumar Karwar 

8 patches applied to wireless-drivers-next.git, thanks.

edba3532c652 rsi: add support for rf-kill functionality
588349a1fe3b rsi: update set_antenna command frame
ce86893fa8d8 rsi: add support for legacy power save
db07971d085f rsi: add support for U-APSD power save
23e414cca1f7 rsi: rename sdio_read_buffer_status_register
d64dd2a172d8 rsi: buffer full check optimization
67c52a4dafce rsi: buffer available interrupt handling
80a88ecf3bcc rsi: RTS threshold configuration

-- 
https://patchwork.kernel.org/patch/9879251/

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

Re: bcma: make BCMA a menuconfig to ease disabling it all

[Kalle Valo]

Vincent Legoll  wrote:

> No need to get into the submenu to disable all BCMA-related config entries.
> 
> Signed-off-by: Vincent Legoll 

Patch applied to wireless-drivers-next.git, thanks.

9ca766b3641f bcma: make BCMA a menuconfig to ease disabling it all

-- 
https://patchwork.kernel.org/patch/9683685/

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

Re: [PATCH 31/34] brcmfmac: Remove func0 from function array

[Arend van Spriel]

On 26-07-17 22:25, Ian Molton wrote:
> Linux doesnt pass you func0 as a function when probing - instead
> providing specific access functions to read/write it.
> 
> This prepares for a patch to remove the actual array entry itself.

Reviewed-by: Arend van Spriel 
> Signed-off-by: Ian Molton 
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c |  5 +
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c   |  6 +++---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h   | 13 ++---
>  3 files changed, 10 insertions(+), 14 deletions(-)

[...]

> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
> index 8a976c89cf63..227c90198a8e 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
> @@ -21,7 +21,9 @@
>  #include 
>  #include "firmware.h"
>  
> -#define SDIO_FUNC_0  0
> +/* Maximum number of I/O funcs */
> +#define NUM_SDIO_FUNCS   3
> +
>  #define SDIO_FUNC_1  1
>  #define SDIO_FUNC_2  2
>  
> @@ -39,9 +41,6 @@
>  #define INTR_STATUS_FUNC10x2
>  #define INTR_STATUS_FUNC20x4
>  
> -/* Maximum number of I/O funcs */
> -#define SDIOD_MAX_IOFUNCS7
> -

Good riddance, because ...

>  /* mask of register map */
>  #define REG_F0_REG_MASK  0x7FF
>  #define REG_F1_MISC_MASK 0x1
> @@ -175,7 +174,7 @@ struct brcmf_sdio;
>  struct brcmf_sdiod_freezer;
>  
>  struct brcmf_sdio_dev {
> - struct sdio_func *func[SDIO_MAX_FUNCS];

... it was not used anyway as this definition is in .

> + struct sdio_func *func[NUM_SDIO_FUNCS];
>   u8 num_funcs;   /* Supported funcs on client */
>   u32 sbwad;  /* Save backplane window address */
>   struct brcmf_core *cc_core; /* chipcommon core info struct */
> @@ -297,10 +296,10 @@ void brcmf_sdiod_intr_unregister(struct brcmf_sdio_dev 
> *sdiodev);
>  /* SDIO device register access interface */
>  /* Functions for accessing SDIO Function 0 */
>  #define brcmf_sdiod_func0_rb(sdiodev, addr, r) \
> - sdio_f0_readb((sdiodev)->func[0], (addr), (r))
> + sdio_f0_readb((sdiodev)->func[1], (addr), (r))

There is no reason to keep these any longer as these do not provide any
functionality over the core sdio function unless you consider the
sdiodev dereference.

Re: ath9k: make ath_ps_ops structures as const

[Kalle Valo]

Bhumika Goyal  wrote:

> ath_ps_ops structures are only stored as a reference in the ps_ops
> field of a ath_common structure. This field is of type const, so make
> the structures as const.
> 
> Signed-off-by: Bhumika Goyal 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

3588e1110e49 ath9k: make ath_ps_ops structures as const

-- 
https://patchwork.kernel.org/patch/9879297/

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

Re: [v1] ath10k: Switch to use new generic UUID API

[Kalle Valo]

Andy Shevchenko  wrote:

> There are new types and helpers that are supposed to be used in new code.
> 
> As a preparation to get rid of legacy types and API functions do
> the conversion here.
> 
> Signed-off-by: Andy Shevchenko 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

ab3f9c886865 ath10k: switch to use new generic UUID API

-- 
https://patchwork.kernel.org/patch/9876823/

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

Re: [v2] ath10k: fix memory leak in rx ring buffer allocation

[Kalle Valo]

Rakesh Pillai  wrote:

> The rx ring buffers are added to a hash table if
> firmware support full rx reorder. If the full rx
> reorder support flag is not set before allocating
> the rx ring buffers, none of the buffers are added
> to the hash table.
> 
> There is a race condition between rx ring refill and
> rx buffer replenish from napi poll. The interrupts are
> enabled in hif start, before the rx ring is refilled during init.
> We replenish buffers from napi poll due to the interrupts which
> get enabled after hif start. Hence before the entire rx ring is
> refilled during the init, the napi poll replenishes a few buffers
> in steps of 100 buffers per attempt. During this rx ring replenish
> from napi poll, the rx reorder flag has not been set due to which
> the replenished buffers are not added to the hash table
> 
> Set the rx full reorder support flag before we allocate
> the rx ring buffer to avoid the memory leak.
> 
> Signed-off-by: Rakesh Pillai 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

f35a7f91f66a ath10k: fix memory leak in rx ring buffer allocation

-- 
https://patchwork.kernel.org/patch/9876599/

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

Re: [v3] ath10k: ath10k_htt_rx_amsdu_allowed() use ath10k_dbg()

[Kalle Valo]

Gabriel C  wrote:

> Each time we get disconnected from AP we get flooded with messages like:
> 
> ...
> ath10k_pci :03:00.0: no channel configured; ignoring frame(s)!
> 
> ath10k_warn: 155 callbacks suppressed
> ...
> 
> Use ath10k_dbg() here too.
> 
> Signed-off-by: Gabriel Craciunescu 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

984eb9053280 ath10k: ath10k_htt_rx_amsdu_allowed() use ath10k_dbg()

-- 
https://patchwork.kernel.org/patch/9853129/

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

Re: [PATCH v4 10/10] wil6210: make debugfs compilation optional

[Kalle Valo]

Maya Erez  writes:

> From: Gidon Studinski 
>
> Since debugfs is a kernel configuration option, enable the driver to
> compile without debugfs.
>
> Signed-off-by: Gidon Studinski 
> Signed-off-by: Maya Erez 
> ---
>  drivers/net/wireless/ath/wil6210/Makefile  | 2 +-
>  drivers/net/wireless/ath/wil6210/wil6210.h | 6 ++
>  2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/wil6210/Makefile 
> b/drivers/net/wireless/ath/wil6210/Makefile
> index 4ae21da..63a751a 100644
> --- a/drivers/net/wireless/ath/wil6210/Makefile
> +++ b/drivers/net/wireless/ath/wil6210/Makefile
> @@ -4,7 +4,7 @@ wil6210-y := main.o
>  wil6210-y += netdev.o
>  wil6210-y += cfg80211.o
>  wil6210-y += pcie_bus.o
> -wil6210-y += debugfs.o
> +wil6210-$(CONFIG_DEBUG_FS) += debugfs.o
>  wil6210-y += wmi.o
>  wil6210-y += interrupt.o
>  wil6210-y += txrx.o
> diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h 
> b/drivers/net/wireless/ath/wil6210/wil6210.h
> index cf20a8c..d7b1e03 100644
> --- a/drivers/net/wireless/ath/wil6210/wil6210.h
> +++ b/drivers/net/wireless/ath/wil6210/wil6210.h
> @@ -940,8 +940,14 @@ int wil_cfg80211_mgmt_tx(struct wiphy *wiphy, struct 
> wireless_dev *wdev,
>struct cfg80211_mgmt_tx_params *params,
>u64 *cookie);
>  
> +#if defined(CONFIG_DEBUG_FS)
>  int wil6210_debugfs_init(struct wil6210_priv *wil);
>  void wil6210_debugfs_remove(struct wil6210_priv *wil);
> +#else
> +static inline int wil6210_debugfs_init(struct wil6210_priv *wil) { return 0; 
> }
> +static inline void wil6210_debugfs_remove(struct wil6210_priv *wil) {}
> +#endif

I was thinking more that should we have CONFIG_WIL6210_DEBUGFS, just
like we have CONFIG_ATH10K_DEBUGFS and CONFIG_ATH9K_DEBUGFS? This way it
can be controlled per driver if debugfs interface is available or not.

-- 
Kalle Valo

Re: [PATCH v4 02/10] wil6210: allow configuring scan timers

[Kalle Valo]

Maya Erez  writes:

> From: Hamad Kadmany 
>
> Allow setting scan timeout and scan dwell time
> through module parameters.
>
> Signed-off-by: Hamad Kadmany 
> Signed-off-by: Maya Erez 
> ---
>  drivers/net/wireless/ath/wil6210/cfg80211.c | 17 ++---
>  drivers/net/wireless/ath/wil6210/wil6210.h  |  2 +-
>  2 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c 
> b/drivers/net/wireless/ath/wil6210/cfg80211.c
> index 77af749..d079533 100644
> --- a/drivers/net/wireless/ath/wil6210/cfg80211.c
> +++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
> @@ -26,6 +26,14 @@
>  module_param(disable_ap_sme, bool, 0444);
>  MODULE_PARM_DESC(disable_ap_sme, " let user space handle AP mode SME");
>  
> +static uint scan_dwell_time  = WMI_SCAN_DWELL_TIME_MS;
> +module_param(scan_dwell_time, uint, 0644);
> +MODULE_PARM_DESC(scan_dwell_time, " Scan dwell time (msec)");
> +
> +static uint scan_timeout = WIL6210_SCAN_TO_SEC;
> +module_param(scan_timeout, uint, 0644);
> +MODULE_PARM_DESC(scan_timeout, " Scan timeout (seconds)");

Module parameters are not really meant for this kind of configuration
802.11 protocol configuration. Can't you use nl80211?

-- 
Kalle Valo

ath: Incorrect regDomainPairs/allCountries settings

[Sven Eckelmann]

Hi,

I just had two inquiries from Vietnam and Singapore regarding the used CTL 
limits by Atheros based chips. I've checked through the code and noticed that 
regd_common.h assigns SG to APL6_WORLD and VN to NULL1_WORLD.

 * SG: APL6_WORLD
   - 2.4GHz: CTL_ETSI
   -   5GHz: CTL_ETSI
 * VN: NULL1_WORLD
   - 2.4GHz: CTL_ETSI
   -   5GHz: NO_CTL

But I personally would have expected that both countries would be assigned to 
FCC3_WORLD.

 * FCC3_WORLD
   - 2.4GHz: CTL_ETSI
   -   5GHz: CTL_FCC

Maybe someone from QCA can check with their internal driver.

I have compared the current ath/regd_common.h with what I would have expected 
(which might not be correct after all). I still wanted to list the things 
which I found:

Missing Entries in CountryCode (regd.h):

 * CTRY_AFGHANISTAN = 4,
 * CTRY_AMERICAN_SAMOA = 16,
 * CTRY_ANGUILLA = 660,
 * CTRY_BAHAMAS = 44,
 * CTRY_BERMUDA = 60,
 * CTRY_BHUTAN = 64,
 * CTRY_BURKINA_FASO = 854,
 * CTRY_CAYMAN_ISLANDS = 136,
 * CTRY_CENTRAL_AFRICA_REPUBLIC = 140,
 * CTRY_CHAD = 148,
 * CTRY_CHRISTMAS_ISLAND = 162,
 * CTRY_DOMINICA = 212,
 * CTRY_ETHIOPIA = 231,
 * CTRY_FRENCH_GUIANA = 254,
 * CTRY_FRENCH_POLYNESIA = 258,
 * CTRY_GHANA = 288,
 * CTRY_GUADELOUPE = 312,
 * CTRY_GUYANA = 328,
 * CTRY_COTE_D_IVOIRE = 384,
 * CTRY_LESOTHO = 426,
 * CTRY_MALAWI = 454,
 * CTRY_MALDIVES = 462,
 * CTRY_MARSHALL_ISLANDS = 584,
 * CTRY_MARTINIQUE = 474,
 * CTRY_MAURITANIA = 478,
 * CTRY_MAURITIUS = 480,
 * CTRY_MAYOTTE = 175,
 * CTRY_MICRONESIA = 583,
 * CTRY_MOLDOVA = 498,
 * CTRY_MONGOLIA = 496,
 * CTRY_NAMIBIA = 516,
 * CTRY_NIGERIA = 566,
 * CTRY_NORTHERN_MARIANA_ISLANDS = 580,
 * CTRY_PALAU = 585,
 * CTRY_REUNION = 638,
 * CTRY_RWANDA = 646,
 * CTRY_ST_BARTHELEMY = 652,
 * CTRY_ST_KITTS_NEVIS = 659,
 * CTRY_ST_LUCIA = 662,
 * CTRY_ST_MARTIN = 663,
 * CTRY_ST_PIERRE_MIQUELON = 666,
 * CTRY_ST_VINCENT_GRENADIENS= 670,
 * CTRY_SAMOA = 882,
 * CTRY_SENEGAL = 686,
 * CTRY_SERBIA = 688,
 * CTRY_MONTENEGRO = 499,
 * CTRY_SURINAME = 740,
 * CTRY_TANZANIA = 834,
 * CTRY_TOGO = 768,
 * CTRY_TURKS_CAICOS = 796,
 * CTRY_UGANDA = 800,
 * CTRY_UNITED_STATES2 = 841,
 * CTRY_UNITED_STATES3 = 843,
 * CTRY_VANUATU = 548,
 * CTRY_VIRGIN_ISLANDS = 850,
 * CTRY_WALLIS_FUTUNA = 876,
 * CTRY_ARGENTINA2 = 5003

Entries which most likely shouldn't exist in CountryCode:

 * CTRY_KOREA_ROC2
 * CTRY_SERBIA_MONTENEGRO

Things which I missed in the EnumRd:

 * FCC11_WORLD = 0x19,
 * FCC3_ETSIC = 0x3F,
 * ETSI8_WORLD = 0x3D,
 * ETSI9_WORLD = 0x3E,
 * APL12_WORLD = 0x51,
 * APL14_WORLD = 0x57,
 * APL15_WORLD = 0x59,
 * APL13_WORLD = 0x5A,
 * APL10_WORLD = 0x5F,


The new mappings in regDomainPairs for the used EnumRds would then be:

 * {FCC11_WORLD, CTL_FCC, CTL_ETSI},
 * {FCC3_ETSIC, CTL_FCC, CTL_ETSI},
 * {ETSI8_WORLD, CTL_ETSI, CTL_ETSI},
 * {ETSI9_WORLD, CTL_ETSI, CTL_ETSI},
 * {APL10_WORLD, CTL_ETSI, CTL_ETSI},
 * {APL12_WORLD, CTL_ETSI, CTL_ETSI},
 * {APL13_WORLD, CTL_ETSI, CTL_ETSI},
 * {APL14_WORLD, CTL_FCC, CTL_ETSI},
 * {APL15_WORLD, CTL_FCC, CTL_ETSI},


Things which I missed in allCountries

 * {CTRY_AFGHANISTAN, ETSI1_WORLD, "AF"},
 * {CTRY_AMERICAN_SAMOA, FCC3_FCCA, "AS"},
 * {CTRY_ANGUILLA, ETSI1_WORLD, "AI"},
 * {CTRY_BAHAMAS, FCC3_WORLD, "BS"},
 * {CTRY_BERMUDA, FCC3_FCCA, "BM"},
 * {CTRY_BHUTAN, ETSI1_WORLD, "BT"},
 * {CTRY_BURKINA_FASO,FCC3_WORLD, "BF"},
 * {CTRY_CAYMAN_ISLANDS, FCC3_WORLD, "KY"},
 * {CTRY_CENTRAL_AFRICA_REPUBLIC, FCC3_WORLD, "CF"},
 * {CTRY_CHAD, ETSI1_WORLD, "TD"},
 * {CTRY_CHRISTMAS_ISLAND, FCC3_WORLD, "CX"},
 * {CTRY_DOMINICA, FCC1_FCCA, "DM"},
 * {CTRY_ETHIOPIA, ETSI1_WORLD, "ET"},
 * {CTRY_FRENCH_GUIANA, ETSI1_WORLD, "GF"},
 * {CTRY_FRENCH_POLYNESIA, ETSI1_WORLD, "PF"},
 * {CTRY_GHANA, FCC3_WORLD, "GH"},
 * {CTRY_GUADELOUPE, ETSI1_WORLD, "GP"},
 * {CTRY_GUYANA, APL1_ETSIC, "GY"},
 * {CTRY_COTE_D_IVOIRE, FCC3_WORLD, "CI"},
 * {CTRY_KENYA, APL12_WORLD, "KE"},
 * {CTRY_LESOTHO, ETSI1_WORLD, "LS"},
 * {CTRY_MALDIVES, APL6_WORLD, "MV"},
 * {CTRY_MARSHALL_ISLANDS, FCC3_FCCA, "MH"},
 * {CTRY_MARTINIQUE, ETSI1_WORLD, "MQ"},
 * {CTRY_MAURITANIA, ETSI1_WORLD, "MR"},
 * {CTRY_MAURITIUS, FCC3_WORLD, "MU"},
 * {CTRY_MAYOTTE, ETSI1_WORLD, "YT"},
 * {CTRY_MICRONESIA, FCC3_FCCA, "FM"},
 * {CTRY_MOLDOVA, ETSI1_WORLD, "MD"},
 * {CTRY_MONGOLIA, FCC3_WORLD, "MN"},
 * {CTRY_MONTENEGRO, ETSI1_WORLD, "ME"},
 * {CTRY_NAMIBIA, APL9_WORLD, "NA"},
 * {CTRY_NICARAGUA, FCC3_FCCA, "NI"},
 * {CTRY_NIGERIA, APL8_WORLD, "NG"},
 * {CTRY_NORTHERN_MARIANA_ISLANDS, FCC3_FCCA, "MP"},
 * {CTRY_PALAU, FCC3_FCCA, "PW"},
 * {CTRY_PARAGUAY, FCC3_WORLD, "PY"},
 * {CTRY_REUNION, ETSI1_WORLD, "RE"},
 * {CTRY_RWANDA, FCC3_WORLD, "RW"},
 * {CTRY_SENEGAL, FCC3_WORLD, "SN"},
 * {CTRY_SERBIA, ETSI1_WORLD, "RS"},
 * {CTRY_ST_BARTHELEMY, ETSI1_WORLD, "BL"},
 * {CTRY_ST_KITTS_NEVIS, APL10_WORLD, "KN"},
 * {CTRY_ST_LUCIA, APL10_WORLD, "LC"},
 * {CTRY_ST_MARTIN, ETSI1_WORLD, "MF"},
 * {CTRY_ST_PIERRE_MIQUELON, ETSI1_WORLD, "PM"},
 * {CTRY_ST_VINCENT_GRENADIENS, ETSI1_WORLD, "VC"},
 * {CTRY_SAMOA, ETSI1_WORLD, "WS"},
 * 

Re: Problem with the wifi

[Arend van Spriel]

+ linux-wireless
+ Larry

Jesus christ..grow some ears!

On 08-08-17 11:21, Paolo Bettini wrote:
> Arend van Spriel ha scritto:
>> + linux-wireless
>> + Larry
>>
>> please keep linux-wireless in this thread.
>>
>> On 08-08-17 08:21, Paolo Bettini wrote:
>>> Arend van Spriel ha scritto:
 + linux-wireless On 07-08-17 21:38, Paolo Bettini wrote:
> Hi , i am Paolo and i installed Debian stretch on my ezbook2 . One
> problem is the wifi , the card a SDIO device , seems to be 02d0:a9a6
> linux id or Broadcom AP6212 for windowsi installed deb package
> firmware-brcm80211 and nvram sdio txt in /lib/firmware/brcm, reloaded
> bcrmfmac module but nothing the card seems invisible or dead i don't
> know if is a problem of firmware or my system cannot detect the sdio
> card ...do you know something about this problematic ?
 As always a kernel log could help or output from dmesg command. Also
 can you run following commands: $ ls /sys/bus/sdio/devices $ cat
 /sys/bus/sdio/devices/*/modalias Regards, Arend
>>> paolo@paolo:~$ ls /sys/bus/sdio/devices
>>> mmc1:0001:1
>>> paolo@paolo:~$
>>>
>>>
>>> paolo@paolo:~$ cat /sys/bus/sdio/devices/*/modalias sdio:c07v024CdB723
>>> paolo@paolo:~$ sorry for previous mail ls was from another pc:-[
>>> it seems the system see only the card where the system is installed
>> Hi Paolo,
>>
>> Interesting. Now if Google search is correct the vendor id for this
>> device indicates this is a Realtek (v024C) WLAN (c07) device. So what
>> makes you say its linux id is 02d0:a9a6?
>>
>> In upstream linux I do not see any SDIO device drivers in realtek
>> folder. Maybe Larry can provide clue/hint if a driver for this device is
>> publicly available somewhere.
>>
>> Regards,
>> Arend
> Excuse me if i am boring you again , for me the wifi card of the ezbook2
> is a ghost ...but googling it is a broadcom infact with this command i have

You are not boring anyone, but you really should ask the manufacturer.
All I can say is your sysfs shows there is only one SDIO device with
vendor id 0x024c (Realtek) and class 0x07 (WLAN) so brcmfmac will not be
probed for that as all aliases below for brcmfmac are listing vendor id
0x02d0 (Broadcom). That is all the command below indicates.

Regards,
Arend

> paolo@paolo:~$ grep sdio /lib/modules/`uname -r`/modules.alias
> alias sdio:c*v0271d0418* ath6kl_sdio
> alias sdio:c*v0271d0402* ath6kl_sdio
> alias sdio:c*v0271d0401* ath6kl_sdio
> alias sdio:c*v0271d0400* ath6kl_sdio
> alias sdio:c*v0271d0301* ath6kl_sdio
> alias sdio:c*v0271d0300* ath6kl_sdio
> alias sdio:c*v02D0d4356* brcmfmac
> alias sdio:c*v02D0d4354* brcmfmac
> alias sdio:c*v02D0dA9BF* brcmfmac
> alias sdio:c*v02D0d4345* brcmfmac
> alias sdio:c*v02D0dA9A6* brcmfmac
> alias sdio:c*v02D0d4339* brcmfmac
> alias sdio:c*v02D0d4335* brcmfmac
> alias sdio:c*v02D0dA962* brcmfmac
> alias sdio:c*v02D0dA94D* brcmfmac
> alias sdio:c*v02D0dA94C* brcmfmac
> alias sdio:c*v02D0d4334* brcmfmac
> alias sdio:c*v02D0d4330* brcmfmac
> alias sdio:c*v02D0d4329* brcmfmac
> alias sdio:c*v02D0d4324* brcmfmac
> alias sdio:c*v02D0dA887* brcmfmac
> alias sdio:c*v02DFd9104* libertas_sdio
> alias sdio:c*v02DFd9103* libertas_sdio
> alias sdio:c*v02DFd9141* mwifiex_sdio
> alias sdio:c*v02DFd9139* mwifiex_sdio
> alias sdio:c*v02DFd9135* mwifiex_sdio
> alias sdio:c*v02DFd912D* mwifiex_sdio
> alias sdio:c*v02DFd9129* mwifiex_sdio
> alias sdio:c*v02DFd9119* mwifiex_sdio
> alias sdio:c*v02DFd9116* mwifiex_sdio
> alias sdio:c*v039Ad0800* smssdio
> alias sdio:c*v039Ad0700* smssdio
> alias sdio:c*v039Ad0600* smssdio
> alias sdio:c*v039Ad0500* smssdio
> alias sdio:c*v039Ad0302* smssdio
> alias sdio:c*v039Ad0301* smssdio
> alias sdio:c*v039Ad0300* smssdio
> alias sdio:c*v039Ad0201* smssdio
> alias sdio:c*v039Ad1100* smssdio
> alias sdio:c*v039Ad5347* smssdio
> alias sdio:c04v*d* sdio_uart
> alias sdio:c01v*d* sdio_uart
> alias sdio:c09v*d* btsdio
> alias sdio:c03v*d* btsdio
> alias sdio:c02v*d* btsdio
> alias sdio:c*v02DFd9142* btmrvl_sdio
> alias sdio:c*v02DFd912E* btmrvl_sdio
> alias sdio:c*v02DFd9136* btmrvl_sdio
> alias sdio:c*v02DFd912A* btmrvl_sdio
> alias sdio:c*v02DFd911B* btmrvl_sdio
> alias sdio:c*v02DFd911A* btmrvl_sdio
> alias sdio:c*v02DFd9105* btmrvl_sdio
> paolo@paolo:~$
> 

Re: Problem with the wifi

[Arend van Spriel]

+ linux-wireless
+ Larry

please keep linux-wireless in this thread.

On 08-08-17 08:21, Paolo Bettini wrote:
> Arend van Spriel ha scritto:
>> + linux-wireless On 07-08-17 21:38, Paolo Bettini wrote:
>>> Hi , i am Paolo and i installed Debian stretch on my ezbook2 . One
>>> problem is the wifi , the card a SDIO device , seems to be 02d0:a9a6
>>> linux id or Broadcom AP6212 for windowsi installed deb package
>>> firmware-brcm80211 and nvram sdio txt in /lib/firmware/brcm, reloaded
>>> bcrmfmac module but nothing the card seems invisible or dead i don't
>>> know if is a problem of firmware or my system cannot detect the sdio
>>> card ...do you know something about this problematic ?
>> As always a kernel log could help or output from dmesg command. Also
>> can you run following commands: $ ls /sys/bus/sdio/devices $ cat
>> /sys/bus/sdio/devices/*/modalias Regards, Arend
> paolo@paolo:~$ ls /sys/bus/sdio/devices
> mmc1:0001:1
> paolo@paolo:~$
> 
> 
> paolo@paolo:~$ cat /sys/bus/sdio/devices/*/modalias sdio:c07v024CdB723
> paolo@paolo:~$ sorry for previous mail ls was from another pc:-[
> it seems the system see only the card where the system is installed

Hi Paolo,

Interesting. Now if Google search is correct the vendor id for this
device indicates this is a Realtek (v024C) WLAN (c07) device. So what
makes you say its linux id is 02d0:a9a6?

In upstream linux I do not see any SDIO device drivers in realtek
folder. Maybe Larry can provide clue/hint if a driver for this device is
publicly available somewhere.

Regards,
Arend

Re: [PATCH v3] iwlwifi: Demote messages about fw flags size to info

[Coelho, Luciano]

On Thu, 2017-08-03 at 07:47 -0700, João Paulo Rechi Vita wrote:
> These messages are not reporting a real error, just the fact that the
> firmware knows about more flags than the driver.
> 
> Currently these messages are presented to the user during boot if there
> is no bootsplash covering the console, even when booting the kernel with
> "quiet".
> 
> Demoting it to the warn level helps having a clean boot process.
> 
> Signed-off-by: João Paulo Rechi Vita 
> ---
> 
> v2 changes:
>  - Set to warn level instead of info
> 
> v3 changes:
>  - Fix commit message typo

Thanks, João Paulo! I pushed this to our internal tree and it will
eventually reach the mainline following our normal upstreaming process.

--
Cheers,
Luca.

RE: [v5] wlcore: add missing nvs file name info for wilink8

[Reizer, Eyal]

> Subject: Re: [v5] wlcore: add missing nvs file name info for wilink8
> 
> * Reizer, Eyal  [170807 00:47]:
> > Hi Tony,
> > >
> > > * Reizer, Eyal  [170807 00:32]:
> > > > The following commits:
> > > > c815fde wlcore: spi: Populate config firmware data
> > > > d776fc8 wlcore: sdio: Populate config firmware data
> > > >
> > > > Populated the nvs entry for wilink6 and wilink7 only while it is
> > > > still needed for wilink8 as well.
> > > > This broke user space backward compatibility when upgrading from
> older
> > > > kernels, as the alternate mac address would not be read from the nvs
> that
> > > is
> > > > present in the file system (lib/firmware/ti-connectivity/wl1271-nvs.bin)
> > > > causing mac address change of the wlan interface.
> > > >
> > > > This patch fix this and update the structure field with the same default
> > > > nvs file name that has been used before.
> > > >
> > > > In addition, some distros hold a default wl1271-nvs.bin in the file
> > > > system with a bogus mac address (deadbeef...) that for a wl18xx device
> > > > also overrides the mac address that is stored inside the device.
> > > > Warn users about this bogus mac address and use a random mac
> instead
> > >
> > > Hmm looks pretty good to me except for one more thing I just noticed.
> > >
> > > Why don't you just use the hardware mac address instead of a random
> > > mac address on wl18xx device when you see a bogus nvs file?
> > >
> >
> > I agree that this would have been better but the problem is that hardware
> > mac address is available for wilink8 onlyWilink6/7 don't have one stored.
> > The wlcore code responsible for handling mac address is common code
> > and there is method for detecting between them in this module.
> 
> Care to clarify a bit.. Are you saying wilink8 will use the hardware
> mac address in case of bogus nvs file?
> 
With present implementation it will not. It will use the random one for both 
wilink6/7 as well as wilink8.
I need to get a hold of a wilink6/7 module and see if reverting to an internal 
mac address is working. Will try to look around as it has been a while since 
I used one.

Best Regards,
Eyal

Re: [PATCH v2 2/3] brcmfmac: Add support for CYW4373 SDIO/USB chipset

[Chi-Hsien Lin]

On 08/07/2017 8:27, Arend van Spriel wrote:

On 8/3/2017 11:37 AM, Wright Feng wrote:

From: Chi-Hsien Lin 

Add support for CYW4373 SDIO/USB chipset.
CYW4373 is a 1x1 dual-band 11ac chipset with 20/40/80Mhz channel support.
It's a WiFi/BT combo device.


Reviewed-by: Arend van Spriel 

Signed-off-by: Chi-Hsien Lin 
---
v2: add new chip(4737) info in commit message


comment below...


---
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 1 +
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c   | 2 ++
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c   | 4 +++-
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c| 9 
-

  drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 3 +++
  include/linux/mmc/sdio_ids.h  | 1 +
  6 files changed, 18 insertions(+), 2 deletions(-)



[...]


diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h
index b733eb4..abacd54 100644
--- a/include/linux/mmc/sdio_ids.h
+++ b/include/linux/mmc/sdio_ids.h
@@ -39,6 +39,7 @@
  #define SDIO_DEVICE_ID_BROADCOM_434550xa9bf
  #define SDIO_DEVICE_ID_BROADCOM_43540x4354
  #define SDIO_DEVICE_ID_BROADCOM_43560x4356
+#define SDIO_DEVICE_ID_CYPRESS_43730x4373


So is there no specific Cypress SDIO vendor ID?
There is no Cypress SDIO vid. I believe the legacy chips 4343w ...etc. 
shipped are still using BRCM SDIO vid. Also, 4373 project was initiated 
in Broadcom so the default id was set to the Broadcom id. Will it a 
requirement to add Cypress vid here?






  #define SDIO_VENDOR_ID_INTEL0x0089
  #define SDIO_DEVICE_ID_INTEL_IWMC3200WIMAX0x1402



.

Re: [PATCH v3] rt2x00: Fix MMIC Countermeasures

[Stanislaw Gruszka]

On Mon, Aug 07, 2017 at 12:47:36PM -0400, Michael Skeffingfon wrote:
> Set RX_FLAG_DECRYPTED in case of MMIC failure so that
> ieee80211_rx_h_decrypt() doesnt drop the frame before getting to
> ieee80211_rx_h_michael_mic_verify().
> 
> Signed-off-by: Michael Skeffington 

Acked-by: Stanislaw Gruszka