* [PATCH -next] mwifiex: fix missing destroy_workqueue() on error in mwifiex_add_virtual_intf()
From: Wei Yongjun @ 2016-09-29 14:57 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo
Cc: Wei Yongjun, linux-wireless
From: Wei Yongjun <weiyongjun1@huawei.com>
Add the missing destroy_workqueue() before return from
mwifiex_add_virtual_intf() in the error handling case.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 39ce76a..5fd5876 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -3016,6 +3016,8 @@ struct wireless_dev *mwifiex_add_virtual_intf(struct wiphy *wiphy,
priv->netdev = NULL;
memset(&priv->wdev, 0, sizeof(priv->wdev));
priv->wdev.iftype = NL80211_IFTYPE_UNSPECIFIED;
+ destroy_workqueue(priv->dfs_cac_workqueue);
+ priv->dfs_cac_workqueue = NULL;
return ERR_PTR(-ENOMEM);
}
^ permalink raw reply related
* Re: ath10k stuck on 6Mbps and spam syslog
From: Ben Greear @ 2016-09-29 14:47 UTC (permalink / raw)
To: Matteo Grandi, LinuxWireless Mailing List
In-Reply-To: <CAHdg3xa-mJpxZiDHC0NbaZT1PwnhnCbs2zjZiQbKdSCpHepcSw@mail.gmail.com>
stock ath10k firmware does not report tx-rate so the kernel always sees 6Mbps.
I don't know about the splat..maybe post the function
that is causing that?
/home/matteo/linux-imx6/backports4.4.2-i2CAT/net/mac80211/util.c:2621
Thanks,
Ben
On 09/29/2016 06:39 AM, Matteo Grandi wrote:
> Hello all,
>
> I'm struggling with a problem related on ath10k drivers:
> I'm using a Compex WLE600V5-27 (802.11ac) miniPCIe card for some HT
> tests needed for my thesis.
> I'm using ath10k drivers for this card, and backports-4.4.2, in
> particular the firmware-5.bin_10.2.4.70.54 because it seem to be the
> more recent.
> I've connected in mesh mode the WLE600V5 card with an 802.11n card
> (using ath9k drivers) but looking at the station dump, the tx bitrate
> is stuck on 6.0 Mbit/s for the ath10k. The ath9k one works well and
> watch -n1 iw <interfacename> station dump
> let me see changes of the tx rate and MCS on the ath9k during iperf
> tests, but the ath10k stucks on 6.0 Mbit/s.
>
> Then something misterious (for me) happen while the channel
> assignment: the syslog is spammed by this message:
>
> [17554.919459] ------------[ cut here ]------------
> [17554.919839] WARNING: CPU: 0 PID: 0 at
> /home/matteo/linux-imx6/backports4.4.2-i2CAT/net/mac80211/util.c:2621
> ieee80211_calculate_rx_timestamp+0x204/0x278 [mac80211]()
> [17554.919855] Modules linked in: arc4 sky2 ath10k_pci(O)
> ath10k_core(O) ath(O) mac80211(O) cfg80211(O) compat(O)
> [17554.919926] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W O
> 3.14.48-g408ccb9 #4
> [17554.919990] [<80015050>] (unwind_backtrace) from [<80011330>]
> (show_stack+0x10/0x14)
> [17554.920038] [<80011330>] (show_stack) from [<806537dc>]
> (dump_stack+0x80/0x90)
> [17554.920074] [<806537dc>] (dump_stack) from [<8002c578>]
> (warn_slowpath_common+0x6c/0x88)
> [17554.920103] [<8002c578>] (warn_slowpath_common) from [<8002c630>]
> (warn_slowpath_null+0x1c/0x24)
> [17554.920377] [<8002c630>] (warn_slowpath_null) from [<7f089c74>]
> (ieee80211_calculate_rx_timestamp+0x204/0x278 [mac80211])
> [17554.920826] [<7f089c74>] (ieee80211_calculate_rx_timestamp
> [mac80211]) from [<7f07d724>] (ieee80211_rx_napi+0xcc/0x8d4
> [mac80211])
> [17554.921259] [<7f07d724>] (ieee80211_rx_napi [mac80211]) from
> [<7f117fd0>] (ath10k_wmi_event_mgmt_rx+0x1f4/0x35c [ath10k_core])
> [17554.921540] [<7f117fd0>] (ath10k_wmi_event_mgmt_rx [ath10k_core])
> from [<7f10d844>] (ath10k_htc_rx_completion_handler+0x1cc/0x464
> [ath10k_core])
> [17554.921706] [<7f10d844>] (ath10k_htc_rx_completion_handler
> [ath10k_core]) from [<7f157b4c>] (ath10k_pci_process_rx_cb+0x1ac/0x1fc
> [ath10k_pci])
> [17554.921773] [<7f157b4c>] (ath10k_pci_process_rx_cb [ath10k_pci])
> from [<7f15b3ac>] (ath10k_ce_per_engine_service+0x5c/0x94
> [ath10k_pci])
> [17554.921835] [<7f15b3ac>] (ath10k_ce_per_engine_service
> [ath10k_pci]) from [<7f15b464>]
> (ath10k_ce_per_engine_service_any+0x80/0x88 [ath10k_pci])
> [17554.921892] [<7f15b464>] (ath10k_ce_per_engine_service_any
> [ath10k_pci]) from [<7f15a6d8>] (ath10k_pci_tasklet+0x24/0x5c
> [ath10k_pci])
> [17554.921946] [<7f15a6d8>] (ath10k_pci_tasklet [ath10k_pci]) from
> [<800304c8>] (tasklet_action+0x80/0x110)
> [17554.921979] [<800304c8>] (tasklet_action) from [<800306b8>]
> (__do_softirq+0x10c/0x248)
> [17554.922009] [<800306b8>] (__do_softirq) from [<80030a6c>]
> (irq_exit+0xac/0xf4)
> [17554.922042] [<80030a6c>] (irq_exit) from [<8000e904>] (handle_IRQ+0x44/0x90)
> [17554.922072] [<8000e904>] (handle_IRQ) from [<800084f8>]
> (gic_handle_irq+0x2c/0x5c)
> [17554.922105] [<800084f8>] (gic_handle_irq) from [<80011e00>]
> (__irq_svc+0x40/0x50)
> [17554.922122] Exception stack(0x80917f18 to 0x80917f60)
> [17554.922141] 7f00:
> 80917f60 000d3334
> [17554.922166] 7f20: 5221e106 00000ff7 4d693c44 00000ff7 a7705010
> 80924060 00000001 a7705014
> [17554.922190] 7f40: 8096243d 80916000 00000017 80917f60 a6aaaaab
> 80492940 60000013 ffffffff
> [17554.922224] [<80011e00>] (__irq_svc) from [<80492940>]
> (cpuidle_enter_state+0x50/0xe0)
> [17554.922252] [<80492940>] (cpuidle_enter_state) from [<80492ac8>]
> (cpuidle_idle_call+0xf8/0x148)
> [17554.922281] [<80492ac8>] (cpuidle_idle_call) from [<8000ec48>]
> (arch_cpu_idle+0x8/0x44)
> [17554.922322] [<8000ec48>] (arch_cpu_idle) from [<80066648>]
> (cpu_startup_entry+0xfc/0x140)
> [17554.922362] [<80066648>] (cpu_startup_entry) from [<808c5b08>]
> (start_kernel+0x360/0x36c)
> [17554.922379] ---[ end trace 87d4775146813aed ]---
> [17555.943454] ------------[ cut here ]------------
>
> that repeat continuously...
> Forcing legacy bitrates doesn't change the situation.
>
> I made some measurements using iperf, please find it in attachment.
>
> Other info:
>
> root@Yazi:~# modinfo ath10k_pci
> filename:
> /lib/modules/3.14.48-g408ccb9/kernel/drivers/net/wireless/ath/ath10k/ath10k_pci.ko
> firmware: ath10k/QCA9377/hw1.0/board.bin
> firmware: ath10k/QCA9377/hw1.0/firmware-5.bin
> firmware: ath10k/QCA6174/hw3.0/board-2.bin
> firmware: ath10k/QCA6174/hw3.0/board.bin
> firmware: ath10k/QCA6174/hw3.0/firmware-5.bin
> firmware: ath10k/QCA6174/hw3.0/firmware-4.bin
> firmware: ath10k/QCA6174/hw2.1/board-2.bin
> firmware: ath10k/QCA6174/hw2.1/board.bin
> firmware: ath10k/QCA6174/hw2.1/firmware-5.bin
> firmware: ath10k/QCA6174/hw2.1/firmware-4.bin
> firmware: ath10k/QCA988X/hw2.0/board-2.bin
> firmware: ath10k/QCA988X/hw2.0/board.bin
> firmware: ath10k/QCA988X/hw2.0/firmware-5.bin
> firmware: ath10k/QCA988X/hw2.0/firmware-4.bin
> firmware: ath10k/QCA988X/hw2.0/firmware-3.bin
> firmware: ath10k/QCA988X/hw2.0/firmware-2.bin
> firmware: ath10k/QCA988X/hw2.0/firmware.bin
> license: Dual BSD/GPL
> description: Driver support for Atheros QCA988X PCIe devices
> author: Qualcomm Atheros
> version: backported from Linux (v4.4.2-0-g1cb8570) using
> backports v4.4.2-1-0-gbec4037
> srcversion: EBB3D4E36DE49B7EC8057D0
> alias: pci:v0000168Cd00000042sv*sd*bc*sc*i*
> alias: pci:v0000168Cd00000040sv*sd*bc*sc*i*
> alias: pci:v0000168Cd0000003Esv*sd*bc*sc*i*
> alias: pci:v0000168Cd00000041sv*sd*bc*sc*i*
> alias: pci:v0000168Cd0000003Csv*sd*bc*sc*i*
> depends: ath10k_core,compat
> vermagic: 3.14.48-g408ccb9 SMP mod_unload modversions ARMv7 p2v8
> parm: irq_mode:0: auto, 1: legacy, 2: msi (default: 0) (uint)
> parm: reset_mode:0: auto, 1: warm only (default: 0) (uint)
>
> I don't know if it's only a problem of iw station dump that can't show
> the tx rate, but the spammed syslog honestly warn me...
>
> How shall I check what's wrong and see the HT work?
>
> Thanks a lot!
>
> Matteo
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* RE: [PATCH] mwifiex: parse device tree node for PCIe
From: Amitkumar Karwar @ 2016-09-29 13:58 UTC (permalink / raw)
To: Rob Herring
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam,
devicetree@vger.kernel.org, Wei-Ning Huang, Xinming Hu
In-Reply-To: <20160919212753.GA16598@rob-hp-laptop>
Hi Rob,
> From: Rob Herring [mailto:robh@kernel.org]
> Sent: Tuesday, September 20, 2016 2:58 AM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> devicetree@vger.kernel.org; Wei-Ning Huang; Xinming Hu
> Subject: Re: [PATCH] mwifiex: parse device tree node for PCIe
>
> On Fri, Sep 09, 2016 at 08:47:34PM +0530, Amitkumar Karwar wrote:
> > From: Xinming Hu <huxm@marvell.com>
> >
> > This patch derives device tree node from pcie bus layer framework.
> > Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
> > marvell-8xxx.txt) to accomodate PCIe changes.
> >
> > Signed-off-by: Xinming Hu <huxm@marvell.com>
> > Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> > ---
> > .../bindings/net/wireless/marvell-8xxx.txt | 64
> ++++++++++++++++++++++
> > .../bindings/net/wireless/marvell-sd8xxx.txt | 63 -------------
> --------
>
> Resend using -M option so I do have to figure out if you added 1 line or
> changed a bunch.
>
> > drivers/net/wireless/marvell/mwifiex/pcie.c | 19 +++++++
> > drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 +-
> > 4 files changed, 85 insertions(+), 64 deletions(-) create mode
> > 100644 Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> > delete mode 100644
> > Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> > b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> > new file mode 100644
> > index 0000000..a8a95aa
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> > @@ -0,0 +1,64 @@
> > +Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
> > +------
> > +
> > +This node provides properties for controlling the marvell sdio/pcie
> wireless device.
> > +The node is expected to be specified as a child node to the SDIO/PCIE
> > +controller that connects the device to the system.
> > +
> > +Required properties:
> > +
> > + - compatible : should be one of the following:
> > + * "marvell,sd8897"
> > + * "marvell,sd8997"
> > + * "marvell,pcie8997"
>
> PCIe uses vendor and product IDs for compatible strings. Please read the
> OF PCI bus bindings doc.
>
Thanks for review. I have submitted updated version(V3) with this change.
Regards,
Amitkumar Karwar
^ permalink raw reply
* [PATCH v3] mwifiex: parse device tree node for PCIe
From: Amitkumar Karwar @ 2016-09-29 13:56 UTC (permalink / raw)
To: linux-wireless; +Cc: rajatja, Xinming Hu, Amitkumar Karwar
From: Xinming Hu <huxm@marvell.com>
This patch derives device tree node from pcie bus layer framework.
Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
marvell-8xxx.txt) to accomodate PCIe changes.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
v2: Included vendor and product IDs in compatible strings for PCIe
chipsets(Rob Herring)
v3: Patch is created using -M option so that it will only include diff of
original and renamed files(Rob Herring)
---
.../{marvell-sd8xxx.txt => marvell-8xxx.txt} | 8 +++++---
drivers/net/wireless/marvell/mwifiex/pcie.c | 20 ++++++++++++++++++++
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 ++-
3 files changed, 27 insertions(+), 4 deletions(-)
rename Documentation/devicetree/bindings/net/wireless/{marvell-sd8xxx.txt => marvell-8xxx.txt} (91%)
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
similarity index 91%
rename from Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
rename to Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index c421aba..dfe5f8e 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,8 +1,8 @@
-Marvell 8897/8997 (sd8897/sd8997) SDIO devices
+Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
------
-This node provides properties for controlling the marvell sdio wireless device.
-The node is expected to be specified as a child node to the SDIO controller that
+This node provides properties for controlling the marvell sdio/pcie wireless device.
+The node is expected to be specified as a child node to the SDIO/PCIE controller that
connects the device to the system.
Required properties:
@@ -10,6 +10,8 @@ Required properties:
- compatible : should be one of the following:
* "marvell,sd8897"
* "marvell,sd8997"
+ * "pci11ab,2b42"
+ * "pci1b4b,2b42"
Optional properties:
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 063c707..f1eeb73 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -37,6 +37,23 @@ static struct mwifiex_if_ops pcie_ops;
static struct semaphore add_remove_card_sem;
+static const struct of_device_id mwifiex_pcie_of_match_table[] = {
+ { .compatible = "pci11ab,2b42" },
+ { .compatible = "pci1b4b,2b42" },
+ { }
+};
+
+static int mwifiex_pcie_probe_of(struct device *dev)
+{
+ if (!dev->of_node ||
+ !of_match_node(mwifiex_pcie_of_match_table, dev->of_node)) {
+ pr_err("pcie device node not available");
+ return -1;
+ }
+
+ return 0;
+}
+
static int
mwifiex_map_pci_memory(struct mwifiex_adapter *adapter, struct sk_buff *skb,
size_t size, int flags)
@@ -206,6 +223,9 @@ static int mwifiex_pcie_probe(struct pci_dev *pdev,
card->pcie.can_ext_scan = data->can_ext_scan;
}
+ /* device tree node parsing and platform specific configuration*/
+ mwifiex_pcie_probe_of(&pdev->dev);
+
if (mwifiex_add_card(card, &add_remove_card_sem, &pcie_ops,
MWIFIEX_PCIE)) {
pr_err("%s failed\n", __func__);
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index 638d30a..f2a7a13 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -2218,7 +2218,8 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, u8 first_sta, bool init)
* The cal-data can be read from device tree and/or
* a configuration file and downloaded to firmware.
*/
- if (priv->adapter->iface_type == MWIFIEX_SDIO &&
+ if ((priv->adapter->iface_type == MWIFIEX_SDIO ||
+ priv->adapter->iface_type == MWIFIEX_PCIE) &&
adapter->dev->of_node) {
adapter->dt_node = adapter->dev->of_node;
if (of_property_read_u32(adapter->dt_node,
--
1.9.1
^ permalink raw reply related
* Re: [v2] rt2x00: add support for mac addr from device tree
From: Kalle Valo @ 2016-09-29 13:51 UTC (permalink / raw)
To: Mathias Kresin; +Cc: linux-wireless
In-Reply-To: <87shskwaxh.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
>> was it intentional not to CC the linux-wireless list?
>
> No, that was a bug in my script. Thanks for noticing it! Please always
> report back if my script does something strange.
The bug is now fixed, it was just a matter of a loop being in wrong
indentation level. Python is awesome but sometimes I just hate it...
Let me know if the problem still happens. And thanks again for pointing
this out.
--
Kalle Valo
^ permalink raw reply
* ath10k stuck on 6Mbps and spam syslog
From: Matteo Grandi @ 2016-09-29 13:39 UTC (permalink / raw)
To: LinuxWireless Mailing List
[-- Attachment #1: Type: text/plain, Size: 6185 bytes --]
Hello all,
I'm struggling with a problem related on ath10k drivers:
I'm using a Compex WLE600V5-27 (802.11ac) miniPCIe card for some HT
tests needed for my thesis.
I'm using ath10k drivers for this card, and backports-4.4.2, in
particular the firmware-5.bin_10.2.4.70.54 because it seem to be the
more recent.
I've connected in mesh mode the WLE600V5 card with an 802.11n card
(using ath9k drivers) but looking at the station dump, the tx bitrate
is stuck on 6.0 Mbit/s for the ath10k. The ath9k one works well and
watch -n1 iw <interfacename> station dump
let me see changes of the tx rate and MCS on the ath9k during iperf
tests, but the ath10k stucks on 6.0 Mbit/s.
Then something misterious (for me) happen while the channel
assignment: the syslog is spammed by this message:
[17554.919459] ------------[ cut here ]------------
[17554.919839] WARNING: CPU: 0 PID: 0 at
/home/matteo/linux-imx6/backports4.4.2-i2CAT/net/mac80211/util.c:2621
ieee80211_calculate_rx_timestamp+0x204/0x278 [mac80211]()
[17554.919855] Modules linked in: arc4 sky2 ath10k_pci(O)
ath10k_core(O) ath(O) mac80211(O) cfg80211(O) compat(O)
[17554.919926] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W O
3.14.48-g408ccb9 #4
[17554.919990] [<80015050>] (unwind_backtrace) from [<80011330>]
(show_stack+0x10/0x14)
[17554.920038] [<80011330>] (show_stack) from [<806537dc>]
(dump_stack+0x80/0x90)
[17554.920074] [<806537dc>] (dump_stack) from [<8002c578>]
(warn_slowpath_common+0x6c/0x88)
[17554.920103] [<8002c578>] (warn_slowpath_common) from [<8002c630>]
(warn_slowpath_null+0x1c/0x24)
[17554.920377] [<8002c630>] (warn_slowpath_null) from [<7f089c74>]
(ieee80211_calculate_rx_timestamp+0x204/0x278 [mac80211])
[17554.920826] [<7f089c74>] (ieee80211_calculate_rx_timestamp
[mac80211]) from [<7f07d724>] (ieee80211_rx_napi+0xcc/0x8d4
[mac80211])
[17554.921259] [<7f07d724>] (ieee80211_rx_napi [mac80211]) from
[<7f117fd0>] (ath10k_wmi_event_mgmt_rx+0x1f4/0x35c [ath10k_core])
[17554.921540] [<7f117fd0>] (ath10k_wmi_event_mgmt_rx [ath10k_core])
from [<7f10d844>] (ath10k_htc_rx_completion_handler+0x1cc/0x464
[ath10k_core])
[17554.921706] [<7f10d844>] (ath10k_htc_rx_completion_handler
[ath10k_core]) from [<7f157b4c>] (ath10k_pci_process_rx_cb+0x1ac/0x1fc
[ath10k_pci])
[17554.921773] [<7f157b4c>] (ath10k_pci_process_rx_cb [ath10k_pci])
from [<7f15b3ac>] (ath10k_ce_per_engine_service+0x5c/0x94
[ath10k_pci])
[17554.921835] [<7f15b3ac>] (ath10k_ce_per_engine_service
[ath10k_pci]) from [<7f15b464>]
(ath10k_ce_per_engine_service_any+0x80/0x88 [ath10k_pci])
[17554.921892] [<7f15b464>] (ath10k_ce_per_engine_service_any
[ath10k_pci]) from [<7f15a6d8>] (ath10k_pci_tasklet+0x24/0x5c
[ath10k_pci])
[17554.921946] [<7f15a6d8>] (ath10k_pci_tasklet [ath10k_pci]) from
[<800304c8>] (tasklet_action+0x80/0x110)
[17554.921979] [<800304c8>] (tasklet_action) from [<800306b8>]
(__do_softirq+0x10c/0x248)
[17554.922009] [<800306b8>] (__do_softirq) from [<80030a6c>]
(irq_exit+0xac/0xf4)
[17554.922042] [<80030a6c>] (irq_exit) from [<8000e904>] (handle_IRQ+0x44/0x90)
[17554.922072] [<8000e904>] (handle_IRQ) from [<800084f8>]
(gic_handle_irq+0x2c/0x5c)
[17554.922105] [<800084f8>] (gic_handle_irq) from [<80011e00>]
(__irq_svc+0x40/0x50)
[17554.922122] Exception stack(0x80917f18 to 0x80917f60)
[17554.922141] 7f00:
80917f60 000d3334
[17554.922166] 7f20: 5221e106 00000ff7 4d693c44 00000ff7 a7705010
80924060 00000001 a7705014
[17554.922190] 7f40: 8096243d 80916000 00000017 80917f60 a6aaaaab
80492940 60000013 ffffffff
[17554.922224] [<80011e00>] (__irq_svc) from [<80492940>]
(cpuidle_enter_state+0x50/0xe0)
[17554.922252] [<80492940>] (cpuidle_enter_state) from [<80492ac8>]
(cpuidle_idle_call+0xf8/0x148)
[17554.922281] [<80492ac8>] (cpuidle_idle_call) from [<8000ec48>]
(arch_cpu_idle+0x8/0x44)
[17554.922322] [<8000ec48>] (arch_cpu_idle) from [<80066648>]
(cpu_startup_entry+0xfc/0x140)
[17554.922362] [<80066648>] (cpu_startup_entry) from [<808c5b08>]
(start_kernel+0x360/0x36c)
[17554.922379] ---[ end trace 87d4775146813aed ]---
[17555.943454] ------------[ cut here ]------------
that repeat continuously...
Forcing legacy bitrates doesn't change the situation.
I made some measurements using iperf, please find it in attachment.
Other info:
root@Yazi:~# modinfo ath10k_pci
filename:
/lib/modules/3.14.48-g408ccb9/kernel/drivers/net/wireless/ath/ath10k/ath10k_pci.ko
firmware: ath10k/QCA9377/hw1.0/board.bin
firmware: ath10k/QCA9377/hw1.0/firmware-5.bin
firmware: ath10k/QCA6174/hw3.0/board-2.bin
firmware: ath10k/QCA6174/hw3.0/board.bin
firmware: ath10k/QCA6174/hw3.0/firmware-5.bin
firmware: ath10k/QCA6174/hw3.0/firmware-4.bin
firmware: ath10k/QCA6174/hw2.1/board-2.bin
firmware: ath10k/QCA6174/hw2.1/board.bin
firmware: ath10k/QCA6174/hw2.1/firmware-5.bin
firmware: ath10k/QCA6174/hw2.1/firmware-4.bin
firmware: ath10k/QCA988X/hw2.0/board-2.bin
firmware: ath10k/QCA988X/hw2.0/board.bin
firmware: ath10k/QCA988X/hw2.0/firmware-5.bin
firmware: ath10k/QCA988X/hw2.0/firmware-4.bin
firmware: ath10k/QCA988X/hw2.0/firmware-3.bin
firmware: ath10k/QCA988X/hw2.0/firmware-2.bin
firmware: ath10k/QCA988X/hw2.0/firmware.bin
license: Dual BSD/GPL
description: Driver support for Atheros QCA988X PCIe devices
author: Qualcomm Atheros
version: backported from Linux (v4.4.2-0-g1cb8570) using
backports v4.4.2-1-0-gbec4037
srcversion: EBB3D4E36DE49B7EC8057D0
alias: pci:v0000168Cd00000042sv*sd*bc*sc*i*
alias: pci:v0000168Cd00000040sv*sd*bc*sc*i*
alias: pci:v0000168Cd0000003Esv*sd*bc*sc*i*
alias: pci:v0000168Cd00000041sv*sd*bc*sc*i*
alias: pci:v0000168Cd0000003Csv*sd*bc*sc*i*
depends: ath10k_core,compat
vermagic: 3.14.48-g408ccb9 SMP mod_unload modversions ARMv7 p2v8
parm: irq_mode:0: auto, 1: legacy, 2: msi (default: 0) (uint)
parm: reset_mode:0: auto, 1: warm only (default: 0) (uint)
I don't know if it's only a problem of iw station dump that can't show
the tx rate, but the spammed syslog honestly warn me...
How shall I check what's wrong and see the HT work?
Thanks a lot!
Matteo
[-- Attachment #2: ath10kIssue.txt --]
[-- Type: text/plain, Size: 16132 bytes --]
+++++++++++++++++++
#CONFIGUTRATION#
+++++++++++++++++++
##### HOST YAZI 192.168.149.87 with ath10k #####
root@Yazi:~# iw dev wlan1 interface add mp1 type mp
root@Yazi:~# iw dev mp1 set channel 149 HT40+
root@Yazi:~# ifconfig mp1 192.168.149.87
root@Yazi:~# iw dev mp1 mesh join m149h
root@Yazi:~# iw mp1 station dump
Station 04:f0:21:0a:61:eb (on mp1)
inactive time: 870 ms
rx bytes: 4635
rx packets: 75
tx bytes: 302
tx packets: 3
tx retries: 0
tx failed: 0
signal: -66 dBm
signal avg: -68 dBm
tx bitrate: 6.0 MBit/s
mesh llid: 33894
mesh plid: 35428
mesh plink: ESTAB
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
#### HOST GATEWORKS 192.168.149.54 with ath9k ####
root@gateworks:~# iw dev wlan0 interface add mp0 type mp
root@gateworks:~# iw dev mp0 set channel 149 HT40+
root@gateworks:~# ifconfig mp0 192.168.149.54
root@gateworks:~# iw dev mp0 mesh join m149h
root@gateworks:~# iw mp0 station dump
Station 04:f0:21:15:ac:77 (on mp0)
inactive time: 1000 ms
rx bytes: 1709
rx packets: 22
tx bytes: 260
tx packets: 3
tx retries: 23
tx failed: 3
signal: -80 dBm
signal avg: -77 dBm
tx bitrate: 19.5 MBit/s MCS 2
mesh llid: 35428
mesh plid: 33894
mesh plink: ESTAB
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
###CAPTURE BROADCAST POLL MESSAGES -> file BroadcastPoll149###
++++++++++++++++++++++++++++++++++
###IPERF WITHOUT ANY HT OPTOPNS###
++++++++++++++++++++++++++++++++++
###DELETED BOTH INTERFACES AND CREATED NEW TWO WITHOUT THE HT40+ OPTION###
Used wlan1 instead wlan0 on the host Gateworks
Iperf+Capture
.87 client
.54 server
file Iperf149_3
.54 change its bitrates from 6 to 18, .87 stuck on 6
#On .54 (server)
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.54 port 5001 connected with 192.168.149.87 port 53471
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0-10.0 sec 17.9 MBytes 14.9 Mbits/sec 0.193 ms 3/12762 (0.024%)
[ 3] 0.0-10.0 sec 4 datagrams received out-of-order
#On .87 (client)
Client connecting to 192.168.149.54, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.87 port 53471 connected with 192.168.149.54 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 17.9 MBytes 15.0 Mbits/sec
[ 3] Sent 12763 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 17.9 MBytes 14.9 Mbits/sec 0.192 ms 3/12762 (0.024%)
[ 3] 0.0-10.0 sec 4 datagrams received out-of-order
++++++++++++++++++++++++++++++++++++++++++++++++++++++
.87 Server
.54 Client
file Iperf149_4
.54 change its bitrates from 6 to 18 and then 36, .87 stuck on 6
#On .87 (Server)
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.87 port 5001 connected with 192.168.149.54 port 52418
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0-10.0 sec 16.4 MBytes 13.7 Mbits/sec 2.684 ms 6/11686 (0.051%)
[ 3] 0.0-10.0 sec 7 datagrams received out-of-order
#On .54 (Client)
------------------------------------------------------------
Client connecting to 192.168.149.87, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.54 port 52418 connected with 192.168.149.87 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 16.4 MBytes 13.7 Mbits/sec
[ 3] Sent 11687 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 16.4 MBytes 13.7 Mbits/sec 2.683 ms 6/11686 (0.051%)
[ 3] 0.0-10.0 sec 7 datagrams received out-of-order
++++++++++++++++++++++++++++++++++
###IPERF WITH HT20 OPTOPNS###
++++++++++++++++++++++++++++++++++
###DELETED AND REBUILTED TWO INTERFACES WITH HT20 OPTION###
in iw <interfacename> station dump .54 shows the bitrates with the MCS,
.87 doesn't do the same, and bitrate is always 6Mbps
Again Iperf with capture
.54 Server
.87 Client
file Iperf149_5
.54 changes its bitrates in 19.5, 13 and 65MCS7
.87 stuck on 6Mbps
#On .54 (Server)
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.54 port 5001 connected with 192.168.149.87 port 58654
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0- 9.9 sec 23.7 MBytes 20.2 Mbits/sec 0.433 ms 0/16936 (0%)
[ 3] 0.0- 9.9 sec 1 datagrams received out-of-order
#On .87 (Client)
Client connecting to 192.168.149.54, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.87 port 58654 connected with 192.168.149.54 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 23.7 MBytes 19.9 Mbits/sec
[ 3] Sent 16937 datagrams
[ 3] Server Report:
[ 3] 0.0- 9.9 sec 23.7 MBytes 20.2 Mbits/sec 0.433 ms 0/16936 (0%)
[ 3] 0.0- 9.9 sec 1 datagrams received out-of-order
++++++++++++++++++++++++++++++++++++++++++++++++++
.87 Server
.54 Client
file Iperf149_6
.54 changes bitrates 26MCS3, 65 MCS7
.87 6Mbps
#On .87 (Server)
[ 4] local 192.168.149.87 port 5001 connected with 192.168.149.54 port 37926
[ 4] 0.0-10.1 sec 14.8 MBytes 12.3 Mbits/sec 4.649 ms 723/11288 (6.4%)
[ 4] 0.0-10.1 sec 4 datagrams received out-of-order
#On .54 (Client)
Client connecting to 192.168.149.87, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.54 port 37926 connected with 192.168.149.87 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 15.8 MBytes 13.3 Mbits/sec
[ 3] Sent 11289 datagrams
[ 3] Server Report:
[ 3] 0.0-10.1 sec 14.8 MBytes 12.3 Mbits/sec 4.649 ms 723/11288 (6.4%)
[ 3] 0.0-10.1 sec 4 datagrams received out-of-order
++++++++++++++++++++
###FORCE TEST###
++++++++++++++++++++
10 secs 50M
.87 Server
.54 Client
file Iperf149_7
#On .87 (Server)
[ 3] local 192.168.149.87 port 5001 connected with 192.168.149.54 port 48708
[ 3] 0.0-10.5 sec 15.6 MBytes 12.4 Mbits/sec 32.743 ms 197/11300 (1.7%)
[ 3] 0.0-10.5 sec 6 datagrams received out-of-order
#On .54 (Client)
Client connecting to 192.168.149.87, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.54 port 48708 connected with 192.168.149.87 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.4 sec 15.8 MBytes 12.8 Mbits/sec
[ 3] Sent 11301 datagrams
[ 3] Server Report:
[ 3] 0.0-10.5 sec 15.6 MBytes 12.4 Mbits/sec 32.742 ms 197/11300 (1.7%)
[ 3] 0.0-10.5 sec 6 datagrams received out-of-order
++++++++++++++++++++++++++++++++++++++++++++
10 secs 50M
.54 Server
.87 Client
file Iperf149_8
#On .54 (Server)
[ 3] local 192.168.149.54 port 5001 connected with 192.168.149.87 port 48488
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0-10.0 sec 29.5 MBytes 24.7 Mbits/sec 1.435 ms 8/21055 (0.038%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order
#On .87 (Client)
[ 3] local 192.168.149.87 port 48488 connected with 192.168.149.54 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 29.5 MBytes 24.7 Mbits/sec
[ 3] Sent 21056 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 29.5 MBytes 24.7 Mbits/sec 1.434 ms 8/21055 (0.038%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order
++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++
10 secs 100M
.54 Server
.87 Client
file Iperf149_9
#On .54 (Server)
[ 4] local 192.168.149.54 port 5001 connected with 192.168.149.87 port 52895
[ 4] 0.0-10.0 sec 40.3 MBytes 33.8 Mbits/sec 1.108 ms 26/28784 (0.09%)
[ 4] 0.0-10.0 sec 11 datagrams received out-of-order
#On .87 (Client)
[ 3] local 192.168.149.87 port 52895 connected with 192.168.149.54 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 40.4 MBytes 33.8 Mbits/sec
[ 3] Sent 28785 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 40.3 MBytes 33.8 Mbits/sec 1.107 ms 26/28784 (0.09%)
[ 3] 0.0-10.0 sec 11 datagrams received out-of-order
+++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++
10 secs 150M
.54 Server
.87 Client
file Iperf149_10
#On .54 (Server)
[ 3] local 192.168.149.54 port 5001 connected with 192.168.149.87 port 43174
[ 3] 0.0-10.0 sec 40.6 MBytes 34.1 Mbits/sec 1.108 ms 48/29026 (0.17%)
[ 3] 0.0-10.0 sec 11 datagrams received out-of-order
#On .87 (Client)
[ 3] local 192.168.149.87 port 43174 connected with 192.168.149.54 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 40.7 MBytes 34.1 Mbits/sec
[ 3] Sent 29027 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 40.6 MBytes 34.1 Mbits/sec 1.108 ms 48/29026 (0.17%)
[ 3] 0.0-10.0 sec 11 datagrams received out-of-order
34.1Mbps seems to be the max in HT20; looking the station dump .87 shows 6Mbps, .54 26MCS3
(that's ok for HT20 without the SGI), however the max nominal throughput for HT20 nonSGI
and 1 spatial stream is 65M (using a 64QAM).
.54 seems to stuch on MCS3 (watch -n<timeinterval> iw <interfacename> station dump)
+++++++++++++++++++++++++++++++++++++++++
###IPERF WITH HT40+ OPTION###
+++++++++++++++++++++++++++++++++++++++++
###DELETED AND REBUILTED TWO INTERFACES WITH HT40+ OPTION###
.54 Server
.87 Client
file Iperf149_11
#On the .87 (Client)
root@Yazi:~# iperf -c 192.168.149.54 -u -t10 -b150M
------------------------------------------------------------
Client connecting to 192.168.149.54, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.87 port 59120 connected with 192.168.149.54 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 54.2 MBytes 45.4 Mbits/sec
[ 3] Sent 38647 datagrams
[ 3] Server Report:
[ 3] 0.0- 9.9 sec 54.1 MBytes 46.0 Mbits/sec 0.887 ms 46/38646 (0.12%)
[ 3] 0.0- 9.9 sec 29 datagrams received out-of-order
root@Yazi:~# iperf -c 192.168.149.54 -u -t10 -b250M
------------------------------------------------------------
Client connecting to 192.168.149.54, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.87 port 54305 connected with 192.168.149.54 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 56.5 MBytes 47.4 Mbits/sec
[ 3] Sent 40289 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 56.4 MBytes 47.3 Mbits/sec 0.659 ms 80/40288 (0.2%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order
root@Yazi:~# iperf -c 192.168.149.54 -u -t10 -b250M
------------------------------------------------------------
Client connecting to 192.168.149.54, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.149.87 port 42853 connected with 192.168.149.54 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 56.3 MBytes 47.2 Mbits/sec
[ 3] Sent 40154 datagrams
[ 3] Server Report:
[ 3] 0.0-10.0 sec 56.2 MBytes 47.1 Mbits/sec 0.666 ms 81/40153 (0.2%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order
#47.4 seems to be the limit, but .54 changes the bit rates, the MCS and even the GI
#.87 stuck on 6
+++++++++++++++++++++++++++++++++++++++++++
###Change roles with the same parameters###
.87 Server
.54 Client
[ 3] local 192.168.149.54 port 59978 connected with 192.168.149.87 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 15.4 MBytes 12.9 Mbits/sec
[ 3] Sent 11013 datagrams
[ 3] Server Report:
[ 3] 0.0-10.3 sec 13.3 MBytes 10.9 Mbits/sec 5.268 ms 1514/11012 (14%)
[ 3] 0.0-10.3 sec 19 datagrams received out-of-order
By setting the channel
iw dev <interfacename> set channel <channel> [HT20|HT40-|HT40+]
the syslog is spammed with the repetition of
[17554.919459] ------------[ cut here ]------------
[17554.919839] WARNING: CPU: 0 PID: 0 at /home/matteo/linux-imx6/backports4.4.2-i2CAT/net/mac80211/util.c:2621 ieee80211_calculate_rx_timestamp+0x204/0x278 [mac80211]()
[17554.919855] Modules linked in: arc4 sky2 ath10k_pci(O) ath10k_core(O) ath(O) mac80211(O) cfg80211(O) compat(O)
[17554.919926] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W O 3.14.48-g408ccb9 #4
[17554.919990] [<80015050>] (unwind_backtrace) from [<80011330>] (show_stack+0x10/0x14)
[17554.920038] [<80011330>] (show_stack) from [<806537dc>] (dump_stack+0x80/0x90)
[17554.920074] [<806537dc>] (dump_stack) from [<8002c578>] (warn_slowpath_common+0x6c/0x88)
[17554.920103] [<8002c578>] (warn_slowpath_common) from [<8002c630>] (warn_slowpath_null+0x1c/0x24)
[17554.920377] [<8002c630>] (warn_slowpath_null) from [<7f089c74>] (ieee80211_calculate_rx_timestamp+0x204/0x278 [mac80211])
[17554.920826] [<7f089c74>] (ieee80211_calculate_rx_timestamp [mac80211]) from [<7f07d724>] (ieee80211_rx_napi+0xcc/0x8d4 [mac80211])
[17554.921259] [<7f07d724>] (ieee80211_rx_napi [mac80211]) from [<7f117fd0>] (ath10k_wmi_event_mgmt_rx+0x1f4/0x35c [ath10k_core])
[17554.921540] [<7f117fd0>] (ath10k_wmi_event_mgmt_rx [ath10k_core]) from [<7f10d844>] (ath10k_htc_rx_completion_handler+0x1cc/0x464 [ath10k_core])
[17554.921706] [<7f10d844>] (ath10k_htc_rx_completion_handler [ath10k_core]) from [<7f157b4c>] (ath10k_pci_process_rx_cb+0x1ac/0x1fc [ath10k_pci])
[17554.921773] [<7f157b4c>] (ath10k_pci_process_rx_cb [ath10k_pci]) from [<7f15b3ac>] (ath10k_ce_per_engine_service+0x5c/0x94 [ath10k_pci])
[17554.921835] [<7f15b3ac>] (ath10k_ce_per_engine_service [ath10k_pci]) from [<7f15b464>] (ath10k_ce_per_engine_service_any+0x80/0x88 [ath10k_pci])
[17554.921892] [<7f15b464>] (ath10k_ce_per_engine_service_any [ath10k_pci]) from [<7f15a6d8>] (ath10k_pci_tasklet+0x24/0x5c [ath10k_pci])
[17554.921946] [<7f15a6d8>] (ath10k_pci_tasklet [ath10k_pci]) from [<800304c8>] (tasklet_action+0x80/0x110)
[17554.921979] [<800304c8>] (tasklet_action) from [<800306b8>] (__do_softirq+0x10c/0x248)
[17554.922009] [<800306b8>] (__do_softirq) from [<80030a6c>] (irq_exit+0xac/0xf4)
[17554.922042] [<80030a6c>] (irq_exit) from [<8000e904>] (handle_IRQ+0x44/0x90)
[17554.922072] [<8000e904>] (handle_IRQ) from [<800084f8>] (gic_handle_irq+0x2c/0x5c)
[17554.922105] [<800084f8>] (gic_handle_irq) from [<80011e00>] (__irq_svc+0x40/0x50)
[17554.922122] Exception stack(0x80917f18 to 0x80917f60)
[17554.922141] 7f00: 80917f60 000d3334
[17554.922166] 7f20: 5221e106 00000ff7 4d693c44 00000ff7 a7705010 80924060 00000001 a7705014
[17554.922190] 7f40: 8096243d 80916000 00000017 80917f60 a6aaaaab 80492940 60000013 ffffffff
[17554.922224] [<80011e00>] (__irq_svc) from [<80492940>] (cpuidle_enter_state+0x50/0xe0)
[17554.922252] [<80492940>] (cpuidle_enter_state) from [<80492ac8>] (cpuidle_idle_call+0xf8/0x148)
[17554.922281] [<80492ac8>] (cpuidle_idle_call) from [<8000ec48>] (arch_cpu_idle+0x8/0x44)
[17554.922322] [<8000ec48>] (arch_cpu_idle) from [<80066648>] (cpu_startup_entry+0xfc/0x140)
[17554.922362] [<80066648>] (cpu_startup_entry) from [<808c5b08>] (start_kernel+0x360/0x36c)
[17554.922379] ---[ end trace 87d4775146813aed ]---
[17555.943454] ------------[ cut here ]------------
As soon as the HT40+ interface is deleted , it stops
^ permalink raw reply
* [PATCH v2] mwifiex: parse device tree node for PCIe
From: Amitkumar Karwar @ 2016-09-29 13:38 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Xinming Hu, Amitkumar Karwar
From: Xinming Hu <huxm@marvell.com>
This patch derives device tree node from pcie bus layer framework.
Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
marvell-8xxx.txt) to accomodate PCIe changes.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
v2: Included vendor and product IDs in compatible strings for PCIe
chipsets(Rob Herring)
---
.../bindings/net/wireless/marvell-8xxx.txt | 65 ++++++++++++++++++++++
.../bindings/net/wireless/marvell-sd8xxx.txt | 63 ---------------------
drivers/net/wireless/marvell/mwifiex/pcie.c | 20 +++++++
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 +-
4 files changed, 87 insertions(+), 64 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
delete mode 100644 Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
new file mode 100644
index 0000000..dfe5f8e
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -0,0 +1,65 @@
+Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
+------
+
+This node provides properties for controlling the marvell sdio/pcie wireless device.
+The node is expected to be specified as a child node to the SDIO/PCIE controller that
+connects the device to the system.
+
+Required properties:
+
+ - compatible : should be one of the following:
+ * "marvell,sd8897"
+ * "marvell,sd8997"
+ * "pci11ab,2b42"
+ * "pci1b4b,2b42"
+
+Optional properties:
+
+ - marvell,caldata* : A series of properties with marvell,caldata prefix,
+ represent calibration data downloaded to the device during
+ initialization. This is an array of unsigned 8-bit values.
+ the properties should follow below property name and
+ corresponding array length:
+ "marvell,caldata-txpwrlimit-2g" (length = 566).
+ "marvell,caldata-txpwrlimit-5g-sub0" (length = 502).
+ "marvell,caldata-txpwrlimit-5g-sub1" (length = 688).
+ "marvell,caldata-txpwrlimit-5g-sub2" (length = 750).
+ "marvell,caldata-txpwrlimit-5g-sub3" (length = 502).
+ - marvell,wakeup-pin : a wakeup pin number of wifi chip which will be configured
+ to firmware. Firmware will wakeup the host using this pin
+ during suspend/resume.
+ - interrupt-parent: phandle of the parent interrupt controller
+ - interrupts : interrupt pin number to the cpu. driver will request an irq based on
+ this interrupt number. during system suspend, the irq will be enabled
+ so that the wifi chip can wakeup host platform under certain condition.
+ during system resume, the irq will be disabled to make sure
+ unnecessary interrupt is not received.
+
+Example:
+
+Tx power limit calibration data is configured in below example.
+The calibration data is an array of unsigned values, the length
+can vary between hw versions.
+IRQ pin 38 is used as system wakeup source interrupt. wakeup pin 3 is configured
+so that firmware can wakeup host using this device side pin.
+
+&mmc3 {
+ status = "okay";
+ vmmc-supply = <&wlan_en_reg>;
+ bus-width = <4>;
+ cap-power-off-card;
+ keep-power-in-suspend;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ mwifiex: wifi@1 {
+ compatible = "marvell,sd8897";
+ reg = <1>;
+ interrupt-parent = <&pio>;
+ interrupts = <38 IRQ_TYPE_LEVEL_LOW>;
+
+ marvell,caldata_00_txpwrlimit_2g_cfg_set = /bits/ 8 <
+ 0x01 0x00 0x06 0x00 0x08 0x02 0x89 0x01>;
+ marvell,wakeup-pin = <3>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
deleted file mode 100644
index c421aba..0000000
--- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
+++ /dev/null
@@ -1,63 +0,0 @@
-Marvell 8897/8997 (sd8897/sd8997) SDIO devices
-------
-
-This node provides properties for controlling the marvell sdio wireless device.
-The node is expected to be specified as a child node to the SDIO controller that
-connects the device to the system.
-
-Required properties:
-
- - compatible : should be one of the following:
- * "marvell,sd8897"
- * "marvell,sd8997"
-
-Optional properties:
-
- - marvell,caldata* : A series of properties with marvell,caldata prefix,
- represent calibration data downloaded to the device during
- initialization. This is an array of unsigned 8-bit values.
- the properties should follow below property name and
- corresponding array length:
- "marvell,caldata-txpwrlimit-2g" (length = 566).
- "marvell,caldata-txpwrlimit-5g-sub0" (length = 502).
- "marvell,caldata-txpwrlimit-5g-sub1" (length = 688).
- "marvell,caldata-txpwrlimit-5g-sub2" (length = 750).
- "marvell,caldata-txpwrlimit-5g-sub3" (length = 502).
- - marvell,wakeup-pin : a wakeup pin number of wifi chip which will be configured
- to firmware. Firmware will wakeup the host using this pin
- during suspend/resume.
- - interrupt-parent: phandle of the parent interrupt controller
- - interrupts : interrupt pin number to the cpu. driver will request an irq based on
- this interrupt number. during system suspend, the irq will be enabled
- so that the wifi chip can wakeup host platform under certain condition.
- during system resume, the irq will be disabled to make sure
- unnecessary interrupt is not received.
-
-Example:
-
-Tx power limit calibration data is configured in below example.
-The calibration data is an array of unsigned values, the length
-can vary between hw versions.
-IRQ pin 38 is used as system wakeup source interrupt. wakeup pin 3 is configured
-so that firmware can wakeup host using this device side pin.
-
-&mmc3 {
- status = "okay";
- vmmc-supply = <&wlan_en_reg>;
- bus-width = <4>;
- cap-power-off-card;
- keep-power-in-suspend;
-
- #address-cells = <1>;
- #size-cells = <0>;
- mwifiex: wifi@1 {
- compatible = "marvell,sd8897";
- reg = <1>;
- interrupt-parent = <&pio>;
- interrupts = <38 IRQ_TYPE_LEVEL_LOW>;
-
- marvell,caldata_00_txpwrlimit_2g_cfg_set = /bits/ 8 <
- 0x01 0x00 0x06 0x00 0x08 0x02 0x89 0x01>;
- marvell,wakeup-pin = <3>;
- };
-};
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 063c707..f1eeb73 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -37,6 +37,23 @@ static struct mwifiex_if_ops pcie_ops;
static struct semaphore add_remove_card_sem;
+static const struct of_device_id mwifiex_pcie_of_match_table[] = {
+ { .compatible = "pci11ab,2b42" },
+ { .compatible = "pci1b4b,2b42" },
+ { }
+};
+
+static int mwifiex_pcie_probe_of(struct device *dev)
+{
+ if (!dev->of_node ||
+ !of_match_node(mwifiex_pcie_of_match_table, dev->of_node)) {
+ pr_err("pcie device node not available");
+ return -1;
+ }
+
+ return 0;
+}
+
static int
mwifiex_map_pci_memory(struct mwifiex_adapter *adapter, struct sk_buff *skb,
size_t size, int flags)
@@ -206,6 +223,9 @@ static int mwifiex_pcie_probe(struct pci_dev *pdev,
card->pcie.can_ext_scan = data->can_ext_scan;
}
+ /* device tree node parsing and platform specific configuration*/
+ mwifiex_pcie_probe_of(&pdev->dev);
+
if (mwifiex_add_card(card, &add_remove_card_sem, &pcie_ops,
MWIFIEX_PCIE)) {
pr_err("%s failed\n", __func__);
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index 638d30a..f2a7a13 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -2218,7 +2218,8 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, u8 first_sta, bool init)
* The cal-data can be read from device tree and/or
* a configuration file and downloaded to firmware.
*/
- if (priv->adapter->iface_type == MWIFIEX_SDIO &&
+ if ((priv->adapter->iface_type == MWIFIEX_SDIO ||
+ priv->adapter->iface_type == MWIFIEX_PCIE) &&
adapter->dev->of_node) {
adapter->dt_node = adapter->dev->of_node;
if (of_property_read_u32(adapter->dt_node,
--
1.9.1
^ permalink raw reply related
* [NetDev] [ANNOUNCE] Netdev 1.2 program announced
From: Hajime Tazaki @ 2016-09-29 13:35 UTC (permalink / raw)
To: netdev, netfilter-devel, linux-wireless, people, lwn
Hello,
The program of Linux netdev 1.2 is now online !
http://netdevconf.org/1.2/schedule.html
As we stated, all of registered people is now in the mailing
list, people at netdevconf.org. If you wish to communicate
with the attendees of netdev 1.2, feel free to exchange
messages.
-- Hajime
^ permalink raw reply
* Re: bcmdhd: Strange Power Save messages
From: Gucea Doru @ 2016-09-29 11:32 UTC (permalink / raw)
To: Arend van Spriel; +Cc: Andra Paraschiv, linux-wireless
In-Reply-To: <CANfLQrY6AVJoh8PW+5Ev0seKqnNRxRhK-N735q6Aa4KvdUVEcg@mail.gmail.com>
On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
> What is the decision triggering the exit from the PS mode immediately
> after the ping request? I am asking this because 802.11 PS legacy
> specifies that the client should wait for a beacon with TIM set in
> order to wake up: in my case, there is no beacon between the ping
> request message and the Null frame that announces the exit from the PS
> mode.
Any help would be highly appreciated :)
IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
detects that the bit corresponding to its AID is 1 i the TIM, the STA
shall issue a PS Poll". In my capture there are cases when the STA
exits the PS mode without waiting for a beacon.
Thanks!
^ permalink raw reply
* Re: rfkill guidance
From: Johannes Berg @ 2016-09-29 11:22 UTC (permalink / raw)
To: Jonathan Richardson
Cc: linux-wireless, devicetree, Marek Belisko, Mark Rutland
In-Reply-To: <fc993a0d-25cc-fb1c-3d96-86b12d1140d2@broadcom.com>
> This clarifies the issue, thanks. Basically the reason is history -
> this user space code has been around for a while. It turns out the
> HCI BT driver doesn't exist as it should. If it did, then the
> regulator could be tied to the driver. Now I see what's missing.
So like what Marcel wrote over in his email, but with regulator vs.
GPIO. Seems completely reasonable for the BT HCI driver to support
that, if you ask me.
> We will push on the team responsible for the BT drivers but all I
> need to know right now is that an rfkill driver isn't necessary.
And indeed, that would get rid of the need for anything rfkill.
> There might be some need for this but for our purpose I think the
> right path is to have a BT driver doing what this user space app is
> doing and then integrate whatever is missing with this HCI User
> Channel.
>
Sounds good to me, even if I have no idea (and don't really need to
know) what all that is :)
I'll look at killing the rfkill-regulator driver entirely though,
since, afaict, nothing uses it.
johannes
^ permalink raw reply
* [PATCH 0/4] ath10k: fix mesh sync operation
From: Thomas Pedersen @ 2016-09-28 23:56 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Thomas Pedersen
This patchset introduces a new ieee80211_op offset_tsf(), which gives
the driver a s64 TSF offset for TSF adjustment. This is more accurate
than programming absolute TSF since programming delay is avoided.
ath10k can't get the current TSF or program an absolute TSF, so we
remove those ops to not mislead the stack and hopefully avoid future
bugs.
Tested on QCA4019 with firmware 10.4-3.2.1-0033. After this change
Toffset remains stable to within 5us.
Thomas Pedersen (4):
mac80211: add offset_tsf driver op
ath10k: implement offset_tsf ieee80211_op
ath10k: remove set/get_tsf ieee80211_ops
mac80211: mesh: decrease max drift
drivers/net/wireless/ath/ath10k/mac.c | 45 +++++++++++--------------------
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 1 -
drivers/net/wireless/ath/ath10k/wmi.c | 6 ++---
drivers/net/wireless/ath/ath10k/wmi.h | 8 +++++-
include/net/mac80211.h | 8 ++++++
net/mac80211/debugfs_netdev.c | 12 ++++++---
net/mac80211/driver-ops.c | 15 +++++++++++
net/mac80211/driver-ops.h | 3 +++
net/mac80211/mesh_sync.c | 12 ++++++---
net/mac80211/trace.h | 26 ++++++++++++++++++
10 files changed, 94 insertions(+), 42 deletions(-)
--
2.10.0.297.gf6727b0
^ permalink raw reply
* [PATCH 4/4] mac80211: mesh: decrease max drift
From: Thomas Pedersen @ 2016-09-28 23:56 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Thomas Pedersen
In-Reply-To: <20160928235631.9197-1-twp@qca.qualcomm.com>
The old value was 30ms, which means mesh sync will treat
any value below as merely TSF drift. This isn't really
reasonable (typical drift is < 10us/s) since people
probably want to adjust TSF in smaller increments (for ie.
beacon collision avoidance) without mesh sync fighting
back.
Change max drift adjustment to 0.8ms, so manual TSF
adjustments can be made in 1ms increments, with some
margin.
Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com>
---
net/mac80211/mesh_sync.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/mesh_sync.c b/net/mac80211/mesh_sync.c
index 22ca43c..faca22c 100644
--- a/net/mac80211/mesh_sync.c
+++ b/net/mac80211/mesh_sync.c
@@ -28,7 +28,7 @@
* could be, for instance, in case a neighbor is restarted and its TSF counter
* reset.
*/
-#define TOFFSET_MAXIMUM_ADJUSTMENT 30000 /* 30 ms */
+#define TOFFSET_MAXIMUM_ADJUSTMENT 800 /* 0.8 ms */
struct sync_method {
u8 method;
--
2.10.0.297.gf6727b0
^ permalink raw reply related
* [PATCH 2/4] ath10k: implement offset_tsf ieee80211_op
From: Thomas Pedersen @ 2016-09-28 23:56 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Thomas Pedersen
In-Reply-To: <20160928235631.9197-1-twp@qca.qualcomm.com>
Current set_tsf is implemented in terms of TSF_INCREMENT
only. Instead support new WMI command TSF_DECREMENT and
export these through offset_tsf. Advantage is we get
more accurate TSF adjustments, and don't calculate wrong
offset in case absolute TSF was calculated from rx_mactime
(actual TSF).
The new WMI command is available in firmware
10.4-3.2.1-00033 for QCA4019 chips. Old drivers on new
firmware or vice versa shouldn't be a problem since
get/set tsf logic was already broken.
Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 25 +++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.c | 2 ++
drivers/net/wireless/ath/ath10k/wmi.h | 7 +++++++
3 files changed, 34 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 76297d6..06bd027 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6992,6 +6992,30 @@ static void ath10k_set_tsf(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
ath10k_warn(ar, "failed to set tsf offset: %d\n", ret);
}
+static void ath10k_offset_tsf(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif, s64 tsf_offset)
+{
+ struct ath10k *ar = hw->priv;
+ struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
+ u32 offset, vdev_param;
+ int ret;
+
+ if (tsf_offset < 0) {
+ vdev_param = ar->wmi.vdev_param->dec_tsf;
+ offset = -tsf_offset;
+ } else {
+ vdev_param = ar->wmi.vdev_param->inc_tsf;
+ offset = tsf_offset;
+ }
+
+ ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id,
+ vdev_param, offset);
+
+ if (ret && ret != -EOPNOTSUPP)
+ ath10k_warn(ar, "failed to set tsf offset %d cmd %d: %d\n",
+ offset, vdev_param, ret);
+}
+
static int ath10k_ampdu_action(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ieee80211_ampdu_params *params)
@@ -7455,6 +7479,7 @@ static const struct ieee80211_ops ath10k_ops = {
.sta_rc_update = ath10k_sta_rc_update,
.get_tsf = ath10k_get_tsf,
.set_tsf = ath10k_set_tsf,
+ .offset_tsf = ath10k_offset_tsf,
.ampdu_action = ath10k_ampdu_action,
.get_et_sset_count = ath10k_debug_get_et_sset_count,
.get_et_stats = ath10k_debug_get_et_stats,
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 38993d7..430074b 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1013,6 +1013,8 @@ static struct wmi_vdev_param_map wmi_10_4_vdev_param_map = {
.rx_decap_type = WMI_10_4_VDEV_PARAM_RX_DECAP_TYPE,
.bw_nss_ratemask = WMI_10_4_VDEV_PARAM_BW_NSS_RATEMASK,
.set_tsf = WMI_10_4_VDEV_PARAM_TSF_INCREMENT,
+ .inc_tsf = WMI_10_4_VDEV_PARAM_TSF_INCREMENT,
+ .dec_tsf = WMI_10_4_VDEV_PARAM_TSF_DECREMENT,
};
static struct wmi_pdev_param_map wmi_pdev_param_map = {
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 1b243c8..9d13c6f 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4677,6 +4677,8 @@ struct wmi_vdev_param_map {
u32 rx_decap_type;
u32 bw_nss_ratemask;
u32 set_tsf;
+ u32 inc_tsf;
+ u32 dec_tsf;
};
#define WMI_VDEV_PARAM_UNSUPPORTED 0
@@ -5009,6 +5011,11 @@ enum wmi_10_4_vdev_param {
WMI_10_4_VDEV_PARAM_STA_KICKOUT,
WMI_10_4_VDEV_PARAM_CAPABILITIES,
WMI_10_4_VDEV_PARAM_TSF_INCREMENT,
+ WMI_10_4_VDEV_PARAM_RX_FILTER,
+ WMI_10_4_VDEV_PARAM_MGMT_TX_POWER,
+ WMI_10_4_VDEV_PARAM_ATF_SSID_SCHED_POLICY,
+ WMI_10_4_VDEV_PARAM_DISABLE_DYN_BW_RTS,
+ WMI_10_4_VDEV_PARAM_TSF_DECREMENT,
};
#define WMI_VDEV_PARAM_TXBF_SU_TX_BFEE BIT(0)
--
2.10.0.297.gf6727b0
^ permalink raw reply related
* [PATCH 1/4] mac80211: add offset_tsf driver op
From: Thomas Pedersen @ 2016-09-28 23:56 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Thomas Pedersen
In-Reply-To: <20160928235631.9197-1-twp@qca.qualcomm.com>
Allows ie. mesh sync code to make incremental TSF
adjustments, avoiding any uncertainty introduced by delay
in programming absolute TSF.
Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com>
---
include/net/mac80211.h | 8 ++++++++
net/mac80211/debugfs_netdev.c | 12 +++++++++---
net/mac80211/driver-ops.c | 15 +++++++++++++++
net/mac80211/driver-ops.h | 3 +++
net/mac80211/mesh_sync.c | 10 +++++++---
net/mac80211/trace.h | 26 ++++++++++++++++++++++++++
6 files changed, 68 insertions(+), 6 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 5296100..6312cbda9f 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -3166,6 +3166,12 @@ enum ieee80211_reconfig_type {
* required function.
* The callback can sleep.
*
+ * @offset_tsf: Offset the TSF timer by the specified value in the
+ * firmware/hardware. Preferred to set_tsf as it avoids delay between
+ * calling set_tsf() and hardware getting programmed, which will show up
+ * as TSF delay. Is not a required function.
+ * The callback can sleep.
+ *
* @reset_tsf: Reset the TSF timer and allow firmware/hardware to synchronize
* with other STAs in the IBSS. This is only used in IBSS mode. This
* function is optional if the firmware/hardware takes full care of
@@ -3531,6 +3537,8 @@ struct ieee80211_ops {
u64 (*get_tsf)(struct ieee80211_hw *hw, struct ieee80211_vif *vif);
void (*set_tsf)(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
u64 tsf);
+ void (*offset_tsf)(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
+ s64 offset);
void (*reset_tsf)(struct ieee80211_hw *hw, struct ieee80211_vif *vif);
int (*tx_last_beacon)(struct ieee80211_hw *hw);
int (*ampdu_action)(struct ieee80211_hw *hw,
diff --git a/net/mac80211/debugfs_netdev.c b/net/mac80211/debugfs_netdev.c
index 5d35c0f..bcec124 100644
--- a/net/mac80211/debugfs_netdev.c
+++ b/net/mac80211/debugfs_netdev.c
@@ -556,9 +556,15 @@ static ssize_t ieee80211_if_parse_tsf(
ret = kstrtoull(buf, 10, &tsf);
if (ret < 0)
return ret;
- if (tsf_is_delta)
- tsf = drv_get_tsf(local, sdata) + tsf_is_delta * tsf;
- if (local->ops->set_tsf) {
+ if (tsf_is_delta && local->ops->offset_tsf) {
+ drv_offset_tsf(local, sdata, tsf_is_delta * tsf);
+ wiphy_info(local->hw.wiphy,
+ "debugfs offset TSF by %018lld\n",
+ tsf_is_delta * tsf);
+ } else if (local->ops->set_tsf) {
+ if (tsf_is_delta)
+ tsf = drv_get_tsf(local, sdata) +
+ tsf_is_delta * tsf;
drv_set_tsf(local, sdata, tsf);
wiphy_info(local->hw.wiphy,
"debugfs set TSF to %#018llx\n", tsf);
diff --git a/net/mac80211/driver-ops.c b/net/mac80211/driver-ops.c
index c701b64..bb886e7 100644
--- a/net/mac80211/driver-ops.c
+++ b/net/mac80211/driver-ops.c
@@ -215,6 +215,21 @@ void drv_set_tsf(struct ieee80211_local *local,
trace_drv_return_void(local);
}
+void drv_offset_tsf(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ s64 offset)
+{
+ might_sleep();
+
+ if (!check_sdata_in_driver(sdata))
+ return;
+
+ trace_drv_offset_tsf(local, sdata, offset);
+ if (local->ops->offset_tsf)
+ local->ops->offset_tsf(&local->hw, &sdata->vif, offset);
+ trace_drv_return_void(local);
+}
+
void drv_reset_tsf(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata)
{
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index fe35a1c..f47781ab1 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -568,6 +568,9 @@ u64 drv_get_tsf(struct ieee80211_local *local,
void drv_set_tsf(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata,
u64 tsf);
+void drv_offset_tsf(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ s64 offset);
void drv_reset_tsf(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata);
diff --git a/net/mac80211/mesh_sync.c b/net/mac80211/mesh_sync.c
index 64bc22a..22ca43c 100644
--- a/net/mac80211/mesh_sync.c
+++ b/net/mac80211/mesh_sync.c
@@ -70,9 +70,13 @@ void mesh_sync_adjust_tbtt(struct ieee80211_sub_if_data *sdata)
}
spin_unlock_bh(&ifmsh->sync_offset_lock);
- tsf = drv_get_tsf(local, sdata);
- if (tsf != -1ULL)
- drv_set_tsf(local, sdata, tsf + tsfdelta);
+ if (local->ops->offset_tsf) {
+ drv_offset_tsf(local, sdata, tsfdelta);
+ } else {
+ tsf = drv_get_tsf(local, sdata);
+ if (tsf != -1ULL)
+ drv_set_tsf(local, sdata, tsf + tsfdelta);
+ }
}
static void mesh_sync_offset_rx_bcn_presp(struct ieee80211_sub_if_data *sdata,
diff --git a/net/mac80211/trace.h b/net/mac80211/trace.h
index 77e4c53..10e9d4b 100644
--- a/net/mac80211/trace.h
+++ b/net/mac80211/trace.h
@@ -984,6 +984,32 @@ TRACE_EVENT(drv_set_tsf,
)
);
+TRACE_EVENT(drv_offset_tsf,
+ TP_PROTO(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ s64 offset),
+
+ TP_ARGS(local, sdata, offset),
+
+ TP_STRUCT__entry(
+ LOCAL_ENTRY
+ VIF_ENTRY
+ __field(s64, tsf_offset)
+ ),
+
+ TP_fast_assign(
+ LOCAL_ASSIGN;
+ VIF_ASSIGN;
+ __entry->tsf_offset = offset;
+ ),
+
+ TP_printk(
+ LOCAL_PR_FMT VIF_PR_FMT " tsf offset:%lld",
+ LOCAL_PR_ARG, VIF_PR_ARG,
+ (unsigned long long)__entry->tsf_offset
+ )
+);
+
DEFINE_EVENT(local_sdata_evt, drv_reset_tsf,
TP_PROTO(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata),
--
2.10.0.297.gf6727b0
^ permalink raw reply related
* [PATCH 3/4] ath10k: remove set/get_tsf ieee80211_ops
From: Thomas Pedersen @ 2016-09-28 23:56 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Thomas Pedersen
In-Reply-To: <20160928235631.9197-1-twp@qca.qualcomm.com>
Neither of these did the right thing:
- get_tsf just returned 0
- set_tsf assumed a simple offset was applied against
get_tsf(), which works, except in the case of
calculating TSF from rx_mactime (actual TSF).
Just remove them for now. We can reimplement set_tsf in
terms of TSF increment/decrement in the future if get_tsf
is ever supported by FW.
Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 38 -------------------------------
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 1 -
drivers/net/wireless/ath/ath10k/wmi.c | 4 ----
drivers/net/wireless/ath/ath10k/wmi.h | 1 -
4 files changed, 44 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 06bd027..9806546 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6956,42 +6956,6 @@ static void ath10k_sta_rc_update(struct ieee80211_hw *hw,
ieee80211_queue_work(hw, &arsta->update_wk);
}
-static u64 ath10k_get_tsf(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
-{
- /*
- * FIXME: Return 0 for time being. Need to figure out whether FW
- * has the API to fetch 64-bit local TSF
- */
-
- return 0;
-}
-
-static void ath10k_set_tsf(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
- u64 tsf)
-{
- struct ath10k *ar = hw->priv;
- struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
- u32 tsf_offset, vdev_param = ar->wmi.vdev_param->set_tsf;
- int ret;
-
- /* Workaround:
- *
- * Given tsf argument is entire TSF value, but firmware accepts
- * only TSF offset to current TSF.
- *
- * get_tsf function is used to get offset value, however since
- * ath10k_get_tsf is not implemented properly, it will return 0 always.
- * Luckily all the caller functions to set_tsf, as of now, also rely on
- * get_tsf function to get entire tsf value such get_tsf() + tsf_delta,
- * final tsf offset value to firmware will be arithmetically correct.
- */
- tsf_offset = tsf - ath10k_get_tsf(hw, vif);
- ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id,
- vdev_param, tsf_offset);
- if (ret && ret != -EOPNOTSUPP)
- ath10k_warn(ar, "failed to set tsf offset: %d\n", ret);
-}
-
static void ath10k_offset_tsf(struct ieee80211_hw *hw,
struct ieee80211_vif *vif, s64 tsf_offset)
{
@@ -7477,8 +7441,6 @@ static const struct ieee80211_ops ath10k_ops = {
.get_survey = ath10k_get_survey,
.set_bitrate_mask = ath10k_mac_op_set_bitrate_mask,
.sta_rc_update = ath10k_sta_rc_update,
- .get_tsf = ath10k_get_tsf,
- .set_tsf = ath10k_set_tsf,
.offset_tsf = ath10k_offset_tsf,
.ampdu_action = ath10k_ampdu_action,
.get_et_sset_count = ath10k_debug_get_et_sset_count,
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index e64f593..5e399c6 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -3464,7 +3464,6 @@ static struct wmi_vdev_param_map wmi_tlv_vdev_param_map = {
.meru_vc = WMI_VDEV_PARAM_UNSUPPORTED,
.rx_decap_type = WMI_VDEV_PARAM_UNSUPPORTED,
.bw_nss_ratemask = WMI_VDEV_PARAM_UNSUPPORTED,
- .set_tsf = WMI_VDEV_PARAM_UNSUPPORTED,
};
static const struct wmi_ops wmi_tlv_ops = {
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 430074b..8661400 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -785,7 +785,6 @@ static struct wmi_vdev_param_map wmi_vdev_param_map = {
.meru_vc = WMI_VDEV_PARAM_UNSUPPORTED,
.rx_decap_type = WMI_VDEV_PARAM_UNSUPPORTED,
.bw_nss_ratemask = WMI_VDEV_PARAM_UNSUPPORTED,
- .set_tsf = WMI_VDEV_PARAM_UNSUPPORTED,
};
/* 10.X WMI VDEV param map */
@@ -861,7 +860,6 @@ static struct wmi_vdev_param_map wmi_10x_vdev_param_map = {
.meru_vc = WMI_VDEV_PARAM_UNSUPPORTED,
.rx_decap_type = WMI_VDEV_PARAM_UNSUPPORTED,
.bw_nss_ratemask = WMI_VDEV_PARAM_UNSUPPORTED,
- .set_tsf = WMI_VDEV_PARAM_UNSUPPORTED,
};
static struct wmi_vdev_param_map wmi_10_2_4_vdev_param_map = {
@@ -936,7 +934,6 @@ static struct wmi_vdev_param_map wmi_10_2_4_vdev_param_map = {
.meru_vc = WMI_VDEV_PARAM_UNSUPPORTED,
.rx_decap_type = WMI_VDEV_PARAM_UNSUPPORTED,
.bw_nss_ratemask = WMI_VDEV_PARAM_UNSUPPORTED,
- .set_tsf = WMI_10X_VDEV_PARAM_TSF_INCREMENT,
};
static struct wmi_vdev_param_map wmi_10_4_vdev_param_map = {
@@ -1012,7 +1009,6 @@ static struct wmi_vdev_param_map wmi_10_4_vdev_param_map = {
.meru_vc = WMI_10_4_VDEV_PARAM_MERU_VC,
.rx_decap_type = WMI_10_4_VDEV_PARAM_RX_DECAP_TYPE,
.bw_nss_ratemask = WMI_10_4_VDEV_PARAM_BW_NSS_RATEMASK,
- .set_tsf = WMI_10_4_VDEV_PARAM_TSF_INCREMENT,
.inc_tsf = WMI_10_4_VDEV_PARAM_TSF_INCREMENT,
.dec_tsf = WMI_10_4_VDEV_PARAM_TSF_DECREMENT,
};
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 9d13c6f..3a73b5c 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4676,7 +4676,6 @@ struct wmi_vdev_param_map {
u32 meru_vc;
u32 rx_decap_type;
u32 bw_nss_ratemask;
- u32 set_tsf;
u32 inc_tsf;
u32 dec_tsf;
};
--
2.10.0.297.gf6727b0
^ permalink raw reply related
* Re: [PATCHv3] wireless: check A-MSDU inner frame source address on AP interfaces
From: Johannes Berg @ 2016-09-28 22:10 UTC (permalink / raw)
To: Jes Sorensen
Cc: Michael Braun, kvalo, akarwar, nishants, Larry.Finger,
linux-wireless, projekt-wlan
In-Reply-To: <wrfjoa38aqi3.fsf@redhat.com>
On Wed, 2016-09-28 at 13:22 -0400, Jes Sorensen wrote:
> I'll still argue this could be handled better through gradual
> migration rather than one large patch that touches too many places,
I'd agree if it was actually a large patch, but if at all, I have to
coordinate only with Kalle, which won't be difficult.
Comparing that to the alternative - introducing new API, changing all
the users in separate patches, and finally removing the old API - and
the nightmare of coordinating that going in through various different
trees, I'll take this any day. :)
johannes
^ permalink raw reply
* Re: [PATCH 6/6] cfg80211: reduce connect key caching struct size
From: Johannes Berg @ 2016-09-28 21:57 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless
In-Reply-To: <20160928205855.GA27770@w1.fi>
> > struct cfg80211_cached_keys {
> > - struct key_params params[6];
> > - u8 data[6][WLAN_MAX_KEY_LEN];
> > - int def, defmgmt;
> > + struct key_params params[4];
> > + u8 data[4][WLAN_KEY_LEN_WEP104];
> > + int def;
> > };
>
> As noted in our irc discussion, this is not really a good thing to
> do.
> WEXT compat code uses this structure for all ciphers, not just static
> WEP keys. BIP configuration can use key index 4-5 and the key lengths
> can go up to 32 bytes instead of WLAN_KEY_LEN_WEP104. In other words,
> this patch should be dropped or reverted since it causes kernel
> panics due to memory corruption when writing beyond this reduced size
> structure.
Yeah, this was obviously a mistake - and smatch even pointed it out to
me, but I *still* couldn't find it.
I've just sent a fix to *really* only store the WEP keys, which fixes
the issue (after I could reproduce it) for me.
johannes
^ permalink raw reply
* [PATCH] cfg80211: wext: really don't store non-WEP keys
From: Johannes Berg @ 2016-09-28 21:56 UTC (permalink / raw)
To: linux-wireless; +Cc: Jouni Malinen, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Jouni reported that during (repeated) wext_pmf test runs (from the
wpa_supplicant hwsim test suite) the kernel crashes. The reason is
that after the key is set, the wext code still unnecessarily stores
it into the key cache. Despite smatch pointing out an overflow, I
failed to identify the possibility for this in the code and missed
it during development of the earlier patch series.
In order to fix this, simply check that we never store anything but
WEP keys into the cache, adding a comment as to why that's enough.
Also, since the cache is still allocated early even if it won't be
used in many cases, add a comment explaining why - otherwise we'd
have to roll back key settings to the driver in case of allocation
failures, which is far more difficult.
Fixes: 89b706fb28e4 ("cfg80211: reduce connect key caching struct size")
Reported-by: Jouni Malinen <j@w1.fi>
Bisected-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/wext-compat.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index 7b97d43b27e1..2b096c02eb85 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -406,6 +406,10 @@ static int __cfg80211_set_encryption(struct cfg80211_registered_device *rdev,
if (pairwise && !addr)
return -EINVAL;
+ /*
+ * In many cases we won't actually need this, but it's better
+ * to do it first in case the allocation fails. Don't use wext.
+ */
if (!wdev->wext.keys) {
wdev->wext.keys = kzalloc(sizeof(*wdev->wext.keys),
GFP_KERNEL);
@@ -493,7 +497,13 @@ static int __cfg80211_set_encryption(struct cfg80211_registered_device *rdev,
if (err)
return err;
- if (!addr) {
+ /*
+ * We only need to store WEP keys, since they're the only keys that
+ * can be be set before a connection is established and persist after
+ * disconnecting.
+ */
+ if (!addr && (params->cipher == WLAN_CIPHER_SUITE_WEP40 ||
+ params->cipher == WLAN_CIPHER_SUITE_WEP104)) {
wdev->wext.keys->params[idx] = *params;
memcpy(wdev->wext.keys->data[idx],
params->key, params->key_len);
--
2.8.1
^ permalink raw reply related
* Re: [PATCH 6/6] cfg80211: reduce connect key caching struct size
From: Jouni Malinen @ 2016-09-28 20:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <1473777868-32429-6-git-send-email-johannes@sipsolutions.net>
On Tue, Sep 13, 2016 at 04:44:28PM +0200, Johannes Berg wrote:
> After the previous patches, connect keys can only (correctly)
> be used for storing static WEP keys. Therefore, remove all the
> data for dealing with key index 4/5 and reduce the size of the
> key material to the maximum for WEP keys.
> diff --git a/net/wireless/core.h b/net/wireless/core.h
> struct cfg80211_cached_keys {
> - struct key_params params[6];
> - u8 data[6][WLAN_MAX_KEY_LEN];
> - int def, defmgmt;
> + struct key_params params[4];
> + u8 data[4][WLAN_KEY_LEN_WEP104];
> + int def;
> };
As noted in our irc discussion, this is not really a good thing to do.
WEXT compat code uses this structure for all ciphers, not just static
WEP keys. BIP configuration can use key index 4-5 and the key lengths
can go up to 32 bytes instead of WLAN_KEY_LEN_WEP104. In other words,
this patch should be dropped or reverted since it causes kernel panics
due to memory corruption when writing beyond this reduced size
structure.
This was found with hwsim tests and after full day of running full test
runs, a compressed form for easy triggering of the issue was found:
hostap/tests/hwsim/vm$ ./vm-run.sh wext_pmf wext_pmf wext_pmf wext_pmf wext_pmf wext_pmf
Starting test run in a virtual machine
./run-all.sh: passing the following args to run-tests.py: wext_pmf wext_pmf wext_pmf wext_pmf wext_pmf wext_pmf
START wext_pmf 1/6
PASS wext_pmf 7.384815 2016-09-28 20:36:15.644646
START wext_pmf 2/6
qemu-system-x86_64: 9pfs:virtfs_reset: One or more uncluncked fids found during reset
qemu-system-x86_64: 9pfs:virtfs_reset: One or more uncluncked fids found during reset
KERNEL CRASHED!
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: rfkill guidance
From: Jonathan Richardson @ 2016-09-28 20:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, devicetree, Marek Belisko, Mark Rutland
In-Reply-To: <1475044682.4139.18.camel@sipsolutions.net>
Thanks for your help. Your comment below clarifies what's missing.
On 16-09-27 11:38 PM, Johannes Berg wrote:
> Hi,
>
> Mark, Marek, DT folks - the root of the discussion here is the old
> rfkill-regulator device-tree support. I'm discussing some details of
> the system here first, but below we get to the DT discussion.
>
> The old thread is here:
> http://thread.gmane.org/gmane.linux.kernel/1643236
>
>> Sure, I'll tell you what I can. A user space app handles interaction
>> between the kernel and BT radio. When the app is started, it enables
>> the regulator (via the rfkill driver and userspace sysfs interface)
>
> You should probably consider /dev/rfkill over the sysfs interface :)
>
>> to power up the BT chip. The app sends the firmware via a uart to the
>> chip. The chip loads the firmware then goes into a lower power mode.
>> When the app needs to talk to the chip it toggles a gpio (device
>> wake) before sending messages. If the kernel is in a low power mode
>> and the BT chip receives a message that requires handling by the app,
>> then a host wake gpio is driven to wake up the host (kernel).
>
> So the reason then for having it all done in userspace is that there's
> a UART to communicate with it? Or is the reason that you just don't
> want the kernel abstraction? There *are* UART BT drivers in the kernel,
> as far as I can tell, what's the difference? Or is it that there's just
> a completely different protocol, vs. the HCI protocol used normally?
>
> At this point I'm just curious though, doesn't seem all that important
> to the discussion :)
This clarifies the issue, thanks. Basically the reason is history - this
user space code has been around for a while. It turns out the HCI BT
driver doesn't exist as it should. If it did, then the regulator could
be tied to the driver. Now I see what's missing.
We will push on the team responsible for the BT drivers but all I need
to know right now is that an rfkill driver isn't necessary.
>
> Although having a DT binding for a kernel driver for the device that
> includes the regulator might change the discussion somewhat?
>
>> In addition to the regulator(s) controlled by the rfkill driver I
>> didn't mention the two gpio's previously. The existing rfkill driver
>> does nothing with them. It just exports the global gpio # to sysfs
>> which the app can read to control via the gpio sysfs interface. These
>> could be hard coded in a startup script or something, they aren't
>> that important but it does handle the conversion to the global gpio#
>> from 1 of 3 gpio controllers on a Cygnus SOC. I'm not sure how to
>> handle that, since the gpio's vary across board variants.
>
> Could also just be exposed in the DT, I guess? Userspace can read the
> DT, no? Not sure that actually gives you all the dynamic information
> though that might be needed if there's any kind of mapping going on.
I'm not sure there's any way to have the mapping done by just specifying
the gpio somewhere outside a driver. This gpio functionality I mentioned
should probably be handled by the BT HCI driver.
>
>>> Indeed, looks like Documentation/ABI/testing/sysfs-class-regulator
>>> is all read-only.
>>
>> There's a regulator driver named userspace-consumer.c that allows
>> enable/disable from userspace, but it doesn't support DT either.
>
> Adding DT support there might make some sense, perhaps? Although that's
> not really a useful DT binding at all since it won't provide any hints
> as to how you'd use that, so ... maybe not so much.
>
> As I read it, the main concern about or objection to the rfkill-
> regulator DT binding was that it's not tied to a device, when it seems
> that rfkill instances really should be living off a device that they
> control. That's true for many, but not all devices.
>
> Today we already have all the platform rfkill instances (like the
> various ACPI ones) that don't live off a device that they control, but
> instead control the platform's radio functionality. And in some cases,
> that actually has very similar behaviour to what was proposed in the
> previous patch, and what you're looking for, in that it sometimes kills
> power to BT or WiFi chips when soft-disabled (or kicks them off the bus
> in some other way). Particularly for the ones that call some random
> ACPI function to deal with things, that can happen.
>
> rfkill-regulator, with its platform driver today, more or less mirrors
> that. You could even use that with a very simple (few lines of code)
> platform module that just binds the regulators to rfkill-regulator, I
> think.
>
> Making this more flexible and configurable with DT would make sense to
> me, less for the usage of rfkill-for-a-device (which could *also* be
> done, but isn't what you need or what was discussed before), but more
> for the usage of rfkill-for-the-platform.
>
> Mark and DT folks - can you clarify your objections to the old patch?
> Am I reading things correctly, and if so, what do you think about the
> platform rfkill?
There might be some need for this but for our purpose I think the right
path is to have a BT driver doing what this user space app is doing and
then integrate whatever is missing with this HCI User Channel.
>
> johannes
>
Thanks,
Jon
^ permalink raw reply
* Re: rfkill guidance
From: Marcel Holtmann @ 2016-09-28 17:33 UTC (permalink / raw)
To: Johannes Berg
Cc: Jonathan Richardson, linux-wireless, devicetree, Marek Belisko,
Mark Rutland
In-Reply-To: <1475045391.4139.26.camel@sipsolutions.net>
Hi Johannes,
>> Today we already have all the platform rfkill instances (like the
>> various ACPI ones) that don't live off a device that they control,
>> but instead control the platform's radio functionality. And in some
>> cases, that actually has very similar behaviour to what was proposed
>> in the previous patch, and what you're looking for, in that it
>> sometimes kills power to BT or WiFi chips when soft-disabled (or
>> kicks them off the bus in some other way).
>
> Actually, let me retract that a bit. Obviously they *do* control a
> device or radio, but we don't actually know which one. And that can
> actually become a problem, since we don't even know how they work etc.
>
> So IOW, even with the ACPI stuff, there's no real "platform rfkill"
> concept - it's always killing a specific radio.
>
> There used to be some rfkill that was just reflecting the button state,
> but I think we got rid of that in favour of reflecting button state
> through hid/input, if it doesn't also control a radio.
>
> So, actually, the more I think about it the more I agree with Mark's
> objection. It doesn't really make sense to have a concept of an rfkill
> and not know what radio it controls.
>
> In your particular case, Jon, it's complicated by the fact that you
> don't want to bind a kernel driver with the rfkill, not sure where
> you'd get a device to tie the rfkill to then.
we are actually taking away the RFKILL switches that are represented by specific GPIOs. We are mapping these into the Bluetooth driver itself. This has been done for Intel and Broadcom UART based Bluetooth chips. The power control is done via the Bluetooth subsystem and that is how it should be. Enumeration of these GPIOs is done from ACPI or eventually DT (which has not made it upstream yet).
In addition, we do not want this crazy Android side of things with custom vendor specific power control via userspace or whatever crazy is done there. It can be all done through the Bluetooth subsystem and still use Android on top of it. There is a concept called HCI User Channel that allows user space application to gain exclusive access to the HCI transport. It has the advantage that the kernel does all the driver integration and handles power control.
Regards
Marcel
^ permalink raw reply
* Re: [PATCHv3] wireless: check A-MSDU inner frame source address on AP interfaces
From: Jes Sorensen @ 2016-09-28 17:22 UTC (permalink / raw)
To: Johannes Berg
Cc: Michael Braun, kvalo, akarwar, nishants, Larry.Finger,
linux-wireless, projekt-wlan
In-Reply-To: <1475077359.4139.44.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Wed, 2016-09-28 at 11:39 -0400, Jes Sorensen wrote:
>
>> > No Jes, you're wrong this time - this is changing internal API so
>> > it does have to touch all users thereof.
>>
>> Even in this case, change the individual components in individual
>> patches and post them as a set.
>
> No, still wrong - it has to be committed as a single patch so it
> doesn't break bisect.
>
>> Changes to staging needs to go in via staging, and rtl8723au is gone
>> from the staging tree.
>>
>
> I've previously taken API change patches that touch staging, if people
> feel so inclined, and I don't think Greg will mind. I'm going to keep
> doing that unless Dave tells me he won't pull from me when I do it :)
I'll still argue this could be handled better through gradual migration
rather than one large patch that touches too many places, but if you are
willing to take it, I am not going to fight you over it :)
Jes
^ permalink raw reply
* Re: [PATCHv3] wireless: check A-MSDU inner frame source address on AP interfaces
From: Johannes Berg @ 2016-09-28 15:42 UTC (permalink / raw)
To: Jes Sorensen
Cc: Michael Braun, kvalo, akarwar, nishants, Larry.Finger,
linux-wireless, projekt-wlan
In-Reply-To: <wrfj1t04c9ug.fsf@redhat.com>
On Wed, 2016-09-28 at 11:39 -0400, Jes Sorensen wrote:
> > No Jes, you're wrong this time - this is changing internal API so
> > it does have to touch all users thereof.
>
> Even in this case, change the individual components in individual
> patches and post them as a set.
No, still wrong - it has to be committed as a single patch so it
doesn't break bisect.
> Changes to staging needs to go in via staging, and rtl8723au is gone
> from the staging tree.
>
I've previously taken API change patches that touch staging, if people
feel so inclined, and I don't think Greg will mind. I'm going to keep
doing that unless Dave tells me he won't pull from me when I do it :)
johannes
^ permalink raw reply
* Re: [PATCHv3] wireless: check A-MSDU inner frame source address on AP interfaces
From: Jes Sorensen @ 2016-09-28 15:39 UTC (permalink / raw)
To: Johannes Berg
Cc: Michael Braun, kvalo, akarwar, nishants, Larry.Finger,
linux-wireless, projekt-wlan
In-Reply-To: <1475076763.4139.42.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Wed, 2016-09-28 at 11:19 -0400, Jes Sorensen wrote:
>>
>> I understand the intentions of this patch are all good, but you need
>> to not post patches that include both staging and mainline drivers at
>> the same time. In general make it a patchset and do one patch per
>> driver.
>>
>> Ideally split up changes to generic code into their own patches too.
>
> No Jes, you're wrong this time - this is changing internal API so it
> does have to touch all users thereof.
Even in this case, change the individual components in individual
patches and post them as a set.
>> Last drivers/staging/rtl8723au is gone - so your patch is going to
>> fail to apply anyway.
>
> It's there in my tree, for now, so I guess I'll see if it's still there
> when I take this in :)
Changes to staging needs to go in via staging, and rtl8723au is gone
from the staging tree.
Cheers,
Jes
^ permalink raw reply
* Re: [PATCHv3] wireless: check A-MSDU inner frame source address on AP interfaces
From: Johannes Berg @ 2016-09-28 15:32 UTC (permalink / raw)
To: Jes Sorensen, Michael Braun
Cc: kvalo, akarwar, nishants, Larry.Finger, linux-wireless,
projekt-wlan
In-Reply-To: <wrfja8esdpcb.fsf@redhat.com>
On Wed, 2016-09-28 at 11:19 -0400, Jes Sorensen wrote:
>
> I understand the intentions of this patch are all good, but you need
> to not post patches that include both staging and mainline drivers at
> the same time. In general make it a patchset and do one patch per
> driver.
>
> Ideally split up changes to generic code into their own patches too.
No Jes, you're wrong this time - this is changing internal API so it
does have to touch all users thereof.
> Last drivers/staging/rtl8723au is gone - so your patch is going to
> fail to apply anyway.
It's there in my tree, for now, so I guess I'll see if it's still there
when I take this in :)
johannes
^ permalink raw reply
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