Re: [PATCH 02/19] ipw2x00: use to_pci_dev()

2016-03-24 Thread Stanislav Yakovlev
On 18 March 2016 at 06:20, Julian Calaby  wrote:
> From: Geliang Tang 
>
> Use to_pci_dev() instead of open-coding it.
>
> Signed-off-by: Geliang Tang 
> Signed-off-by: Julian Calaby 
> ---
>  drivers/net/wireless/intel/ipw2x00/ipw2100.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Acked-by: Stanislav Yakovlev 

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


[PATCH v3] cfg80211: add start / stop NAN commands

2016-03-24 Thread Emmanuel Grumbach
This allows user space to start/stop NAN interface.
A NAN interface is like P2P device in a few aspects: it
doesn't have a netdev associated to it.
Add the new interface type and prevent operations that
can't be executed on NAN interface like scan.
Define several attributes that may be configured by user space
when starting NAN functionality (master preference and dual
band operation)

Signed-off-by: Andrei Otcheretianski 
Signed-off-by: Emmanuel Grumbach 
---
v3: fix the range of the master preference in the kerneldoc
---
 include/net/cfg80211.h   | 21 +-
 include/uapi/linux/nl80211.h | 44 
 net/mac80211/cfg.c   |  2 +
 net/mac80211/chan.c  |  3 ++
 net/mac80211/iface.c |  4 ++
 net/mac80211/offchannel.c|  1 +
 net/mac80211/rx.c|  3 ++
 net/mac80211/util.c  |  1 +
 net/wireless/chan.c  |  2 +
 net/wireless/core.c  | 34 
 net/wireless/core.h  |  3 ++
 net/wireless/mlme.c  |  1 +
 net/wireless/nl80211.c   | 96 ++--
 net/wireless/rdev-ops.h  | 20 +
 net/wireless/trace.h | 27 +
 net/wireless/util.c  |  6 ++-
 16 files changed, 261 insertions(+), 7 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9e1b24c..8a823a4 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2228,6 +2228,19 @@ struct cfg80211_qos_map {
 };
 
 /**
+ * struct cfg80211_nan_conf - nan configuration
+ *
+ * This struct defines nan configuration parameters
+ *
+ * @master_pref: master preference (1 - 255)
+ * @dual: dual band operation mode
+ */
+struct cfg80211_nan_conf {
+   u8 master_pref;
+   enum nl80211_nan_dual_band_conf dual;
+};
+
+/**
  * struct cfg80211_ops - backend description for wireless configuration
  *
  * This struct is registered by fullmac card drivers and/or wireless stacks
@@ -2500,6 +2513,8 @@ struct cfg80211_qos_map {
  * and returning to the base channel for communication with the AP.
  * @tdls_cancel_channel_switch: Stop channel-switching with a TDLS peer. Both
  * peers must be on the base channel when the call completes.
+ * @start_nan: Start the NAN interface.
+ * @stop_nan: Stop the NAN interface.
  */
 struct cfg80211_ops {
int (*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
@@ -2765,6 +2780,9 @@ struct cfg80211_ops {
void(*tdls_cancel_channel_switch)(struct wiphy *wiphy,
  struct net_device *dev,
  const u8 *addr);
+   int (*start_nan)(struct wiphy *wiphy, struct wireless_dev *wdev,
+struct cfg80211_nan_conf *conf);
+   void(*stop_nan)(struct wiphy *wiphy, struct wireless_dev *wdev);
 };
 
 /*
@@ -3486,6 +3504,7 @@ struct cfg80211_cached_keys;
  * beacons, 0 when not valid
  * @address: The address for this device, valid only if @netdev is %NULL
  * @p2p_started: true if this is a P2P Device that has been started
+ * @nan_started: true if this is a NAN interface that has been started
  * @cac_started: true if DFS channel availability check has been started
  * @cac_start_time: timestamp (jiffies) when the dfs state was entered.
  * @cac_time_ms: CAC time in ms
@@ -3517,7 +3536,7 @@ struct wireless_dev {
 
struct mutex mtx;
 
-   bool use_4addr, p2p_started;
+   bool use_4addr, p2p_started, nan_started;
 
u8 address[ETH_ALEN] __aligned(sizeof(u16));
 
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 5a30a75..6e27f1b 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -824,6 +824,16 @@
  * not running. The driver indicates the status of the scan through
  * cfg80211_scan_done().
  *
+ * @NL80211_CMD_START_NAN: Start NAN operation, identified by its
+ * %NL80211_ATTR_WDEV interface. This interface must have been previously
+ * created with %NL80211_CMD_NEW_INTERFACE. After it has been started, the
+ * NAN interface will create or join a cluster. This command must have a
+ * valid %NL80211_ATTR_NAN_MASTER_PREF attribute and optional
+ * %NL80211_ATTR_NAN_DUAL attributes.
+ * After this command NAN functions can be added.
+ * @NL80211_CMD_STOP_NAN: Stop the NAN operation, identified by
+ * its %NL80211_ATTR_WDEV interface.
+ *
  * @NL80211_CMD_MAX: highest used command number
  * @__NL80211_CMD_AFTER_LAST: internal use
  */
@@ -1012,6 +1022,9 @@ enum nl80211_commands {
 
NL80211_CMD_ABORT_SCAN,
 
+   NL80211_CMD_START_NAN,
+   NL80211_CMD_STOP_NAN,
+
/* add new commands above here */
 
/* used to define NL80211_CMD_MAX below */
@@ -1796,6 +1809,12 @@ enum nl80211_commands {
  * connecting to a PCP, and in %NL80211_CMD_START_AP to start
  * a PCP instead of 

Re: [PATCH v2] cfg80211: add start / stop NAN commands

2016-03-24 Thread Grumbach, Emmanuel
On Thu, 2016-03-24 at 19:30 +0100, Arend Van Spriel wrote:
> 
> On 24-3-2016 16:12, Emmanuel Grumbach wrote:
> > This allows user space to start/stop NAN interface.
> > A NAN interface is like P2P device in a few aspects: it
> > doesn't have a netdev associated to it.
> > Add the new interface type and prevent operations that
> > can't be executed on NAN interface like scan.
> > Define several attributes that may be configured by user space
> > when starting NAN functionality (master preference and dual
> > band operation)
> > 
> > Signed-off-by: Andrei Otcheretianski <
> > andrei.otcheretian...@intel.com>
> > Signed-off-by: Emmanuel Grumbach 
> > ---
> > v2: allow master preference 1 and 255 as required by the
> > certification
> > ---
> >  include/net/cfg80211.h   | 21 +-
> >  include/uapi/linux/nl80211.h | 44 
> >  net/mac80211/cfg.c   |  2 +
> >  net/mac80211/chan.c  |  3 ++
> >  net/mac80211/iface.c |  4 ++
> >  net/mac80211/offchannel.c|  1 +
> >  net/mac80211/rx.c|  3 ++
> >  net/mac80211/util.c  |  1 +
> >  net/wireless/chan.c  |  2 +
> >  net/wireless/core.c  | 34 
> >  net/wireless/core.h  |  3 ++
> >  net/wireless/mlme.c  |  1 +
> >  net/wireless/nl80211.c   | 96
> > ++--
> >  net/wireless/rdev-ops.h  | 20 +
> >  net/wireless/trace.h | 27 +
> >  net/wireless/util.c  |  6 ++-
> >  16 files changed, 261 insertions(+), 7 deletions(-)
> > 
> > diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> > index 9e1b24c..cb5ab88 100644
> > --- a/include/net/cfg80211.h
> > +++ b/include/net/cfg80211.h
> > @@ -2228,6 +2228,19 @@ struct cfg80211_qos_map {
> >  };
> >  
> >  /**
> > + * struct cfg80211_nan_conf - nan configuration
> > + *
> > + * This struct defines nan configuration parameters
> > + *
> > + * @master_pref: master preference (2 -254)
> 
> This seems to contradict the change log above...

Thanks for catching this.

> 
> > + * @dual: dual band operation mode
> > + */
> > +struct cfg80211_nan_conf {
> > +   u8 master_pref;
> > +   enum nl80211_nan_dual_band_conf dual;
> > +};
> > +
> > +/**
> >   * struct cfg80211_ops - backend description for wireless
> > configuration
> >   *
> >   * This struct is registered by fullmac card drivers and/or
> > wireless stacks
> > @@ -2500,6 +2513,8 @@ struct cfg80211_qos_map {
> >   * and returning to the base channel for communication with
> > the AP.
> >   * @tdls_cancel_channel_switch: Stop channel-switching with a TDLS
> > peer. Both
> >   * peers must be on the base channel when the call
> > completes.
> > + * @start_nan: Start the NAN interface.
> > + * @stop_nan: Stop the NAN interface.
> >   */
> >  struct cfg80211_ops {
> > int (*suspend)(struct wiphy *wiphy, struct
> > cfg80211_wowlan *wow);
> > @@ -2765,6 +2780,9 @@ struct cfg80211_ops {
> > void(*tdls_cancel_channel_switch)(struct wiphy
> > *wiphy,
> >   struct net_device
> > *dev,
> >   const u8 *addr);
> > +   int (*start_nan)(struct wiphy *wiphy, struct
> > wireless_dev *wdev,
> > +struct cfg80211_nan_conf *conf);
> > +   void(*stop_nan)(struct wiphy *wiphy, struct
> > wireless_dev *wdev);
> >  };
> >  
> >  /*
> > @@ -3486,6 +3504,7 @@ struct cfg80211_cached_keys;
> >   * beacons, 0 when not valid
> >   * @address: The address for this device, valid only if @netdev is
> > %NULL
> >   * @p2p_started: true if this is a P2P Device that has been
> > started
> > + * @nan_started: true if this is a NAN interface that has been
> > started
> >   * @cac_started: true if DFS channel availability check has been
> > started
> >   * @cac_start_time: timestamp (jiffies) when the dfs state was
> > entered.
> >   * @cac_time_ms: CAC time in ms
> > @@ -3517,7 +3536,7 @@ struct wireless_dev {
> >  
> > struct mutex mtx;
> >  
> > -   bool use_4addr, p2p_started;
> > +   bool use_4addr, p2p_started, nan_started;
> >  
> > u8 address[ETH_ALEN] __aligned(sizeof(u16));
> >  
> > diff --git a/include/uapi/linux/nl80211.h
> > b/include/uapi/linux/nl80211.h
> > index 5a30a75..e5a7cfb 100644
> > --- a/include/uapi/linux/nl80211.h
> > +++ b/include/uapi/linux/nl80211.h
> > @@ -824,6 +824,16 @@
> >   * not running. The driver indicates the status of the scan
> > through
> >   * cfg80211_scan_done().
> >   *
> > + * @NL80211_CMD_START_NAN: Start NAN operation, identified by its
> > + * %NL80211_ATTR_WDEV interface. This interface must have
> > been previously
> > + * created with %NL80211_CMD_NEW_INTERFACE. After it has
> > been started, the
> > + * NAN interface will create or join a cluster. This
> > command must have a
> > + * valid %NL80211_ATTR_NAN_MASTER_PREF attribute and
> > optional
> > + * %NL80211_ATTR_NAN_DUAL attributes.
> > + * 

Re: [PATCH v2] cfg80211: add start / stop NAN commands

2016-03-24 Thread Arend Van Spriel


On 24-3-2016 16:12, Emmanuel Grumbach wrote:
> This allows user space to start/stop NAN interface.
> A NAN interface is like P2P device in a few aspects: it
> doesn't have a netdev associated to it.
> Add the new interface type and prevent operations that
> can't be executed on NAN interface like scan.
> Define several attributes that may be configured by user space
> when starting NAN functionality (master preference and dual
> band operation)
> 
> Signed-off-by: Andrei Otcheretianski 
> Signed-off-by: Emmanuel Grumbach 
> ---
> v2: allow master preference 1 and 255 as required by the certification
> ---
>  include/net/cfg80211.h   | 21 +-
>  include/uapi/linux/nl80211.h | 44 
>  net/mac80211/cfg.c   |  2 +
>  net/mac80211/chan.c  |  3 ++
>  net/mac80211/iface.c |  4 ++
>  net/mac80211/offchannel.c|  1 +
>  net/mac80211/rx.c|  3 ++
>  net/mac80211/util.c  |  1 +
>  net/wireless/chan.c  |  2 +
>  net/wireless/core.c  | 34 
>  net/wireless/core.h  |  3 ++
>  net/wireless/mlme.c  |  1 +
>  net/wireless/nl80211.c   | 96 
> ++--
>  net/wireless/rdev-ops.h  | 20 +
>  net/wireless/trace.h | 27 +
>  net/wireless/util.c  |  6 ++-
>  16 files changed, 261 insertions(+), 7 deletions(-)
> 
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 9e1b24c..cb5ab88 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -2228,6 +2228,19 @@ struct cfg80211_qos_map {
>  };
>  
>  /**
> + * struct cfg80211_nan_conf - nan configuration
> + *
> + * This struct defines nan configuration parameters
> + *
> + * @master_pref: master preference (2 -254)

This seems to contradict the change log above...

> + * @dual: dual band operation mode
> + */
> +struct cfg80211_nan_conf {
> + u8 master_pref;
> + enum nl80211_nan_dual_band_conf dual;
> +};
> +
> +/**
>   * struct cfg80211_ops - backend description for wireless configuration
>   *
>   * This struct is registered by fullmac card drivers and/or wireless stacks
> @@ -2500,6 +2513,8 @@ struct cfg80211_qos_map {
>   *   and returning to the base channel for communication with the AP.
>   * @tdls_cancel_channel_switch: Stop channel-switching with a TDLS peer. Both
>   *   peers must be on the base channel when the call completes.
> + * @start_nan: Start the NAN interface.
> + * @stop_nan: Stop the NAN interface.
>   */
>  struct cfg80211_ops {
>   int (*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
> @@ -2765,6 +2780,9 @@ struct cfg80211_ops {
>   void(*tdls_cancel_channel_switch)(struct wiphy *wiphy,
> struct net_device *dev,
> const u8 *addr);
> + int (*start_nan)(struct wiphy *wiphy, struct wireless_dev *wdev,
> +  struct cfg80211_nan_conf *conf);
> + void(*stop_nan)(struct wiphy *wiphy, struct wireless_dev *wdev);
>  };
>  
>  /*
> @@ -3486,6 +3504,7 @@ struct cfg80211_cached_keys;
>   *   beacons, 0 when not valid
>   * @address: The address for this device, valid only if @netdev is %NULL
>   * @p2p_started: true if this is a P2P Device that has been started
> + * @nan_started: true if this is a NAN interface that has been started
>   * @cac_started: true if DFS channel availability check has been started
>   * @cac_start_time: timestamp (jiffies) when the dfs state was entered.
>   * @cac_time_ms: CAC time in ms
> @@ -3517,7 +3536,7 @@ struct wireless_dev {
>  
>   struct mutex mtx;
>  
> - bool use_4addr, p2p_started;
> + bool use_4addr, p2p_started, nan_started;
>  
>   u8 address[ETH_ALEN] __aligned(sizeof(u16));
>  
> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
> index 5a30a75..e5a7cfb 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -824,6 +824,16 @@
>   *   not running. The driver indicates the status of the scan through
>   *   cfg80211_scan_done().
>   *
> + * @NL80211_CMD_START_NAN: Start NAN operation, identified by its
> + *   %NL80211_ATTR_WDEV interface. This interface must have been previously
> + *   created with %NL80211_CMD_NEW_INTERFACE. After it has been started, the
> + *   NAN interface will create or join a cluster. This command must have a
> + *   valid %NL80211_ATTR_NAN_MASTER_PREF attribute and optional
> + *   %NL80211_ATTR_NAN_DUAL attributes.
> + *   After this command NAN functions can be added.
> + * @NL80211_CMD_STOP_NAN: Stop the NAN operation, identified by
> + *   its %NL80211_ATTR_WDEV interface.
> + *
>   * @NL80211_CMD_MAX: highest used command number
>   * @__NL80211_CMD_AFTER_LAST: internal use
>   */
> @@ -1012,6 +1022,9 @@ enum nl80211_commands {
>  
>   NL80211_CMD_ABORT_SCAN,
>  
> +  

Re: Google Summer of Code 2016 - Many new applications

2016-03-24 Thread Greg KH
On Thu, Mar 24, 2016 at 02:39:55PM -0300, Till Kamppeter wrote:
> Hi,
> 
> tomorrow the student application period will end. Up to now we got 22
> applications, where many lokk interesting and some really strange.
> 
> Most are for the kernel, many for LSB, and I had also some luck getting 3
> for OpenPrinting.
> 
> Please everyone of you, have a look whether there are proposals which you
> like to mentor, click the "WANT TO MENTOR" button on appropriate ones, and
> remeber the students to complete their applications if they are still marked
> "incomplete" (they must submit a final PDF). Only complete applications can
> get accepted and they do not auto-complete at the deadline.

I've gone through the submitted "kernel" ones so far.  I've been working
through email with one more student who hopefully will submit their
application before the deadline.

thanks,

greg k-h
--
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


Google Summer of Code 2016 - Many new applications

2016-03-24 Thread Till Kamppeter

Hi,

tomorrow the student application period will end. Up to now we got 22 
applications, where many lokk interesting and some really strange.


Most are for the kernel, many for LSB, and I had also some luck getting 
3 for OpenPrinting.


Please everyone of you, have a look whether there are proposals which 
you like to mentor, click the "WANT TO MENTOR" button on appropriate 
ones, and remeber the students to complete their applications if they 
are still marked "incomplete" (they must submit a final PDF). Only 
complete applications can get accepted and they do not auto-complete at 
the deadline.


So please remember the students interesting to you to complete their 
applications to do not loose them.


If you got this e-mail but are not registered as mentor but want to see 
the applications, please tell me so that I can invite you as mentor. You 
can read the applications then and step up to mentor a student, but you 
are not required to mentor a student then.


Note that tomorrow is a national holiday in many countries, so please 
send out any reminders, comments, ... today.


   Till

--
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] mwifiex: advertise low priority scan feature

2016-03-24 Thread Amitkumar Karwar
> From: Wei-Ning Huang [mailto:wnhu...@chromium.org]
> Sent: Tuesday, March 22, 2016 9:40 AM
> To: Linux Wireless
> Cc: LKML; Amitkumar Karwar; djku...@chromium.org; Wei-Ning Huang;
> Nishant Sarmukadam; kv...@codeaurora.org; net...@vger.kernel.org
> Subject: [PATCH v2] mwifiex: advertise low priority scan feature
> 
> From: Amitkumar Karwar 
> 
> Low priority scan handling code which delays or aborts scan operation
> based on Tx traffic is removed recently. The reason is firmware already
> takes care of it in our new feature scan channel gap. Hence we should
> advertise low priority scan support to cfg80211.
> 
> This patch fixes a problem in which OBSS scan request from
> wpa_supplicant was being rejected by cfg80211.
> 
> Signed-off-by: Amitkumar Karwar 
> Signed-off-by: Wei-Ning Huang 
> ---
>  drivers/net/wireless/marvell/mwifiex/cfg80211.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> index bb7235e..7dafc5b 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> @@ -4086,6 +4086,7 @@ int mwifiex_register_cfg80211(struct
> mwifiex_adapter *adapter)
> 
>   wiphy->features |= NL80211_FEATURE_HT_IBSS |
>  NL80211_FEATURE_INACTIVITY_TIMER |
> +NL80211_FEATURE_LOW_PRIORITY_SCAN |
>  NL80211_FEATURE_NEED_OBSS_SCAN;
> 
>   if (ISSUPP_TDLS_ENABLED(adapter->fw_cap_info))
> --
> 2.8.0.rc3.226.g39d4020

Acked-by: Amitkumar Karwar 

Regards,
Amitkumar
--
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 1/9] ath10k: speedup htt rx descriptor processing for tx completion

2016-03-24 Thread Manoharan, Rajkumar
[...]
>>
>> I see two new warnings on the kfifo_put() call:
>>
>> drivers/net/wireless/ath/ath10k/htt_rx.c:1722:22: warning: cast to non-scalar
>> drivers/net/wireless/ath/ath10k/htt_rx.c:1722:22: warning: cast from 
>> non-scalar
>>
>> But I suspect they are false warnings due to my old compiler:
>>
>> gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
>>
>> Opinions?
>>
> Hmm... I am not sure why older compiler is not complaining this. Unfortunately
> both x86 and cross compiler are not throwing any warnings though :(
>

older/latest/g--
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 1/9] ath10k: speedup htt rx descriptor processing for tx completion

2016-03-24 Thread Manoharan, Rajkumar
[...]
>
>> @@ -1712,7 +1710,20 @@ static void ath10k_htt_rx_frm_tx_compl(struct ath10k 
>> *ar,
>>   for (i = 0; i < resp->data_tx_completion.num_msdus; i++) {
>>   msdu_id = resp->data_tx_completion.msdus[i];
>>   tx_done.msdu_id = __le16_to_cpu(msdu_id);
>> - ath10k_txrx_tx_unref(htt, _done);
>> +
>> + /* kfifo_put: In practice firmware shouldn't fire off per-CE
>> +  * interrupt and main interrupt (MSI/-X range case) for the 
>> same
>> +  * HTC service so it should be safe to use kfifo_put w/o lock.
>> +  *
>> +  * From kfifo_put() documentation:
>> +  *  Note that with only one concurrent reader and one 
>> concurrent
>> +  *  writer, you don't need extra locking to use these macro.
>> +  */
>> + if (!kfifo_put(>txdone_fifo, tx_done)) {
>> + ath10k_warn(ar, "txdone fifo overrun, msdu_id %d 
>> status %d\n",
>> + tx_done.msdu_id, tx_done.status);
>> + ath10k_txrx_tx_unref(htt, _done);
>> + }
>
> I see two new warnings on the kfifo_put() call:
>
> drivers/net/wireless/ath/ath10k/htt_rx.c:1722:22: warning: cast to non-scalar
> drivers/net/wireless/ath/ath10k/htt_rx.c:1722:22: warning: cast from 
> non-scalar
> 
> But I suspect they are false warnings due to my old compiler:
> 
> gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
> 
> Opinions?
> 
Hmm... I am not sure why older compiler is not complaining this. Unfortunately
both x86 and cross compiler are not throwing any warnings though :(

gcc version 5.3.0 (GCC)
Target: x86_64-unknown-linux-gnu

gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 r47724)
Target: arm-openwrt-linux-uclibcgnueabi

Any suggestions welcome.

-Rajkumar

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


[PATCH v2] cfg80211: allow the user space to change current NAN configuration

2016-03-24 Thread Emmanuel Grumbach
Some NAN configuration paramaters may change during the operation of
the NaN device. For example, a user may want to update master preference
value when the device gets plugged/unplugged to the power.
Add API that allows to do so.

Signed-off-by: Andrei Otcheretianski 
Signed-off-by: Emmanuel Grumbach 
---
v2: allow 1 and 255 as master preference
---
 include/net/cfg80211.h   | 17 +
 include/uapi/linux/nl80211.h | 13 +++--
 net/wireless/nl80211.c   | 45 
 net/wireless/rdev-ops.h  | 17 +
 net/wireless/trace.h | 24 +++
 5 files changed, 114 insertions(+), 2 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index e6bd90e..776827d 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2308,6 +2308,17 @@ struct cfg80211_nan_func {
 };
 
 /**
+ * enum cfg80211_nan_conf_changes - indicates changed fields in nan 
configuration
+ *
+ * @CFG80211_NAN_CONF_CHANGED_PREF: master preference
+ * @CFG80211_NAN_CONF_CHANGED_DUAL: dual band operation
+ */
+enum cfg80211_nan_conf_changes {
+   CFG80211_NAN_CONF_CHANGED_PREF = BIT(0),
+   CFG80211_NAN_CONF_CHANGED_DUAL = BIT(1),
+};
+
+/**
  * struct cfg80211_ops - backend description for wireless configuration
  *
  * This struct is registered by fullmac card drivers and/or wireless stacks
@@ -2587,6 +2598,8 @@ struct cfg80211_nan_func {
  * scope of this call. The function assigns a unique instance_id in the
  * provided @nan_func.
  * @rm_nan_func: Remove a nan function.
+ * @nan_change_conf: changes NAN configuration. The changed parameters must
+ * be specified in @changes. All other parameters must be ignored.
  */
 struct cfg80211_ops {
int (*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
@@ -2859,6 +2872,10 @@ struct cfg80211_ops {
struct cfg80211_nan_func *nan_func);
void(*rm_nan_func)(struct wiphy *wiphy, struct wireless_dev *wdev,
   u64 cookie);
+   int (*nan_change_conf)(struct wiphy *wiphy,
+  struct wireless_dev *wdev,
+  struct cfg80211_nan_conf *conf,
+  u32 changes);
 };
 
 /*
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index cf5464f..5efa882 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -850,6 +850,10 @@
  * This command is also used as a notification sent when a NAN function is
  * terminated. This will contain a %NL80211_ATTR_NAN_FUNC_INST_ID
  * and %NL80211_ATTR_COOKIE attributes.
+ * @NL80211_CMD_CHANGE_NAN_CONFIG: Change current NAN configuration. NAN
+ * must be operational (%NL80211_CMD_START_NAN was executed).
+ * It must contain at least one of the following attributes:
+ * %NL80211_ATTR_NAN_MASTER_PREF, %NL80211_ATTR_NAN_DUAL.
  *
  * @NL80211_CMD_MAX: highest used command number
  * @__NL80211_CMD_AFTER_LAST: internal use
@@ -1043,6 +1047,7 @@ enum nl80211_commands {
NL80211_CMD_STOP_NAN,
NL80211_CMD_ADD_NAN_FUNCTION,
NL80211_CMD_RM_NAN_FUNCTION,
+   NL80211_CMD_CHANGE_NAN_CONFIG,
 
/* add new commands above here */
 
@@ -1829,10 +1834,14 @@ enum nl80211_commands {
  * a PCP instead of AP. Relevant for DMG networks only.
  *
  * @NL80211_ATTR_NAN_MASTER_PREF: the master preference to be used by
- * _CMD_START_NAN. Its type is u8 and it can't be 0, 1 or 255.
+ * _CMD_START_NAN and optionally with
+ * _CMD_CHANGE_NAN_CONFIG. Its type is u8 and it can't be 0.
+ * Also, values 1 and 255 are reserved for certification purposes and
+ * should not be used during a normal device operation.
  * @NL80211_ATTR_NAN_DUAL: NAN dual band operation config (see
  *  nl80211_nan_dual_band_conf). This attribute is used with
- * _CMD_START_NAN.
+ * _CMD_START_NAN and optionally with
+ * _CMD_CHANGE_NAN_CONFIG.
  * @NL80211_ATTR_NAN_FUNC: a function that can be added to NAN. See
  *  nl80211_nan_func_attributes for description of this nested
  * attribute.
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index c2eb639..9f95438 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -10375,6 +10375,43 @@ static int nl80211_nan_rm_func(struct sk_buff *skb,
return 0;
 }
 
+static int nl80211_nan_change_config(struct sk_buff *skb,
+struct genl_info *info)
+{
+   struct cfg80211_registered_device *rdev = info->user_ptr[0];
+   struct wireless_dev *wdev = info->user_ptr[1];
+   struct cfg80211_nan_conf conf = {};
+   u32 changed = 0;
+
+   if (wdev->iftype != NL80211_IFTYPE_NAN)
+   return -EOPNOTSUPP;
+
+   if (!wdev->nan_started)
+   return 

[PATCH v2] cfg80211: add start / stop NAN commands

2016-03-24 Thread Emmanuel Grumbach
This allows user space to start/stop NAN interface.
A NAN interface is like P2P device in a few aspects: it
doesn't have a netdev associated to it.
Add the new interface type and prevent operations that
can't be executed on NAN interface like scan.
Define several attributes that may be configured by user space
when starting NAN functionality (master preference and dual
band operation)

Signed-off-by: Andrei Otcheretianski 
Signed-off-by: Emmanuel Grumbach 
---
v2: allow master preference 1 and 255 as required by the certification
---
 include/net/cfg80211.h   | 21 +-
 include/uapi/linux/nl80211.h | 44 
 net/mac80211/cfg.c   |  2 +
 net/mac80211/chan.c  |  3 ++
 net/mac80211/iface.c |  4 ++
 net/mac80211/offchannel.c|  1 +
 net/mac80211/rx.c|  3 ++
 net/mac80211/util.c  |  1 +
 net/wireless/chan.c  |  2 +
 net/wireless/core.c  | 34 
 net/wireless/core.h  |  3 ++
 net/wireless/mlme.c  |  1 +
 net/wireless/nl80211.c   | 96 ++--
 net/wireless/rdev-ops.h  | 20 +
 net/wireless/trace.h | 27 +
 net/wireless/util.c  |  6 ++-
 16 files changed, 261 insertions(+), 7 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9e1b24c..cb5ab88 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2228,6 +2228,19 @@ struct cfg80211_qos_map {
 };
 
 /**
+ * struct cfg80211_nan_conf - nan configuration
+ *
+ * This struct defines nan configuration parameters
+ *
+ * @master_pref: master preference (2 -254)
+ * @dual: dual band operation mode
+ */
+struct cfg80211_nan_conf {
+   u8 master_pref;
+   enum nl80211_nan_dual_band_conf dual;
+};
+
+/**
  * struct cfg80211_ops - backend description for wireless configuration
  *
  * This struct is registered by fullmac card drivers and/or wireless stacks
@@ -2500,6 +2513,8 @@ struct cfg80211_qos_map {
  * and returning to the base channel for communication with the AP.
  * @tdls_cancel_channel_switch: Stop channel-switching with a TDLS peer. Both
  * peers must be on the base channel when the call completes.
+ * @start_nan: Start the NAN interface.
+ * @stop_nan: Stop the NAN interface.
  */
 struct cfg80211_ops {
int (*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
@@ -2765,6 +2780,9 @@ struct cfg80211_ops {
void(*tdls_cancel_channel_switch)(struct wiphy *wiphy,
  struct net_device *dev,
  const u8 *addr);
+   int (*start_nan)(struct wiphy *wiphy, struct wireless_dev *wdev,
+struct cfg80211_nan_conf *conf);
+   void(*stop_nan)(struct wiphy *wiphy, struct wireless_dev *wdev);
 };
 
 /*
@@ -3486,6 +3504,7 @@ struct cfg80211_cached_keys;
  * beacons, 0 when not valid
  * @address: The address for this device, valid only if @netdev is %NULL
  * @p2p_started: true if this is a P2P Device that has been started
+ * @nan_started: true if this is a NAN interface that has been started
  * @cac_started: true if DFS channel availability check has been started
  * @cac_start_time: timestamp (jiffies) when the dfs state was entered.
  * @cac_time_ms: CAC time in ms
@@ -3517,7 +3536,7 @@ struct wireless_dev {
 
struct mutex mtx;
 
-   bool use_4addr, p2p_started;
+   bool use_4addr, p2p_started, nan_started;
 
u8 address[ETH_ALEN] __aligned(sizeof(u16));
 
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 5a30a75..e5a7cfb 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -824,6 +824,16 @@
  * not running. The driver indicates the status of the scan through
  * cfg80211_scan_done().
  *
+ * @NL80211_CMD_START_NAN: Start NAN operation, identified by its
+ * %NL80211_ATTR_WDEV interface. This interface must have been previously
+ * created with %NL80211_CMD_NEW_INTERFACE. After it has been started, the
+ * NAN interface will create or join a cluster. This command must have a
+ * valid %NL80211_ATTR_NAN_MASTER_PREF attribute and optional
+ * %NL80211_ATTR_NAN_DUAL attributes.
+ * After this command NAN functions can be added.
+ * @NL80211_CMD_STOP_NAN: Stop the NAN operation, identified by
+ * its %NL80211_ATTR_WDEV interface.
+ *
  * @NL80211_CMD_MAX: highest used command number
  * @__NL80211_CMD_AFTER_LAST: internal use
  */
@@ -1012,6 +1022,9 @@ enum nl80211_commands {
 
NL80211_CMD_ABORT_SCAN,
 
+   NL80211_CMD_START_NAN,
+   NL80211_CMD_STOP_NAN,
+
/* add new commands above here */
 
/* used to define NL80211_CMD_MAX below */
@@ -1796,6 +1809,12 @@ enum nl80211_commands {
  * connecting to a PCP, and in %NL80211_CMD_START_AP to start
  * a PCP 

[PATCH 2/4] ath10k: prefer kernel type 'u64' over 'u_int64_t'

2016-03-24 Thread Kalle Valo
Fixes checkpatch warnings:

drivers/net/wireless/ath/ath10k/htt.h:1477: Prefer kernel type 'u64' over 
'u_int64_t'
drivers/net/wireless/ath/ath10k/htt.h:1480: Prefer kernel type 'u64' over 
'u_int64_t'

Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/ath/ath10k/htt.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt.h 
b/drivers/net/wireless/ath/ath10k/htt.h
index d196bcc50e50..71d69d0c1960 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1474,10 +1474,10 @@ union htt_rx_pn_t {
u32 pn24;
 
/* TKIP or CCMP: 48-bit PN */
-   u_int64_t pn48;
+   u64 pn48;
 
/* WAPI: 128-bit PN */
-   u_int64_t pn128[2];
+   u64 pn128[2];
 };
 
 struct htt_cmd {

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


[PATCH 1/4] ath10k: fix checkpatch warnings related to spaces

2016-03-24 Thread Kalle Valo
Fix checkpatch warnings about use of spaces with operators:

spaces preferred around that '*' (ctx:VxV)

This has been recently added to checkpatch.

Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/ath/ath10k/ce.c|6 +++---
 drivers/net/wireless/ath/ath10k/ce.h|2 +-
 drivers/net/wireless/ath/ath10k/core.h  |6 +++---
 drivers/net/wireless/ath/ath10k/debug.h |2 +-
 drivers/net/wireless/ath/ath10k/htc.h   |4 ++--
 drivers/net/wireless/ath/ath10k/htt.c   |2 +-
 drivers/net/wireless/ath/ath10k/mac.c   |8 
 drivers/net/wireless/ath/ath10k/targaddrs.h |2 +-
 drivers/net/wireless/ath/ath10k/thermal.h   |2 +-
 drivers/net/wireless/ath/ath10k/txrx.c  |2 +-
 drivers/net/wireless/ath/ath10k/wmi-tlv.h   |4 ++--
 drivers/net/wireless/ath/ath10k/wmi.c   |2 +-
 drivers/net/wireless/ath/ath10k/wmi.h   |   18 +-
 13 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/ce.c 
b/drivers/net/wireless/ath/ath10k/ce.c
index edf3629288bc..52ac97bf8a4d 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -1048,11 +1048,11 @@ int ath10k_ce_alloc_pipe(struct ath10k *ar, int ce_id,
 *
 * For the lack of a better place do the check here.
 */
-   BUILD_BUG_ON(2*TARGET_NUM_MSDU_DESC >
+   BUILD_BUG_ON(2 * TARGET_NUM_MSDU_DESC >
 (CE_HTT_H2T_MSG_SRC_NENTRIES - 1));
-   BUILD_BUG_ON(2*TARGET_10X_NUM_MSDU_DESC >
+   BUILD_BUG_ON(2 * TARGET_10X_NUM_MSDU_DESC >
 (CE_HTT_H2T_MSG_SRC_NENTRIES - 1));
-   BUILD_BUG_ON(2*TARGET_TLV_NUM_MSDU_DESC >
+   BUILD_BUG_ON(2 * TARGET_TLV_NUM_MSDU_DESC >
 (CE_HTT_H2T_MSG_SRC_NENTRIES - 1));
 
ce_state->ar = ar;
diff --git a/drivers/net/wireless/ath/ath10k/ce.h 
b/drivers/net/wireless/ath/ath10k/ce.h
index dac676817532..a3b9473ff667 100644
--- a/drivers/net/wireless/ath/ath10k/ce.h
+++ b/drivers/net/wireless/ath/ath10k/ce.h
@@ -413,7 +413,7 @@ static inline u32 ath10k_ce_base_address(struct ath10k *ar, 
unsigned int ce_id)
 
 /* Ring arithmetic (modulus number of entries in ring, which is a pwr of 2). */
 #define CE_RING_DELTA(nentries_mask, fromidx, toidx) \
-   (((int)(toidx)-(int)(fromidx)) & (nentries_mask))
+   (((int)(toidx) - (int)(fromidx)) & (nentries_mask))
 
 #define CE_RING_IDX_INCR(nentries_mask, idx) (((idx) + 1) & (nentries_mask))
 
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index b6c157ef705a..908ab1834f26 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -44,8 +44,8 @@
 
 #define ATH10K_SCAN_ID 0
 #define WMI_READY_TIMEOUT (5 * HZ)
-#define ATH10K_FLUSH_TIMEOUT_HZ (5*HZ)
-#define ATH10K_CONNECTION_LOSS_HZ (3*HZ)
+#define ATH10K_FLUSH_TIMEOUT_HZ (5 * HZ)
+#define ATH10K_CONNECTION_LOSS_HZ (3 * HZ)
 #define ATH10K_NUM_CHANS 39
 
 /* Antenna noise floor */
@@ -334,7 +334,7 @@ struct ath10k_sta {
 #endif
 };
 
-#define ATH10K_VDEV_SETUP_TIMEOUT_HZ (5*HZ)
+#define ATH10K_VDEV_SETUP_TIMEOUT_HZ (5 * HZ)
 
 enum ath10k_beacon_state {
ATH10K_BEACON_SCHEDULED = 0,
diff --git a/drivers/net/wireless/ath/ath10k/debug.h 
b/drivers/net/wireless/ath/ath10k/debug.h
index 6206edd7c49f..75c89e3625ef 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -57,7 +57,7 @@ enum ath10k_dbg_aggr_mode {
 };
 
 /* FIXME: How to calculate the buffer size sanely? */
-#define ATH10K_FW_STATS_BUF_SIZE (1024*1024)
+#define ATH10K_FW_STATS_BUF_SIZE (1024 * 1024)
 
 extern unsigned int ath10k_debug_mask;
 
diff --git a/drivers/net/wireless/ath/ath10k/htc.h 
b/drivers/net/wireless/ath/ath10k/htc.h
index e70aa38e6e05..cc827185d3e9 100644
--- a/drivers/net/wireless/ath/ath10k/htc.h
+++ b/drivers/net/wireless/ath/ath10k/htc.h
@@ -297,10 +297,10 @@ struct ath10k_htc_svc_conn_resp {
 #define ATH10K_NUM_CONTROL_TX_BUFFERS 2
 #define ATH10K_HTC_MAX_LEN 4096
 #define ATH10K_HTC_MAX_CTRL_MSG_LEN 256
-#define ATH10K_HTC_WAIT_TIMEOUT_HZ (1*HZ)
+#define ATH10K_HTC_WAIT_TIMEOUT_HZ (1 * HZ)
 #define ATH10K_HTC_CONTROL_BUFFER_SIZE (ATH10K_HTC_MAX_CTRL_MSG_LEN + \
sizeof(struct ath10k_htc_hdr))
-#define ATH10K_HTC_CONN_SVC_TIMEOUT_HZ (1*HZ)
+#define ATH10K_HTC_CONN_SVC_TIMEOUT_HZ (1 * HZ)
 
 struct ath10k_htc_ep {
struct ath10k_htc *htc;
diff --git a/drivers/net/wireless/ath/ath10k/htt.c 
b/drivers/net/wireless/ath/ath10k/htt.c
index 7561f22f10f9..42a4c18a3806 100644
--- a/drivers/net/wireless/ath/ath10k/htt.c
+++ b/drivers/net/wireless/ath/ath10k/htt.c
@@ -208,7 +208,7 @@ int ath10k_htt_init(struct ath10k *ar)
return 0;
 }
 
-#define HTT_TARGET_VERSION_TIMEOUT_HZ (3*HZ)
+#define HTT_TARGET_VERSION_TIMEOUT_HZ (3 * HZ)
 
 static int ath10k_htt_verify_version(struct ath10k_htt *htt)
 {

[PATCH 4/4] ath10k: prefer ether_addr_copy() over memcpy()

2016-03-24 Thread Kalle Valo
Fixes checkpatch warning:

drivers/net/wireless/ath/ath10k/wmi.c:5800: Prefer ether_addr_copy() over 
memcpy() if the Ethernet addresses are __aligned(2)

Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/ath/ath10k/wmi.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index ffb300823376..c0ce56804afa 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -5797,9 +5797,8 @@ ath10k_wmi_put_start_scan_tlvs(struct wmi_start_scan_tlvs 
*tlvs,
bssids->num_bssid = __cpu_to_le32(arg->n_bssids);
 
for (i = 0; i < arg->n_bssids; i++)
-   memcpy(>bssid_list[i],
-  arg->bssids[i].bssid,
-  ETH_ALEN);
+   ether_addr_copy(bssids->bssid_list[i].addr,
+   arg->bssids[i].bssid);
 
ptr += sizeof(*bssids);
ptr += sizeof(struct wmi_mac_addr) * arg->n_bssids;

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


[PATCH 3/4] ath10k: prefer ether_addr_equal() or ether_addr_equal_unaligned() over memcmp()

2016-03-24 Thread Kalle Valo
Fixes checkpatch warnings:

drivers/net/wireless/ath/ath10k/mac.c:452: Prefer ether_addr_equal() or 
ether_addr_equal_unaligned() over memcmp()
drivers/net/wireless/ath/ath10k/mac.c:455: Prefer ether_addr_equal() or 
ether_addr_equal_unaligned() over memcmp()
drivers/net/wireless/ath/ath10k/txrx.c:133: Prefer ether_addr_equal() or 
ether_addr_equal_unaligned() over memcmp()

Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/ath/ath10k/mac.c  |4 ++--
 drivers/net/wireless/ath/ath10k/txrx.c |2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 74a0e25183d0..c89f711a796b 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -449,10 +449,10 @@ static int ath10k_mac_vif_update_wep_key(struct 
ath10k_vif *arvif,
lockdep_assert_held(>conf_mutex);
 
list_for_each_entry(peer, >peers, list) {
-   if (!memcmp(peer->addr, arvif->vif->addr, ETH_ALEN))
+   if (!ether_addr_equal(peer->addr, arvif->vif->addr))
continue;
 
-   if (!memcmp(peer->addr, arvif->bssid, ETH_ALEN))
+   if (!ether_addr_equal(peer->addr, arvif->bssid))
continue;
 
if (peer->keys[key->keyidx] == key)
diff --git a/drivers/net/wireless/ath/ath10k/txrx.c 
b/drivers/net/wireless/ath/ath10k/txrx.c
index 31335c510f1e..17a493be 100644
--- a/drivers/net/wireless/ath/ath10k/txrx.c
+++ b/drivers/net/wireless/ath/ath10k/txrx.c
@@ -130,7 +130,7 @@ struct ath10k_peer *ath10k_peer_find(struct ath10k *ar, int 
vdev_id,
list_for_each_entry(peer, >peers, list) {
if (peer->vdev_id != vdev_id)
continue;
-   if (memcmp(peer->addr, addr, ETH_ALEN))
+   if (ether_addr_equal(peer->addr, addr))
continue;
 
return peer;

--
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: [RFD] workqueue: WQ_MEM_RECLAIM usage in network drivers

2016-03-24 Thread Johannes Berg
On Sun, 2016-03-20 at 14:55 -0400, Tejun Heo wrote:
> If everything else is working, I'd be happy to throw in
> WQ_MEM_RECLAIM but I really don't want to add it if it doesn't
> actually achieve the goal.  Can a wireless person chime in here?
> 

I think for many wireless devices the workqueue, like for iwldvm that
was just changed, isn't in the packet path and thus less relevant.

For some, like SDIO based chips, it's more likely to be in the packet
path, so it would make sense to keep it.

Of course there's always a possibility of getting disconnected and then
not being able to re-establish the connection in memory pressure, but
that's not something we can control/predict (the disconnection). Can of
course also happen with wired if somebody pulls out the cable, but it's
less reliant on memory allocations to get back to working there, I
guess :)

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


[PATCH 0/4] ath10k: fix recent checkpatch warnings

2016-03-24 Thread Kalle Valo
I updated checkpatch and noticed that there are few new warnings.

---

Kalle Valo (4):
  ath10k: fix checkpatch warnings related to spaces
  ath10k: prefer kernel type 'u64' over 'u_int64_t'
  ath10k: prefer ether_addr_equal() or ether_addr_equal_unaligned() over 
memcmp()
  ath10k: prefer ether_addr_copy() over memcpy()


 drivers/net/wireless/ath/ath10k/ce.c|6 +++---
 drivers/net/wireless/ath/ath10k/ce.h|2 +-
 drivers/net/wireless/ath/ath10k/core.h  |6 +++---
 drivers/net/wireless/ath/ath10k/debug.h |2 +-
 drivers/net/wireless/ath/ath10k/htc.h   |4 ++--
 drivers/net/wireless/ath/ath10k/htt.c   |2 +-
 drivers/net/wireless/ath/ath10k/htt.h   |4 ++--
 drivers/net/wireless/ath/ath10k/mac.c   |   12 ++--
 drivers/net/wireless/ath/ath10k/targaddrs.h |2 +-
 drivers/net/wireless/ath/ath10k/thermal.h   |2 +-
 drivers/net/wireless/ath/ath10k/txrx.c  |4 ++--
 drivers/net/wireless/ath/ath10k/wmi-tlv.h   |4 ++--
 drivers/net/wireless/ath/ath10k/wmi.c   |7 +++
 drivers/net/wireless/ath/ath10k/wmi.h   |   18 +-
 14 files changed, 37 insertions(+), 38 deletions(-)

--
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: [1/2] bcma: fix building without OF_IRQ

2016-03-24 Thread Arnd Bergmann
On Thursday 24 March 2016 15:53:14 Kalle Valo wrote:
> Arnd Bergmann  writes:
> 
> > On Wednesday 23 March 2016 15:52:43 Kalle Valo wrote:
> >> > The bcma driver core can be built with or without DT support, but
> >> > it fails to build when CONFIG_OF=y and CONFIG_OF_IRQ=n, which
> >> > can happen on platforms that do not support IRQ domains.
> >> > 
> >> > ERROR: "irq_create_of_mapping" [drivers/bcma/bcma.ko] undefined!
> >> > ERROR: "of_irq_parse_raw" [drivers/bcma/bcma.ko] undefined!
> >> > ERROR: "of_irq_parse_one" [drivers/bcma/bcma.ko] undefined!
> >> > 
> >> > This adds another compile-time check for OF_IRQ, but also
> >> > gets rid of now unneeded #ifdef checks: Using the simpler
> >> > IS_ENABLED() check for OF_IRQ also covers the case of not
> >> > having CONFIG_OF enabled. The check for CONFIG_OF_ADDRESS
> >> > was added to allow building on architectures without
> >> > OF_ADDRESS, but that has been addressed already in
> >> > b1d06b60e90c ("of: Provide static inline function for
> >> > of_translate_address if needed").
> >> > 
> >> > Signed-off-by: Arnd Bergmann 
> >> 
> >> Thanks, applied to wireless-drivers.git.
> >> 
> >
> > Thanks! I see you have applied patch 1/2 but not patch 2/2.
> >
> > As mentioned in the comment for patch 2, it should be tested
> > better, but I want to make sure that someone still has it
> > on their radar.
> 
> Just to avoid any confusions I assume you are talking about this patch:
> 
> [v2] bcma: use of_dma_configure() to set initial dma mask
> https://patchwork.kernel.org/patch/8608751/

Correct.

> It's on my patchwork queue and I'm planning to apply it to
> wireless-drivers-next once it opens again.

Ok, sounds good.

Arnd
--
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: [1/2] bcma: fix building without OF_IRQ

2016-03-24 Thread Kalle Valo
Arnd Bergmann  writes:

> On Wednesday 23 March 2016 15:52:43 Kalle Valo wrote:
>> > The bcma driver core can be built with or without DT support, but
>> > it fails to build when CONFIG_OF=y and CONFIG_OF_IRQ=n, which
>> > can happen on platforms that do not support IRQ domains.
>> > 
>> > ERROR: "irq_create_of_mapping" [drivers/bcma/bcma.ko] undefined!
>> > ERROR: "of_irq_parse_raw" [drivers/bcma/bcma.ko] undefined!
>> > ERROR: "of_irq_parse_one" [drivers/bcma/bcma.ko] undefined!
>> > 
>> > This adds another compile-time check for OF_IRQ, but also
>> > gets rid of now unneeded #ifdef checks: Using the simpler
>> > IS_ENABLED() check for OF_IRQ also covers the case of not
>> > having CONFIG_OF enabled. The check for CONFIG_OF_ADDRESS
>> > was added to allow building on architectures without
>> > OF_ADDRESS, but that has been addressed already in
>> > b1d06b60e90c ("of: Provide static inline function for
>> > of_translate_address if needed").
>> > 
>> > Signed-off-by: Arnd Bergmann 
>> 
>> Thanks, applied to wireless-drivers.git.
>> 
>
> Thanks! I see you have applied patch 1/2 but not patch 2/2.
>
> As mentioned in the comment for patch 2, it should be tested
> better, but I want to make sure that someone still has it
> on their radar.

Just to avoid any confusions I assume you are talking about this patch:

[v2] bcma: use of_dma_configure() to set initial dma mask
https://patchwork.kernel.org/patch/8608751/

It's on my patchwork queue and I'm planning to apply it to
wireless-drivers-next once it opens again. But I'm not able to test the
patch myself, I hope someone else could do it.

-- 
Kalle Valo
--
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: [1/2] bcma: fix building without OF_IRQ

2016-03-24 Thread Arnd Bergmann
On Wednesday 23 March 2016 15:52:43 Kalle Valo wrote:
> > The bcma driver core can be built with or without DT support, but
> > it fails to build when CONFIG_OF=y and CONFIG_OF_IRQ=n, which
> > can happen on platforms that do not support IRQ domains.
> > 
> > ERROR: "irq_create_of_mapping" [drivers/bcma/bcma.ko] undefined!
> > ERROR: "of_irq_parse_raw" [drivers/bcma/bcma.ko] undefined!
> > ERROR: "of_irq_parse_one" [drivers/bcma/bcma.ko] undefined!
> > 
> > This adds another compile-time check for OF_IRQ, but also
> > gets rid of now unneeded #ifdef checks: Using the simpler
> > IS_ENABLED() check for OF_IRQ also covers the case of not
> > having CONFIG_OF enabled. The check for CONFIG_OF_ADDRESS
> > was added to allow building on architectures without
> > OF_ADDRESS, but that has been addressed already in
> > b1d06b60e90c ("of: Provide static inline function for
> > of_translate_address if needed").
> > 
> > Signed-off-by: Arnd Bergmann 
> 
> Thanks, applied to wireless-drivers.git.
> 

Thanks! I see you have applied patch 1/2 but not patch 2/2.

As mentioned in the comment for patch 2, it should be tested
better, but I want to make sure that someone still has it
on their radar.

Arnd
--
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 1/9] ath10k: speedup htt rx descriptor processing for tx completion

2016-03-24 Thread Valo, Kalle
Rajkumar Manoharan  writes:

> To optimize CPU usage htt rx descriptors will be reused instead of
> refilling it for htt rx copy engine (CE5). To support that all htt rx
> indications should be processed at same context. FIFO queue is used
> to maintain tx completion status for each msdu. This helps to retain
> the order of tx completion.
>
> Signed-off-by: Rajkumar Manoharan 

[...]

> @@ -1712,7 +1710,20 @@ static void ath10k_htt_rx_frm_tx_compl(struct ath10k 
> *ar,
>   for (i = 0; i < resp->data_tx_completion.num_msdus; i++) {
>   msdu_id = resp->data_tx_completion.msdus[i];
>   tx_done.msdu_id = __le16_to_cpu(msdu_id);
> - ath10k_txrx_tx_unref(htt, _done);
> +
> + /* kfifo_put: In practice firmware shouldn't fire off per-CE
> +  * interrupt and main interrupt (MSI/-X range case) for the same
> +  * HTC service so it should be safe to use kfifo_put w/o lock.
> +  *
> +  * From kfifo_put() documentation:
> +  *  Note that with only one concurrent reader and one concurrent
> +  *  writer, you don't need extra locking to use these macro.
> +  */
> + if (!kfifo_put(>txdone_fifo, tx_done)) {
> + ath10k_warn(ar, "txdone fifo overrun, msdu_id %d status 
> %d\n",
> + tx_done.msdu_id, tx_done.status);
> + ath10k_txrx_tx_unref(htt, _done);
> + }

I see two new warnings on the kfifo_put() call:

drivers/net/wireless/ath/ath10k/htt_rx.c:1722:22: warning: cast to non-scalar
drivers/net/wireless/ath/ath10k/htt_rx.c:1722:22: warning: cast from non-scalar

But I suspect they are false warnings due to my old compiler:

gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

Opinions?

-- 
Kalle Valo--
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: [RFCv2 2/3] ath10k: report per-station tx/rate rates to mac80211

2016-03-24 Thread Michal Kazior
On 24 March 2016 at 13:23, Mohammed Shafi Shajakhan
 wrote:
> On Thu, Mar 24, 2016 at 08:49:12AM +0100, Michal Kazior wrote:
>> On 24 March 2016 at 08:19, Mohammed Shafi Shajakhan
>>  wrote:
>> > Hi Michal,
>> >
>> > On Wed, Mar 16, 2016 at 11:17:57AM +0100, Michal Kazior wrote:
>> >> The rate control is offloaded by firmware so it's
>> >> challanging to provide expected throughput value
>> >> for given station.
>> >>
>> >> This approach is naive as it reports last tx rate
>> >> used for given station as provided by firmware
>> >> stat event.
>> >>
>> >> This should be sufficient for airtime estimation
>> >> used for fq-codel-in-mac80211 tx scheduling
>> >> purposes now.
>> >>
>> >> This patch uses a very hacky way to get the stats.
>> >> This is sufficient for proof-of-concept but must
>> >> be cleaned up properly eventually.
>> >>
>> >> Signed-off-by: Michal Kazior 
>> >> ---
>> >>  drivers/net/wireless/ath/ath10k/core.h  |  5 +++
>> >>  drivers/net/wireless/ath/ath10k/debug.c | 61 
>> >> +
>> >>  drivers/net/wireless/ath/ath10k/mac.c   | 26 --
>> >>  drivers/net/wireless/ath/ath10k/wmi.h   |  2 +-
>> >>  4 files changed, 76 insertions(+), 18 deletions(-)
>> >>
>> >> diff --git a/drivers/net/wireless/ath/ath10k/core.h 
>> >> b/drivers/net/wireless/ath/ath10k/core.h
>> >> index 23ba03fb7a5f..3f76669d44cf 100644
>> >> --- a/drivers/net/wireless/ath/ath10k/core.h
>> >> +++ b/drivers/net/wireless/ath/ath10k/core.h
>> >> @@ -331,6 +331,9 @@ struct ath10k_sta {
>> >>   /* protected by conf_mutex */
>> >>   bool aggr_mode;
>> >>   u64 rx_duration;
>> >> +
>> >> + u32 tx_rate_kbps;
>> >> + u32 rx_rate_kbps;
>> >>  #endif
>> >>  };
>> >>
>> >> @@ -372,6 +375,8 @@ struct ath10k_vif {
>> >>   s8 def_wep_key_idx;
>> >>
>> >>   u16 tx_seq_no;
>> >> + u32 tx_rate_kbps;
>> >> + u32 rx_rate_kbps;
>> >>
>> >>   union {
>> >>   struct {
>> >> diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
>> >> b/drivers/net/wireless/ath/ath10k/debug.c
>> >> index 076d29b53ddf..cc7ebf04ae00 100644
>> >> --- a/drivers/net/wireless/ath/ath10k/debug.c
>> >> +++ b/drivers/net/wireless/ath/ath10k/debug.c
>> >> @@ -316,6 +316,58 @@ static void ath10k_debug_fw_stats_reset(struct 
>> >> ath10k *ar)
>> >>   spin_unlock_bh(>data_lock);
>> >>  }
>> >>
>> >> +static void ath10k_mac_update_txrx_rate_iter(void *data,
>> >> +  u8 *mac,
>> >> +  struct ieee80211_vif *vif)
>> >> +{
>> >> + struct ath10k_fw_stats_peer *peer = data;
>> >> + struct ath10k_vif *arvif;
>> >> +
>> >> + if (memcmp(vif->addr, peer->peer_macaddr, ETH_ALEN))
>> >> + return;
>> >> +
>> >> + arvif = (void *)vif->drv_priv;
>> >> + arvif->tx_rate_kbps = peer->peer_tx_rate;
>> >> + arvif->rx_rate_kbps = peer->peer_rx_rate;
>> >> +}
>> >> +
>> >> +static void ath10k_mac_update_txrx_rate(struct ath10k *ar,
>> >> + struct ath10k_fw_stats *stats)
>> >> +{
>> >> + struct ieee80211_hw *hw = ar->hw;
>> >> + struct ath10k_fw_stats_peer *peer;
>> >> + struct ath10k_sta *arsta;
>> >> + struct ieee80211_sta *sta;
>> >> + const u8 *localaddr = NULL;
>> >> +
>> >> + rcu_read_lock();
>> >> +
>> >> + list_for_each_entry(peer, >peers, list) {
>> >> + /* This doesn't account for multiple STA connected on 
>> >> different
>> >> +  * vifs. Unfortunately there's no way to derive that from 
>> >> the available
>> >> +  * information.
>> >> +  */
>> >> + sta = ieee80211_find_sta_by_ifaddr(hw,
>> >> +peer->peer_macaddr,
>> >> +localaddr);
>> >> + if (!sta) {
>> >> + /* This tries to update multicast rates */
>> >> + ieee80211_iterate_active_interfaces_atomic(
>> >> + hw,
>> >> + IEEE80211_IFACE_ITER_NORMAL,
>> >> + ath10k_mac_update_txrx_rate_iter,
>> >> + peer);
>> >> + continue;
>> >> + }
>> >> +
>> >> + arsta = (void *)sta->drv_priv;
>> >> + arsta->tx_rate_kbps = peer->peer_tx_rate;
>> >> + arsta->rx_rate_kbps = peer->peer_rx_rate;
>> >> + }
>> >> +
>> >> + rcu_read_unlock();
>> >> +}
>> >> +
>> >>  void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff 
>> >> *skb)
>> >>  {
>> >>   struct ath10k_fw_stats stats = {};
>> >> @@ -335,6 +387,8 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, 
>> >> struct sk_buff *skb)
>> >>   goto free;
>> >>   }
>> >>
>> >> + 

Re: [RFCv2 2/3] ath10k: report per-station tx/rate rates to mac80211

2016-03-24 Thread Mohammed Shafi Shajakhan
On Thu, Mar 24, 2016 at 08:49:12AM +0100, Michal Kazior wrote:
> On 24 March 2016 at 08:19, Mohammed Shafi Shajakhan
>  wrote:
> > Hi Michal,
> >
> > On Wed, Mar 16, 2016 at 11:17:57AM +0100, Michal Kazior wrote:
> >> The rate control is offloaded by firmware so it's
> >> challanging to provide expected throughput value
> >> for given station.
> >>
> >> This approach is naive as it reports last tx rate
> >> used for given station as provided by firmware
> >> stat event.
> >>
> >> This should be sufficient for airtime estimation
> >> used for fq-codel-in-mac80211 tx scheduling
> >> purposes now.
> >>
> >> This patch uses a very hacky way to get the stats.
> >> This is sufficient for proof-of-concept but must
> >> be cleaned up properly eventually.
> >>
> >> Signed-off-by: Michal Kazior 
> >> ---
> >>  drivers/net/wireless/ath/ath10k/core.h  |  5 +++
> >>  drivers/net/wireless/ath/ath10k/debug.c | 61 
> >> +
> >>  drivers/net/wireless/ath/ath10k/mac.c   | 26 --
> >>  drivers/net/wireless/ath/ath10k/wmi.h   |  2 +-
> >>  4 files changed, 76 insertions(+), 18 deletions(-)
> >>
> >> diff --git a/drivers/net/wireless/ath/ath10k/core.h 
> >> b/drivers/net/wireless/ath/ath10k/core.h
> >> index 23ba03fb7a5f..3f76669d44cf 100644
> >> --- a/drivers/net/wireless/ath/ath10k/core.h
> >> +++ b/drivers/net/wireless/ath/ath10k/core.h
> >> @@ -331,6 +331,9 @@ struct ath10k_sta {
> >>   /* protected by conf_mutex */
> >>   bool aggr_mode;
> >>   u64 rx_duration;
> >> +
> >> + u32 tx_rate_kbps;
> >> + u32 rx_rate_kbps;
> >>  #endif
> >>  };
> >>
> >> @@ -372,6 +375,8 @@ struct ath10k_vif {
> >>   s8 def_wep_key_idx;
> >>
> >>   u16 tx_seq_no;
> >> + u32 tx_rate_kbps;
> >> + u32 rx_rate_kbps;
> >>
> >>   union {
> >>   struct {
> >> diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
> >> b/drivers/net/wireless/ath/ath10k/debug.c
> >> index 076d29b53ddf..cc7ebf04ae00 100644
> >> --- a/drivers/net/wireless/ath/ath10k/debug.c
> >> +++ b/drivers/net/wireless/ath/ath10k/debug.c
> >> @@ -316,6 +316,58 @@ static void ath10k_debug_fw_stats_reset(struct ath10k 
> >> *ar)
> >>   spin_unlock_bh(>data_lock);
> >>  }
> >>
> >> +static void ath10k_mac_update_txrx_rate_iter(void *data,
> >> +  u8 *mac,
> >> +  struct ieee80211_vif *vif)
> >> +{
> >> + struct ath10k_fw_stats_peer *peer = data;
> >> + struct ath10k_vif *arvif;
> >> +
> >> + if (memcmp(vif->addr, peer->peer_macaddr, ETH_ALEN))
> >> + return;
> >> +
> >> + arvif = (void *)vif->drv_priv;
> >> + arvif->tx_rate_kbps = peer->peer_tx_rate;
> >> + arvif->rx_rate_kbps = peer->peer_rx_rate;
> >> +}
> >> +
> >> +static void ath10k_mac_update_txrx_rate(struct ath10k *ar,
> >> + struct ath10k_fw_stats *stats)
> >> +{
> >> + struct ieee80211_hw *hw = ar->hw;
> >> + struct ath10k_fw_stats_peer *peer;
> >> + struct ath10k_sta *arsta;
> >> + struct ieee80211_sta *sta;
> >> + const u8 *localaddr = NULL;
> >> +
> >> + rcu_read_lock();
> >> +
> >> + list_for_each_entry(peer, >peers, list) {
> >> + /* This doesn't account for multiple STA connected on 
> >> different
> >> +  * vifs. Unfortunately there's no way to derive that from 
> >> the available
> >> +  * information.
> >> +  */
> >> + sta = ieee80211_find_sta_by_ifaddr(hw,
> >> +peer->peer_macaddr,
> >> +localaddr);
> >> + if (!sta) {
> >> + /* This tries to update multicast rates */
> >> + ieee80211_iterate_active_interfaces_atomic(
> >> + hw,
> >> + IEEE80211_IFACE_ITER_NORMAL,
> >> + ath10k_mac_update_txrx_rate_iter,
> >> + peer);
> >> + continue;
> >> + }
> >> +
> >> + arsta = (void *)sta->drv_priv;
> >> + arsta->tx_rate_kbps = peer->peer_tx_rate;
> >> + arsta->rx_rate_kbps = peer->peer_rx_rate;
> >> + }
> >> +
> >> + rcu_read_unlock();
> >> +}
> >> +
> >>  void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
> >>  {
> >>   struct ath10k_fw_stats stats = {};
> >> @@ -335,6 +387,8 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, 
> >> struct sk_buff *skb)
> >>   goto free;
> >>   }
> >>
> >> + ath10k_mac_update_txrx_rate(ar, );
> >> +
> >>   /* Stat data may exceed htc-wmi buffer limit. In such case firmware
> >>* splits the stats data and delivers it in a ping-pong fashion of
> >>* request cmd-update event.
> >> @@ 

Re: [PATCH v2 1/2] ath10k: Add support for ath10k_sta_statistics support

2016-03-24 Thread Mohammed Shafi Shajakhan
Hi Michal / Kalle,

> 
> On Thu, Mar 17, 2016 at 12:35:00PM +0100, Michal Kazior wrote:
> > On 17 March 2016 at 12:20, Mohammed Shafi Shajakhan
> >  wrote:
> > > Hi Michal,
> > >
> > > On Thu, Mar 17, 2016 at 12:12:31PM +0100, Michal Kazior wrote:
> > >> On 17 March 2016 at 11:48, Mohammed Shafi Shajakhan
> > >>  wrote:
> > >> [...]
> > >> > +void ath10k_sta_statistics(struct ieee80211_hw *hw, struct 
> > >> > ieee80211_vif *vif,
> > >> > +  struct ieee80211_sta *sta,
> > >> > +  struct station_info *sinfo)
> > >> > +{
> > >> > +   struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
> > >> > +   struct ath10k *ar = arsta->arvif->ar;
> > >> > +
> > >> > +   mutex_lock(>conf_mutex);
> > >> > +
> > >> > +   if (ar->state != ATH10K_STATE_ON &&
> > >> > +   ar->state != ATH10K_STATE_RESTARTED)
> > >> > +   goto out;
> > >>
> > >> Do you really need mutex and ar->state check in this function?
> > >>
> > >
> > > [shafi] By default peer stats will be disabled, we are enabling this by 
> > > debugfs
> > > (hw-restart) so i thought these checks are needed , please advise .. Do 
> > > you say
> > > they  will be never hit
> > 
> > Hmm.. I think mac80211 shouldn't call sta_statistics() before
> > sta_state() during recovery (it makes no sense). In practice I think
> > this isn't enforced in which case it's a mac80211 bug.
> 
> [shafi] sure i will check this. If the hardware is restarting there should
> be no stations connected and station related info.

[shafi] I did not see any checks in mac80211 to prevent this (may be i missed
something), but i did remove the checks and tested it, could not find warnings, 
crashes
(or) garbage values, so is it safer to remove (unless we find some issue with
this) ?, please suggest Michal.

i was doing this parallely in two terminals

a) while true
do
cat rx_stats | grep duration -A 2
done

b) /sys/kernel/debug/ieee80211/phy0/ath10k# echo 1 > peer_stats 
 /sys/kernel/debug/ieee80211/phy0/ath10k# echo 0 > peer_stats 

 (or)
 /sys/kernel/debug/ieee80211/phy0/ath10k# echo hw-restart > simulate_fw_crash 



> 
> > 
> > Anyway, this isn't much of a problem now. You only read out u64 from
> > `arsta` (sta->drv_priv). Even if it's uninitialized/undefined there's
> > no way for you to crash the system (it's not a list, spinlock or any
> > other complex data structure). Worst case userspace will get garbage
> > rx_duration value if it happens to get_station() while hw-restart is
> > ongoing.
> 
> [shafi] will check this ..

[shafi] agree though i could not see any checks in mac80211 to prevent
sta_set_sinfo (or check for the station state), i did not see any issues in my
testing

> 
> > 
> > It'd be good to verify this is actually a problem and - assuming you
> > want to guarantee correct readouts at all times - to fix the problem
> > in mac80211.
> >
> [shafi] ok, sure

[shafi] I really don't have a deeper understanding of mac80211 code,
i need to go through it thoroughly if i need to have checks for this
if they were not already there.

regards,
shafi
--
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 2/2] wil6210: add module parameter for alternate interface name

2016-03-24 Thread Lior David
On 3/23/2016 5:27 PM, Kalle Valo wrote:
> Maya Erez  writes:
> 
>> From: Lior David 
>>
>> Add a module parameter alt_ifname that when set, will name
>> the primary network interface wigig instead of the default
>> wlan. This helps platforms such as android where we need to
>> clearly separate the WIGIG interface from the default wireless
>> interface.
>>
>> Signed-off-by: Lior David 
>> Signed-off-by: Maya Erez 
>> ---
>>  drivers/net/wireless/ath/wil6210/netdev.c | 8 +++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/ath/wil6210/netdev.c 
>> b/drivers/net/wireless/ath/wil6210/netdev.c
>> index 3bc0e26..f78ea91 100644
>> --- a/drivers/net/wireless/ath/wil6210/netdev.c
>> +++ b/drivers/net/wireless/ath/wil6210/netdev.c
>> @@ -14,10 +14,15 @@
>>   * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
>>   */
>>  
>> +#include 
>>  #include 
>>  #include "wil6210.h"
>>  #include "txrx.h"
>>  
>> +static bool alt_ifname; /* = false; */
>> +module_param(alt_ifname, bool, S_IRUGO);
>> +MODULE_PARM_DESC(alt_ifname, " use an alternate interface name wigigN 
>> instead of wlanN");
>> +
>>  static int wil_open(struct net_device *ndev)
>>  {
>>  struct wil6210_priv *wil = ndev_to_wil(ndev);
>> @@ -136,6 +141,7 @@ void *wil_if_alloc(struct device *dev)
>>  struct wil6210_priv *wil;
>>  struct ieee80211_channel *ch;
>>  int rc = 0;
>> +const char *ifname = alt_ifname ? "wigig%d" : "wlan%d";
>>  
>>  wdev = wil_cfg80211_init(dev);
>>  if (IS_ERR(wdev)) {
>> @@ -160,7 +166,7 @@ void *wil_if_alloc(struct device *dev)
>>  ch = wdev->wiphy->bands[IEEE80211_BAND_60GHZ]->channels;
>>  cfg80211_chandef_create(>preset_chandef, ch, NL80211_CHAN_NO_HT);
>>  
>> -ndev = alloc_netdev(0, "wlan%d", NET_NAME_UNKNOWN, wil_dev_setup);
>> +ndev = alloc_netdev(0, ifname, NET_NAME_UNKNOWN, wil_dev_setup);
>>  if (!ndev) {
>>  dev_err(dev, "alloc_netdev_mqs failed\n");
>>  rc = -ENOMEM;
> 
> To me this looks like an ugly hack and I hope there is a better way to
> handle the problem this patch is fixing. I think interface names
> shouldn't matter from functionality point of view, anything requiring
> certain naming is broken.
> 
> But if the interface name is so important why not use "wigig%d" always?
> The user space can rename the interface name anyway.

The problem we try to solve is with Android. Android uses hard-coded "wlan0"
interface name for wifi. We have a platform where wigig(11ad) is used
alongside wifi(11ac). Both are independent and managed by separate services,
but started at boot at roughly the same time. Sometimes 11ad will get wlan0
interface name and 11ac will get wlan1, and wifi will not work.
We considered using "wigig%d" always as you suggested, but it may break an
unknown number of existing tools/scripts that rely on wlan0 interface name.

As I see it, it is an issue of classification. Network drivers use a default
interface name prefix depending on the device type. Ethernet drivers get 
"eth%d",
wireless drivers get "wlan%d" and so on. There are even existing drivers
that give different prefixes based on other conditions, for example see
drivers/s390/net/ctcm_main.c, ctcm_init_netdevice.
For our 11ad device, in many platforms it is used as a wifi replacement, so
the wlan%d name is appropriate, in other platforms it is used as
a different wireless device for different purposes, so the default "wigig%d"
prefix seems appropriate.

Thanks,
Lior

--
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: [RFCv2 2/3] ath10k: report per-station tx/rate rates to mac80211

2016-03-24 Thread Michal Kazior
On 24 March 2016 at 08:19, Mohammed Shafi Shajakhan
 wrote:
> Hi Michal,
>
> On Wed, Mar 16, 2016 at 11:17:57AM +0100, Michal Kazior wrote:
>> The rate control is offloaded by firmware so it's
>> challanging to provide expected throughput value
>> for given station.
>>
>> This approach is naive as it reports last tx rate
>> used for given station as provided by firmware
>> stat event.
>>
>> This should be sufficient for airtime estimation
>> used for fq-codel-in-mac80211 tx scheduling
>> purposes now.
>>
>> This patch uses a very hacky way to get the stats.
>> This is sufficient for proof-of-concept but must
>> be cleaned up properly eventually.
>>
>> Signed-off-by: Michal Kazior 
>> ---
>>  drivers/net/wireless/ath/ath10k/core.h  |  5 +++
>>  drivers/net/wireless/ath/ath10k/debug.c | 61 
>> +
>>  drivers/net/wireless/ath/ath10k/mac.c   | 26 --
>>  drivers/net/wireless/ath/ath10k/wmi.h   |  2 +-
>>  4 files changed, 76 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/core.h 
>> b/drivers/net/wireless/ath/ath10k/core.h
>> index 23ba03fb7a5f..3f76669d44cf 100644
>> --- a/drivers/net/wireless/ath/ath10k/core.h
>> +++ b/drivers/net/wireless/ath/ath10k/core.h
>> @@ -331,6 +331,9 @@ struct ath10k_sta {
>>   /* protected by conf_mutex */
>>   bool aggr_mode;
>>   u64 rx_duration;
>> +
>> + u32 tx_rate_kbps;
>> + u32 rx_rate_kbps;
>>  #endif
>>  };
>>
>> @@ -372,6 +375,8 @@ struct ath10k_vif {
>>   s8 def_wep_key_idx;
>>
>>   u16 tx_seq_no;
>> + u32 tx_rate_kbps;
>> + u32 rx_rate_kbps;
>>
>>   union {
>>   struct {
>> diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
>> b/drivers/net/wireless/ath/ath10k/debug.c
>> index 076d29b53ddf..cc7ebf04ae00 100644
>> --- a/drivers/net/wireless/ath/ath10k/debug.c
>> +++ b/drivers/net/wireless/ath/ath10k/debug.c
>> @@ -316,6 +316,58 @@ static void ath10k_debug_fw_stats_reset(struct ath10k 
>> *ar)
>>   spin_unlock_bh(>data_lock);
>>  }
>>
>> +static void ath10k_mac_update_txrx_rate_iter(void *data,
>> +  u8 *mac,
>> +  struct ieee80211_vif *vif)
>> +{
>> + struct ath10k_fw_stats_peer *peer = data;
>> + struct ath10k_vif *arvif;
>> +
>> + if (memcmp(vif->addr, peer->peer_macaddr, ETH_ALEN))
>> + return;
>> +
>> + arvif = (void *)vif->drv_priv;
>> + arvif->tx_rate_kbps = peer->peer_tx_rate;
>> + arvif->rx_rate_kbps = peer->peer_rx_rate;
>> +}
>> +
>> +static void ath10k_mac_update_txrx_rate(struct ath10k *ar,
>> + struct ath10k_fw_stats *stats)
>> +{
>> + struct ieee80211_hw *hw = ar->hw;
>> + struct ath10k_fw_stats_peer *peer;
>> + struct ath10k_sta *arsta;
>> + struct ieee80211_sta *sta;
>> + const u8 *localaddr = NULL;
>> +
>> + rcu_read_lock();
>> +
>> + list_for_each_entry(peer, >peers, list) {
>> + /* This doesn't account for multiple STA connected on different
>> +  * vifs. Unfortunately there's no way to derive that from the 
>> available
>> +  * information.
>> +  */
>> + sta = ieee80211_find_sta_by_ifaddr(hw,
>> +peer->peer_macaddr,
>> +localaddr);
>> + if (!sta) {
>> + /* This tries to update multicast rates */
>> + ieee80211_iterate_active_interfaces_atomic(
>> + hw,
>> + IEEE80211_IFACE_ITER_NORMAL,
>> + ath10k_mac_update_txrx_rate_iter,
>> + peer);
>> + continue;
>> + }
>> +
>> + arsta = (void *)sta->drv_priv;
>> + arsta->tx_rate_kbps = peer->peer_tx_rate;
>> + arsta->rx_rate_kbps = peer->peer_rx_rate;
>> + }
>> +
>> + rcu_read_unlock();
>> +}
>> +
>>  void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
>>  {
>>   struct ath10k_fw_stats stats = {};
>> @@ -335,6 +387,8 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, 
>> struct sk_buff *skb)
>>   goto free;
>>   }
>>
>> + ath10k_mac_update_txrx_rate(ar, );
>> +
>>   /* Stat data may exceed htc-wmi buffer limit. In such case firmware
>>* splits the stats data and delivers it in a ping-pong fashion of
>>* request cmd-update event.
>> @@ -351,13 +405,6 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, 
>> struct sk_buff *skb)
>>   if (peer_stats_svc)
>>   ath10k_sta_update_rx_duration(ar, );
>>
>> - if (ar->debug.fw_stats_done) {
>> - if (!peer_stats_svc)
>> - ath10k_warn(ar, "received unsolicited stats 

Re: [RFCv2 2/3] ath10k: report per-station tx/rate rates to mac80211

2016-03-24 Thread Mohammed Shafi Shajakhan
Hi Michal,

On Wed, Mar 16, 2016 at 11:17:57AM +0100, Michal Kazior wrote:
> The rate control is offloaded by firmware so it's
> challanging to provide expected throughput value
> for given station.
> 
> This approach is naive as it reports last tx rate
> used for given station as provided by firmware
> stat event.
> 
> This should be sufficient for airtime estimation
> used for fq-codel-in-mac80211 tx scheduling
> purposes now.
> 
> This patch uses a very hacky way to get the stats.
> This is sufficient for proof-of-concept but must
> be cleaned up properly eventually.
> 
> Signed-off-by: Michal Kazior 
> ---
>  drivers/net/wireless/ath/ath10k/core.h  |  5 +++
>  drivers/net/wireless/ath/ath10k/debug.c | 61 
> +
>  drivers/net/wireless/ath/ath10k/mac.c   | 26 --
>  drivers/net/wireless/ath/ath10k/wmi.h   |  2 +-
>  4 files changed, 76 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath10k/core.h 
> b/drivers/net/wireless/ath/ath10k/core.h
> index 23ba03fb7a5f..3f76669d44cf 100644
> --- a/drivers/net/wireless/ath/ath10k/core.h
> +++ b/drivers/net/wireless/ath/ath10k/core.h
> @@ -331,6 +331,9 @@ struct ath10k_sta {
>   /* protected by conf_mutex */
>   bool aggr_mode;
>   u64 rx_duration;
> +
> + u32 tx_rate_kbps;
> + u32 rx_rate_kbps;
>  #endif
>  };
>  
> @@ -372,6 +375,8 @@ struct ath10k_vif {
>   s8 def_wep_key_idx;
>  
>   u16 tx_seq_no;
> + u32 tx_rate_kbps;
> + u32 rx_rate_kbps;
>  
>   union {
>   struct {
> diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
> b/drivers/net/wireless/ath/ath10k/debug.c
> index 076d29b53ddf..cc7ebf04ae00 100644
> --- a/drivers/net/wireless/ath/ath10k/debug.c
> +++ b/drivers/net/wireless/ath/ath10k/debug.c
> @@ -316,6 +316,58 @@ static void ath10k_debug_fw_stats_reset(struct ath10k 
> *ar)
>   spin_unlock_bh(>data_lock);
>  }
>  
> +static void ath10k_mac_update_txrx_rate_iter(void *data,
> +  u8 *mac,
> +  struct ieee80211_vif *vif)
> +{
> + struct ath10k_fw_stats_peer *peer = data;
> + struct ath10k_vif *arvif;
> +
> + if (memcmp(vif->addr, peer->peer_macaddr, ETH_ALEN))
> + return;
> +
> + arvif = (void *)vif->drv_priv;
> + arvif->tx_rate_kbps = peer->peer_tx_rate;
> + arvif->rx_rate_kbps = peer->peer_rx_rate;
> +}
> +
> +static void ath10k_mac_update_txrx_rate(struct ath10k *ar,
> + struct ath10k_fw_stats *stats)
> +{
> + struct ieee80211_hw *hw = ar->hw;
> + struct ath10k_fw_stats_peer *peer;
> + struct ath10k_sta *arsta;
> + struct ieee80211_sta *sta;
> + const u8 *localaddr = NULL;
> +
> + rcu_read_lock();
> +
> + list_for_each_entry(peer, >peers, list) {
> + /* This doesn't account for multiple STA connected on different
> +  * vifs. Unfortunately there's no way to derive that from the 
> available
> +  * information.
> +  */
> + sta = ieee80211_find_sta_by_ifaddr(hw,
> +peer->peer_macaddr,
> +localaddr);
> + if (!sta) {
> + /* This tries to update multicast rates */
> + ieee80211_iterate_active_interfaces_atomic(
> + hw,
> + IEEE80211_IFACE_ITER_NORMAL,
> + ath10k_mac_update_txrx_rate_iter,
> + peer);
> + continue;
> + }
> +
> + arsta = (void *)sta->drv_priv;
> + arsta->tx_rate_kbps = peer->peer_tx_rate;
> + arsta->rx_rate_kbps = peer->peer_rx_rate;
> + }
> +
> + rcu_read_unlock();
> +}
> +
>  void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
>  {
>   struct ath10k_fw_stats stats = {};
> @@ -335,6 +387,8 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, 
> struct sk_buff *skb)
>   goto free;
>   }
>  
> + ath10k_mac_update_txrx_rate(ar, );
> +
>   /* Stat data may exceed htc-wmi buffer limit. In such case firmware
>* splits the stats data and delivers it in a ping-pong fashion of
>* request cmd-update event.
> @@ -351,13 +405,6 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, 
> struct sk_buff *skb)
>   if (peer_stats_svc)
>   ath10k_sta_update_rx_duration(ar, );
>  
> - if (ar->debug.fw_stats_done) {
> - if (!peer_stats_svc)
> - ath10k_warn(ar, "received unsolicited stats update 
> event\n");
> -
> - goto free;
> - }
> -

[shafi] As you had suggested previously, should we completely clean up this ping
- pong response approach for f/w stats, (or) this should be 

Re: [PATCH v1 3/3] ath10k: Enable parsing per station rx duration for 10.4

2016-03-24 Thread Mohammed Shafi Shajakhan
Hi Kalle,

On Thu, Mar 24, 2016 at 06:51:18AM +, Valo, Kalle wrote:
> "Shajakhan, Mohammed Shafi (Mohammed Shafi)" 
> writes:
> > I will make sure, I will run sparse before sending it for review
> > http://linuxwireless.org/en/users/Drivers/ath10k/CodingStyle/#Linux_style
> >
> > make drivers/net/wireless/ath/ath10k/ C=2 CF="-D__CHECK_ENDIAN__"
> >
> > regret the inconvenience so caused  (including the compilation error)
> 
> I guess easier is to use my ath10k-check script:
> 
> https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath10k/ath10k-check
> 
> I use that script to test every patch before I commit them. Run the
> script on the top level kernel source tree and ideally you should not
> see any warnings (the output should be empty).
>

[shafi] sure will do that.

regards,
shafi
--
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 v1 3/3] ath10k: Enable parsing per station rx duration for 10.4

2016-03-24 Thread Valo, Kalle
"Shajakhan, Mohammed Shafi (Mohammed Shafi)" 
writes:
> I will make sure, I will run sparse before sending it for review
> http://linuxwireless.org/en/users/Drivers/ath10k/CodingStyle/#Linux_style
>
> make drivers/net/wireless/ath/ath10k/ C=2 CF="-D__CHECK_ENDIAN__"
>
> regret the inconvenience so caused  (including the compilation error)

I guess easier is to use my ath10k-check script:

https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath10k/ath10k-check

I use that script to test every patch before I commit them. Run the
script on the top level kernel source tree and ideally you should not
see any warnings (the output should be empty).

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