[PATCH] ath6kl: fix return value in ath6kl_wmi_set_pvb_cmd

[Chaehyun Lim]

When building with W=1, we got one warning as belows:
drivers/net/wireless/ath/ath6kl/wmi.c:3509:6: warning: variable ‘ret’
set but not used [-Wunused-but-set-variable]

At the end of ath6kl_wmi_set_pvb_cmd, it is returned by 0 regardless of
return value of ath6kl_wmi_cmd_send.
This patch fixes return value from 0 to ret that has result of
ath6kl_wmi_cmd_send execution.

Signed-off-by: Chaehyun Lim 
---
 drivers/net/wireless/ath/ath6kl/wmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath6kl/wmi.c 
b/drivers/net/wireless/ath/ath6kl/wmi.c
index b8cf04d..3fd1cc9 100644
--- a/drivers/net/wireless/ath/ath6kl/wmi.c
+++ b/drivers/net/wireless/ath/ath6kl/wmi.c
@@ -3520,7 +3520,7 @@ int ath6kl_wmi_set_pvb_cmd(struct wmi *wmi, u8 if_idx, 
u16 aid,
ret = ath6kl_wmi_cmd_send(wmi, if_idx, skb, WMI_AP_SET_PVB_CMDID,
  NO_SYNC_WMIFLAG);
 
-   return 0;
+   return ret;
 }
 
 int ath6kl_wmi_set_rx_frame_format_cmd(struct wmi *wmi, u8 if_idx,
-- 
2.9.3

Re: [PATCH 2/4] carl9170: fix debugfs crashes

[Greg KH]

On Sun, Sep 18, 2016 at 10:54:18AM +0300, Kalle Valo wrote:
> Greg KH  writes:
> 
> > On Sat, Sep 17, 2016 at 09:43:02PM +0200, Christian Lamparter wrote:
> >> Ben Greear reported:
> >> > I see lots of instability as soon as I load up the carl9710 NIC.
> >> > My application is going to be poking at it's debugfs files...
> >> >
> >> > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
> >> > [carl9170] at addr 8801bc1208b0
> >> > Read of size 8 by task btserver/5888
> >> > ===
> >> > BUG kmalloc-256 (Tainted: GW  ): kasan: bad access detected
> >> > ---
> >> >
> >> > INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
> >> >...
> >> 
> >> This breakage was caused by the introduction of intermediate
> >> fops in debugfs by commit 9fd4dcece43a
> >> ("debugfs: prevent access to possibly dead file_operations at file open")
> >
> > Because of this, these should all be backported to 4.7-stable, and
> > 4.8-stable, right?
> 
> Via which tree should these go, Greg's or mine?

I'll take it if you ack it, as it's a debugfs issue.

thanks,

greg k-h

Re: [PATCH 2/4] carl9170: fix debugfs crashes

[Kalle Valo]

Greg KH  writes:

> On Sat, Sep 17, 2016 at 09:43:02PM +0200, Christian Lamparter wrote:
>> Ben Greear reported:
>> > I see lots of instability as soon as I load up the carl9710 NIC.
>> > My application is going to be poking at it's debugfs files...
>> >
>> > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
>> > [carl9170] at addr 8801bc1208b0
>> > Read of size 8 by task btserver/5888
>> > ===
>> > BUG kmalloc-256 (Tainted: GW  ): kasan: bad access detected
>> > ---
>> >
>> > INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
>> >...
>> 
>> This breakage was caused by the introduction of intermediate
>> fops in debugfs by commit 9fd4dcece43a
>> ("debugfs: prevent access to possibly dead file_operations at file open")
>
> Because of this, these should all be backported to 4.7-stable, and
> 4.8-stable, right?

Via which tree should these go, Greg's or mine?

-- 
Kalle Valo

Re: [PATCH 2/4] carl9170: fix debugfs crashes

[Christian Lamparter]

On Sunday, September 18, 2016 12:14:55 PM CEST Greg KH wrote:
> On Sun, Sep 18, 2016 at 10:54:18AM +0300, Kalle Valo wrote:
> > Greg KH  writes:
> > 
> > > On Sat, Sep 17, 2016 at 09:43:02PM +0200, Christian Lamparter wrote:
> > >> Ben Greear reported:
> > >> > I see lots of instability as soon as I load up the carl9710 NIC.
> > >> > My application is going to be poking at it's debugfs files...
> > >> >
> > >> > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
> > >> > [carl9170] at addr 8801bc1208b0
> > >> > Read of size 8 by task btserver/5888
> > >> > ===
> > >> > BUG kmalloc-256 (Tainted: GW  ): kasan: bad access detected
> > >> > ---
> > >> >
> > >> > INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
> > >> >...
> > >> 
> > >> This breakage was caused by the introduction of intermediate
> > >> fops in debugfs by commit 9fd4dcece43a
> > >> ("debugfs: prevent access to possibly dead file_operations at file open")
> > >
> > > Because of this, these should all be backported to 4.7-stable, and
> > > 4.8-stable, right?
Ok, only b43legacy has debugfs enabled by default. For b43 and carl9170 
debugfs support is usually disabled.

Greg, would you take these four patches "as is" for -stable
or do you want a "minimal version" which just replaces the

dfops = container_of(file->f_op, ...

with

dfops = container_of(file->f_path.dentry->d_fsdata, ...

in the three drivers for -stable?

> > Via which tree should these go, Greg's or mine?
> 
> I'll take it if you ack it, as it's a debugfs issue.
For carl9170: Ben Greear has reported:
"I have verified this fixes my problem in the 4.7 kernel."

But this was with a preliminary/minimal version so I didn't
add the tested-by tag.

As for b43, I'll see if I have a working b43 in my collection
somewhere to confirm the issue and the fix. Question is, do
you want to wait or not?

Regards,
Christian

Re: [PATCH] rtl8xxxu: Stop log spam from each successful interrupt

[Kalle Valo]

Jes Sorensen  writes:

> Joe Perches  writes:
>> On Sat, 2016-09-17 at 12:09 -0500, Larry Finger wrote:
>>> As soon as debugging is turned on, the logs are filled with messages
>>> reporting the interrupt status. As this quantity is usually zero, this
>>> output is not needed. In fact, there will be a report if the status is
>>> not zero, thus the debug line in question could probably be deleted.
>>> Rather than taking that action, I have changed it to only be printed
>>> when the RTL8XXXU_DEBUG_USB bit is set in the debug mask.
>>
>> There are many uses of
>>  if (rtl8xxxu_debug & ) {
>>  dev_info(dev, ...)
>>
>> Emitting debugging information at KERN_INFO is odd.
>
> Not at all, it's a pain to enable it in debug fs post loading the
> driver, especially if you need the output immediately during driver
> init. That is why the flags are there.
>
>> I think it'd be nicer to use dev_dbg for all these cases
>> and as well use some new macro that includes the test
>>
>> Something like:
>>
>> #define rtl8xxxu_dbg(type, fmt, ...) \
>> do { \
>>  if (rtl8xxxu_debug & (type))\
>>  dev_dbg(dev, fmt, ##__VA_ARGS__);   \
>> } while (0)
>
> Yuck yuck yuck, no thanks!
>
> Any attempt of adding that kinda grossness to the driver will get a
> NACK.

Huh, how is that ugly? To me it's the opposite, original code is ugly
and Joes' proposal makes sense. Lots of wireless drivers have something
similar.

-- 
Kalle Valo

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

[Otcheretianski, Andrei]

> -Original Message-
> From: Arend Van Spriel [mailto:arend.vanspr...@broadcom.com]
> Sent: Friday, September 16, 2016 13:59
> To: Luca Coelho ; johan...@sipsolutions.net
> Cc: linux-wireless@vger.kernel.org; Beker, Ayala ;
> Otcheretianski, Andrei ; Grumbach,
> Emmanuel ; Coelho, Luciano
> 
> Subject: Re: [PATCH v2 1/9] cfg80211: add start / stop NAN commands
> 
> On 16-9-2016 10:33, Luca Coelho wrote:
> > From: Ayala Beker 
> >
> > 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 
> > Signed-off-by: Luca Coelho 
> > ---
> >  include/net/cfg80211.h   | 21 +-
> >  include/uapi/linux/nl80211.h | 52 +
> >  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   | 93
> ++--
> >  net/wireless/rdev-ops.h  | 20 ++
> >  net/wireless/trace.h | 27 +
> >  net/wireless/util.c  |  6 ++-
> >  16 files changed, 267 insertions(+), 6 deletions(-)
> >
> > diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index
> > d5e7f69..ca64d69 100644
> > --- a/include/net/cfg80211.h
> > +++ b/include/net/cfg80211.h
> > @@ -2293,6 +2293,19 @@ struct cfg80211_qos_map {  };
> 
> [...]
> 
> > +/**
> > + * enum nl80211_nan_dual_band_conf - NAN dual band configuration
> > + *
> > + * Defines the NAN dual band mode of operation
> 
> Does it make sense to have such a notion of bands in use. And what does
> 5.2GHz mean. Is this a subband within 5G channels? Probably I should read
> the NAN spec to understand what is meant here. I would consider 5.2G as
> lower 5G, ie. discovery on channel 44 but not sure if that is meant here.
>

The NAN spec defines single and dual band modes of operation. The channels are 
fixed for each band.
On 2.4Ghz is channel 6 and 5GHz is either 44 or 149. Regarding 5.2 - it's just 
a typo. It should be 5G - no deeper meaning.
 
> > + * @NL80211_NAN_BAND_DEFAULT: device default mode
> > + * @NL80211_NAN_BAND_SINGLE: 2.4GHz only mode
> > + * @NL80211_NAN_BAND_DUAL: 2.4GHz and 5.2GHz mode
> > +  */
> > +enum nl80211_nan_dual_band_conf {
> > +   NL80211_NAN_BAND_DEFAULT,
> > +   NL80211_NAN_BAND_SINGLE,
> > +   NL80211_NAN_BAND_DUAL,
> > +
> > +   /* keep last */
> > +   __NL80211_NAN_BAND_AFTER_LAST,
> > +   NL80211_NAN_BAND_MAX =
> > +   __NL80211_NAN_BAND_AFTER_LAST - 1,
> > +};
> > +
> >  #endif /* __LINUX_NL80211_H */
> > diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c index
> > e29ff57..a74027f 100644
> > --- a/net/mac80211/cfg.c
> > +++ b/net/mac80211/cfg.c
> > @@ -257,6 +257,7 @@ static int ieee80211_add_key(struct wiphy *wiphy,
> struct net_device *dev,
> > case NL80211_IFTYPE_WDS:
> > case NL80211_IFTYPE_MONITOR:
> > case NL80211_IFTYPE_P2P_DEVICE:
> > +   case NL80211_IFTYPE_NAN:
> > case NL80211_IFTYPE_UNSPECIFIED:
> > case NUM_NL80211_IFTYPES:
> 
> Huh? What is this doing here? Not yours but weird still.
> 
> > case NL80211_IFTYPE_P2P_CLIENT:
> > @@ -2036,6 +2037,7 @@ static int ieee80211_scan(struct wiphy *wiphy,
> >  !(req->flags & NL80211_SCAN_FLAG_AP)))
> > return -EOPNOTSUPP;
> > break;
> > +   case NL80211_IFTYPE_NAN:
> > default:
> > return -EOPNOTSUPP;
> > }
> > diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c index
> > 74142d0..acb50f8 100644
> > --- a/net/mac80211/chan.c
> > +++ b/net/mac80211/chan.c
> > @@ -274,6 +274,7 @@ ieee80211_get_chanctx_max_required_bw(struct
> ieee80211_local *local,
> > ieee80211_get_max_required_bw(sdata));
> > break;
> > case NL80211_IFTYPE_P2P_DEVICE:
> > +   case NL80211_IFTYPE_NAN:
> > continue;
> > case NL80211_IFTYPE_ADHOC:
> > case NL80211_IFTYPE_WDS:
> > @@ -718,6 +719,7 @@ void ieee80211_recalc_smps_chanctx(struct
> > ieee80211_local *local,
> >

RE: [PATCH v2 2/9] mac80211: add boilerplate code for start / stop NAN

[Otcheretianski, Andrei]

> -Original Message-
> From: Arend Van Spriel [mailto:arend.vanspr...@broadcom.com]
> Sent: Friday, September 16, 2016 14:09
> To: Luca Coelho ; johan...@sipsolutions.net
> Cc: linux-wireless@vger.kernel.org; Beker, Ayala ;
> Otcheretianski, Andrei ; Grumbach,
> Emmanuel ; Coelho, Luciano
> 
> Subject: Re: [PATCH v2 2/9] mac80211: add boilerplate code for start / stop
> NAN
> 
> On 16-9-2016 10:33, Luca Coelho wrote:
> > From: Ayala Beker 
> >
> > This code doesn't do much besides allowing to start and stop the vif.
> >
> > Signed-off-by: Andrei Otcheretianski 
> > Signed-off-by: Emmanuel Grumbach 
> > Signed-off-by: Ayala Beker 
> > Signed-off-by: Luca Coelho 
> > ---
> >  include/net/mac80211.h|  9 +
> >  net/mac80211/cfg.c| 36 ++
> >  net/mac80211/chan.c   |  3 +++
> >  net/mac80211/driver-ops.h | 29 ++-
> >  net/mac80211/iface.c  |  8 ++--
> >  net/mac80211/main.c   |  5 +
> >  net/mac80211/offchannel.c |  3 ++-
> >  net/mac80211/trace.h  | 50
> +++
> >  net/mac80211/util.c   |  3 ++-
> >  9 files changed, 141 insertions(+), 5 deletions(-)
> 
> [...]
> 
> > diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
> > index fe35a1c..67b42c8 100644
> > --- a/net/mac80211/driver-ops.h
> > +++ b/net/mac80211/driver-ops.h
> > @@ -163,7 +163,8 @@ static inline void drv_bss_info_changed(struct
> > ieee80211_local *local,
> >
> > if (WARN_ON_ONCE(sdata->vif.type ==
> NL80211_IFTYPE_P2P_DEVICE ||
> >  (sdata->vif.type == NL80211_IFTYPE_MONITOR &&
> > - !sdata->vif.mu_mimo_owner)))
> > + !sdata->vif.mu_mimo_owner) ||
> > +sdata->vif.type == NL80211_IFTYPE_NAN))
> 
> Might be more clear to move this up right after P2P_DEVICE check.

Why? It's a completely separate new condition - so it goes to the end.

> 
> > return;
> >
> > if (!check_sdata_in_driver(sdata))
> > @@ -1165,4 +1166,30 @@ static inline void drv_wake_tx_queue(struct
> ieee80211_local *local,
> > local->ops->wake_tx_queue(>hw, >txq);  }
> >
> > +static inline int drv_start_nan(struct ieee80211_local *local,
> > +   struct ieee80211_sub_if_data *sdata,
> > +   struct cfg80211_nan_conf *conf)
> > +{
> > +   int ret;
> > +
> > +   might_sleep();
> > +   check_sdata_in_driver(sdata);
> > +
> > +   trace_drv_start_nan(local, sdata, conf);
> > +   ret = local->ops->start_nan(>hw, >vif, conf);
> > +   trace_drv_return_int(local, ret);
> > +   return ret;
> > +}
> > +
> > +static inline void drv_stop_nan(struct ieee80211_local *local,
> > +   struct ieee80211_sub_if_data *sdata) {
> > +   might_sleep();
> > +   check_sdata_in_driver(sdata);
> > +
> > +   trace_drv_stop_nan(local, sdata);
> > +   local->ops->stop_nan(>hw, >vif);
> > +   trace_drv_return_void(local);
> > +}
> > +
> >  #endif /* __MAC80211_DRIVER_OPS */
> > diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c index
> > e694ca2..507f46a 100644
> > --- a/net/mac80211/iface.c
> > +++ b/net/mac80211/iface.c
> > @@ -327,6 +327,9 @@ static int ieee80211_check_queues(struct
> ieee80211_sub_if_data *sdata,
> > int n_queues = sdata->local->hw.queues;
> > int i;
> >
> > +   if (iftype == NL80211_IFTYPE_NAN)
> > +   return 0;
> > +
> > if (iftype != NL80211_IFTYPE_P2P_DEVICE) {
> > for (i = 0; i < IEEE80211_NUM_ACS; i++) {
> > if (WARN_ON_ONCE(sdata->vif.hw_queue[i] == @@
> -647,7 +650,8 @@ int
> > ieee80211_do_open(struct wireless_dev *wdev, bool coming_up)
> > local->fif_probe_req++;
> > }
> >
> > -   if (sdata->vif.type != NL80211_IFTYPE_P2P_DEVICE)
> > +   if (sdata->vif.type != NL80211_IFTYPE_P2P_DEVICE &&
> > +   sdata->vif.type != NL80211_IFTYPE_NAN)
> 
> similar check keeps reoccuring in various places so maybe we can create a
> helper function for it.

Right, but not sure that it deserves a function.

> 
> > changed |= ieee80211_reset_erp_info(sdata);
> > ieee80211_bss_info_change_notify(sdata, changed);
> >
> 
> Regards,
> Arend

Re: [PATCH 2/4] carl9170: fix debugfs crashes

[Greg KH]

On Sun, Sep 18, 2016 at 02:49:33PM +0200, Christian Lamparter wrote:
> On Sunday, September 18, 2016 12:14:55 PM CEST Greg KH wrote:
> > On Sun, Sep 18, 2016 at 10:54:18AM +0300, Kalle Valo wrote:
> > > Greg KH  writes:
> > > 
> > > > On Sat, Sep 17, 2016 at 09:43:02PM +0200, Christian Lamparter wrote:
> > > >> Ben Greear reported:
> > > >> > I see lots of instability as soon as I load up the carl9710 NIC.
> > > >> > My application is going to be poking at it's debugfs files...
> > > >> >
> > > >> > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
> > > >> > [carl9170] at addr 8801bc1208b0
> > > >> > Read of size 8 by task btserver/5888
> > > >> > ===
> > > >> > BUG kmalloc-256 (Tainted: GW  ): kasan: bad access 
> > > >> > detected
> > > >> > ---
> > > >> >
> > > >> > INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
> > > >> >...
> > > >> 
> > > >> This breakage was caused by the introduction of intermediate
> > > >> fops in debugfs by commit 9fd4dcece43a
> > > >> ("debugfs: prevent access to possibly dead file_operations at file 
> > > >> open")
> > > >
> > > > Because of this, these should all be backported to 4.7-stable, and
> > > > 4.8-stable, right?
> Ok, only b43legacy has debugfs enabled by default. For b43 and carl9170 
> debugfs support is usually disabled.
> 
> Greg, would you take these four patches "as is" for -stable
> or do you want a "minimal version" which just replaces the
> 
> dfops = container_of(file->f_op, ...
> 
> with
> 
> dfops = container_of(file->f_path.dentry->d_fsdata, ...
> 
> in the three drivers for -stable?

No, I'll take this as is, we want things to remain as close as possible
to Linus's tree.  When we are not, is when things break.

> > > Via which tree should these go, Greg's or mine?
> > 
> > I'll take it if you ack it, as it's a debugfs issue.
> For carl9170: Ben Greear has reported:
> "I have verified this fixes my problem in the 4.7 kernel."
> 
> But this was with a preliminary/minimal version so I didn't
> add the tested-by tag.
> 
> As for b43, I'll see if I have a working b43 in my collection
> somewhere to confirm the issue and the fix. Question is, do
> you want to wait or not?

I'll queue these up this week, no rush.

thanks,

greg k-h

[PATCH 1/2] rhashtable: Add rhlist interface

[Herbert Xu]

The insecure_elasticity setting is an ugly wart brought out by
users who need to insert duplicate objects (that is, distinct
objects with identical keys) into the same table.

In fact, those users have a much bigger problem.  Once those
duplicate objects are inserted, they don't have an interface to
find them (unless you count the walker interface which walks
over the entire table).

Some users have resorted to doing a manual walk over the hash
table which is of course broken because they don't handle the
potential existence of multiple hash tables.  The result is that
they will break sporadically when they encounter a hash table
resize/rehash.

This patch provides a way out for those users, at the expense
of an extra pointer per object.  Essentially each object is now
a list of objects carrying the same key.  The hash table will
only see the lists so nothing changes as far as rhashtable is
concerned.

To use this new interface, you need to insert a struct rhlist_head
into your objects instead of struct rhash_head.  While the hash
table is unchanged, for type-safety you'll need to use struct
rhltable instead of struct rhashtable.  All the existing interfaces
have been duplicated for rhlist, including the hash table walker.

One missing feature is nulls marking because AFAIK the only potential
user of it does not need duplicate objects.  Should anyone need
this it shouldn't be too hard to add.

Signed-off-by: Herbert Xu 
---

 include/linux/rhashtable.h |  490 ++---
 lib/rhashtable.c   |  231 -
 2 files changed, 560 insertions(+), 161 deletions(-)

diff --git a/include/linux/rhashtable.h b/include/linux/rhashtable.h
index fd82584..dc7bea6 100644
--- a/include/linux/rhashtable.h
+++ b/include/linux/rhashtable.h
@@ -1,7 +1,7 @@
 /*
  * Resizable, Scalable, Concurrent Hash Table
  *
- * Copyright (c) 2015 Herbert Xu 
+ * Copyright (c) 2015-2016 Herbert Xu 
  * Copyright (c) 2014-2015 Thomas Graf 
  * Copyright (c) 2008-2014 Patrick McHardy 
  *
@@ -53,6 +53,11 @@ struct rhash_head {
struct rhash_head __rcu *next;
 };
 
+struct rhlist_head {
+   struct rhash_head   rhead;
+   struct rhlist_head __rcu*next;
+};
+
 /**
  * struct bucket_table - Table of hash buckets
  * @size: Number of hash buckets
@@ -137,6 +142,7 @@ struct rhashtable_params {
  * @key_len: Key length for hashfn
  * @elasticity: Maximum chain length before rehash
  * @p: Configuration parameters
+ * @rhlist: True if this is an rhltable
  * @run_work: Deferred worker to expand/shrink asynchronously
  * @mutex: Mutex to protect current/future table swapping
  * @lock: Spin lock to protect walker list
@@ -147,12 +153,21 @@ struct rhashtable {
unsigned intkey_len;
unsigned intelasticity;
struct rhashtable_paramsp;
+   boolrhlist;
struct work_struct  run_work;
struct mutexmutex;
spinlock_t  lock;
 };
 
 /**
+ * struct rhltable - Hash table with duplicate objects in a list
+ * @ht: Underlying rhtable
+ */
+struct rhltable {
+   struct rhashtable ht;
+};
+
+/**
  * struct rhashtable_walker - Hash table walker
  * @list: List entry on list of walkers
  * @tbl: The table that we were walking over
@@ -163,9 +178,10 @@ struct rhashtable_walker {
 };
 
 /**
- * struct rhashtable_iter - Hash table iterator, fits into netlink cb
+ * struct rhashtable_iter - Hash table iterator
  * @ht: Table to iterate through
  * @p: Current pointer
+ * @list: Current hash list pointer
  * @walker: Associated rhashtable walker
  * @slot: Current slot
  * @skip: Number of entries to skip in slot
@@ -173,6 +189,7 @@ struct rhashtable_walker {
 struct rhashtable_iter {
struct rhashtable *ht;
struct rhash_head *p;
+   struct rhlist_head *list;
struct rhashtable_walker walker;
unsigned int slot;
unsigned int skip;
@@ -339,13 +356,11 @@ static inline int lockdep_rht_bucket_is_held(const struct 
bucket_table *tbl,
 
 int rhashtable_init(struct rhashtable *ht,
const struct rhashtable_params *params);
+int rhltable_init(struct rhltable *hlt,
+ const struct rhashtable_params *params);
 
-struct bucket_table *rhashtable_insert_slow(struct rhashtable *ht,
-   const void *key,
-   struct rhash_head *obj,
-   struct bucket_table *old_tbl,
-   void **data);
-int rhashtable_insert_rehash(struct rhashtable *ht, struct bucket_table *tbl);
+void *rhashtable_insert_slow(struct rhashtable *ht, const void *key,
+struct 

Re: [PATCH v2 2/9] mac80211: add boilerplate code for start / stop NAN

[Arend Van Spriel]

On 18-9-2016 9:59, Otcheretianski, Andrei wrote:
>> -Original Message-
>> From: Arend Van Spriel [mailto:arend.vanspr...@broadcom.com]
>> Sent: Friday, September 16, 2016 14:09
>> To: Luca Coelho ; johan...@sipsolutions.net
>> Cc: linux-wireless@vger.kernel.org; Beker, Ayala ;
>> Otcheretianski, Andrei ; Grumbach,
>> Emmanuel ; Coelho, Luciano
>> 
>> Subject: Re: [PATCH v2 2/9] mac80211: add boilerplate code for start / stop
>> NAN
>>
>> On 16-9-2016 10:33, Luca Coelho wrote:
>>> From: Ayala Beker 
>>>
>>> This code doesn't do much besides allowing to start and stop the vif.
>>>
>>> Signed-off-by: Andrei Otcheretianski 
>>> Signed-off-by: Emmanuel Grumbach 
>>> Signed-off-by: Ayala Beker 
>>> Signed-off-by: Luca Coelho 
>>> ---
>>>  include/net/mac80211.h|  9 +
>>>  net/mac80211/cfg.c| 36 ++
>>>  net/mac80211/chan.c   |  3 +++
>>>  net/mac80211/driver-ops.h | 29 ++-
>>>  net/mac80211/iface.c  |  8 ++--
>>>  net/mac80211/main.c   |  5 +
>>>  net/mac80211/offchannel.c |  3 ++-
>>>  net/mac80211/trace.h  | 50
>> +++
>>>  net/mac80211/util.c   |  3 ++-
>>>  9 files changed, 141 insertions(+), 5 deletions(-)
>>
>> [...]
>>
>>> diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
>>> index fe35a1c..67b42c8 100644
>>> --- a/net/mac80211/driver-ops.h
>>> +++ b/net/mac80211/driver-ops.h
>>> @@ -163,7 +163,8 @@ static inline void drv_bss_info_changed(struct
>>> ieee80211_local *local,
>>>
>>> if (WARN_ON_ONCE(sdata->vif.type ==
>> NL80211_IFTYPE_P2P_DEVICE ||
>>>  (sdata->vif.type == NL80211_IFTYPE_MONITOR &&
>>> - !sdata->vif.mu_mimo_owner)))
>>> + !sdata->vif.mu_mimo_owner) ||
>>> +sdata->vif.type == NL80211_IFTYPE_NAN))
>>
>> Might be more clear to move this up right after P2P_DEVICE check.
> 
> Why? It's a completely separate new condition - so it goes to the end.

I would say readability. Both P2P_DEVICE and NAN checks are single
comparisons as opposed to the MONITOR check.

>>
>>> return;
>>>
>>> if (!check_sdata_in_driver(sdata))
>>> @@ -1165,4 +1166,30 @@ static inline void drv_wake_tx_queue(struct
>> ieee80211_local *local,
>>> local->ops->wake_tx_queue(>hw, >txq);  }
>>>
>>> +static inline int drv_start_nan(struct ieee80211_local *local,
>>> +   struct ieee80211_sub_if_data *sdata,
>>> +   struct cfg80211_nan_conf *conf)
>>> +{
>>> +   int ret;
>>> +
>>> +   might_sleep();
>>> +   check_sdata_in_driver(sdata);
>>> +
>>> +   trace_drv_start_nan(local, sdata, conf);
>>> +   ret = local->ops->start_nan(>hw, >vif, conf);
>>> +   trace_drv_return_int(local, ret);
>>> +   return ret;
>>> +}
>>> +
>>> +static inline void drv_stop_nan(struct ieee80211_local *local,
>>> +   struct ieee80211_sub_if_data *sdata) {
>>> +   might_sleep();
>>> +   check_sdata_in_driver(sdata);
>>> +
>>> +   trace_drv_stop_nan(local, sdata);
>>> +   local->ops->stop_nan(>hw, >vif);
>>> +   trace_drv_return_void(local);
>>> +}
>>> +
>>>  #endif /* __MAC80211_DRIVER_OPS */
>>> diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c index
>>> e694ca2..507f46a 100644
>>> --- a/net/mac80211/iface.c
>>> +++ b/net/mac80211/iface.c
>>> @@ -327,6 +327,9 @@ static int ieee80211_check_queues(struct
>> ieee80211_sub_if_data *sdata,
>>> int n_queues = sdata->local->hw.queues;
>>> int i;
>>>
>>> +   if (iftype == NL80211_IFTYPE_NAN)
>>> +   return 0;
>>> +
>>> if (iftype != NL80211_IFTYPE_P2P_DEVICE) {
>>> for (i = 0; i < IEEE80211_NUM_ACS; i++) {
>>> if (WARN_ON_ONCE(sdata->vif.hw_queue[i] == @@
>> -647,7 +650,8 @@ int
>>> ieee80211_do_open(struct wireless_dev *wdev, bool coming_up)
>>> local->fif_probe_req++;
>>> }
>>>
>>> -   if (sdata->vif.type != NL80211_IFTYPE_P2P_DEVICE)
>>> +   if (sdata->vif.type != NL80211_IFTYPE_P2P_DEVICE &&
>>> +   sdata->vif.type != NL80211_IFTYPE_NAN)
>>
>> similar check keeps reoccuring in various places so maybe we can create a
>> helper function for it.
> 
> Right, but not sure that it deserves a function.

If similar new iftypes are anticipated it would make sense as it would
mean adding it in one place.

Regards,
Arend

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

[Arend Van Spriel]

On 18-9-2016 9:44, Otcheretianski, Andrei wrote:
>> -Original Message-
>> From: Arend Van Spriel [mailto:arend.vanspr...@broadcom.com]
>> Sent: Friday, September 16, 2016 13:59
>> To: Luca Coelho ; johan...@sipsolutions.net
>> Cc: linux-wireless@vger.kernel.org; Beker, Ayala ;
>> Otcheretianski, Andrei ; Grumbach,
>> Emmanuel ; Coelho, Luciano
>> 
>> Subject: Re: [PATCH v2 1/9] cfg80211: add start / stop NAN commands
>>
>> On 16-9-2016 10:33, Luca Coelho wrote:
>>> From: Ayala Beker 
>>>
>>> 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 
>>> Signed-off-by: Luca Coelho 
>>> ---
>>>  include/net/cfg80211.h   | 21 +-
>>>  include/uapi/linux/nl80211.h | 52 +
>>>  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   | 93
>> ++--
>>>  net/wireless/rdev-ops.h  | 20 ++
>>>  net/wireless/trace.h | 27 +
>>>  net/wireless/util.c  |  6 ++-
>>>  16 files changed, 267 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index
>>> d5e7f69..ca64d69 100644
>>> --- a/include/net/cfg80211.h
>>> +++ b/include/net/cfg80211.h
>>> @@ -2293,6 +2293,19 @@ struct cfg80211_qos_map {  };
>>
>> [...]
>>
>>> +/**
>>> + * enum nl80211_nan_dual_band_conf - NAN dual band configuration
>>> + *
>>> + * Defines the NAN dual band mode of operation
>>
>> Does it make sense to have such a notion of bands in use. And what does
>> 5.2GHz mean. Is this a subband within 5G channels? Probably I should read
>> the NAN spec to understand what is meant here. I would consider 5.2G as
>> lower 5G, ie. discovery on channel 44 but not sure if that is meant here.
>>
> 
> The NAN spec defines single and dual band modes of operation. The channels 
> are fixed for each band.
> On 2.4Ghz is channel 6 and 5GHz is either 44 or 149. Regarding 5.2 - it's 
> just a typo. It should be 5G - no deeper meaning.

The thing is that it seems likely other bands will be added so that
would kinda obsolete this whole enum. So I would propose to have another
way to configure the bands to use. This enum is not really extensible
though it may reflect the current state of the spec, which is still in
draft if I am not mistaken.

Regards,
Arend

Re: [PATCH v2 6/9] cfg80211: Provide an API to report NAN function termination

[Arend Van Spriel]

On 16-9-2016 10:33, Luca Coelho wrote:
> From: Ayala Beker 
> 
> Provide a function that reports NAN DE function termination. The function
> may be terminated due to one of the following reasons: user request,
> ttl expiration or failure.
> If the NAN instance is tied to the owner, the notification will be
> sent to the socket that started the NAN interface only

So the driver is supposed to use this function from the .rm_nan_func
callback (or .del_nan_func). How should the driver use this together
with cfg80211_free_nan_func() function.

> Signed-off-by: Andrei Otcheretianski 
> Signed-off-by: Emmanuel Grumbach 
> Signed-off-by: Luca Coelho 
> ---
>  include/net/cfg80211.h   | 16 
>  include/uapi/linux/nl80211.h | 15 
>  net/wireless/nl80211.c   | 58 
> 
>  3 files changed, 89 insertions(+)
> 
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index a08d7da..81770d6 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -5676,6 +5676,22 @@ struct cfg80211_nan_match_params {
>  void cfg80211_nan_match(struct wireless_dev *wdev,
>   struct cfg80211_nan_match_params *match, gfp_t gfp);
>  
> +/**
> + * cfg80211_nan_func_terminated - notify about NAN function termination.
> + *
> + * @wdev: the wireless device reporting the match
> + * @inst_id: the local instance id
> + * @reason: termination reason (one of the NL80211_NAN_FUNC_TERM_REASON_*)
> + * @cookie: unique NAN function identifier
> + * @gfp: allocation flags
> + *
> + * This function reports that the a NAN function is terminated.
> + */
> +void cfg80211_nan_func_terminated(struct wireless_dev *wdev,
> +   u8 inst_id,
> +   enum nl80211_nan_func_term_reason reason,
> +   u64 cookie, gfp_t gfp);
> +
>  /* ethtool helper */
>  void cfg80211_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo 
> *info);
>  
> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
> index badb4a6..fd86be6 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -4978,6 +4978,21 @@ enum nl80211_nan_publish_type {
>   NL80211_NAN_UNSOLICITED_PUBLISH = 1 << 1,
>  };
>  
> +/**
> + * enum nl80211_nan_func_term_reason - NAN functions termination reason
> + *
> + * Defines termination reasons of a NAN function
> + *
> + * @NL80211_NAN_FUNC_TERM_REASON_USER_REQUEST: requested by user
> + * @NL80211_NAN_FUNC_TERM_REASON_TTL_EXPIRED: timeout
> + * @NL80211_NAN_FUNC_TERM_REASON_ERROR: errored
> + */
> +enum nl80211_nan_func_term_reason {
> + NL80211_NAN_FUNC_TERM_REASON_USER_REQUEST,
> + NL80211_NAN_FUNC_TERM_REASON_TTL_EXPIRED,
> + NL80211_NAN_FUNC_TERM_REASON_ERROR,
> +};
> +
>  #define NL80211_NAN_FUNC_SERVICE_ID_LEN 6
>  #define NL80211_NAN_FUNC_SERVICE_SPEC_INFO_MAX_LEN 0xff
>  #define NL80211_NAN_FUNC_SRF_MAX_LEN 0xff
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 4d37717..f817105 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -10945,6 +10945,64 @@ nla_put_failure:
>  }
>  EXPORT_SYMBOL(cfg80211_nan_match);
>  
> +void cfg80211_nan_func_terminated(struct wireless_dev *wdev,
> +   u8 inst_id,
> +   enum nl80211_nan_func_term_reason reason,
> +   u64 cookie, gfp_t gfp)
> +{
> + struct wiphy *wiphy = wdev->wiphy;
> + struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy);
> + struct sk_buff *msg;
> + struct nlattr *func_attr;
> + void *hdr;
> +
> + if (WARN_ON(!inst_id))
> + return;
> +
> + msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
> + if (!msg)
> + return;
> +
> + hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_RM_NAN_FUNCTION);
> + if (!hdr) {
> + nlmsg_free(msg);
> + return;
> + }
> +
> + if (nla_put_u32(msg, NL80211_ATTR_WIPHY, rdev->wiphy_idx) ||
> + (wdev->netdev && nla_put_u32(msg, NL80211_ATTR_IFINDEX,
> +  wdev->netdev->ifindex)) ||
> + nla_put_u64(msg, NL80211_ATTR_WDEV, wdev_id(wdev)))
> + goto nla_put_failure;
> +
> + if (nla_put_u64(msg, NL80211_ATTR_COOKIE, cookie))
> + goto nla_put_failure;
> +
> + func_attr = nla_nest_start(msg, NL80211_ATTR_NAN_FUNC);
> + if (!func_attr)
> + goto nla_put_failure;
> +
> + if (nla_put_u8(msg, NL80211_NAN_FUNC_INSTANCE_ID, inst_id) ||
> + nla_put_u8(msg, NL80211_NAN_FUNC_TERM_REASON, reason))
> + goto nla_put_failure;
> +
> + nla_nest_end(msg, func_attr);
> + genlmsg_end(msg, hdr);
> +
> + if (!wdev->owner_nlportid)
> + genlmsg_multicast_netns(_fam, 

[PATCH 0/2] rhashtable: rhashtable with duplicate objects

[Herbert Xu]

On Fri, Aug 05, 2016 at 12:50:33PM +0200, Johannes Berg wrote:
> > My plan is to build support for this directly into rhashtable.
> > So I'm adding a struct rhlist_head that would be used in place
> > of rhash_head for these cases and it'll carry an extra pointer
> > for the list of identical entries.
> > 
> > I will then add an additional layer of insert/lookup interfaces
> > for rhlist_head.
> 
> Oh, ok.

OK, it's finally ready now.

This series contains one two patches.  The first adds the rhlist
interface and the second converts mac80211 to use it.  If this works
out I'll then proceed to convert the other insecure_elasticity
users over to this.

I've tested the rhlist code with test_rhashtable but I haven't
tested the mac80211 conversion.  So please give it a go and see
if it still works.

Thanks!
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] rtl8xxxu: Stop log spam from each successful interrupt

[Jes Sorensen]

Kalle Valo  writes:
> Jes Sorensen  writes:
>
>> Joe Perches  writes:
>>> I think it'd be nicer to use dev_dbg for all these cases
>>> and as well use some new macro that includes the test
>>>
>>> Something like:
>>>
>>> #define rtl8xxxu_dbg(type, fmt, ...)\
>>> do {\
>>> if (rtl8xxxu_debug & (type))\
>>> dev_dbg(dev, fmt, ##__VA_ARGS__);   \
>>> } while (0)
>>
>> Yuck yuck yuck, no thanks!
>>
>> Any attempt of adding that kinda grossness to the driver will get a
>> NACK.
>
> Huh, how is that ugly? To me it's the opposite, original code is ugly
> and Joes' proposal makes sense. Lots of wireless drivers have something
> similar.

Sorry it's a classic case of obfuscating the code for zero gain. If
someone else likes this kinda wrapper in their code, by all means go
ahead. In my book it's just bad coding taste.

Jes

Re: [PATCH v2 3/9] cfg80211: add add_nan_func / rm_nan_func

[Arend Van Spriel]

On 16-9-2016 10:33, Luca Coelho wrote:
> From: Ayala Beker 
> 
> A NAN function can be either publish, subscribe or follow
> up. Make all the necessary verifications and just pass the
> request to the driver.
> Allow the user space application that starts NAN to
> forbid any other socket to add or remove functions.
> 
> Signed-off-by: Andrei Otcheretianski 
> Signed-off-by: Emmanuel Grumbach 
> Signed-off-by: Ayala Beker 
> Signed-off-by: Luca Coelho 
> ---

[...]

> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
> index 7ab18c8..ab16c8e 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -847,6 +847,24 @@
>   *   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_ADD_NAN_FUNCTION: Add a NAN function. The function is defined
> + *   with %NL80211_ATTR_NAN_FUNC nested attribute. When called, this
> + *   operation returns the strictly positive and unique instance id
> + *   (%NL80211_ATTR_NAN_FUNC_INST_ID) and a cookie (%NL80211_ATTR_COOKIE)
> + *   of the function upon success.
> + *   Since instance ID's can be re-used, this cookie is the right
> + *   way to identify the function. This will avoid races when a termination
> + *   event is handled by the user space after it has already added a new
> + *   function that got the same instance id from the kernel as the one
> + *   which just terminated.
> + *   This cookie may be used in NAN events even before the command
> + *   returns, so userspace shouldn't process NAN events until it processes
> + *   the response to this command.
> + *   Look at %NL80211_ATTR_SOCKET_OWNER as well.
> + * @NL80211_CMD_RM_NAN_FUNCTION: Remove a NAN function by cookie.
> + *   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.

This patch does not show the notification scenario as it is added in
patch 6. So those three lines could be added by that patch instead to
keep things logically together.

Regards,
Arend

Re: [PATCH] rtl8xxxu: Stop log spam from each successful interrupt

[Jes Sorensen]

Larry Finger  writes:
> On 09/17/2016 03:59 PM, Jes Sorensen wrote:
>> Larry Finger  writes:
>>> As soon as debugging is turned on, the logs are filled with messages
>>> reporting the interrupt status. As this quantity is usually zero, this
>>> output is not needed. In fact, there will be a report if the status is
>>> not zero, thus the debug line in question could probably be deleted.
>>> Rather than taking that action, I have changed it to only be printed
>>> when the RTL8XXXU_DEBUG_USB bit is set in the debug mask.
>>
>> Wrong flag, please add a RTL8XXXU_DEBUG_INTERRUPT flag instead and use
>> that.
>>
>> Which device do you see this with?
>
> OK. I will change the flag.
>
> I found this with a TP-Link TL-MN8200ND, which has some variant of the
> RTL8188CU chip. It transmits, but I see no evidence that the receiver
> is functioning at all. The same is true for driver rtl8192cu. Only the
> driver from Realtek's web site actually works.

I assume you mean TL-WN8200ND? That device is 'interesting' in the least
positive sense of the word. It seems abandoned by the manufacturer
too. I have one of them but never managed to get it working, not with
any driver under Linux nor Windows.

TP-Link shipped a driver disc with it, but you cannot install that in
any recent version of Windows because the OS ships with it's own driver
for the 8192cu/8188cu series and the device uses the common USB ID. I
have been meaning to see if I could find a box with Vista on it to
install their driver and run a USB trace on it.

> One other problem that I have found is that the debug option on module
> load seems to be ignored. So far, I've had to hard wire the
> flags. Once I find the reason, I'll send a patch for that as well.

That is odd - I use it regularly and haven't had problems with it.

Cheers,
Jes

[PATCH 2/2] mac80211: Use rhltable instead of rhashtable

[Herbert Xu]

mac80211 currently uses rhashtable with insecure_elasticity set
to true.  The latter is because of duplicate objects.  What's
more, mac80211 walks the rhashtable chains by hand which is broken
as rhashtable may contain multiple tables due to resizing or
rehashing.

This patch fixes it by converting it to the newly added rhltable
interface which is designed for use with duplicate objects.

With rhltable a lookup returns a list of objects instead of a
single one.  This is then fed into the existing for_each_sta_info
macro.

This patch also deletes the sta_addr_hash function since rhashtable
defaults to jhash.

Signed-off-by: Herbert Xu 
---

 net/mac80211/ieee80211_i.h |2 -
 net/mac80211/rx.c  |7 +-
 net/mac80211/sta_info.c|   52 ++---
 net/mac80211/sta_info.h|   19 ++--
 net/mac80211/status.c  |7 +-
 5 files changed, 33 insertions(+), 54 deletions(-)

diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index f56d342..1a52cd4 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1208,7 +1208,7 @@ struct ieee80211_local {
spinlock_t tim_lock;
unsigned long num_sta;
struct list_head sta_list;
-   struct rhashtable sta_hash;
+   struct rhltable sta_hash;
struct timer_list sta_cleanup;
int sta_generation;
 
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 9dce3b1..5e26dc6 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -3940,7 +3940,7 @@ static void __ieee80211_rx_handle_packet(struct 
ieee80211_hw *hw,
__le16 fc;
struct ieee80211_rx_data rx;
struct ieee80211_sub_if_data *prev;
-   struct rhash_head *tmp;
+   struct rhlist_head *tmp;
int err = 0;
 
fc = ((struct ieee80211_hdr *)skb->data)->frame_control;
@@ -3983,13 +3983,10 @@ static void __ieee80211_rx_handle_packet(struct 
ieee80211_hw *hw,
goto out;
} else if (ieee80211_is_data(fc)) {
struct sta_info *sta, *prev_sta;
-   const struct bucket_table *tbl;
 
prev_sta = NULL;
 
-   tbl = rht_dereference_rcu(local->sta_hash.tbl, 
>sta_hash);
-
-   for_each_sta_info(local, tbl, hdr->addr2, sta, tmp) {
+   for_each_sta_info(local, hdr->addr2, sta, tmp) {
if (!prev_sta) {
prev_sta = sta;
continue;
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 19f14c9..198d0bd 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -67,12 +67,10 @@
 
 static const struct rhashtable_params sta_rht_params = {
.nelem_hint = 3, /* start small */
-   .insecure_elasticity = true, /* Disable chain-length checks. */
.automatic_shrinking = true,
.head_offset = offsetof(struct sta_info, hash_node),
.key_offset = offsetof(struct sta_info, addr),
.key_len = ETH_ALEN,
-   .hashfn = sta_addr_hash,
.max_size = CONFIG_MAC80211_STA_HASH_MAX_SIZE,
 };
 
@@ -80,8 +78,8 @@ static const struct rhashtable_params sta_rht_params = {
 static int sta_info_hash_del(struct ieee80211_local *local,
 struct sta_info *sta)
 {
-   return rhashtable_remove_fast(>sta_hash, >hash_node,
- sta_rht_params);
+   return rhltable_remove(>sta_hash, >hash_node,
+  sta_rht_params);
 }
 
 static void __cleanup_single_sta(struct sta_info *sta)
@@ -157,19 +155,22 @@ static void cleanup_single_sta(struct sta_info *sta)
sta_info_free(local, sta);
 }
 
+struct rhlist_head *sta_info_hash_lookup(struct ieee80211_local *local,
+const u8 *addr)
+{
+   return rhltable_lookup(>sta_hash, addr, sta_rht_params);
+}
+
 /* protected by RCU */
 struct sta_info *sta_info_get(struct ieee80211_sub_if_data *sdata,
  const u8 *addr)
 {
struct ieee80211_local *local = sdata->local;
+   struct rhlist_head *tmp;
struct sta_info *sta;
-   struct rhash_head *tmp;
-   const struct bucket_table *tbl;
 
rcu_read_lock();
-   tbl = rht_dereference_rcu(local->sta_hash.tbl, >sta_hash);
-
-   for_each_sta_info(local, tbl, addr, sta, tmp) {
+   for_each_sta_info(local, addr, sta, tmp) {
if (sta->sdata == sdata) {
rcu_read_unlock();
/* this is safe as the caller must already hold
@@ -190,14 +191,11 @@ struct sta_info *sta_info_get_bss(struct 
ieee80211_sub_if_data *sdata,
  const u8 *addr)
 {
struct ieee80211_local *local = sdata->local;
+   struct rhlist_head *tmp;
struct sta_info *sta;
-   struct rhash_head *tmp;
-   const struct bucket_table *tbl;
 

Re: [PATCH v2 3/9] cfg80211: add add_nan_func / rm_nan_func

[Arend Van Spriel]

On 16-9-2016 10:33, Luca Coelho wrote:
> From: Ayala Beker 
> 
> A NAN function can be either publish, subscribe or follow
> up. Make all the necessary verifications and just pass the
> request to the driver.
> Allow the user space application that starts NAN to
> forbid any other socket to add or remove functions.
> 
> Signed-off-by: Andrei Otcheretianski 
> Signed-off-by: Emmanuel Grumbach 
> Signed-off-by: Ayala Beker 
> Signed-off-by: Luca Coelho 
> ---
>  include/net/cfg80211.h   |  91 +++
>  include/uapi/linux/nl80211.h | 153 ++
>  net/wireless/core.c  |   3 +-
>  net/wireless/nl80211.c   | 368 
> +++
>  net/wireless/rdev-ops.h  |  21 +++
>  net/wireless/trace.h |  39 +
>  net/wireless/util.c  |  22 +++
>  7 files changed, 696 insertions(+), 1 deletion(-)
> 
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index ca64d69..ced5b8a 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -2306,6 +2306,73 @@ struct cfg80211_nan_conf {
>  };
>  
>  /**
> + * struct cfg80211_nan_func_filter - a NAN function Rx / Tx filter
> + *
> + * @filter: the content of the filter
> + * @len: the length of the filter
> + */
> +struct cfg80211_nan_func_filter {
> + const u8 *filter;
> + u8 len;
> +};
> +
> +/**
> + * struct cfg80211_nan_func - a NAN function
> + *
> + * @type:  nl80211_nan_function_type
> + * @service_id: the service ID of the function
> + * @publish_type: _nan_publish_type
> + * @close_range: if true, the range should be limited. Threshold is
> + *   implementation specific.
> + * @publish_bcast: if true, the solicited publish should be broadcasted
> + * @subscribe_active: if true, the subscribe is active
> + * @followup_id: the instance ID for follow up
> + * @followup_reqid: the requestor instance ID for follow up
> + * @followup_dest: MAC address of the recipient of the follow up
> + * @ttl: time to live counter in DW.
> + * @serv_spec_info: Service Specific Info
> + * @serv_spec_info_len: Service Specific Info length
> + * @srf_include: if true, SRF is inclusive
> + * @srf_bf: Bloom Filter
> + * @srf_bf_len: Bloom Filter length
> + * @srf_bf_idx: Bloom Filter index
> + * @srf_macs: SRF MAC addresses
> + * @srf_num_macs: number of MAC addresses in SRF
> + * @rx_filters: rx filters that are matched with corresponding peer's 
> tx_filter
> + * @tx_filters: filters that should be transmitted in the SDF.
> + * @num_rx_filters: length of _filters.
> + * @num_tx_filters: length of _filters.
> + * @instance_id: driver allocated id of the function.
> + * @cookie: unique NAN function identifier.

Might be wrong but it seems a subset of the fields is used depending on
the type of NAN function. Maybe better to separate the function type
specific field in a sub structure defintion.

> + */
> +struct cfg80211_nan_func {
> + enum nl80211_nan_function_type type;
> + u8 service_id[NL80211_NAN_FUNC_SERVICE_ID_LEN];
> + u8 publish_type;
> + bool close_range;
> + bool publish_bcast;
> + bool subscribe_active;
> + u8 followup_id;
> + u8 followup_reqid;
> + struct mac_address followup_dest;
> + u32 ttl;
> + const u8 *serv_spec_info;
> + u8 serv_spec_info_len;
> + bool srf_include;
> + const u8 *srf_bf;
> + u8 srf_bf_len;
> + u8 srf_bf_idx;
> + struct mac_address *srf_macs;
> + int srf_num_macs;
> + struct cfg80211_nan_func_filter *rx_filters;
> + struct cfg80211_nan_func_filter *tx_filters;
> + u8 num_tx_filters;
> + u8 num_rx_filters;
> + u8 instance_id;
> + u64 cookie;
> +};
> +
> +/**
>   * struct cfg80211_ops - backend description for wireless configuration
>   *
>   * This struct is registered by fullmac card drivers and/or wireless stacks
> @@ -2595,6 +2662,14 @@ struct cfg80211_nan_conf {
>   *   peers must be on the base channel when the call completes.
>   * @start_nan: Start the NAN interface.
>   * @stop_nan: Stop the NAN interface.
> + * @add_nan_func: Add a NAN function. Returns negative value on failure.
> + *   On success @nan_func ownership is transferred to the driver and
> + *   it may access it outside of the scope of this function. The driver
> + *   should free the @nan_func when no longer needed by calling
> + *   cfg80211_free_nan_func().
> + *   On success the driver should assign an instance_id in the
> + *   provided @nan_func.
> + * @rm_nan_func: Remove a NAN function.

Would prefer del_nan_func here. At least all other add_* callbacks in
this structure have a del_* counter part.

>   */
>  struct cfg80211_ops {
>   int (*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
> @@ -2863,6 +2938,10 @@ struct cfg80211_ops {
>   int (*start_nan)(struct wiphy *wiphy, struct wireless_dev *wdev,
>  

Re: [PATCH 2/4] carl9170: fix debugfs crashes

[Kalle Valo]

Greg KH  writes:

> On Sun, Sep 18, 2016 at 10:54:18AM +0300, Kalle Valo wrote:
>> Greg KH  writes:
>> 
>> > On Sat, Sep 17, 2016 at 09:43:02PM +0200, Christian Lamparter wrote:
>> >> Ben Greear reported:
>> >> > I see lots of instability as soon as I load up the carl9710 NIC.
>> >> > My application is going to be poking at it's debugfs files...
>> >> >
>> >> > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
>> >> > [carl9170] at addr 8801bc1208b0
>> >> > Read of size 8 by task btserver/5888
>> >> > ===
>> >> > BUG kmalloc-256 (Tainted: GW  ): kasan: bad access detected
>> >> > ---
>> >> >
>> >> > INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
>> >> >...
>> >> 
>> >> This breakage was caused by the introduction of intermediate
>> >> fops in debugfs by commit 9fd4dcece43a
>> >> ("debugfs: prevent access to possibly dead file_operations at file open")
>> >
>> > Because of this, these should all be backported to 4.7-stable, and
>> > 4.8-stable, right?
>> 
>> Via which tree should these go, Greg's or mine?
>
> I'll take it if you ack it, as it's a debugfs issue.

Good, thanks. The wireless patches look good to me so:

Acked-by: Kalle Valo 

-- 
Kalle Valo

Re: [PATCH v2 4/9] cfg80211: allow the user space to change current NAN configuration

[Arend Van Spriel]

On 16-9-2016 10:33, Luca Coelho wrote:
> From: Ayala Beker 
> 
> Some NAN configuration paramaters may change during the operation of
> the NaN device. For example, a user may want to update master preference

typo: NAN iso NaN.

Regards,
Arend

Re: Using ath5k/ath9k radio for constant-tx noise source.

[Bob Copeland]

On Wed, Aug 19, 2015 at 12:07:50PM -0700, Ben Greear wrote:
> I have a commercial AP that is using a CM9 ath5k radio (evidently, I could be 
> wrong)
> and it has the ability to do a constant transmit of raw noise (RF probe shows
> noise, but a monitor-port sniffer does not see any frames from the CM9).
> 
> I don't know the low-level details of how it is doing this, but I suspect
> it is using something like madwifi for a driver.
> 
> Does anyone know how this can be done with modern software and
> ath5k or ath9k NICs?

So, see the below patch for something that might work.  I only dusted off
and compile-tested this, and I'm not sure if it is controllable to the
extent that would be needed for things like DFS testing.

Just to reiterate the disclaimer, I'm told running radio in this mode for
an extended period of time can damage it, so -- good luck.

Note, ath9k has another kind of tx-99 mode which just sends out packets
constantly; ath5k is of course capable of doing that kind of thing too.
Setup for that is mostly the same except the descriptor list is just
self-linked and some of the phy tricks aren't needed.

>From fd374ea31833f705d6a08bb8f8e171cfcda8c302 Mon Sep 17 00:00:00 2001
From: Bob Copeland 
Date: Tue, 17 May 2016 00:24:42 -0400
Subject: [PATCH] ath5k: add continuous-wave transmit mode

Continuous-wave mode is a kind of testmode in which RF is emitted on
a single carrier frequency; sometimes this kind of thing is needed
for FCC certification.  Some Atheros devices support entering this
mode for testing.

This patch demonstrates (some of?) the settings needed to get the
device into the mode.  I don't claim to understand it and the PHY
is 100% undocumented as far as I know, so a lot of this is guesswork
based on what is done in some versions of madwifi.  It seems to work
on one radio I tried it on (monitored with ath9k's spectral scan and
my own "speccy" tool) -- but it might well destroy yours, so, don't
run it unless you don't care about that possibility.

Signed-off-by: Bob Copeland 
---
 drivers/net/wireless/ath/ath5k/Makefile |   1 +
 drivers/net/wireless/ath/ath5k/ath5k.h  |   1 +
 drivers/net/wireless/ath/ath5k/base.h   |   3 +
 drivers/net/wireless/ath/ath5k/debug.c  |  47 
 drivers/net/wireless/ath/ath5k/tx99.c   | 200 
 5 files changed, 252 insertions(+)
 create mode 100644 drivers/net/wireless/ath/ath5k/tx99.c

diff --git a/drivers/net/wireless/ath/ath5k/Makefile 
b/drivers/net/wireless/ath/ath5k/Makefile
index 1b3a34f..afc699f 100644
--- a/drivers/net/wireless/ath/ath5k/Makefile
+++ b/drivers/net/wireless/ath/ath5k/Makefile
@@ -16,6 +16,7 @@ ath5k-y   += rfkill.o
 ath5k-y+= ani.o
 ath5k-y+= sysfs.o
 ath5k-y+= mac80211-ops.o
+ath5k-y+= tx99.o
 ath5k-$(CONFIG_ATH5K_DEBUG)+= debug.o
 ath5k-$(CONFIG_ATH5K_AHB)  += ahb.o
 ath5k-$(CONFIG_ATH5K_PCI)  += pci.o
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h 
b/drivers/net/wireless/ath/ath5k/ath5k.h
index 67fedb6..8c86a96 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -1446,6 +1446,7 @@ struct ath5k_hw {
 
/* Calibration mask */
u8  ah_cal_mask;
+   booltx99_active;
 
/*
 * Function pointers
diff --git a/drivers/net/wireless/ath/ath5k/base.h 
b/drivers/net/wireless/ath/ath5k/base.h
index 97469d0..3e50c747 100644
--- a/drivers/net/wireless/ath/ath5k/base.h
+++ b/drivers/net/wireless/ath/ath5k/base.h
@@ -112,6 +112,9 @@ const char *ath5k_chip_name(enum ath5k_srev_type type, 
u_int16_t val);
 int ath5k_init_ah(struct ath5k_hw *ah, const struct ath_bus_ops *bus_ops);
 void ath5k_deinit_ah(struct ath5k_hw *ah);
 
+void ath5k_tx99_cw_start(struct ath5k_hw *ah);
+void ath5k_tx99_cw_stop(struct ath5k_hw *ah);
+
 /* Check whether BSSID mask is supported */
 #define ath5k_hw_hasbssidmask(_ah) (ah->ah_version == AR5K_AR5212)
 
diff --git a/drivers/net/wireless/ath/ath5k/debug.c 
b/drivers/net/wireless/ath/ath5k/debug.c
index 4f8d9ed..260f061 100644
--- a/drivers/net/wireless/ath/ath5k/debug.c
+++ b/drivers/net/wireless/ath/ath5k/debug.c
@@ -991,6 +991,50 @@ static const struct file_operations fops_eeprom = {
 };
 
 
+static ssize_t read_file_tx99(struct file *file, char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+   char buf[3];
+   struct ath5k_hw *ah = file->private_data;
+
+   if (!ah->tx99_active)
+   buf[0] = '0';
+   else
+   buf[0] = '1';
+   buf[1] = '\n';
+   buf[2] = '\0';
+   return simple_read_from_buffer(user_buf, count, ppos, buf, 2);
+}
+
+static ssize_t write_file_tx99(struct file *file, const char __user *user_buf,
+  size_t count, loff_t 

Re: [PATCH v2 6/9] cfg80211: Provide an API to report NAN function termination

[Arend Van Spriel]

On 18-9-2016 21:56, Arend Van Spriel wrote:
> On 16-9-2016 10:33, Luca Coelho wrote:
>> From: Ayala Beker 
>>
>> Provide a function that reports NAN DE function termination. The function
>> may be terminated due to one of the following reasons: user request,
>> ttl expiration or failure.
>> If the NAN instance is tied to the owner, the notification will be
>> sent to the socket that started the NAN interface only
> 
> So the driver is supposed to use this function from the .rm_nan_func
> callback (or .del_nan_func). How should the driver use this together
> with cfg80211_free_nan_func() function.

Hit Send button too fast. Would it make sense to free the nan func
implicitly in cfg80211_nan_func_terminated() function or would there be
reasons to keep it.

Regards,
Arend

ath10k inoperatable after suspend

[Steffen Arntz]

Hi at all,

I have an QCA988X based card in my laptop and have some "issues" with
it, that I was not experiencing with my previous ath9k based card.

The main issue is, that after suspend to RAM the card seems to be
"hung up" and only reloading ath10k_core and ath10k_pci helps to fix
the problem.

dmesg shows the following info after resuming:
>
> ACPI: Low-level resume complete
> ACPI : EC: EC started
> PM: Restoring platform NVS memory
> Enabling non-boot CPUs ...
> x86: Booting SMP configuration:
> smpboot: Booting Node 0 Processor 1 APIC 0x1
> numa_add_cpu cpu 1 node 0: mask now 0-1
>  cache: parent cpu1 should not be sleeping
> CPU1 is up
> smpboot: Booting Node 0 Processor 2 APIC 0x4
> numa_add_cpu cpu 2 node 0: mask now 0-2
>  cache: parent cpu2 should not be sleeping
> CPU2 is up
> smpboot: Booting Node 0 Processor 3 APIC 0x5
> numa_add_cpu cpu 3 node 0: mask now 0-3
>  cache: parent cpu3 should not be sleeping
> CPU3 is up
> ACPI: Waking up from system sleep state S3
> ehci-pci :00:1d.0: System wakeup disabled by ACPI
> PM: noirq resume of devices complete after 22.000 msecs
> PM: early resume of devices complete after 2.082 msecs
> tg3 :03:00.0: System wakeup disabled by ACPI
> sd 0:0:0:0: [sda] Starting disk
> rtc_cmos 00:01: System wakeup disabled by ACPI
> usb 2-1.6: reset high-speed USB device number 4 using ehci-pci
> ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> ata1.00: supports DRM functions and may not be fully accessible
> ata1.00: disabling queued TRIM support
> ata1.00: supports DRM functions and may not be fully accessible
> ata1.00: disabling queued TRIM support
> ata1.00: configured for UDMA/133
> psmouse serio4: synaptics: queried max coordinates: x [..5714], y [..5172]
> usb 1-1.5: reset full-speed USB device number 10 using ehci-pci
> usb 1-1.5: device firmware changed
> usb 1-1.4: reset full-speed USB device number 4 using ehci-pci
> usb 1-1.2: reset high-speed USB device number 3 using ehci-pci
> PM: resume of devices complete after 4693.622 msecs
> PM: Finishing wakeup.
> Restarting tasks ... done.
> video LNXVIDEO:00: Restoring backlight state
> usb 1-1.5: USB disconnect, device number 10
> usb 1-1.5: new full-speed USB device number 11 using ehci-pci
> usb 1-1.5: New USB device found, idVendor=0cf3, idProduct=3004
> usb 1-1.5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
> IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
> IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
> usb 1-1.5: USB disconnect, device number 11
> usb 1-1.5: new full-speed USB device number 12 using ehci-pci
> usb 1-1.5: New USB device found, idVendor=0cf3, idProduct=3004
> usb 1-1.5: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> wlp1s0: authenticate with 14:cc:20:ec:xx:xx
> ath10k_pci :01:00.0: failed to synchronize setup for vdev 0 restart 0: 
> -110
> ath10k_pci :01:00.0: failed to start vdev 0 addr 1c:3e:84:d3:xx:xx on 
> freq 5180: -110
> ath10k_pci :01:00.0: failed to synchronize setup for vdev 0 restart 0: 
> -110
> ath10k_pci :01:00.0: failed to start vdev 0 addr 1c:3e:84:d3:xx:xx on 
> freq 5180: -110
> ath10k_pci :01:00.0: failed to start WMI vdev 0: -11
> ath10k_pci :01:00.0: failed to start vdev 0 addr 1c:3e:84:d3:xx:xx on 
> freq 5180: -11
> ath10k_pci :01:00.0: failed to start WMI vdev 0: -11
> ath10k_pci :01:00.0: failed to start vdev 0 addr 1c:3e:84:d3:xx:xx on 
> freq 5180: -11
> ath10k_pci :01:00.0: failed to delete WMI vdev 0: -11
> ath10k_pci :01:00.0: could not suspend target (-11)
> ath10k_pci :01:00.0: device has crashed during init
> ath10k_pci :01:00.0: device has crashed during init
> ath10k_pci :01:00.0: failed to wait for target init: -70
> [drm:ironlake_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
> [drm:ironlake_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun

at this point I reload the kernel modules
>
> ath10k_pci :01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
> ath10k_pci :01:00.0: Direct firmware load for 
> ath10k/pre-cal-pci-:01:00.0.bin failed with error -2
> ath10k_pci :01:00.0: Direct firmware load for 
> ath10k/cal-pci-:01:00.0.bin failed with error -2
> ath10k_pci :01:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043022ff 
> sub 1a56:1420
> ath10k_pci :01:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0 testmode 0
> ath10k_pci :01:00.0: firmware ver 10.2.4.70.54 api 5 features 
> no-p2p,raw-mode,mfp crc32 9d340dd9
> ath10k_pci :01:00.0: Direct firmware load for 
> ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
> ath10k_pci :01:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
> ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 
> raw 0 hwcrypto 1


this happens on Linux hostnamehere 

Re: [PATCH v6 1/3] Documentation: dt: net: add ath9k wireless device binding

[Martin Blumenstingl]

On Fri, Sep 16, 2016 at 2:45 PM, Rob Herring  wrote:
> On Fri, Sep 09, 2016 at 10:57:06PM +0200, Martin Blumenstingl wrote:
>> On Fri, Sep 9, 2016 at 9:48 AM, Oleksij Rempel  
>> wrote:
>> >> +Optional properties:
>> >> +- reg: Address and length of the register set for the device.
>> >> +- qca,clk-25mhz: Defines that a 25MHz clock is used
>> >
>> > Some SoCs even Atheros WiSoCs use WiFi clock for System Clock. In this
>> > case we need to use clock framework any way, so why not in this case too?
>> > Provide dummy static clock in DT and connect it with this node?
>> >
>> > osc25m: oscillator {
>> > compatible = "fixed-clock";
>> > #clock-cells = <0>;
>> > clock-frequency = <2500>;
>> > clock-accuracy = <3>;
>> > };
>> >
>> > acc: clock-controller@8004 {
>> > compatible = "some-clock-controller";
>> > #clock-cells = <1>;
>> > clocks = <>;
>> > reg = <0x8004 0x204>;
>> > };
>> >
>> >
>> >  {
>> > ath9k@168c,002d {
>> > compatible = "pci168c,002d";
>> > reg = <0x7000 0 0 0 0x1000>;
>> > clocks = <>;
>> > qca,disable-5ghz;
>> > };
>> > };
>> >
>> >
>> > driver will need to use clk_get and compare frequency instead of
>> > of_property_read_bool(np, "qca,clk-25mhz"). In this case you will need
>> > to define source clock only one time and reuse it by all affected DT
>> > nodes. If we have 40MHz clock you will only need to change it in
>> > fixed-clock.
>> that does sound like a good idea, thanks for that input!
>> However, I will remove the property for the first version because I am
>> trying to get PCI(e) devices supported. OF support for AHB (WiSoC)
>> needs more work (in other places, like ahb.c) anyways.
>> But this suggestion should be remembered!
>>
>> >> +- qca,no-eeprom: Indicates that there is no physical EEPROM connected to 
>> >> the
>> >> + ath9k wireless chip (in this case the calibration /
>> >> + EEPROM data will be loaded from userspace using the
>> >> + kernel firmware loader).
>> >> +- qca,disable-2ghz: Overrides the settings from the EEPROM and disables 
>> >> the
>> >> + 2.4GHz band. Setting this property is only needed
>> >> + when the RF circuit does not support the 2.4GHz band
>> >> + while it is enabled nevertheless in the EEPROM.
>> >> +- qca,disable-5ghz: Overrides the settings from the EEPROM and disables 
>> >> the
>> >> + 5GHz band. Setting this property is only needed when
>> >> + the RF circuit does not support the 5GHz band while
>> >> + it is enabled nevertheless in the EEPROM.
>> >
>> > This option can be reused for every WiFi controller. Not only for qca.
>> > So may be instead of adding vendor specific name, make it reusable for
>> > all vendors. Instead of qca,disable-5ghz and qca,disable-2ghz make
>> > disable-5ghz and disable-2ghz?
>
> Fine, but if you do this then document in a common location.
what about Documentation/devicetree/bindings/net/wireless/ieee80211-common.txt?

>> I am personally fine with anything that fits best into the grand
>> scheme of things.
>> There are three scenarios I can think of which may be influenced by
>> devicetree configuration:
>> a) let the driver decide automatically whether the 2.4GHz and/or 5GHz
>> band is/are enabled
>> b) explicitly disable either bands (because the driver thinks due to
>> whatever reason that a band is supported while in reality it isn't)
>> c) explicitly enable a band (for example because the driver cannot
>> automagically detect which band should be enabled)
>>
>> for ath9k we default to a) but also allow b): the EEPROM (device
>> specific calibration data) contains information about which bands are
>> enabled (or not). But some manufacturers are shipping devices for
>> example with the 5G band enabled, while the actual hardware doesn't
>> support it.
>
> And you can't determine that based on different device IDs? If you can
> use vendor/device ID, then you should. If not, then this is fine.
one example is the TP-Link TW-8970 which uses a AR9381. ath9k
identifies this chip as AR9380 (probably because both are *very*
similar). The former does not support the 5G band, the latter does
(but unfortunately - even though it's not supported - the EEPROM data
on the TW-8970 indicates that 5G is supported)

> Is it possible to have no EEPROM at all? If so, you might want to just
> put the raw EEPROM data into DT rather than a property for every field
> (I'm assuming there's more than just what you have properties for now).
In theory: yes
However, most devices we are talking about are legacy ones without
devicetree support in the bootloader (in other 

Re: pull-request: mac80211 2016-09-16

[David Miller]

From: Johannes Berg 
Date: Fri, 16 Sep 2016 14:47:22 +0200

> Sorry - I know you only just pulled my tree for the previous fixes,
> but we found two more problems in the last few days; it'd be great
> to get those fixes in as well.
> 
> Let me know if there's any problem.

Pulled, thanks Johannes.

Re: pull-request: mac80211-next 2016-09-16

[David Miller]

From: Johannes Berg 
Date: Fri, 16 Sep 2016 14:56:45 +0200

> And here's another set for net-next, it's been a month or so and we have a
> reasonably large number of patches (for a change, mostly because I cleaned
> up some WEP crypto thing and a few static checkers.)

Pulled, thanks.

wireless-drivers-next soon closing for 4.9

[Kalle Valo]

Hi,

Linus released 4.8-rc7 few hours and said that he "might" release -rc8
still. So if there's anything which you absolutely want to have in 4.9
send it now to make sure it makes it in time in the unlikely case that
-rc8 is not released. If -rc8 is released the deadline will be this
week's Sunday.

wireless-drivers remains open for important fixes.

-- 
Kalle Valo