[PATCH] cfg80211: Allow cfg80211_connect_result() errors to be distinguished

[Jouni Malinen]

Previously, the status parameter to cfg80211_connect_result() was
documented as using WLAN_STATUS_UNSPECIFIED_FAILURE (1) when the real
status code for the failure is not known. This value can be used by an
AP (and often is) and as such, user space cannot distinguish between
explicitly rejected authentication/association and not being able to
even try to associate or not receiving a response from the AP.

Add a new inline function, cfg80211_connect_timeout(), to be used when
the driver knows that the connection attempt failed due to a reason
where connection could not be attempt or no response was received from
the AP. The internal functions now allow a negative status value (-1) to
be used as an indication of this special case. This results in the
NL80211_ATTR_TIMED_OUT to be added to the NL80211_CMD_CONNECT event to
allow user space to determine this case was hit. For backwards
compatibility, NL80211_STATUS_CODE with the value
WLAN_STATUS_UNSPECIFIED_FAILURE is still indicated in the event in such
a case.

Signed-off-by: Jouni Malinen 
---
 include/net/cfg80211.h   | 54 ++--
 include/uapi/linux/nl80211.h |  7 +-
 net/wireless/core.h  |  4 ++--
 net/wireless/nl80211.c   |  7 --
 net/wireless/nl80211.h   |  2 +-
 net/wireless/sme.c   |  6 ++---
 6 files changed, 58 insertions(+), 22 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 58cdd42..b60c244 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2367,19 +2367,26 @@ struct cfg80211_qos_map {
  * (invoked with the wireless_dev mutex held)
  *
  * @connect: Connect to the ESS with the specified parameters. When connected,
- * call cfg80211_connect_result() with status code %WLAN_STATUS_SUCCESS.
- * If the connection fails for some reason, call cfg80211_connect_result()
- * with the status from the AP. The driver is allowed to roam to other
- * BSSes within the ESS when the other BSS matches the connect parameters.
- * When such roaming is initiated by the driver, the driver is expected to
- * verify that the target matches the configured security parameters and
- * to use Reassociation Request frame instead of Association Request frame.
- * The connect function can also be used to request the driver to perform
- * a specific roam when connected to an ESS. In that case, the prev_bssid
+ * call cfg80211_connect_result()/cfg80211_connect_bss() with status code
+ * %WLAN_STATUS_SUCCESS. If the connection fails for some reason, call
+ * cfg80211_connect_result()/cfg80211_connect_bss() with the status code
+ * from the AP or cfg80211_connect_timeout() if no frame with status code
+ * was received.
+ *
+ * The driver is allowed to roam to other BSSes within the ESS when the
+ * other BSS matches the connect parameters. When such roaming is initiated
+ * by the driver, the driver is expected to verify that the target matches
+ * the configured security parameters and to use Reassociation Request
+ * frame instead of Association Request frame.
+ *
+ * The connect function can also be used to request the driver to perform a
+ * specific roam when connected to an ESS. In that case, the prev_bssid
  * parameter is set to the BSSID of the currently associated BSS as an
- * indication of requesting reassociation. In both the driver-initiated and
- * new connect() call initiated roaming cases, the result of roaming is
- * indicated with a call to cfg80211_roamed() or cfg80211_roamed_bss().
+ * indication of requesting reassociation.
+ *
+ * In both the driver-initiated and new connect() call initiated roaming
+ * cases, the result of roaming is indicated with a call to
+ * cfg80211_roamed() or cfg80211_roamed_bss().
  * (invoked with the wireless_dev mutex held)
  * @disconnect: Disconnect from the BSS/ESS.
  * (invoked with the wireless_dev mutex held)
@@ -4736,6 +4743,29 @@ cfg80211_connect_result(struct net_device *dev, const u8 
*bssid,
 }
 
 /**
+ * cfg80211_connect_timeout - notify cfg80211 of connection timeout
+ *
+ * @dev: network device
+ * @bssid: the BSSID of the AP
+ * @req_ie: association request IEs (maybe be %NULL)
+ * @req_ie_len: association request IEs length
+ * @gfp: allocation flags
+ *
+ * It should be called by the underlying driver whenever connect() has failed
+ * in a sequence where no explicit authentication/association rejection was
+ * received from the AP. This could happen, e.g., due to not being able to send
+ * out the Authentication or Association Request frame or timing out while
+ * waiting for the response.
+ */
+static inline void
+cfg80211_connect_timeout(struct net_device *dev, const u8 *bssid,
+const u8 *req_ie, size_t req_ie_len, gfp_t gfp)
+{
+   cfg80211_connect_bss(dev, bssid, NULL, req_ie, req_ie_len, NULL, 0, -1,
+  

Re: linux-next: Tree for May 30

[Sudip Mukherjee]

On Monday 30 May 2016 08:52 AM, Stephen Rothwell wrote:

Hi all,

Changes since 20160527:


Hi All,
I have just built and booted with next-20160530 and my dmesg is full of 
warnings from ath9k. Last kernel tested was v4.6 and there was no 
problem with that.


The traces are like:
Call Trace:
 [] dump_stack+0x63/0x87
 [] __warn+0xd1/0xf0
 [] warn_slowpath_null+0x1d/0x20
 [] ath9k_hw_gpio_request+0x6f/0x320 [ath9k_hw]
 [] ath9k_hw_reset+0xfe4/0x12e0 [ath9k_hw]
 [] ath_reset_internal+0x104/0x1f0 [ath9k]
 [] ath_reset+0x3d/0x60 [ath9k]
 [] ath_chanctx_set_channel+0x1b6/0x300 [ath9k]
 [] ath9k_config+0xc6/0x1f0 [ath9k]
 [] ? mutex_lock+0x12/0x2f
 [] ieee80211_hw_config+0x63/0x350 [mac80211]
 [] ieee80211_scan_work+0x161/0x480 [mac80211]
 [] process_one_work+0x153/0x3f0
 [] worker_thread+0x12b/0x4b0
 [] ? rescuer_thread+0x340/0x340
 [] kthread+0xc9/0xe0
 [] ret_from_fork+0x1f/0x40
 [] ? kthread_park+0x60/0x60
---[ end trace 27eb5094a52869ea ]---

Call Trace:
 [] dump_stack+0x63/0x87
 [] __warn+0xd1/0xf0
 [] warn_slowpath_null+0x1d/0x20
 [] ath9k_hw_gpio_get+0x1a9/0x1b0 [ath9k_hw]
 [] ath9k_rfkill_poll_state+0x34/0x60 [ath9k]
 [] ieee80211_rfkill_poll+0x33/0x40 [mac80211]
 [] cfg80211_rfkill_poll+0x2a/0xc0 [cfg80211]
 [] rfkill_poll+0x24/0x50
 [] process_one_work+0x153/0x3f0
 [] worker_thread+0x12b/0x4b0
 [] ? rescuer_thread+0x340/0x340
 [] kthread+0xc9/0xe0
 [] ret_from_fork+0x1f/0x40
 [] ? kthread_park+0x60/0x60
---[ end trace 27eb5094a5286a3d ]---


If it is a known problem then great.. else i can debug and see what the 
problem is. There are only few patches added for GPIO, so should not be 
a problem to find out what is causing the error.


Regards
Sudip

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] rtlwifi: fix error handling in *_read_adapter_info()

[Larry Finger]

On 05/30/2016 10:26 AM, Arnd Bergmann wrote:

There are nine copies of the _rtl88ee_read_adapter_info() function,
and most but not all of them cause a build warning in some configurations:

rtl8192de/hw.c: In function '_rtl92de_read_adapter_info':
rtl8192de/hw.c:1767:12: error: 'hwinfo' may be used uninitialized in this 
function [-Werror=maybe-uninitialized]
rtl8723ae/hw.c: In function '_rtl8723e_read_adapter_info.constprop':
rtlwifi/rtl8723ae/hw.c:1654:12: error: 'hwinfo' may be used uninitialized in 
this function [-Werror=maybe-uninitialized]

The problem is that when rtlefuse->epromtype is something other than
EEPROM_BOOT_EFUSE, the rest of the function uses undefined data, resulting
in random behavior later.

Apparently, in some drivers, the problem was already found and fixed
but the fix did not make it into the others.

This picks one approach to deal with the problem and applies identical
code to all 9 files, to simplify the later consolidation of those.

Signed-off-by: Arnd Bergmann 
---
  drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 12 +++-
  drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 17 -
  drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 16 +++-
  drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 16 +++-
  drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c | 12 +++-
  drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 20 ++--
  drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 13 +
  drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 16 
  drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 15 +++
  9 files changed, 94 insertions(+), 43 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
index 8ee83b093c0d..e26a233684bb 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
@@ -1839,20 +1839,22 @@ static void _rtl88ee_read_adapter_info(struct 
ieee80211_hw *hw)
u8 hwinfo[HWSET_MAX_SIZE];
u16 eeprom_id;

-   if (rtlefuse->epromtype == EEPROM_BOOT_EFUSE) {
+   switch (rtlefuse->epromtype) {
+   case EEPROM_BOOT_EFUSE:
rtl_efuse_shadow_map_update(hw);
+   break;

-   memcpy(hwinfo, >efuse_map[EFUSE_INIT_MAP][0],
-  HWSET_MAX_SIZE);
-   } else if (rtlefuse->epromtype == EEPROM_93C46) {
+   case EEPROM_93C46:
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
 "RTL819X Not boot from eeprom, check it !!");
return;
-   } else {
+
+   default:
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
 "boot from neither eeprom nor efuse, check it !!");
return;
}
+   memcpy(hwinfo, >efuse_map[EFUSE_INIT_MAP][0], HWSET_MAX_SIZE);

RT_PRINT_DATA(rtlpriv, COMP_INIT, DBG_DMESG, "MAP\n",
  hwinfo, HWSET_MAX_SIZE);
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
index 04eb5c3f8464..58b7ac6899ef 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
@@ -1680,21 +1680,28 @@ static void _rtl92ce_read_adapter_info(struct 
ieee80211_hw *hw)
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_efuse *rtlefuse = rtl_efuse(rtl_priv(hw));
struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
+   struct device *dev = _pcipriv(hw)->dev.pdev->dev;
u16 i, usvalue;
u8 hwinfo[HWSET_MAX_SIZE];
u16 eeprom_id;

-   if (rtlefuse->epromtype == EEPROM_BOOT_EFUSE) {
+   switch (rtlefuse->epromtype) {
+   case EEPROM_BOOT_EFUSE:
rtl_efuse_shadow_map_update(hw);
+   break;

-   memcpy((void *)hwinfo,
-  (void *)>efuse_map[EFUSE_INIT_MAP][0],
-  HWSET_MAX_SIZE);
-   } else if (rtlefuse->epromtype == EEPROM_93C46) {
+   case EEPROM_93C46:
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
 "RTL819X Not boot from eeprom, check it !!");
+   return;
+
+   default:
+   dev_warn(dev, "no efuse data\n");
+   return;
}

+   memcpy(hwinfo, >efuse_map[EFUSE_INIT_MAP][0], HWSET_MAX_SIZE);
+
RT_PRINT_DATA(rtlpriv, COMP_INIT, DBG_DMESG, "MAP",
  hwinfo, HWSET_MAX_SIZE);

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
index 34ce06441d1b..ae1129f916d5 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
@@ -351,15 +351,21 @@ static void _rtl92cu_read_adapter_info(struct 
ieee80211_hw 

[PATCH] rtlwifi: fix error handling in *_read_adapter_info()

[Arnd Bergmann]

There are nine copies of the _rtl88ee_read_adapter_info() function,
and most but not all of them cause a build warning in some configurations:

rtl8192de/hw.c: In function '_rtl92de_read_adapter_info':
rtl8192de/hw.c:1767:12: error: 'hwinfo' may be used uninitialized in this 
function [-Werror=maybe-uninitialized]
rtl8723ae/hw.c: In function '_rtl8723e_read_adapter_info.constprop':
rtlwifi/rtl8723ae/hw.c:1654:12: error: 'hwinfo' may be used uninitialized in 
this function [-Werror=maybe-uninitialized]

The problem is that when rtlefuse->epromtype is something other than
EEPROM_BOOT_EFUSE, the rest of the function uses undefined data, resulting
in random behavior later.

Apparently, in some drivers, the problem was already found and fixed
but the fix did not make it into the others.

This picks one approach to deal with the problem and applies identical
code to all 9 files, to simplify the later consolidation of those.

Signed-off-by: Arnd Bergmann 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 12 +++-
 drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 17 -
 drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 16 +++-
 drivers/net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 16 +++-
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c | 12 +++-
 drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 20 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 13 +
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 16 
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 15 +++
 9 files changed, 94 insertions(+), 43 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
index 8ee83b093c0d..e26a233684bb 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
@@ -1839,20 +1839,22 @@ static void _rtl88ee_read_adapter_info(struct 
ieee80211_hw *hw)
u8 hwinfo[HWSET_MAX_SIZE];
u16 eeprom_id;
 
-   if (rtlefuse->epromtype == EEPROM_BOOT_EFUSE) {
+   switch (rtlefuse->epromtype) {
+   case EEPROM_BOOT_EFUSE:
rtl_efuse_shadow_map_update(hw);
+   break;
 
-   memcpy(hwinfo, >efuse_map[EFUSE_INIT_MAP][0],
-  HWSET_MAX_SIZE);
-   } else if (rtlefuse->epromtype == EEPROM_93C46) {
+   case EEPROM_93C46:
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
 "RTL819X Not boot from eeprom, check it !!");
return;
-   } else {
+
+   default:
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
 "boot from neither eeprom nor efuse, check it !!");
return;
}
+   memcpy(hwinfo, >efuse_map[EFUSE_INIT_MAP][0], HWSET_MAX_SIZE);
 
RT_PRINT_DATA(rtlpriv, COMP_INIT, DBG_DMESG, "MAP\n",
  hwinfo, HWSET_MAX_SIZE);
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
index 04eb5c3f8464..58b7ac6899ef 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
@@ -1680,21 +1680,28 @@ static void _rtl92ce_read_adapter_info(struct 
ieee80211_hw *hw)
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_efuse *rtlefuse = rtl_efuse(rtl_priv(hw));
struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
+   struct device *dev = _pcipriv(hw)->dev.pdev->dev;
u16 i, usvalue;
u8 hwinfo[HWSET_MAX_SIZE];
u16 eeprom_id;
 
-   if (rtlefuse->epromtype == EEPROM_BOOT_EFUSE) {
+   switch (rtlefuse->epromtype) {
+   case EEPROM_BOOT_EFUSE:
rtl_efuse_shadow_map_update(hw);
+   break;
 
-   memcpy((void *)hwinfo,
-  (void *)>efuse_map[EFUSE_INIT_MAP][0],
-  HWSET_MAX_SIZE);
-   } else if (rtlefuse->epromtype == EEPROM_93C46) {
+   case EEPROM_93C46:
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
 "RTL819X Not boot from eeprom, check it !!");
+   return;
+
+   default:
+   dev_warn(dev, "no efuse data\n");
+   return;
}
 
+   memcpy(hwinfo, >efuse_map[EFUSE_INIT_MAP][0], HWSET_MAX_SIZE);
+
RT_PRINT_DATA(rtlpriv, COMP_INIT, DBG_DMESG, "MAP",
  hwinfo, HWSET_MAX_SIZE);
 
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
index 34ce06441d1b..ae1129f916d5 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c
@@ -351,15 +351,21 @@ static void _rtl92cu_read_adapter_info(struct 
ieee80211_hw *hw)
u8 hwinfo[HWSET_MAX_SIZE] = {0};
   

Re: [Make-wifi-fast] [RFC] ath9k: Measure per-station airtime usage

[Toke Høiland-Jørgensen]

Michal Kazior  writes:

>> +void ath_debug_tx_airtime(struct ath_softc *sc,
>> + struct ath_node *an,
>> + struct ath_tx_status *ts)
>> +{
>> +   struct ath_airtime_stats *astats;
>> +
>> +   rcu_read_lock();
>> +
>> +   astats = >airtime_stats;
>> +   astats->tx_airtime += ts->duration;
>
> I'm not ath9k expert but this seems to be oblivious to tx retries. The
> ts->duration is acquired from the last used tx rate for given frame.
> Or am I missing something?

No, don't think you are. Wasn't sure what exactly that duration field
included, but I think you're right that it doesn't factor in retries.

> I think you should use ts->ts_rateindex and ts->ts_longretry to factor
> in retries (see ath_tx_rc_status).

I'll go digging. Thanks, this was exactly the kind of feedback I had
hoped for! :)

-Toke
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Make-wifi-fast] [RFC] ath9k: Measure per-station airtime usage

[Michal Kazior]

On 26 May 2016 at 15:50, Toke Høiland-Jørgensen  wrote:
> This is my attempt to add per-station airtime usage accounting to ath9k.
> For now I just export it to a new debugfs entry, but my plan is to use
> it to make (station) scheduling decisions. However, before attempting
> that I would like some feedback from someone more familiar with the
> ath9k than me as to whether this way of measuring airtime usage is
> likely to give reasonable results.
>
> I realise that there's probably some things I'm missing, but an initial
> test run indicates that the values are at least in the right ballpark (I
> get a total of ~170k usecs of measured airtime per 200 ms sampling
> interval when running three simultaneous TCP streams to three different
> stations).
>
> So can anyone comment on whether I'm on the right track here? And
> possibly provide some more detail as to what I'm missing and how to
> remedy that?
[...]
>
> +void ath_debug_tx_airtime(struct ath_softc *sc,
> + struct ath_node *an,
> + struct ath_tx_status *ts)
> +{
> +   struct ath_airtime_stats *astats;
> +
> +   rcu_read_lock();
> +
> +   astats = >airtime_stats;
> +   astats->tx_airtime += ts->duration;

I'm not ath9k expert but this seems to be oblivious to tx retries. The
ts->duration is acquired from the last used tx rate for given frame.
Or am I missing something?

I think you should use ts->ts_rateindex and ts->ts_longretry to factor
in retries (see ath_tx_rc_status).


Michał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] ath10k: Add support for QCA9887

[Sven Eckelmann]

On Friday 27 May 2016 12:44:52 Valo, Kalle wrote:
[...]
> > But maybe I should add that the results with the original AP147 firmware 
> > also
> > wasn't better.
> 
> That doesn't sound good. Maybe a calibration issue?

Maybe but I don't have a different card to compare it to.

[...]
> I pushed a new firmware image firmware-5.bin_10.2.3.31.7-2 with those
> enabled:
> 
> https://github.com/kvalo/ath10k-firmware/tree/master/QCA9887

Thanks for the updated firmware file. I have done some basic tests and seems
to work fine. Bindiff also looks fine

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 0/8] mwifiex: Fix some error handling issues in mwifiex_sdio_probe() function

[Enric Balletbo Serra]

Hi Javier,

2016-05-27 16:18 GMT+02:00 Javier Martinez Canillas :
> Hello,
>
> While booting a system with a mwifiex WiFi card, I noticed the following
> missleading error message:
>
> [  12.480042] mwifiex_sdio mmc2:0001:1: sdio platform data not available
>
> This error only applies to platforms that define a child node for the SDIO
> device, but it's currently shown even in platforms that don't have a child
> node defined.
>
> So this series fixes this issue and others I found in the .probe function
> (mostly related to error handling and the error path) while looking at it.
>

The patches looks good to me and tested on my Veyron Chromebook, so
for all this series:

Tested-by: Enric Balletbo i Serra 

Thanks,
  Enric

> Best regards,
> Javier
>
>
> Javier Martinez Canillas (8):
>   mwifiex: only call mwifiex_sdio_probe_of() if dev has an OF node
>   mwifiex: propagate sdio_enable_func() errno code in
> mwifiex_sdio_probe()
>   mwifiex: propagate mwifiex_add_card() errno code in
> mwifiex_sdio_probe()
>   mwifiex: consolidate mwifiex_sdio_probe() error paths
>   mwifiex: use dev_err() instead of pr_err() in mwifiex_sdio_probe()
>   mwifiex: check if mwifiex_sdio_probe_of() fails and return error
>   mwifiex: don't print an error if an optional DT property is missing
>   mwifiex: use better message and error code when OF node doesn't match
>
>  drivers/net/wireless/marvell/mwifiex/sdio.c | 46 
> ++---
>  1 file changed, 28 insertions(+), 18 deletions(-)
>
> --
> 2.5.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 03/10] nl80211: Prefer ether_addr_copy

[Kirtika Ruchandani]

> This looks right to me, but doesn't ether_addr_copy() have alignment
> requirements? Could someone more familiar with that review these
> changes to ensure they're met?

Thanks for catching this.
The requirement is to be __aligned(2). I've added 4 instances of
ether_addr_copy with 8 addresses as arguments.  Of these, the 4
src arguments are really the same type (i.e. nla_data acting on a
const nlattr*), so I'll try to reason about the 5 total cases below -
1. cfg->dst_mac should be 16-bit aligned due to the layout of
struct cfg80211_wowlan_tcp. Its offset is 10 or 12 bytes in the
structure depending on the system.
2 and 3. For mac_addr and mac_addr_mask, nl80211_parse_random_mac
takes these in as u8* (and hence does not guarantee alignment?)
Both the callers of this function today pass in arguments that are
explicitly __aligned(2). But this cannot be said of future potential callers
- so perhaps my patch introduces a bug?
4. Based on struct cfg80211_acl_data, acl->mac_addrs[i] should be not
guaranteed to be __aligned(2).
5. For all the nla_data src arguments, the nla_data function returns
((char*) foo + 5) for pointer foo. So likely not __aligned(2).

Based on 3, 4 and 5, this patch should be revoked, but it would be nice
to have a confirmation from someone else.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 06/10] nl80211: Various checkpatch.pl spacing fixes

[Julian Calaby]

Hi All,

On Mon, May 30, 2016 at 12:53 PM, Kirtika Ruchandani
 wrote:
> This patch fixes the following spacing issues reported
> by checkpatch.pl -
> - space preferred around that 
> - no space needed after cast.
> - Alignment should match open parenthesis
> - suspect code indent for conditional statements
> - Statements should start on a tabstop
>
> This patch also contains two hunks to fix 'line over 80 characters',
> that are spacing related.
> All other instances of that warning have been ignored.
>
> Signed-off-by: Kirtika Ruchandani 

With Kirtika's explanation, this is:

Reviewed-by: Julian Calaby 

Thanks,

Julian Calaby


> ---
>  net/wireless/nl80211.c | 103 
> ++---
>  1 file changed, 54 insertions(+), 49 deletions(-)
>
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 11cbf0b..ad7cdce 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -39,10 +39,10 @@ static void nl80211_post_doit(const struct genl_ops *ops, 
> struct sk_buff *skb,
>
>  /* the netlink family */
>  static struct genl_family nl80211_fam = {
> -   .id = GENL_ID_GENERATE, /* don't bother with a hardcoded ID */
> -   .name = NL80211_GENL_NAME,  /* have users key off the name 
> instead */
> -   .hdrsize = 0,   /* no private header */
> -   .version = 1,   /* no particular meaning now */
> +   .id = GENL_ID_GENERATE, /* don't bother with a hardcoded ID */
> +   .name = NL80211_GENL_NAME,  /* have users key off the name instead */
> +   .hdrsize = 0,   /* no private header */
> +   .version = 1,   /* no particular meaning now */
> .maxattr = NL80211_ATTR_MAX,
> .netnsok = true,
> .pre_doit = nl80211_pre_doit,
> @@ -213,7 +213,7 @@ cfg80211_get_dev_from_info(struct net *netns, struct 
> genl_info *info)
>  static const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = {
> [NL80211_ATTR_WIPHY] = { .type = NLA_U32 },
> [NL80211_ATTR_WIPHY_NAME] = { .type = NLA_NUL_STRING,
> - .len = 20-1 },
> + .len = 20 - 1 },
> [NL80211_ATTR_WIPHY_TXQ_PARAMS] = { .type = NLA_NESTED },
>
> [NL80211_ATTR_WIPHY_FREQ] = { .type = NLA_U32 },
> @@ -231,7 +231,7 @@ static const struct nla_policy 
> nl80211_policy[NUM_NL80211_ATTR] = {
>
> [NL80211_ATTR_IFTYPE] = { .type = NLA_U32 },
> [NL80211_ATTR_IFINDEX] = { .type = NLA_U32 },
> -   [NL80211_ATTR_IFNAME] = { .type = NLA_NUL_STRING, .len = IFNAMSIZ-1 },
> +   [NL80211_ATTR_IFNAME] = { .type = NLA_NUL_STRING, .len = IFNAMSIZ - 1 
> },
>
> [NL80211_ATTR_MAC] = { .len = ETH_ALEN },
> [NL80211_ATTR_PREV_BSSID] = { .len = ETH_ALEN },
> @@ -967,7 +967,7 @@ static int nl80211_put_iface_combinations(struct wiphy 
> *wiphy,
> int i, j;
>
> nl_combis = nla_nest_start(msg,
> -   NL80211_ATTR_INTERFACE_COMBINATIONS);
> +  NL80211_ATTR_INTERFACE_COMBINATIONS);
> if (!nl_combis)
> goto nla_put_failure;
>
> @@ -1012,9 +1012,9 @@ static int nl80211_put_iface_combinations(struct wiphy 
> *wiphy,
> goto nla_put_failure;
> if (large &&
> (nla_put_u32(msg, NL80211_IFACE_COMB_RADAR_DETECT_WIDTHS,
> -   c->radar_detect_widths) ||
> +c->radar_detect_widths) ||
>  nla_put_u32(msg, NL80211_IFACE_COMB_RADAR_DETECT_REGIONS,
> -   c->radar_detect_regions)))
> +c->radar_detect_regions)))
> goto nla_put_failure;
>
> nla_nest_end(msg, nl_combi);
> @@ -1493,7 +1493,7 @@ static int nl80211_send_wiphy(struct 
> cfg80211_registered_device *rdev,
>
> i = 0;
>  #define CMD(op, n) \
> -do {   \
> +   do {\
> if (rdev->ops->op) {\
> i++;\
> if (nla_put_u32(msg, i, NL80211_CMD_ ## n)) \
> @@ -1735,8 +1735,9 @@ static int nl80211_send_wiphy(struct 
> cfg80211_registered_device *rdev,
>rdev->wiphy.max_num_csa_counters))
> goto nla_put_failure;
>
> -   if (rdev->wiphy.regulatory_flags & 
> REGULATORY_WIPHY_SELF_MANAGED &&
> -   nla_put_flag(msg, NL80211_ATTR_WIPHY_SELF_MANAGED_REG))
> +   if ((rdev->wiphy.regulatory_flags &
> +  

Re: [PATCH v2 06/10] nl80211: Various checkpatch.pl spacing fixes

[Julian Calaby]

Hi Kirtika,

On Mon, May 30, 2016 at 4:04 PM, Kirtika Ruchandani
 wrote:
>> Adding the brackets around the & expression doesn't look spacing
>> related to me. What's the exact warning this is fixing?
>
> From the commit message - "This patch also contains two hunks to fix
> 'line over 80 characters',
> that are spacing related". This is the second hunk, the first being
> the comments in the nl80211_fam
> definition. Should I resend with these two hunks omitted, or fix my wording?

That explains it, I missed that bit.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 06/10] nl80211: Various checkpatch.pl spacing fixes

[Kirtika Ruchandani]

> Adding the brackets around the & expression doesn't look spacing
> related to me. What's the exact warning this is fixing?

>From the commit message - "This patch also contains two hunks to fix
'line over 80 characters',
that are spacing related". This is the second hunk, the first being
the comments in the nl80211_fam
definition. Should I resend with these two hunks omitted, or fix my wording?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html