* [PATCH 03/25] iwlwifi: mvm: cleanup skb queue functions use
From: Luca Coelho @ 2016-09-19 7:30 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Sara Sharon, Luca Coelho
In-Reply-To: <1474270071.5664.89.camel@coelho.fi>
From: Sara Sharon <sara.sharon@intel.com>
Use skb_queue_empty() and not skb_peek_tail() to check for
empty list.
Avoid a redundant check as well - loop will take care of it.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
index d6d9ec4..b386628 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
@@ -418,10 +418,11 @@ static void iwl_mvm_release_frames(struct iwl_mvm *mvm,
ssn = ieee80211_sn_inc(ssn);
- /* holes are valid since nssn indicates frames were received. */
- if (skb_queue_empty(skb_list) || !skb_peek_tail(skb_list))
- continue;
- /* Empty the list. Will have more than one frame for A-MSDU */
+ /*
+ * Empty the list. Will have more than one frame for A-MSDU.
+ * Empty list is valid as well since nssn indicates frames were
+ * received.
+ */
while ((skb = __skb_dequeue(skb_list))) {
iwl_mvm_pass_packet_to_mac80211(mvm, napi, skb,
reorder_buf->queue,
@@ -434,7 +435,7 @@ static void iwl_mvm_release_frames(struct iwl_mvm *mvm,
if (reorder_buf->num_stored && !reorder_buf->removed) {
u16 index = reorder_buf->head_sn % reorder_buf->buf_size;
- while (!skb_peek_tail(&reorder_buf->entries[index]))
+ while (skb_queue_empty(&reorder_buf->entries[index]))
index = (index + 1) % reorder_buf->buf_size;
/* modify timer to match next frame's expiration time */
mod_timer(&reorder_buf->reorder_timer,
@@ -462,7 +463,7 @@ void iwl_mvm_reorder_timer_expired(unsigned long data)
for (i = 0; i < buf->buf_size ; i++) {
index = (buf->head_sn + i) % buf->buf_size;
- if (!skb_peek_tail(&buf->entries[index]))
+ if (skb_queue_empty(&buf->entries[index]))
continue;
if (!time_after(jiffies, buf->reorder_time[index] +
RX_REORDER_BUF_TIMEOUT_MQ))
--
2.9.3
^ permalink raw reply related
* [PATCH 02/25] iwlwifi: pcie: fix typo in struct name for a000 devices
From: Luca Coelho @ 2016-09-19 7:30 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Sara Sharon, Luca Coelho
In-Reply-To: <1474270071.5664.89.camel@coelho.fi>
From: Sara Sharon <sara.sharon@intel.com>
commit 3cd1980b0cdf ("iwlwifi: pcie: introduce new tfd and tb formats")
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index 188b0de..74199b1 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -2953,7 +2953,7 @@ struct iwl_trans *iwl_trans_pcie_alloc(struct pci_dev *pdev,
if (cfg->use_tfh) {
trans_pcie->max_tbs = IWL_TFH_NUM_TBS;
- trans_pcie->tfd_size = sizeof(struct iwl_tfh_tb);
+ trans_pcie->tfd_size = sizeof(struct iwl_tfh_tfd);
} else {
trans_pcie->max_tbs = IWL_NUM_OF_TBS;
--
2.9.3
^ permalink raw reply related
* [PATCH 01/25] iwlwifi: mvm: remove variable shadowing
From: Luca Coelho @ 2016-09-19 7:30 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Liad Kaufman, Luca Coelho
In-Reply-To: <1474270071.5664.89.camel@coelho.fi>
From: Liad Kaufman <liad.kaufman@intel.com>
Variable "ac" defined twice. Fix that.
Fixes: commit 93f436e2c7fe ("iwlwifi: mvm: set sta_id in SCD_QUEUE_CONFIG cmd")
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
index 216aa54..d3a0378 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -745,14 +745,14 @@ static int iwl_mvm_sta_alloc_queue(struct iwl_mvm *mvm,
.scd_queue = queue,
.action = SCD_CFG_DISABLE_QUEUE,
};
- u8 ac;
+ u8 txq_curr_ac;
disable_agg_tids = iwl_mvm_remove_sta_queue_marking(mvm, queue);
spin_lock_bh(&mvm->queue_info_lock);
- ac = mvm->queue_info[queue].mac80211_ac;
+ txq_curr_ac = mvm->queue_info[queue].mac80211_ac;
cmd.sta_id = mvm->queue_info[queue].ra_sta_id;
- cmd.tx_fifo = iwl_mvm_ac_to_tx_fifo[ac];
+ cmd.tx_fifo = iwl_mvm_ac_to_tx_fifo[txq_curr_ac];
cmd.tid = mvm->queue_info[queue].txq_tid;
spin_unlock_bh(&mvm->queue_info_lock);
--
2.9.3
^ permalink raw reply related
* pull-request: iwlwifi-next 2016-09-19
From: Luca Coelho @ 2016-09-19 7:27 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, linuxwifi
[-- Attachment #1: Type: text/plain, Size: 5257 bytes --]
Hi Kalle,
Here we go again, now I'm almost catching up with the pending stuff in
our internal tree, just in time for 4.9. This pull contains a bunch of
fixes to DQA and new HW support code, a few new features and some
cleanups. More details in the tag description.
Let me know if everything's fine (or not). :)
Luca.
The following changes since commit 80ba4f1d365af206b9e818d17d22fed02fe5def0:
mwifiex: fix null pointer deference when adapter is null (2016-09-17 18:26:32 +0300)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2016-09-19
for you to fetch changes up to e9dd5c83fd1c8d36d9b8180a1ca7576f823442fd:
iwlwifi: pcie: use LIST_HEAD() macro (2016-09-19 10:10:19 +0300)
----------------------------------------------------------------
* added support for MU-MIMO sniffer
* added support for RRM by scan
* added support for packet injection
* migrate to devm memory allocation handling
* some fixes, mostly in DQA and new HW support
* other generic cleanups
----------------------------------------------------------------
Arik Nemtsov (1):
iwlwifi: move BIOS MCC retrieval to common code
Aviya Erenfeld (1):
iwlwifi: mvm: add support for MU-MIMO air sniffer
Avrahams Stern (1):
iwlwifi: mvm: Add support for RRM by scan
Emmanuel Grumbach (1):
iwlwifi: don't export trace points that are used in iwlwifi only
Haim Dreyfuss (1):
iwlwifi: check for valid ethernet address provided by OEM
Ido Yariv (1):
iwlwifi: mvm: Add mem debugfs entry
Johannes Berg (6):
iwlwifi: mvm: compare full command ID
iwlwifi: mvm: make iwl_mvm_update_sta() an inline
iwlwifi: mvm: document passing unexpected Block Ack Request frames
iwlwifi: mvm: move AP-specific code to right function
iwlwifi: mvm: use LIST_HEAD() macro
iwlwifi: pcie: use LIST_HEAD() macro
Liad Kaufman (1):
iwlwifi: mvm: remove variable shadowing
Oren Givon (1):
iwlwifi: add new 8265 series PCI ID
Roee Zamir (1):
iwlwifi: mvm: Add debugfs function for clocks diff
Sara Sharon (9):
iwlwifi: pcie: fix typo in struct name for a000 devices
iwlwifi: mvm: cleanup skb queue functions use
iwlwifi: mvm: fix DQA AP mode station assumption
iwlwifi: mvm: support BAR in reorder buffer
iwlwifi: mvm: support packet injection
iwlwifi: pcie: log full command sequence
iwlwifi: move to wide ID for all commands
iwlwifi: mvm: disable P2P queue on mac context release
iwlwifi: mvm: set HCMD_NAME for PHY_DB as well
Sharon Dvir (1):
iwlwifi: migrate to devm_* API
drivers/net/wireless/intel/iwlwifi/iwl-devtrace.c | 3 --
drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 5 ++
drivers/net/wireless/intel/iwlwifi/iwl-notif-wait.c | 8 +++-
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 104 ++++++++++++++++++++++++++++++++++++++++--
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.h | 20 +++++++-
drivers/net/wireless/intel/iwlwifi/iwl-phy-db.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-trans.c | 11 ++---
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 5 +-
drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c | 26 +++++++++++
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 184 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/net/wireless/intel/iwlwifi/mvm/fw-api-scan.h | 20 ++++----
drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h | 52 ++++++++++++++++++++-
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 47 ++++++++++---------
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 18 ++++++++
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 6 +++
drivers/net/wireless/intel/iwlwifi/mvm/nvm.c | 93 +------------------------------------
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 32 +++++++------
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 30 ++++++++----
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 61 ++++++++++++++++++++++---
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 13 ++----
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 11 +++--
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 35 +++++++++++---
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 1 +
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 2 -
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 9 ++--
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 84 ++++++++++++++--------------------
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 2 +-
27 files changed, 632 insertions(+), 252 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* RE: [PATCH v2 1/9] cfg80211: add start / stop NAN commands
From: Otcheretianski, Andrei @ 2016-09-19 7:25 UTC (permalink / raw)
To: Arend Van Spriel, Luca Coelho, johannes@sipsolutions.net
Cc: linux-wireless@vger.kernel.org, Beker, Ayala, Grumbach, Emmanuel,
Coelho, Luciano
In-Reply-To: <0480de5c-4137-2991-e829-68e6af6e1935@broadcom.com>
> -----Original Message-----
> From: Arend Van Spriel [mailto:arend.vanspriel@broadcom.com]
> Sent: Sunday, September 18, 2016 21:54
> To: Otcheretianski, Andrei <andrei.otcheretianski@intel.com>; Luca Coelho
> <luca@coelho.fi>; johannes@sipsolutions.net
> Cc: linux-wireless@vger.kernel.org; Beker, Ayala <ayala.beker@intel.com>;
> Grumbach, Emmanuel <emmanuel.grumbach@intel.com>; Coelho, Luciano
> <luciano.coelho@intel.com>
> Subject: Re: [PATCH v2 1/9] cfg80211: add start / stop NAN commands
>
> On 18-9-2016 9:44, Otcheretianski, Andrei wrote:
> >> -----Original Message-----
> >> From: Arend Van Spriel [mailto:arend.vanspriel@broadcom.com]
> >> Sent: Friday, September 16, 2016 13:59
> >> To: Luca Coelho <luca@coelho.fi>; johannes@sipsolutions.net
> >> Cc: linux-wireless@vger.kernel.org; Beker, Ayala
> >> <ayala.beker@intel.com>; Otcheretianski, Andrei
> >> <andrei.otcheretianski@intel.com>; Grumbach, Emmanuel
> >> <emmanuel.grumbach@intel.com>; Coelho, Luciano
> >> <luciano.coelho@intel.com>
> >> Subject: Re: [PATCH v2 1/9] cfg80211: add start / stop NAN commands
> >>
> >> On 16-9-2016 10:33, Luca Coelho wrote:
> >>> From: Ayala Beker <ayala.beker@intel.com>
> >>>
> >>> 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.otcheretianski@intel.com>
> >>> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> >>> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
> >>> ---
> >>> 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.
>
I guess you are talking about additional bands that are mentioned in NAN2 spec (like sub-1Ghz etc..).
I'm not sure that these bands will be used for sync or NAN2 specific operations only (like data path or ranging).
Nevertheless, you're right, I guess it doesn't harm to make it a bitmask of supported bands.
> Regards,
> Arend
^ permalink raw reply
* Re: ath10k mesh + ap + encryption?
From: Simon Wunderlich @ 2016-09-19 6:43 UTC (permalink / raw)
To: ath10k
Cc: Pedersen, Thomas, Valo, Kalle, Martin Blumenstingl,
openwrt-devel@lists.openwrt.org, linux-wireless@vger.kernel.org
In-Reply-To: <1473789271.27738.4.camel@qca.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]
On Tuesday, September 13, 2016 5:54:38 PM CEST Pedersen, Thomas wrote:
> On Tue, 2016-09-13 at 14:30 +0200, Simon Wunderlich wrote:
>
> > [...]
> >
> > Thanks for the clarification. We will then stick to the 70's branch
> > then.
> >
> > Does anyone have pointers for the other questions? :) I would believe
> > hat many
> > people would be interested in running AP + Mesh encrypted at the same
> > time (at
> > least in the open source community ...).
>
>
> We're testing encrypted AP + Mesh quite successfully right now with
> this firmware: https://github.com/kvalo/ath10k-firmware/commit/307cb46b
> 06661ebd3186723b5002de769c7add83, of course that is for a QCA4019 chip.
> Which chip are you using? I can poke the firmware guys for possibility
> of getting a 10.4.3.2 firmware build for it.
Hi Thomas,
thanks for the hint! We are using an older QCA9882. I assume your firmware will
not work for this one? If you can poke the firmware guys, that would be great.
:)
We also want to test the 70.52 firmware version next, maybe there were some
changes since the .42 we used.
Thanks,
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: TCP data throughput for BCM43362
From: Jörg Krause @ 2016-09-19 6:36 UTC (permalink / raw)
To: Arend Van Spriel, Franky Lin
Cc: Brett Rudley, brcm80211-dev-list, Hante Meuleman, Franky Lin,
linux-wireless, Arend van Spriel
In-Reply-To: <27e007ed-57f6-4082-2f65-a11ba3b7f548@broadcom.com>
Hi Arend,
On Wed, 2016-09-14 at 20:13 +0200, Arend Van Spriel wrote:
> On 14-9-2016 15:41, Jörg Krause wrote:
> >
> > Hi,
> >
> > On Mon, 2016-08-29 at 23:15 +0200, Jörg Krause wrote:
> > >
> > > On Mi, 2016-08-24 at 20:35 +0200, Arend Van Spriel wrote:
> > > >
> > > >
> > > > On 22-8-2016 15:37, Jörg Krause wrote:
> > > > >
> > > > >
> > > > >
> > > > > Hi all,
> > > > >
> > > > > I am back from vacation and I'd like to do more
> > > > > investigations
> > > > > about
> > > > > this issue. Please see my comments below...
> > > > >
> > > > > On Sun, 2016-08-07 at 13:41 +0200, Arend van Spriel wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 06-08-16 16:12, Jörg Krause wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hi all,
> > > > > >
> > > > > > A bit weird email format making it a bit hard to determine
> > > > > > where
> > > > > > your
> > > > > > last reply starts...
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fr, 2016-08-05 at 17:56 -0700, Franky Lin wrote:
> > > > > > >
> > > > > > > On Fri, Aug 5, 2016 at 2:29 PM, Jörg Krause <joerg.krause
> > > > > > > @emb
> > > > > > > ed
> > > > > > > ded.
> > > > > > > ro
> > > > > > > cks>
> > > > > > > wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Am 5. August 2016 23:01:10 MESZ, schrieb Arend Van Spriel
> > > > > > > <
> > > > > > > arend.vanspriel@broadcom.com>:
> > > > > > >
> > > > > > >
> > > > > > > Op 5 aug. 2016 22:46 schreef "Jörg Krause"
> > > > > > > <joerg.krause@embedded.rocks>:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I'm using a custom ARM board with an BCM43362 wifi chip
> > > > > > > from
> > > > > > >
> > > > > > > Broadcom.
> > > > > > >
> > > > > > >
> > > > > > > The wifi chip is attached via SDIO to the controller with
> > > > > > > a
> > > > > > > clock of
> > > > > > > 48MHz. Linux kernel version is 4.7.
> > > > > > >
> > > > > > > When measuring the network bandwidth with iperf3 I get a
> > > > > > > bandwith of
> > > > > > > only around 5 Mbps. I found a similar thread at the
> > > > > > > Broadcom
> > > > > > >
> > > > > > > community
> > > > > > >
> > > > > > >
> > > > > > > [1] where the test was done with a M4 CPU + BCM43362 and
> > > > > > > an
> > > > > > > average
> > > > > > > result of 3.3 Mbps.
> > > > > > >
> > > > > > > Interestingly, a BCM43362 Wi-Fi Dev Kit [2] notes a TCP
> > > > > > > data
> > > > > > >
> > > > > > > throughput
> > > > > > >
> > > > > > >
> > > > > > > greater than 20 Mbps.
> > > > > > >
> > > > > > > Why is the throughput I measured much lower? Note that I
> > > > > > > measured
> > > > > > > several times with almost no neighbor devices or
> > > > > > > networks.
> > > > > > >
> > > > > > > This is a test sample measured with iperf3:
> > > > > > >
> > > > > > > $ iperf3 -c 192.168.2.1 -i 1 -t 10
> > > > > > > Connecting to host 192.168.2.1, port 5201
> > > > > > > [ 4] local 192.168.2.155 port 36442 connected to
> > > > > > > 192.168.2.1
> > > > > > >
> > > > > > > port
> > > > > > >
> > > > > > >
> > > > > > > 5201
> > > > > > > [ ID]
> > > > > > > Interval Transfer Bandwidth Retr Cwn
> > > > > > > d
> > > > > > > [ 4] 0.00-1.00 sec 615 KBytes 5.04
> > > > > > > Mbits/sec 0 56.6
> > > > > > > KBytes
> > > > > > > [ 4] 1.00-2.00 sec 622 KBytes 5.10
> > > > > > > Mbits/sec 0 84.8
> > > > > > > KBytes
> > > > > > > [ 4] 2.00-3.00 sec 625 KBytes 5.12
> > > > > > > Mbits/sec 0 113
> > > > > > > KBytes
> > > > > > > [ 4] 3.00-4.00 sec 571 KBytes 4.68
> > > > > > > Mbits/sec 0 140
> > > > > > > KBytes
> > > > > > > [ 4] 4.00-5.00 sec 594 KBytes 4.87
> > > > > > > Mbits/sec 0 167
> > > > > > > KBytes
> > > > > > > [ 4] 5.00-6.00 sec 628 KBytes 5.14
> > > > > > > Mbits/sec 0 195
> > > > > > > KBytes
> > > > > > > [ 4] 6.00-7.00 sec 619 KBytes 5.07
> > > > > > > Mbits/sec 0 202
> > > > > > > KBytes
> > > > > > > [ 4] 7.00-8.00 sec 608 KBytes 4.98
> > > > > > > Mbits/sec 0 202
> > > > > > > KBytes
> > > > > > > [ 4] 8.00-9.00 sec 602 KBytes 4.93
> > > > > > > Mbits/sec 0 202
> > > > > > > KBytes
> > > > > > > [ 4] 9.00-10.00 sec 537 KBytes 4.40
> > > > > > > Mbits/sec 0 202
> > > > > > > KBytes
> > > > > > > - - - - - - - - - - - - - - - - - - - - - - - - -
> > > > > > > [ ID]
> > > > > > > Interval Transfer Bandwidth Retr
> > > > > > > [ 4] 0.00-10.00 sec 5.88 MBytes 4.93
> > > > > > > Mbits/sec 0 sender
> > > > > > > [ 4] 0.00-10.00 sec 5.68 MBytes 4.76
> > > > > > > Mbits/sec receiver
> > > > > > >
> > > > > > >
> > > > > > > Not overly familiar with iperf3. Do these lines mean you
> > > > > > > are
> > > > > > > doing
> > > > > > > bidirectional test, ie. upstream and downstream at the
> > > > > > > same
> > > > > > > time.
> > > > > > > Another
> > > > > > > thing affecting tput could be power-save.
> > > > > > >
> > > > > > >
> > > > > > > No, iperf3 does not support bidrectional test. Power-save
> > > > > > > is
> > > > > > > turned
> > > > > > > off.
> > > > > > >
> > > > > > > What does iw link say?
> > > > > > >
> > > > > >
> > > > > > but I guess it starts here!
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I compared the results with a Cubietruck I have:
> > > > > > >
> > > > > > > # iperf3 -s
> > > > > > > -------------------------------------------------------
> > > > > > > ----
> > > > > > > Server listening on 5201
> > > > > > > -------------------------------------------------------
> > > > > > > ----
> > > > > > > Accepted connection from 192.168.178.46, port 42906
> > > > > > > [ 5] local 192.168.178.38 port 5201 connected to
> > > > > > > 192.168.178.46
> > > > > > > port
> > > > > > > 42908
> > > > > > > [ ID] Interval Transfer Bandwidth
> > > > > > > [ 5] 0.00-1.00 sec 2.29 MBytes 19.2
> > > > > > > Mbits/sec
> > > > > > > [ 5] 1.00-2.00 sec 2.21 MBytes 18.5
> > > > > > > Mbits/sec
> > > > > > > [ 5] 2.00-3.00 sec 2.17 MBytes 18.2
> > > > > > > Mbits/sec
> > > > > > > [ 5] 3.00-4.00 sec 2.09 MBytes 17.6
> > > > > > > Mbits/sec
> > > > > > > [ 5] 4.00-5.00 sec 2.20 MBytes 18.5
> > > > > > > Mbits/sec
> > > > > > > [ 5] 5.00-6.00 sec 2.64 MBytes 22.1
> > > > > > > Mbits/sec
> > > > > > > [ 5] 6.00-7.00 sec 2.67 MBytes 22.4
> > > > > > > Mbits/sec
> > > > > > > [ 5] 7.00-8.00 sec 2.62 MBytes 22.0
> > > > > > > Mbits/sec
> > > > > > > [ 5] 8.00-9.00 sec 2.35 MBytes 19.8
> > > > > > > Mbits/sec
> > > > > > > [ 5] 9.00-10.00 sec 2.30 MBytes 19.3
> > > > > > > Mbits/sec
> > > > > > > [ 5] 10.00-10.03 sec 83.4 KBytes 23.5
> > > > > > > Mbits/sec
> > > > > > > - - - - - - - - - - - - - - - - - - - - - - - - -
> > > > > > > [ ID]
> > > > > > > Interval Transfer Bandwidth Retr
> > > > > > > [ 5] 0.00-10.03 sec 23.9 MBytes 20.0
> > > > > > > Mbits/sec 0 sender
> > > > > > > [ 5] 0.00-10.03 sec 23.6 MBytes 19.8
> > > > > > > Mbits/sec receiver
> > > > > > >
> > > > > > > # iw dev wlan0 link
> > > > > > > Connected to xx:xx:xx:xx:xx (on wlan0)
> > > > > > > SSID: xxx
> > > > > > > freq: 2437
> > > > > > > tx bitrate: 65.0 MBit/s
> > > > > > >
> > > > > > > bss flags: short-preamble short-slot-time
> > > > > > > dtim period: 1
> > > > > > > beacon int: 100
> > > > > >
> > > > > > Too bad RSSI is not in the output above. That may be due to
> > > > > > a
> > > > > > regression
> > > > > > in our driver which has been fixed by commit 94abd778a7bb
> > > > > > ("brcmfmac:
> > > > > > add fallback for devices that do not report per-chain
> > > > > > values").
> > > > > > However,
> > > > > > the tx bitrate seems within the same range as the other
> > > > > > platform.
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > The Cubietruck works also with the brcmfmac driver.
> > > > > > >
> > > > > > > May it depend on the NVRAM file?
> > > > > >
> > > > > > Not sure. Can you tell me a bit more about the custom ARM
> > > > > > board.
> > > > > > Does
> > > > > > it
> > > > > > use the same wifi module as Cubietruck, ie. the AMPAK
> > > > > > AP6210?
> > > > > > If
> > > > > > you
> > > > > > can
> > > > > > make a wireshark sniff we can check the actual bitrate and
> > > > > > medium
> > > > > > density in terms of packets. Another thing to look at is
> > > > > > the
> > > > > > SDIO
> > > > > > host
> > > > > > controller. In brcmf_sdiod_sgtable_alloc() some key values
> > > > > > are
> > > > > > used
> > > > > > from
> > > > > > the host controller. It only logs the number of entries of
> > > > > > the
> > > > > > scatter-gather table, but could you add the other values in
> > > > > > this
> > > > > > function that are used to determine the number of entries.
> > > > >
> > > > > My board uses the BCM43362 chip solely (no Bluetooth)
> > > > > attached to
> > > > > the
> > > > > SDIO interface of a NXP i.MX28 processor.
> > > > >
> > > > > I added some additional printk() to
> > > > > brcmf_sdiod_sgtable_alloc().
> > > > > These
> > > > > are the values printed after modprobe brcmfmac:
> > > > >
> > > > > [ 8.926657] sg_support=1
> > > > > [ 8.929440] max_blocks=511
> > > > > [ 8.932213] max_request_size=261632
> > > > > [ 8.935741] max_segment_count=52
> > > > > [ 8.939005] max_segment_size=65280
> > > > > [ 8.946095] nents=35
> > > >
> > > > Thanks. That looks good.
> > > >
> > > > >
> > > > >
> > > > >
> > > > > Additionally I attached a xz compresses wireshark sniff while
> > > > > running
> > > > > iper3 between the BCM43362 running as in AP mode with iperf3
> > > > > as a
> > > > > server and a PC in station mode running iperf3 as a client.
> > > >
> > > > Looking at the sniff it seems you captured on the ethernet
> > > > side.
> > > > That
> > > > does not give me any 802.11 specific info. Can you make a
> > > > wireless
> > > > capture preferably without encryption.
> > >
> > > You,re right! Sorry for this mistake. I did a re-capture on the
> > > wireless side now.
> >
> > Anything new about this? Anything I can do to help?
>
> I missed your previous email. Was already wondering whether to ping
> you.
> Digging around in my email folders I found it so will take a look at
> it.
Did you had some time to look at this?
Best regards
Jörg Krause
^ permalink raw reply
* wireless-drivers-next soon closing for 4.9
From: Kalle Valo @ 2016-09-19 5:46 UTC (permalink / raw)
To: linux-wireless
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
^ permalink raw reply
* Re: pull-request: mac80211-next 2016-09-16
From: David Miller @ 2016-09-19 2:30 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <1474030606-16664-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
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.
^ permalink raw reply
* Re: pull-request: mac80211 2016-09-16
From: David Miller @ 2016-09-19 2:27 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <1474030043-16094-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
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.
^ permalink raw reply
* ath10k inoperatable after suspend
From: Steffen Arntz @ 2016-09-18 22:52 UTC (permalink / raw)
To: linux-wireless
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 0000: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 0000: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 0000:01:00.0: failed to synchronize setup for vdev 0 restart 0: -110
> ath10k_pci 0000:01:00.0: failed to start vdev 0 addr 1c:3e:84:d3:xx:xx on freq 5180: -110
> ath10k_pci 0000:01:00.0: failed to synchronize setup for vdev 0 restart 0: -110
> ath10k_pci 0000:01:00.0: failed to start vdev 0 addr 1c:3e:84:d3:xx:xx on freq 5180: -110
> ath10k_pci 0000:01:00.0: failed to start WMI vdev 0: -11
> ath10k_pci 0000:01:00.0: failed to start vdev 0 addr 1c:3e:84:d3:xx:xx on freq 5180: -11
> ath10k_pci 0000:01:00.0: failed to start WMI vdev 0: -11
> ath10k_pci 0000:01:00.0: failed to start vdev 0 addr 1c:3e:84:d3:xx:xx on freq 5180: -11
> ath10k_pci 0000:01:00.0: failed to delete WMI vdev 0: -11
> ath10k_pci 0000:01:00.0: could not suspend target (-11)
> ath10k_pci 0000:01:00.0: device has crashed during init
> ath10k_pci 0000:01:00.0: device has crashed during init
> ath10k_pci 0000: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 0000:01:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
> ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:01:00.0.bin failed with error -2
> ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/cal-pci-0000:01:00.0.bin failed with error -2
> ath10k_pci 0000:01:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043022ff sub 1a56:1420
> ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0 testmode 0
> ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54 api 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
> ath10k_pci 0000:01:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
> ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
> ath10k_pci 0000: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 4.8.0-040800rc5-generic
#201609041832 SMP Sun Sep 4 22:34:01 UTC 2016 x86_64 x86_64 x86_64
GNU/Linux
And the issues where a lot worse with Kernel 4.4.
Fell free to request more detailed debug info as needed.
I wish all a nice rest of the weekend
Steffen Arntz
^ permalink raw reply
* Re: Using ath5k/ath9k radio for constant-tx noise source.
From: Bob Copeland @ 2016-09-18 22:14 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <55D4D406.5000603@candelatech.com>
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 <me@bobcopeland.com>
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 <me@bobcopeland.com>
---
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;
+ bool tx99_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 *ppos)
+{
+ char buf[32];
+ size_t buf_size;
+ struct ath5k_hw *ah = file->private_data;
+
+ buf_size = min(count, (sizeof(buf)-1));
+ if (copy_from_user(buf, user_buf, buf_size))
+ return -EFAULT;
+
+ buf[buf_size] = '\0';
+
+ if (buf[0] == '0')
+ ath5k_tx99_cw_stop(ah);
+ else if (buf[0] == '1')
+ ath5k_tx99_cw_start(ah);
+
+ return count;
+}
+
+static const struct file_operations fops_tx99 = {
+ .read = read_file_tx99,
+ .write = write_file_tx99,
+ .open = simple_open,
+ .owner = THIS_MODULE,
+ .llseek = default_llseek,
+};
+
void
ath5k_debug_init_device(struct ath5k_hw *ah)
{
@@ -1029,6 +1073,9 @@ ath5k_debug_init_device(struct ath5k_hw *ah)
debugfs_create_bool("32khz_clock", S_IWUSR | S_IRUSR, phydir,
&ah->ah_use_32khz_clock);
+
+ debugfs_create_file("tx99", S_IRUSR | S_IWUSR, phydir,
+ ah, &fops_tx99);
}
/* functions used in other places */
diff --git a/drivers/net/wireless/ath/ath5k/tx99.c b/drivers/net/wireless/ath/ath5k/tx99.c
new file mode 100644
index 0000000..3a88893
--- /dev/null
+++ b/drivers/net/wireless/ath/ath5k/tx99.c
@@ -0,0 +1,200 @@
+#include <net/mac80211.h>
+#include "ath5k.h"
+#include "base.h"
+#include "reg.h"
+
+/*
+ * Copyright (c) 2016 Bob Copeland <me@bobcopeland.com>
+ *
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer,
+ * without modification.
+ * 2. Redistributions in binary form must reproduce at minimum a disclaimer
+ * similar to the "NO WARRANTY" disclaimer below ("Disclaimer") and any
+ * redistribution must be conditioned upon including a substantially
+ * similar Disclaimer requirement for further binary redistribution.
+ * 3. Neither the names of the above-listed copyright holders nor the names
+ * of any contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ *
+ * NO WARRANTY
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTIBILITY
+ * AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY,
+ * OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
+ * IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
+ * THE POSSIBILITY OF SUCH DAMAGES.
+ */
+
+static void ath5k_tx99_queue_frames(struct ath5k_hw *ah, int count)
+{
+ int i, j;
+ int frame_len = 1500;
+ __le16 fc;
+ u8 rate_idx;
+ u8 qnum = 3;
+ int max_loops = 1000, loop;
+ struct ieee80211_hdr *frame;
+ struct ieee80211_tx_info *info;
+
+ struct sk_buff *skb;
+ struct ieee80211_tx_control control = {
+ .sta = NULL
+ };
+
+ for (i = 0; i < count; i++) {
+ fc = cpu_to_le16(IEEE80211_FTYPE_DATA | IEEE80211_FCTL_TODS);
+ skb = dev_alloc_skb(ah->hw->extra_tx_headroom + frame_len);
+ if (!skb)
+ continue;
+ skb_reserve(skb, ah->hw->extra_tx_headroom);
+
+ frame = (struct ieee80211_hdr *) skb_put(skb, frame_len);
+ memset(frame, 0, frame_len);
+ frame->frame_control = fc;
+ memcpy(frame->addr1, ah->common.macaddr, ETH_ALEN);
+ memcpy(frame->addr2, ah->common.macaddr, ETH_ALEN);
+ memcpy(frame->addr3, ah->common.macaddr, ETH_ALEN);
+ skb_set_queue_mapping(skb, IEEE80211_AC_VO);
+
+ info = IEEE80211_SKB_CB(skb);
+ memset(info, 0, sizeof(*info));
+ info->flags |= IEEE80211_TX_CTL_INJECTED;
+
+ /* use highest rate on whichever band we're on */
+ info->band = ah->curchan->band;
+ rate_idx = ah->sbands[info->band].n_bitrates - 1;
+
+ for (j=0; j < IEEE80211_TX_MAX_RATES; j++)
+ info->control.rates[j].idx = -1;
+
+ info->control.rates[0].idx = rate_idx;
+ info->control.rates[0].count = 15;
+
+ rcu_read_lock();
+ ath5k_tx_queue(ah->hw, skb, &ah->txqs[qnum], &control);
+ rcu_read_unlock();
+ }
+
+ /* wait for queued frames to be sent */
+ printk(KERN_INFO "ath5k: tx99: sending initial frames...\n");
+ loop = 0;
+ while (ath5k_hw_num_tx_pending(ah, qnum) > 0) {
+ msleep(10);
+ if (loop++ > max_loops)
+ break;
+ }
+ printk(KERN_INFO "ath5k: tx99: done sending initial frames\n");
+}
+
+void ath5k_tx99_cw_start(struct ath5k_hw *ah)
+{
+ u32 val, xpa_orig;
+ bool xpaa_active_high, xpab_active_high;
+
+ if (ah->tx99_active)
+ return;
+
+ printk(KERN_INFO "ath5k: entering tx99 mode on freq %d, txpower %d dBm\n",
+ ah->curchan->center_freq, ah->ah_txpower.txp_requested),
+ ah->tx99_active = true;
+
+ /*
+ * disable TX hang queue check -- if we don't do this then
+ * the tx watchdog will issue a reset eventually and we'll
+ * leave tx99 mode
+ */
+ clear_bit(ATH_STAT_STARTED, ah->status);
+
+ /* toggle XPA -- A for 5G or B for 2G */
+ ath5k_hw_reg_write(ah, 7, AR5K_PHY_PA_CTL);
+
+ val = ath5k_hw_reg_read(ah, AR5K_PHY_PA_CTL);
+ xpaa_active_high = !!(val & AR5K_PHY_PA_CTL_XPA_A_HI);
+ xpab_active_high = !!(val & AR5K_PHY_PA_CTL_XPA_B_HI);
+ xpa_orig = val;
+
+ if (ah->curchan->band == NL80211_BAND_5GHZ) {
+ val &= ~AR5K_PHY_PA_CTL_XPA_A_HI;
+ if (!xpaa_active_high)
+ val |= AR5K_PHY_PA_CTL_XPA_A_HI;
+ } else {
+ val &= ~AR5K_PHY_PA_CTL_XPA_B_HI;
+ if (!xpab_active_high)
+ val |= AR5K_PHY_PA_CTL_XPA_B_HI;
+ }
+ ath5k_hw_reg_write(ah, val, AR5K_PHY_PA_CTL);
+
+ /*
+ * baseband operates in receive mode in continuous wave mode so
+ * use non-transmitting antenna
+ */
+ ah->ah_tx_ant = 2;
+
+ /* send a few frames to ramp up output power */
+ ath5k_tx99_queue_frames(ah, 20);
+
+ mdelay(20);
+
+ /* disable interrupts */
+ ath5k_hw_set_imr(ah, 0);
+
+ /* force AGC clear */
+ AR5K_REG_ENABLE_BITS(ah, AR5K_PHY_TST2, AR5K_PHY_TST2_FORCE_AGC_CLR);
+ AR5K_REG_ENABLE_BITS(ah, 0x9864, 0x7f000);
+ AR5K_REG_ENABLE_BITS(ah, 0x9924, 0x7f00fe);
+
+ /* disable carrier sense */
+ AR5K_REG_ENABLE_BITS(ah, AR5K_DIAG_SW, AR5K_DIAG_SW_RX_CLEAR_HIGH | AR5K_DIAG_SW_IGNORE_CARR_SENSE);
+
+ /* disable receive */
+ ath5k_hw_reg_write(ah, AR5K_CR_RXD, AR5K_CR);
+
+ /* set constant values */
+ ath5k_hw_reg_write(ah, (0x1ff << 9) | 0x1ff, 0x983c);
+
+ /* enable testmode on the ADC */
+ AR5K_REG_MASKED_BITS(ah, AR5K_PHY_TST1, (1 << 7) | (1 << 1), 0xffffff7d);
+
+ /* turn on the ADC */
+ ath5k_hw_reg_write(ah, 0x80038ffc, AR5K_PHY_ADC_CTL);
+ mdelay(10);
+
+ /* turn on RF */
+ val = 0x10a098c2;
+ if (ah->curchan->band == NL80211_BAND_2GHZ) {
+ val |= 0x400000;
+ }
+ ath5k_hw_reg_write(ah, val, 0x98dc);
+ mdelay(10);
+ val |= 0x4000;
+
+ ath5k_hw_reg_write(ah, val, 0x98dc);
+}
+
+void ath5k_tx99_cw_stop(struct ath5k_hw *ah)
+{
+ if (!ah->tx99_active)
+ return;
+
+ printk(KERN_INFO "ath5k: leaving tx99 mode\n");
+ set_bit(ATH_STAT_STARTED, ah->status);
+ ah->tx99_active = false;
+
+ /* just reset the device */
+ ath5k_hw_reset(ah, ah->opmode, ah->curchan, false, false);
+}
--
2.9.0
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply related
* Re: [PATCH v6 1/3] Documentation: dt: net: add ath9k wireless device binding
From: Martin Blumenstingl @ 2016-09-18 21:51 UTC (permalink / raw)
To: Rob Herring
Cc: Oleksij Rempel, ath9k-devel, devicetree, linux-wireless,
ath9k-devel, mcgrof, mark.rutland, kvalo, chunkeey,
arend.vanspriel, julian.calaby, bjorn, nbd, arnd
In-Reply-To: <20160916124541.GB9689@rob-hp-laptop>
On Fri, Sep 16, 2016 at 2:45 PM, Rob Herring <robh@kernel.org> 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 <linux@rempel-privat.de> 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 = <25000000>;
>> > clock-accuracy = <30000>;
>> > };
>> >
>> > acc: clock-controller@80040000 {
>> > compatible = "some-clock-controller";
>> > #clock-cells = <1>;
>> > clocks = <&osc25m>;
>> > reg = <0x80040000 0x204>;
>> > };
>> >
>> >
>> > &pci0 {
>> > ath9k@168c,002d {
>> > compatible = "pci168c,002d";
>> > reg = <0x7000 0 0 0 0x1000>;
>> > clocks = <&osc25m>;
>> > 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 words: hand-written
.dts files).
^ permalink raw reply
* Re: [PATCH v2 6/9] cfg80211: Provide an API to report NAN function termination
From: Arend Van Spriel @ 2016-09-18 20:00 UTC (permalink / raw)
To: Luca Coelho, johannes
Cc: linux-wireless, Ayala Beker, Andrei Otcheretianski,
Emmanuel Grumbach, Luca Coelho
In-Reply-To: <c72fdae0-fa63-be83-62dc-9c7f409fcc61@broadcom.com>
On 18-9-2016 21:56, Arend Van Spriel wrote:
> On 16-9-2016 10:33, Luca Coelho wrote:
>> From: Ayala Beker <ayala.beker@intel.com>
>>
>> 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
^ permalink raw reply
* Re: [PATCH v2 6/9] cfg80211: Provide an API to report NAN function termination
From: Arend Van Spriel @ 2016-09-18 19:56 UTC (permalink / raw)
To: Luca Coelho, johannes
Cc: linux-wireless, Ayala Beker, Andrei Otcheretianski,
Emmanuel Grumbach, Luca Coelho
In-Reply-To: <20160916083321.5840-7-luca@coelho.fi>
On 16-9-2016 10:33, Luca Coelho wrote:
> From: Ayala Beker <ayala.beker@intel.com>
>
> 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 <andrei.otcheretianski@intel.com>
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
> ---
> 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(&nl80211_fam, wiphy_net(&rdev->wiphy),
> + msg, 0, NL80211_MCGRP_NAN, gfp);
> + else
> + genlmsg_unicast(wiphy_net(&rdev->wiphy), msg,
> + wdev->owner_nlportid);
> +
> + return;
> +
> +nla_put_failure:
> + nlmsg_free(msg);
> +}
> +EXPORT_SYMBOL(cfg80211_nan_func_terminated);
> +
> static int nl80211_get_protocol_features(struct sk_buff *skb,
> struct genl_info *info)
> {
>
^ permalink raw reply
* Re: [PATCH v2 3/9] cfg80211: add add_nan_func / rm_nan_func
From: Arend Van Spriel @ 2016-09-18 19:54 UTC (permalink / raw)
To: Luca Coelho, johannes
Cc: linux-wireless, Ayala Beker, Andrei Otcheretianski,
Emmanuel Grumbach, Luca Coelho
In-Reply-To: <20160916083321.5840-4-luca@coelho.fi>
On 16-9-2016 10:33, Luca Coelho wrote:
> From: Ayala Beker <ayala.beker@intel.com>
>
> 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 <andrei.otcheretianski@intel.com>
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> Signed-off-by: Ayala Beker <ayala.beker@intel.com>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
> ---
[...]
> 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
^ permalink raw reply
* Re: [PATCH v2 4/9] cfg80211: allow the user space to change current NAN configuration
From: Arend Van Spriel @ 2016-09-18 19:43 UTC (permalink / raw)
To: Luca Coelho, johannes
Cc: linux-wireless, Ayala Beker, Andrei Otcheretianski,
Emmanuel Grumbach, Luca Coelho
In-Reply-To: <20160916083321.5840-5-luca@coelho.fi>
On 16-9-2016 10:33, Luca Coelho wrote:
> From: Ayala Beker <ayala.beker@intel.com>
>
> 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
^ permalink raw reply
* Re: [PATCH v2 3/9] cfg80211: add add_nan_func / rm_nan_func
From: Arend Van Spriel @ 2016-09-18 19:28 UTC (permalink / raw)
To: Luca Coelho, johannes
Cc: linux-wireless, Ayala Beker, Andrei Otcheretianski,
Emmanuel Grumbach, Luca Coelho
In-Reply-To: <20160916083321.5840-4-luca@coelho.fi>
On 16-9-2016 10:33, Luca Coelho wrote:
> From: Ayala Beker <ayala.beker@intel.com>
>
> 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 <andrei.otcheretianski@intel.com>
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> Signed-off-by: Ayala Beker <ayala.beker@intel.com>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
> ---
> 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: &enum nl80211_nan_function_type
> + * @service_id: the service ID of the function
> + * @publish_type: &nl80211_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 &rx_filters.
> + * @num_tx_filters: length of &tx_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,
> struct cfg80211_nan_conf *conf);
> void (*stop_nan)(struct wiphy *wiphy, struct wireless_dev *wdev);
> + int (*add_nan_func)(struct wiphy *wiphy, struct wireless_dev *wdev,
> + struct cfg80211_nan_func *nan_func);
> + void (*rm_nan_func)(struct wiphy *wiphy, struct wireless_dev *wdev,
> + u64 cookie);
> };
>
> /*
> @@ -3311,6 +3390,8 @@ struct wiphy_iftype_ext_capab {
> * @bss_select_support: bitmask indicating the BSS selection criteria supported
> * by the driver in the .connect() callback. The bit position maps to the
> * attribute indices defined in &enum nl80211_bss_select_attr.
> + *
> + * @cookie_counter: unique generic cookie counter, used to identify objects.
> */
> struct wiphy {
> /* assign these fields before you register the wiphy */
> @@ -3440,6 +3521,8 @@ struct wiphy {
>
> u32 bss_select_support;
>
> + u64 cookie_counter;
> +
> char priv[0] __aligned(NETDEV_ALIGN);
> };
>
> @@ -5529,6 +5612,14 @@ wiphy_ext_feature_isset(struct wiphy *wiphy,
> return (ft_byte & BIT(ftidx % 8)) != 0;
> }
>
> +/**
> + * cfg80211_free_nan_func - free NAN function
> + * @f: NAN function that should be freed
> + *
> + * Frees all the NAN function and all it's allocated members.
> + */
> +void cfg80211_free_nan_func(struct cfg80211_nan_func *f);
> +
> /* 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 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.
> *
> * @NL80211_CMD_MAX: highest used command number
> * @__NL80211_CMD_AFTER_LAST: internal use
> @@ -1038,6 +1056,8 @@ enum nl80211_commands {
>
> NL80211_CMD_START_NAN,
> NL80211_CMD_STOP_NAN,
> + NL80211_CMD_ADD_NAN_FUNCTION,
> + NL80211_CMD_RM_NAN_FUNCTION,
NL80211_CMD_DEL_NAN_FUNCTION?
Regards,
Arend
^ permalink raw reply
* Re: [PATCH v2 2/9] mac80211: add boilerplate code for start / stop NAN
From: Arend Van Spriel @ 2016-09-18 19:01 UTC (permalink / raw)
To: Otcheretianski, Andrei, Luca Coelho, johannes@sipsolutions.net
Cc: linux-wireless@vger.kernel.org, Beker, Ayala, Grumbach, Emmanuel,
Coelho, Luciano
In-Reply-To: <B2CD83211F5FDD478D7EFFF030D107ED57286E64@hasmsx108.ger.corp.intel.com>
On 18-9-2016 9:59, Otcheretianski, Andrei wrote:
>> -----Original Message-----
>> From: Arend Van Spriel [mailto:arend.vanspriel@broadcom.com]
>> Sent: Friday, September 16, 2016 14:09
>> To: Luca Coelho <luca@coelho.fi>; johannes@sipsolutions.net
>> Cc: linux-wireless@vger.kernel.org; Beker, Ayala <ayala.beker@intel.com>;
>> Otcheretianski, Andrei <andrei.otcheretianski@intel.com>; Grumbach,
>> Emmanuel <emmanuel.grumbach@intel.com>; Coelho, Luciano
>> <luciano.coelho@intel.com>
>> 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 <ayala.beker@intel.com>
>>>
>>> This code doesn't do much besides allowing to start and stop the vif.
>>>
>>> Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
>>> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>>> Signed-off-by: Ayala Beker <ayala.beker@intel.com>
>>> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
>>> ---
>>> 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(&local->hw, &txq->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(&local->hw, &sdata->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(&local->hw, &sdata->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
^ permalink raw reply
* Re: [PATCH v2 1/9] cfg80211: add start / stop NAN commands
From: Arend Van Spriel @ 2016-09-18 18:54 UTC (permalink / raw)
To: Otcheretianski, Andrei, Luca Coelho, johannes@sipsolutions.net
Cc: linux-wireless@vger.kernel.org, Beker, Ayala, Grumbach, Emmanuel,
Coelho, Luciano
In-Reply-To: <B2CD83211F5FDD478D7EFFF030D107ED57286E44@hasmsx108.ger.corp.intel.com>
On 18-9-2016 9:44, Otcheretianski, Andrei wrote:
>> -----Original Message-----
>> From: Arend Van Spriel [mailto:arend.vanspriel@broadcom.com]
>> Sent: Friday, September 16, 2016 13:59
>> To: Luca Coelho <luca@coelho.fi>; johannes@sipsolutions.net
>> Cc: linux-wireless@vger.kernel.org; Beker, Ayala <ayala.beker@intel.com>;
>> Otcheretianski, Andrei <andrei.otcheretianski@intel.com>; Grumbach,
>> Emmanuel <emmanuel.grumbach@intel.com>; Coelho, Luciano
>> <luciano.coelho@intel.com>
>> Subject: Re: [PATCH v2 1/9] cfg80211: add start / stop NAN commands
>>
>> On 16-9-2016 10:33, Luca Coelho wrote:
>>> From: Ayala Beker <ayala.beker@intel.com>
>>>
>>> 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.otcheretianski@intel.com>
>>> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>>> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
>>> ---
>>> 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
^ permalink raw reply
* Re: [PATCH 2/4] carl9170: fix debugfs crashes
From: Kalle Valo @ 2016-09-18 16:57 UTC (permalink / raw)
To: Greg KH
Cc: Christian Lamparter, Christian Lamparter, linux-kernel,
linux-wireless, b43-dev, Nicolai Stange, Ben Greear, Larry Finger
In-Reply-To: <20160918101455.GA8410@kroah.com>
Greg KH <gregkh@linuxfoundation.org> writes:
> On Sun, Sep 18, 2016 at 10:54:18AM +0300, Kalle Valo wrote:
>> Greg KH <gregkh@linuxfoundation.org> 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 ffff8801bc1208b0
>> >> > Read of size 8 by task btserver/5888
>> >> > =======================================================================
>> >> > BUG kmalloc-256 (Tainted: G W ): 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 <kvalo@codeaurora.org>
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/4] carl9170: fix debugfs crashes
From: Greg KH @ 2016-09-18 16:44 UTC (permalink / raw)
To: Christian Lamparter
Cc: Kalle Valo, linux-kernel, linux-wireless, b43-dev, Nicolai Stange,
Ben Greear, Larry Finger
In-Reply-To: <2731122.i7AxIUFRZe@debian64>
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 <gregkh@linuxfoundation.org> 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 ffff8801bc1208b0
> > > >> > Read of size 8 by task btserver/5888
> > > >> > =======================================================================
> > > >> > BUG kmalloc-256 (Tainted: G W ): 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
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Stop log spam from each successful interrupt
From: Jes Sorensen @ 2016-09-18 16:26 UTC (permalink / raw)
To: Kalle Valo; +Cc: Joe Perches, Larry Finger, devel, linux-wireless
In-Reply-To: <8760pt7hzv.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> Jes Sorensen <Jes.Sorensen@redhat.com> writes:
>
>> Joe Perches <joe@perches.com> 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
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Stop log spam from each successful interrupt
From: Jes Sorensen @ 2016-09-18 15:00 UTC (permalink / raw)
To: Larry Finger; +Cc: kvalo, devel, linux-wireless
In-Reply-To: <a9bcf666-719e-bda8-17bb-212e269ca497@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> On 09/17/2016 03:59 PM, Jes Sorensen wrote:
>> Larry Finger <Larry.Finger@lwfinger.net> 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
^ permalink raw reply
* [PATCH 2/2] mac80211: Use rhltable instead of rhashtable
From: Herbert Xu @ 2016-09-18 13:54 UTC (permalink / raw)
To: Johannes Berg, David S. Miller, netdev, linux-wireless,
Thomas Graf, tom, Ben Greear
In-Reply-To: <20160918135030.GA7062@gondor.apana.org.au>
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 <herbert@gondor.apana.org.au>
---
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, &local->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(&local->sta_hash, &sta->hash_node,
- sta_rht_params);
+ return rhltable_remove(&local->sta_hash, &sta->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(&local->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, &local->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;
rcu_read_lock();
- tbl = rht_dereference_rcu(local->sta_hash.tbl, &local->sta_hash);
-
- for_each_sta_info(local, tbl, addr, sta, tmp) {
+ for_each_sta_info(local, addr, sta, tmp) {
if (sta->sdata == sdata ||
(sta->sdata->bss && sta->sdata->bss == sdata->bss)) {
rcu_read_unlock();
@@ -263,8 +261,8 @@ void sta_info_free(struct ieee80211_local *local, struct sta_info *sta)
static int sta_info_hash_add(struct ieee80211_local *local,
struct sta_info *sta)
{
- return rhashtable_insert_fast(&local->sta_hash, &sta->hash_node,
- sta_rht_params);
+ return rhltable_insert(&local->sta_hash, &sta->hash_node,
+ sta_rht_params);
}
static void sta_deliver_ps_frames(struct work_struct *wk)
@@ -450,9 +448,9 @@ static int sta_info_insert_check(struct sta_info *sta)
is_multicast_ether_addr(sta->sta.addr)))
return -EINVAL;
- /* Strictly speaking this isn't necessary as we hold the mutex, but
- * the rhashtable code can't really deal with that distinction. We
- * do require the mutex for correctness though.
+ /* The RCU read lock is required by rhashtable due to
+ * asynchronous resize/rehash. We also require the mutex
+ * for correctness.
*/
rcu_read_lock();
lockdep_assert_held(&sdata->local->sta_mtx);
@@ -1040,16 +1038,11 @@ static void sta_info_cleanup(unsigned long data)
round_jiffies(jiffies + STA_INFO_CLEANUP_INTERVAL));
}
-u32 sta_addr_hash(const void *key, u32 length, u32 seed)
-{
- return jhash(key, ETH_ALEN, seed);
-}
-
int sta_info_init(struct ieee80211_local *local)
{
int err;
- err = rhashtable_init(&local->sta_hash, &sta_rht_params);
+ err = rhltable_init(&local->sta_hash, &sta_rht_params);
if (err)
return err;
@@ -1065,7 +1058,7 @@ int sta_info_init(struct ieee80211_local *local)
void sta_info_stop(struct ieee80211_local *local)
{
del_timer_sync(&local->sta_cleanup);
- rhashtable_destroy(&local->sta_hash);
+ rhltable_destroy(&local->sta_hash);
}
@@ -1135,17 +1128,14 @@ struct ieee80211_sta *ieee80211_find_sta_by_ifaddr(struct ieee80211_hw *hw,
const u8 *localaddr)
{
struct ieee80211_local *local = hw_to_local(hw);
+ struct rhlist_head *tmp;
struct sta_info *sta;
- struct rhash_head *tmp;
- const struct bucket_table *tbl;
-
- tbl = rht_dereference_rcu(local->sta_hash.tbl, &local->sta_hash);
/*
* Just return a random station if localaddr is NULL
* ... first in list.
*/
- for_each_sta_info(local, tbl, addr, sta, tmp) {
+ for_each_sta_info(local, addr, sta, tmp) {
if (localaddr &&
!ether_addr_equal(sta->sdata->vif.addr, localaddr))
continue;
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 0556be3..d347ab5 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -452,7 +452,7 @@ struct sta_info {
/* General information, mostly static */
struct list_head list, free_list;
struct rcu_head rcu_head;
- struct rhash_head hash_node;
+ struct rhlist_head hash_node;
u8 addr[ETH_ALEN];
struct ieee80211_local *local;
struct ieee80211_sub_if_data *sdata;
@@ -635,6 +635,9 @@ rcu_dereference_protected_tid_tx(struct sta_info *sta, int tid)
*/
#define STA_INFO_CLEANUP_INTERVAL (10 * HZ)
+struct rhlist_head *sta_info_hash_lookup(struct ieee80211_local *local,
+ const u8 *addr);
+
/*
* Get a STA info, must be under RCU read lock.
*/
@@ -644,17 +647,9 @@ struct sta_info *sta_info_get(struct ieee80211_sub_if_data *sdata,
struct sta_info *sta_info_get_bss(struct ieee80211_sub_if_data *sdata,
const u8 *addr);
-u32 sta_addr_hash(const void *key, u32 length, u32 seed);
-
-#define _sta_bucket_idx(_tbl, _a) \
- rht_bucket_index(_tbl, sta_addr_hash(_a, ETH_ALEN, (_tbl)->hash_rnd))
-
-#define for_each_sta_info(local, tbl, _addr, _sta, _tmp) \
- rht_for_each_entry_rcu(_sta, _tmp, tbl, \
- _sta_bucket_idx(tbl, _addr), \
- hash_node) \
- /* compare address and run code only if it matches */ \
- if (ether_addr_equal(_sta->addr, (_addr)))
+#define for_each_sta_info(local, _addr, _sta, _tmp) \
+ rhl_for_each_entry_rcu(_sta, _tmp, \
+ sta_info_hash_lookup(local, _addr), hash_node)
/*
* Get STA info by index, BROKEN!
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index a2a6826..6361709 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -740,8 +740,8 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
__le16 fc;
struct ieee80211_supported_band *sband;
+ struct rhlist_head *tmp;
struct sta_info *sta;
- struct rhash_head *tmp;
int retry_count;
int rates_idx;
bool send_to_cooked;
@@ -749,7 +749,6 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
struct ieee80211_bar *bar;
int shift = 0;
int tid = IEEE80211_NUM_TIDS;
- const struct bucket_table *tbl;
rates_idx = ieee80211_tx_get_rates(hw, info, &retry_count);
@@ -758,9 +757,7 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
sband = local->hw.wiphy->bands[info->band];
fc = hdr->frame_control;
- tbl = rht_dereference_rcu(local->sta_hash.tbl, &local->sta_hash);
-
- for_each_sta_info(local, tbl, hdr->addr1, sta, tmp) {
+ for_each_sta_info(local, hdr->addr1, sta, tmp) {
/* skip wrong virtual interface */
if (!ether_addr_equal(hdr->addr2, sta->sdata->vif.addr))
continue;
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox