* Re: [v7,2/5] ath10k: Enable TDLS peer buffer STA feature
From: Kalle Valo @ 2017-10-27 9:25 UTC (permalink / raw)
To: yintang; +Cc: ath10k, linux-wireless
In-Reply-To: <1508835074-3384-3-git-send-email-yintang@qti.qualcomm.com>
yintang@qti.qualcomm.com wrote:
> From: Yingying Tang <yintang@qti.qualcomm.com>
>
> Enable TDLS peer buffer STA feature.
> QCA6174 firmware(version: WLAN.RM.4.4) support TDLS peer buffer STA,
> it reports this capability through wmi service map in wmi service ready
> event. Set related parameter in TDLS WMI command to enable this feature.
>
> Signed-off-by: Yingying Tang <yintang@qti.qualcomm.com>
Depends on:
a9cd27b34d66 mac80211: enable TDLS peer buffer STA feature
Currently in mac80211-next.
4 patches set to Awaiting Upstream.
10023753 [v7,2/5] ath10k: Enable TDLS peer buffer STA feature
10023743 [v7,3/5] ath10k: Enable TDLS peer inactivity detection
10023725 [v7,4/5] ath10k: Avoid to set WEP key for TDLS peer
10023737 [v7,5/5] ath10k: Fix TDLS peer TX data failure issue on encryped AP
--
https://patchwork.kernel.org/patch/10023753/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: drivers/wireless: ath: Convert timers to use timer_setup()
From: Kalle Valo @ 2017-10-27 9:18 UTC (permalink / raw)
To: Kees Cook; +Cc: Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <20171024092954.GA47365@beast>
Kees Cook <keescook@chromium.org> wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
>
> Cc: Kalle Valo <kvalo@qca.qualcomm.com>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
There were some conflicts but luckily 3-way merge was able to automatically
solve them. But please do check the patch from my pending branch:
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=master-pending&id=dd08329d31a4c150f8aab8274033901baaf3e923
--
https://patchwork.kernel.org/patch/10023835/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/5] qtnfmac: modify full Tx queue error reporting
From: Kalle Valo @ 2017-10-27 8:48 UTC (permalink / raw)
To: Sergey Matyukevich
Cc: linux-wireless, Igor Mitsyanko, Avinash Patil, Vasily Ulyanov,
Sergey Matyukevich
In-Reply-To: <20171015205327.9966-2-sergey.matyukevich.os@quantenna.com>
Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> wrote:
> Under heavy load it is normal that h/w Tx queue is almost full all the time
> and reclaim should be done before transmitting next packet. Warning still
> should be reported as well as s/w Tx queues should be stopped in the
> case when reclaim failed.
>
> Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Failed to apply:
fatal: sha1 information is lacking or useless (drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c).
error: could not build fake ancestor
Applying: qtnfmac: modify full Tx queue recovery
Patch failed at 0001 qtnfmac: modify full Tx queue recovery
The copy of the patch that failed is found in: .git/rebase-apply/patch
5 patches set to Changes Requested.
10007281 [1/5] qtnfmac: modify full Tx queue error reporting
10007279 [2/5] qtnfmac: enable registration of more mgmt frames
10007283 [3/5] qtnfmac: drop nonexistent function declaration
10007285 [4/5] qtnfmac: modify full Tx queue recovery
10007287 [5/5] qtnfmac: advertise support of inactivity timeout
--
https://patchwork.kernel.org/patch/10007281/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rtlwifi: Remove seq_number from rtl_tid_data
From: Kalle Valo @ 2017-10-27 8:03 UTC (permalink / raw)
To: Ping-Ke Shih
Cc: Larry.Finger, linux-wireless, netdev, linux-kernel, yhchuang,
pkshih
In-Reply-To: <20171024020331.7353-1-pkshih@realtek.com>
Ping-Ke Shih <pkshih@realtek.com> wrote:
> From: Ping-Ke Shih <pkshih@realtek.com>
>
> Since mac80211 maintains the sequence number for each STA/TID,
> driver doesn't need to maintain a copy.
>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Patch applied to wireless-drivers-next.git, thanks.
1d1aa8f1ea24 rtlwifi: Remove seq_number from rtl_tid_data
--
https://patchwork.kernel.org/patch/10023425/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rtlwifi: rtl8821ae: Fix typo in variable name
From: Kalle Valo @ 2017-10-27 8:02 UTC (permalink / raw)
To: Nik Nyby; +Cc: Larry.Finger, linux-wireless, netdev, trivial, Nik Nyby
In-Reply-To: <20171024014909.7347-1-nikolas@gnu.org>
Nik Nyby <nikolas@gnu.org> wrote:
> In _rtl8821ae_dbi_write(), wrtie_addr should be write_addr.
>
> Signed-off-by: Nik Nyby <nikolas@gnu.org>
Patch applied to wireless-drivers-next.git, thanks.
62689167261d rtlwifi: rtl8821ae: Fix typo in variable name
--
https://patchwork.kernel.org/patch/10023407/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [V2] bcma: Use bcma_debug and not pr_cont in MIPS driver
From: Kalle Valo @ 2017-10-27 8:01 UTC (permalink / raw)
To: Joe Perches
Cc: Rafał Miłecki, Hauke Mehrtens, linux-wireless,
linux-kernel
In-Reply-To: <d0155fd60408cebf8e32c523582d71e1240e40ec.1508391860.git.joe@perches.com>
Joe Perches <joe@perches.com> wrote:
> Commit 66cc04424960 ("bcma: use bcma_debug and pr_cont in MIPS driver")
> converted a printk(KERN_DEBUG to bcma_debug.
>
> bcma_debug is guarded by a #define DEBUG via pr_debug.
>
> This means that the bcma_debug will generally not be emitted
> but any pr_cont following the bcma_debug will be emitted.
>
> Correct this by removing the uses of pr_cont by using a temporary.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Patch applied to wireless-drivers-next.git, thanks.
758f7e06063a bcma: Use bcma_debug and not pr_cont in MIPS driver
--
https://patchwork.kernel.org/patch/10016013/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v4,2/9] brcmsmac: split up wlc_phy_workarounds_nphy
From: Kalle Valo @ 2017-10-27 7:51 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Arnd Bergmann, Mauro Carvalho Chehab, Jiri Pirko,
David S. Miller, Andrey Ryabinin, Alexander Potapenko,
Dmitry Vyukov, Masahiro Yamada, Michal Marek, Andrew Morton,
Kees Cook, Geert Uytterhoeven, Greg Kroah-Hartman, linux-media,
linux-kernel, netdev, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, kasan-dev, linux-kbuild, Jakub Jelinek,
Martin Liška
In-Reply-To: <20170922212930.620249-3-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> The stack consumption in this driver is still relatively high, with one
> remaining warning if the warning level is lowered to 1536 bytes:
>
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:17135:1: error: the frame size of 1880 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
>
> The affected function is actually a collection of three separate implementations,
> and each of them is fairly large by itself. Splitting them up is done easily
> and improves readability at the same time.
>
> I'm leaving the original indentation to make the review easier.
>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2 patches applied to wireless-drivers-next.git, thanks.
0425f079590c brcmsmac: split up wlc_phy_workarounds_nphy
ad1987d67392 brcmsmac: reindent split functions
--
https://patchwork.kernel.org/patch/9967141/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: libertas: Convert timers to use timer_setup()
From: Kalle Valo @ 2017-10-27 7:49 UTC (permalink / raw)
To: Kees Cook
Cc: Arvind Yadav, Ingo Molnar, Johannes Berg, David S. Miller,
Andrew Zaborowski, libertas-dev, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20171024092928.GA47234@beast>
Kees Cook <keescook@chromium.org> wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: Arvind Yadav <arvind.yadav.cs@gmail.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Johannes Berg <johannes.berg@intel.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Andrew Zaborowski <andrew.zaborowski@intel.com>
> Cc: libertas-dev@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
Patch applied to wireless-drivers-next.git, thanks.
78ce6a9083c4 libertas: Convert timers to use timer_setup()
--
https://patchwork.kernel.org/patch/10023823/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: mwifiex: Convert timers to use timer_setup()
From: Kalle Valo @ 2017-10-27 7:48 UTC (permalink / raw)
To: Kees Cook
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
Arvind Yadav, Ingo Molnar, Johannes Berg, David S. Miller,
Andrew Zaborowski, libertas-dev, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20171024092919.GA47203@beast>
Kees Cook <keescook@chromium.org> wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: Amitkumar Karwar <amitkarwar@gmail.com>
> Cc: Nishant Sarmukadam <nishants@marvell.com>
> Cc: Ganapathi Bhat <gbhat@marvell.com>
> Cc: Xinming Hu <huxm@marvell.com>
> Cc: Arvind Yadav <arvind.yadav.cs@gmail.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Johannes Berg <johannes.berg@intel.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Andrew Zaborowski <andrew.zaborowski@intel.com>
> Cc: libertas-dev@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
Patch applied to wireless-drivers-next.git, thanks.
08c2eb8ec800 mwifiex: Convert timers to use timer_setup()
--
https://patchwork.kernel.org/patch/10023837/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: drivers/wireless: rsi: Convert timers to use timer_setup()
From: Kalle Valo @ 2017-10-27 7:47 UTC (permalink / raw)
To: Kees Cook
Cc: Amitkumar Karwar, Prameela Rani Garnepudi, Pavani Muthyala,
Karun Eagalapati, linux-wireless, netdev, linux-kernel
In-Reply-To: <20171024092909.GA47160@beast>
Kees Cook <keescook@chromium.org> wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: Amitkumar Karwar <amit.karwar@redpinesignals.com>
> Cc: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
> Cc: Pavani Muthyala <pavani.muthyala@redpinesignals.com>
> Cc: Karun Eagalapati <karun256@gmail.com>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
Patch applied to wireless-drivers-next.git, thanks.
dfefb9f8d082 drivers/wireless: rsi: Convert timers to use timer_setup()
--
https://patchwork.kernel.org/patch/10023815/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: cw1200: Convert timers to use timer_setup()
From: Kalle Valo @ 2017-10-27 7:46 UTC (permalink / raw)
To: Kees Cook; +Cc: Solomon Peachy, linux-wireless, netdev, linux-kernel
In-Reply-To: <20171024092900.GA47129@beast>
Kees Cook <keescook@chromium.org> wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
>
> Cc: Solomon Peachy <pizza@shaftnet.org>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
Patch applied to wireless-drivers-next.git, thanks.
e3dcf8bbeb0c cw1200: Convert timers to use timer_setup()
--
https://patchwork.kernel.org/patch/10023845/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: atmel: Convert timers to use timer_setup()
From: Kalle Valo @ 2017-10-27 7:45 UTC (permalink / raw)
To: Kees Cook; +Cc: Simon Kelley, linux-wireless, netdev, linux-kernel
In-Reply-To: <20171024092852.GA47097@beast>
Kees Cook <keescook@chromium.org> wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
>
> Cc: Simon Kelley <simon@thekelleys.org.uk>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
Patch applied to wireless-drivers-next.git, thanks.
3e79202b1152 atmel: Convert timers to use timer_setup()
--
https://patchwork.kernel.org/patch/10023841/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: iwlegacy: Convert timers to use timer_setup()
From: Kalle Valo @ 2017-10-27 7:45 UTC (permalink / raw)
To: Kees Cook; +Cc: Stanislaw Gruszka, linux-wireless, netdev, linux-kernel
In-Reply-To: <20171024092845.GA47078@beast>
Kees Cook <keescook@chromium.org> wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: Stanislaw Gruszka <sgruszka@redhat.com>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
Patch applied to wireless-drivers-next.git, thanks.
2b77839b3734 iwlegacy: Convert timers to use timer_setup()
--
https://patchwork.kernel.org/patch/10023849/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: qtnfmac: Convert timers to use timer_setup()
From: Kalle Valo @ 2017-10-27 7:43 UTC (permalink / raw)
To: Kees Cook
Cc: Igor Mitsyanko, Avinash Patil, Sergey Matyukevich, Kamlesh Rath,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20171024092837.GA47040@beast>
Kees Cook <keescook@chromium.org> wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: Igor Mitsyanko <imitsyanko@quantenna.com>
> Cc: Avinash Patil <avinashp@quantenna.com>
> Cc: Sergey Matyukevich <smatyukevich@quantenna.com>
> Cc: Kamlesh Rath <krath@quantenna.com>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
Patch applied to wireless-drivers-next.git, thanks.
7e916cafb4d9 qtnfmac: Convert timers to use timer_setup()
--
https://patchwork.kernel.org/patch/10023851/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rtlwifi: Convert timers to use timer_setup()
From: Kalle Valo @ 2017-10-27 7:42 UTC (permalink / raw)
To: Kees Cook
Cc: Larry Finger, Chaoming Li, Ping-Ke Shih, Arvind Yadav,
Souptick Joarder, linux-wireless, netdev, linux-kernel
In-Reply-To: <20171024092829.GA47013@beast>
Kees Cook <keescook@chromium.org> wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Chaoming Li <chaoming_li@realsil.com.cn>
> Cc: Ping-Ke Shih <pkshih@realtek.com>
> Cc: Arvind Yadav <arvind.yadav.cs@gmail.com>
> Cc: Souptick Joarder <jrdr.linux@gmail.com>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
Patch applied to wireless-drivers-next.git, thanks.
7c51d17c027e rtlwifi: Convert timers to use timer_setup()
--
https://patchwork.kernel.org/patch/10023861/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [08/58] net/wireless/ray_cs: Convert timers to use timer_setup()
From: Kalle Valo @ 2017-10-27 7:31 UTC (permalink / raw)
To: Kees Cook
Cc: David S. Miller, Kees Cook, linux-wireless, netdev,
Thomas Gleixner, linux-kernel
In-Reply-To: <1508200182-104605-9-git-send-email-keescook@chromium.org>
Kees Cook <keescook@chromium.org> wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
I see that Dave already applied this so dropping it from my queue.
Patch set to Not Applicable.
--
https://patchwork.kernel.org/patch/10010421/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [RFC PATCH v10 3/7] mwifiex: Disable wakeup irq handling for pcie
From: Jeffy Chen @ 2017-10-27 7:26 UTC (permalink / raw)
To: linux-kernel, bhelgaas
Cc: linux-pm, tony, shawn.lin, briannorris, rjw, dianders, Jeffy Chen,
Xinming Hu, Kalle Valo, Ganapathi Bhat, Amitkumar Karwar,
linux-wireless, Nishant Sarmukadam, netdev
In-Reply-To: <20171027072612.26565-1-jeffy.chen@rock-chips.com>
We are going to handle the wakeup irq in the pci core.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
---
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v3: None
Changes in v2: None
drivers/net/wireless/marvell/mwifiex/main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index ee40b739b289..ba081c16f85c 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1568,6 +1568,10 @@ static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
goto err_exit;
adapter->dt_node = dev->of_node;
+
+ if (adapter->iface_type != MWIFIEX_PCIE)
+ goto err_exit;
+
adapter->irq_wakeup = irq_of_parse_and_map(adapter->dt_node, 0);
if (!adapter->irq_wakeup) {
dev_dbg(dev, "fail to parse irq_wakeup from device tree\n");
--
2.11.0
^ permalink raw reply related
* [RFC PATCH v10 0/7] PCI: rockchip: Move PCIe WAKE# handling into pci core
From: Jeffy Chen @ 2017-10-27 7:26 UTC (permalink / raw)
To: linux-kernel, bhelgaas
Cc: linux-pm, tony, shawn.lin, briannorris, rjw, dianders, Jeffy Chen,
Xinming Hu, linux-pci, Rob Herring, Catalin Marinas, Kalle Valo,
Heiko Stuebner, linux-acpi, linux-rockchip, Nishant Sarmukadam,
Will Deacon, Matthias Kaehlcke, devicetree, Ganapathi Bhat,
Frank Rowand, Len Brown, Amitkumar Karwar, linux-arm-kernel,
netdev, linux-wireless, Caesar Wang, Klaus Goger, Mark Rutland
Currently we are handling wake irq in mrvl wifi driver. Move it into
pci core.
Tested on my chromebook bob(with cros 4.4 kernel and mrvl wifi).
Changes in v10:
Use device_set_wakeup_capable() instead of device_set_wakeup_enable(),
since dedicated wakeirq will be lost in device_set_wakeup_enable(false).
Changes in v9:
Add section for PCI devices and rewrite the commit message.
Rewrite the commit message.
Fix check error in .cleanup().
Move dedicated wakeirq setup to setup() callback and use
device_set_wakeup_enable() to enable/disable.
Changes in v8:
Add optional "pci", and rewrite commit message.
Rewrite the commit message.
Add pci-of.c and use platform_pm_ops to handle the PCIe WAKE# signal.
Changes in v7:
Move PCIE_WAKE handling into pci core.
Changes in v6:
Fix device_init_wake error handling, and add some comments.
Changes in v5:
Move to pci.txt
Use "wakeup" instead of "wake"
Rebase.
Changes in v3:
Fix error handling.
Changes in v2:
Use dev_pm_set_dedicated_wake_irq.
Jeffy Chen (7):
dt-bindings: PCI: Add definition of PCIe WAKE# irq and PCI irq
of/irq: Adjust of_pci_irq parsing for multiple interrupts
mwifiex: Disable wakeup irq handling for pcie
arm64: dts: rockchip: Move PCIe WAKE# irq to pcie driver for Gru
PCI: Make pci_platform_pm_ops's callbacks optional
PCI / PM: Move acpi wakeup code to pci core
PCI / PM: Add support for the PCIe WAKE# signal for OF
Documentation/devicetree/bindings/pci/pci.txt | 8 ++
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 15 +--
drivers/net/wireless/marvell/mwifiex/main.c | 4 +
drivers/of/of_pci_irq.c | 13 ++-
drivers/pci/Makefile | 2 +-
drivers/pci/pci-acpi.c | 121 ++++++++++++------------
drivers/pci/pci-driver.c | 9 ++
drivers/pci/pci-of.c | 127 ++++++++++++++++++++++++++
drivers/pci/pci.c | 112 +++++++++++++++++++----
drivers/pci/pci.h | 31 +++++--
drivers/pci/probe.c | 12 ++-
drivers/pci/remove.c | 2 +
include/linux/pci.h | 2 +
13 files changed, 361 insertions(+), 97 deletions(-)
create mode 100644 drivers/pci/pci-of.c
--
2.11.0
^ permalink raw reply
* [RFC PATCH v9 3/7] mwifiex: Disable wakeup irq handling for pcie
From: Jeffy Chen @ 2017-10-27 7:17 UTC (permalink / raw)
To: linux-kernel, bhelgaas
Cc: linux-pm, tony, shawn.lin, briannorris, rjw, dianders, Jeffy Chen,
Xinming Hu, Kalle Valo, Ganapathi Bhat, Amitkumar Karwar,
linux-wireless, Nishant Sarmukadam, netdev
In-Reply-To: <20171027071739.21927-1-jeffy.chen@rock-chips.com>
We are going to handle the wakeup irq in the pci core.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
---
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v3: None
Changes in v2: None
drivers/net/wireless/marvell/mwifiex/main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index ee40b739b289..ba081c16f85c 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1568,6 +1568,10 @@ static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
goto err_exit;
adapter->dt_node = dev->of_node;
+
+ if (adapter->iface_type != MWIFIEX_PCIE)
+ goto err_exit;
+
adapter->irq_wakeup = irq_of_parse_and_map(adapter->dt_node, 0);
if (!adapter->irq_wakeup) {
dev_dbg(dev, "fail to parse irq_wakeup from device tree\n");
--
2.11.0
^ permalink raw reply related
* [RFC PATCH v9 0/7] PCI: rockchip: Move PCIe WAKE# handling into pci core
From: Jeffy Chen @ 2017-10-27 7:17 UTC (permalink / raw)
To: linux-kernel, bhelgaas
Cc: linux-pm, tony, shawn.lin, briannorris, rjw, dianders, Jeffy Chen,
Xinming Hu, linux-pci, Rob Herring, Catalin Marinas, Kalle Valo,
Heiko Stuebner, linux-acpi, linux-rockchip, Nishant Sarmukadam,
Will Deacon, Matthias Kaehlcke, devicetree, Ganapathi Bhat,
Frank Rowand, Len Brown, Amitkumar Karwar, linux-arm-kernel,
netdev, linux-wireless, Caesar Wang, Mark Rutland
Currently we are handling wake irq in mrvl wifi driver. Move it into
pci core.
Tested on my chromebook bob(with cros 4.4 kernel and mrvl wifi).
Changes in v9:
Add section for PCI devices and rewrite the commit message.
Rewrite the commit message.
Fix check error in .cleanup().
Move dedicated wakeirq setup to setup() callback and use
device_set_wakeup_enable() to enable/disable.
Changes in v8:
Add optional "pci", and rewrite commit message.
Rewrite the commit message.
Add pci-of.c and use platform_pm_ops to handle the PCIe WAKE# signal.
Changes in v7:
Move PCIE_WAKE handling into pci core.
Changes in v6:
Fix device_init_wake error handling, and add some comments.
Changes in v5:
Move to pci.txt
Use "wakeup" instead of "wake"
Rebase.
Changes in v3:
Fix error handling.
Changes in v2:
Use dev_pm_set_dedicated_wake_irq.
Jeffy Chen (7):
dt-bindings: PCI: Add definition of PCIe WAKE# irq and PCI irq
of/irq: Adjust of_pci_irq parsing for multiple interrupts
mwifiex: Disable wakeup irq handling for pcie
arm64: dts: rockchip: Move PCIe WAKE# irq to pcie driver for Gru
PCI: Make pci_platform_pm_ops's callbacks optional
PCI / PM: Move acpi wakeup code to pci core
PCI / PM: Add support for the PCIe WAKE# signal for OF
Documentation/devicetree/bindings/pci/pci.txt | 8 ++
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 15 +--
drivers/net/wireless/marvell/mwifiex/main.c | 4 +
drivers/of/of_pci_irq.c | 13 ++-
drivers/pci/Makefile | 2 +-
drivers/pci/pci-acpi.c | 121 ++++++++++++-------------
drivers/pci/pci-driver.c | 9 ++
drivers/pci/pci-of.c | 126 ++++++++++++++++++++++++++
drivers/pci/pci.c | 112 +++++++++++++++++++----
drivers/pci/pci.h | 31 +++++--
drivers/pci/probe.c | 12 ++-
drivers/pci/remove.c | 2 +
include/linux/pci.h | 2 +
13 files changed, 360 insertions(+), 97 deletions(-)
create mode 100644 drivers/pci/pci-of.c
--
2.11.0
^ permalink raw reply
* Re: rtlwifi oops
From: James Cameron @ 2017-10-27 4:57 UTC (permalink / raw)
To: nirinA raseliarison; +Cc: Larry Finger, linux-wireless
In-Reply-To: <a1ca0a52-c033-205a-8b3e-e6879016728c@gmail.com>
On Fri, Oct 27, 2017 at 04:08:48AM +0300, nirinA raseliarison wrote:
> hi all,
> i applied the patch against 4.13.8. i still got some trouble, dmesg
> is below.
As this new event does not have "disabled by hub (EMI?)", it is a
different problem to your 19th October post, so I don't think the
patch is relevant.
> after i plugged the device, it seems to be detected and all modules
> loaded, but when i tried to connect to an access point, by using
> wicd, it halted after a while. at this point, all usb ports are
> broken, there was no more log in dmesg,
If the other USB ports are not responding, then your problem is
probably wider than the wireless device, and the wireless device
is acting as the "canary in the mine"; failing first because it is
the most active.
Can you test to exclude possibility of damaged USB host controller or
hub?
> lsusb still showed the device even after being unplugged. it got
> even worse as reboot failed.
Yes, once a USB host controller is failed, organised reboot can be
difficult. lsusb not updated confirms host controller not responding.
> i cannot really trace the error as right now all thing works fine.
Your dmesg looks like you removed and reinserted the wireless device
several times. Did you do that, or did the system do it without any
physical action?
A full dmesg from boot may be interesting, at least to better
understand the USB host controller.
--
James Cameron
http://quozl.netrek.org/
^ permalink raw reply
* Re: pull-request: mac80211 2017-10-25
From: David Miller @ 2017-10-27 4:51 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20171025140343.21477-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Wed, 25 Oct 2017 16:03:42 +0200
> Here are a few more fixes for net, we started comprehensive testing
> for the security issues and found that the problem wasn't addressed
> in TKIP, so that's included, along with a handful other fixes.
>
> Please pull and let me know if there's any problem.
Pulled, thanks Johannes.
^ permalink raw reply
* Re: RTL usb adapter question
From: James Cameron @ 2017-10-27 4:41 UTC (permalink / raw)
To: David Ashley; +Cc: linux-wireless
In-Reply-To: <CABkE59BgQ-nk-yQ2XY-T2QTfshQghv3zYiyydnj7t0ek7qSCWQ@mail.gmail.com>
Interesting, thanks. It should be a QFN 46 pin chip; you may have
counted 15 instead of 14 pins on the long edge. Send me a photograph
of the inside, off-list?
There's a brief datasheet that I found, but no sign of firmware or
registers documentation, as usual;
http://www.cnping.com/wp-content/uploads/2015/09/RTL8188CUS_DataSheet_1.01.pdf
I've no direct experience with the rtl8188cus chip. I can't prove it,
but my experience with other vendors suggests a small non-volatile
storage built into the chip for device configuration and firmware.
Device configuration often includes USB vendor:product.
I've read that Edimax uses rtl8188cus in a device programmed with
vendor:product 7392:7811, and the kernel handles this in
rtl8xxxu/rtl8xxxu_core.c
rtlwifi/rtl8192cu/sw.c
rtl8188cus has several configurable pins, so device configuration or
firmware would have been programmed to match the circuit layout.
As your kernel isn't providing firmware, yet the device works to an
extent, there is probably firmware already on the device. I don't
know of a way to ask the device for a firmware version, or a firmware
dump.
You might sacrifice a sample to see if loading rtl8192cu firmware
changes behaviour at all.
You might also work with your device vendor to improve clarity. ;-)
On Thu, Oct 26, 2017 at 08:28:00PM -0500, David Ashley wrote:
> I opened up the dongle, it has these things inside (aside from 2 coils
> and various resistors and capacitors)
> 1)
> 48 pin chip (9 pins, 15 pins, 9 pins, 15 pins)
> REALTEK
> RTL8188CUS
> F6J23P2
> GF27 TAIWAN
>
> 6 pin chip (3 pins,3 pins)
> BZ5JA
>
> 40.0 mhz crystal oscillator
>
> I was thinking maybe some serial eeprom would be included, but there wasn't one.
>
> -Dave
>
>
> On 10/26/17, James Cameron <quozl@laptop.org> wrote:
> > Base on your evidence, I'd say the device is different to others and
> > has firmware included.
> >
> > On Thu, Oct 26, 2017 at 04:45:54PM -0500, David Ashley wrote:
> >> OK I'm completely baffled.
> >>
> >> I have explicitly removed all rtlwifi/ firmware files from the root
> >> filesystem and yet the usb dongle still works, even after a power
> >> cycle. How can it possibly be getting its firmware file????????
> >>
> >> Here are the relevant kernel messages. There is no file
> >> rtl8192cufw.bin anywhere for the kernel to find...
> >> root@30046:~# ls -l /lib/firmware/rtlwifi/
> >> total 0
> >>
> >> I have ensured there is no *OTHER* route to the internet such that the
> >> driver (or udev) can magically get the firmware file from the
> >> internet...
> >>
> >> Here's other info that may be useful...
> >>
> >> root@30046:~# zcat /proc/config.gz | grep FIRM
> >> CONFIG_PREVENT_FIRMWARE_BUILD=y
> >> CONFIG_FIRMWARE_IN_KERNEL=y
> >> CONFIG_EXTRA_FIRMWARE="am335x-pm-firmware.elf
> >> am335x-bone-scale-data.bin am335x-evm-scale-data.bin
> >> am43x-evm-scale-data.bin"
> >> CONFIG_EXTRA_FIRMWARE_DIR="firmware"
> >> # CONFIG_LIBERTAS_THINFIRM is not set
> >> # CONFIG_FIRMWARE_MEMMAP is not set
> >> # CONFIG_TEST_FIRMWARE is not set
> >> root@30046:~# cat /proc/version
> >> Linux version 4.1.19-bone20 (dash@DaveDesktop) (gcc version 5.4.0
> >> 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) ) #2 Tue Oct 3
> >> 17:25:35 CDT 2017
> >> root@30046:~# lsusb
> >> Bus 001 Device 002: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un
> >> 802.11n Wireless Adapter [Realtek RTL8188CUS]
> >>
> >> ... ifconfig
> >> wlan0 Link encap:Ethernet HWaddr 74:da:38:61:f1:2c
> >> inet addr:192.168.10.31 Bcast:192.168.10.255
> >> Mask:255.255.255.0
> >> inet6 addr: fe80::76da:38ff:fe61:f12c/64 Scope:Link
> >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> >> RX packets:509 errors:0 dropped:0 overruns:0 frame:0
> >> TX packets:146 errors:0 dropped:0 overruns:0 carrier:0
> >> collisions:0 txqueuelen:1000
> >> RX bytes:60812 (59.3 KiB) TX bytes:16365 (15.9 KiB)
> >>
> >>
> >>
> >>
> >> [ 9.663796] rtl8192cu: Chip version 0x10
> >> [ 9.745394] cfg80211: Calling CRDA to update world regulatory domain
> >> [ 9.844311] random: nonblocking pool is initialized
> >> [ 9.877851] rtl8192cu: MAC address: 74:da:38:61:f1:2c
> >> [ 9.877883] rtl8192cu: Board Type 0
> >> [ 9.877989] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
> >> [ 9.878098] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
> >> [ 9.878249] usb 1-1: Direct firmware load for
> >> rtlwifi/rtl8192cufw_TMSC.bin failed with error -2
> >> [ 9.889781] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
> >> [ 9.890862] usbcore: registered new interface driver rtl8192cu
> >> [ 9.897667] usb 1-1: Direct firmware load for
> >> rtlwifi/rtl8192cufw.bin failed with error -2
> >> [ 9.906030] rtlwifi: Loading alternative firmware
> >> rtlwifi/rtl8192cufw.bin
> >> [ 9.906037] rtlwifi: Firmware rtlwifi/rtl8192cufw_TMSC.bin not
> >> available
> >> [ 11.316476] rtl8192cu: MAC auto ON okay!
> >> [ 11.333847] rtl8192cu: Tx queue select: 0x05
> >> [ 12.364722] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> >> [ 12.905367] cfg80211: Calling CRDA to update world regulatory domain
> >> [ 13.413043] rtl8192cu: MAC auto ON okay!
> >> [ 13.430371] rtl8192cu: Tx queue select: 0x05
> >> [ 15.795679] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> >> [ 16.065356] cfg80211: Calling CRDA to update world regulatory domain
> >> [ 19.225333] cfg80211: Calling CRDA to update world regulatory domain
> >> [ 21.582749] wlan0: authenticate with 70:4d:7b:1d:91:40
> >> [ 21.600676] wlan0: send auth to 70:4d:7b:1d:91:40 (try 1/3)
> >> [ 21.605390] wlan0: authenticated
> >> [ 21.615431] wlan0: associate with 70:4d:7b:1d:91:40 (try 1/3)
> >> [ 21.667523] wlan0: RX AssocResp from 70:4d:7b:1d:91:40 (capab=0x411
> >> status=0 aid=5)
> >> [ 21.669000] wlan0: associated
> >> [ 21.669671] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> >> [ 22.385320] cfg80211: Calling CRDA to update world regulatory domain
> >> [ 25.545336] cfg80211: Calling CRDA to update world regulatory domain
> >> [ 28.705312] cfg80211: Calling CRDA to update world regulatory domain
> >> [ 31.865335] cfg80211: Calling CRDA to update world regulatory domain
> >> [ 35.025348] cfg80211: Exceeded CRDA call max attempts. Not calling
> >> CRDA
> >>
> >>
> >> Thanks!!!!!!
> >> -Dave
> >>
> >> On 10/25/17, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> >> > On 10/25/2017 01:43 PM, David Ashley wrote:
> >> >> I'm trying to understand how the linux kernel loads RTL8188CUS
> >> >> firmware
> >> >> rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin
> >> >> when that file isn't available anywhere in my embedded system's
> >> >> filesystem.
> >> >>
> >> >> Basically I'm trying to understand the theory. We have a product that
> >> >> is making use of the device
> >> >>
> >> >> Bus 001 Device 007: ID 7392:7811 Edimax Technology Co., Ltd
> >> >> EW-7811Un802.11n Wireless Adapter [Realtek RTL8188CUS]
> >> >>
> >> >> It has not been especially reliable. I've never provided firmware
> >> >> files for the device in the root filesystem. I've started to pay
> >> >> attention to the kernel error messages. Now the kernel drivers seem to
> >> >> be loading the rtlwifi/rtl8192cufw_TMSC.bin file and I'm trying to
> >> >> understand if this is actually working, if it makes any difference in
> >> >> reliability...
> >> >>
> >> >> It's like I can't figure out how the usb dongle even worked without
> >> >> its firmware file...
> >> >>
> >> >> My working theory is that the usb dongle comes from the factory with a
> >> >> hardcoded firmware file (rtlwifi/rtl8192cufw.bin) but it is buggy or
> >> >> inferior. And the performance and reliability can be improved if the
> >> >> driver successfully manages to load the rtl8192cufw_TMSC.bin file. I
> >> >> don't know if the firmware load persists across a power cycle (my
> >> >> assumption is it doesn't).
> >> >
> >> > There is NO firmware coded by the factory in the device. It only has
> >> > enough
> >> >
> >> > intelligence to load the real firmware. The exact file that it loads is
> >> > determined by the model. If you provide the appropriate section of the
> >> > output of
> >> > dmesg where the above firmware messages occur, and a file listing of
> >> > /lib/firmware/rtlwifi/, I can tell you what firmware is being loaded.
> >> >
> >> > No, firmware will not persist across a power failure.
> >> >
> >> > The driver has never been particularly reliable, and the USB group at
> >> > Realtek
> >> > seems not to care. You might try their other driver, but you will be on
> >> > your
> >> >
> >> > own, as I will not support that particular piece of ****.
> >> >
> >> > Please reply to all on any followups.
> >> >
> >> > Larry
> >> >
> >> >
> >
> > --
> > James Cameron
> > http://quozl.netrek.org/
> >
--
James Cameron
http://quozl.netrek.org/
^ permalink raw reply
* [PATCH] ath10k: Fix data rx for CCMP-256, GCMP and GCMP-256 in raw mode
From: Vasanthakumar Thiagarajan @ 2017-10-27 4:39 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Vasanthakumar Thiagarajan
Make sure 16-byte mic is removed from the rx data packet
tail when CCMP-256, GCMP and GCMP-256 ciphers are used
in raw decap mode. This fixed rx traffic failures in those
ciphers in raw mode. Split the helper returning crypto
tail length into two, one to get the ICV length and other
to get the mic lengh for the cipher to make it clean.
Fixes: 2ea9f12cefe4 ("ath10k: add new cipher suite support")
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
---
This patch depends on https://patchwork.kernel.org/patch/10028621/
drivers/net/wireless/ath/ath10k/htt_rx.c | 51 ++++++++++++++++++++++++--------
1 file changed, 38 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 5beb6ee0f091..656385f80929 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -566,18 +566,16 @@ static int ath10k_htt_rx_crypto_param_len(struct ath10k *ar,
#define MICHAEL_MIC_LEN 8
-static int ath10k_htt_rx_crypto_tail_len(struct ath10k *ar,
- enum htt_rx_mpdu_encrypt_type type)
+static int ath10k_htt_rx_crypto_mic_len(struct ath10k *ar,
+ enum htt_rx_mpdu_encrypt_type type)
{
switch (type) {
case HTT_RX_MPDU_ENCRYPT_NONE:
- return 0;
case HTT_RX_MPDU_ENCRYPT_WEP40:
case HTT_RX_MPDU_ENCRYPT_WEP104:
- return IEEE80211_WEP_ICV_LEN;
case HTT_RX_MPDU_ENCRYPT_TKIP_WITHOUT_MIC:
case HTT_RX_MPDU_ENCRYPT_TKIP_WPA:
- return IEEE80211_TKIP_ICV_LEN;
+ return 0;
case HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2:
return IEEE80211_CCMP_MIC_LEN;
case HTT_RX_MPDU_ENCRYPT_AES_CCM256_WPA2:
@@ -594,6 +592,31 @@ static int ath10k_htt_rx_crypto_tail_len(struct ath10k *ar,
return 0;
}
+static int ath10k_htt_rx_crypto_icv_len(struct ath10k *ar,
+ enum htt_rx_mpdu_encrypt_type type)
+{
+ switch (type) {
+ case HTT_RX_MPDU_ENCRYPT_NONE:
+ case HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2:
+ case HTT_RX_MPDU_ENCRYPT_AES_CCM256_WPA2:
+ case HTT_RX_MPDU_ENCRYPT_AES_GCMP_WPA2:
+ case HTT_RX_MPDU_ENCRYPT_AES_GCMP256_WPA2:
+ return 0;
+ case HTT_RX_MPDU_ENCRYPT_WEP40:
+ case HTT_RX_MPDU_ENCRYPT_WEP104:
+ return IEEE80211_WEP_ICV_LEN;
+ case HTT_RX_MPDU_ENCRYPT_TKIP_WITHOUT_MIC:
+ case HTT_RX_MPDU_ENCRYPT_TKIP_WPA:
+ return IEEE80211_TKIP_ICV_LEN;
+ case HTT_RX_MPDU_ENCRYPT_WEP128:
+ case HTT_RX_MPDU_ENCRYPT_WAPI:
+ break;
+ }
+
+ ath10k_warn(ar, "unsupported encryption type %d\n", type);
+ return 0;
+}
+
struct amsdu_subframe_hdr {
u8 dst[ETH_ALEN];
u8 src[ETH_ALEN];
@@ -1063,25 +1086,27 @@ static void ath10k_htt_rx_h_undecap_raw(struct ath10k *ar,
/* Tail */
if (status->flag & RX_FLAG_IV_STRIPPED) {
skb_trim(msdu, msdu->len -
- ath10k_htt_rx_crypto_tail_len(ar, enctype));
+ ath10k_htt_rx_crypto_mic_len(ar, enctype));
+
+ skb_trim(msdu, msdu->len -
+ ath10k_htt_rx_crypto_icv_len(ar, enctype));
} else {
/* MIC */
- if ((status->flag & RX_FLAG_MIC_STRIPPED) &&
- enctype == HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2)
- skb_trim(msdu, msdu->len - 8);
+ if (status->flag & RX_FLAG_MIC_STRIPPED)
+ skb_trim(msdu, msdu->len -
+ ath10k_htt_rx_crypto_mic_len(ar, enctype));
/* ICV */
- if (status->flag & RX_FLAG_ICV_STRIPPED &&
- enctype != HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2)
+ if (status->flag & RX_FLAG_ICV_STRIPPED)
skb_trim(msdu, msdu->len -
- ath10k_htt_rx_crypto_tail_len(ar, enctype));
+ ath10k_htt_rx_crypto_icv_len(ar, enctype));
}
/* MMIC */
if ((status->flag & RX_FLAG_MMIC_STRIPPED) &&
!ieee80211_has_morefrags(hdr->frame_control) &&
enctype == HTT_RX_MPDU_ENCRYPT_TKIP_WPA)
- skb_trim(msdu, msdu->len - 8);
+ skb_trim(msdu, msdu->len - MICHAEL_MIC_LEN);
/* Head */
if (status->flag & RX_FLAG_IV_STRIPPED) {
--
1.9.1
^ permalink raw reply related
* Re: RTL usb adapter question
From: David Ashley @ 2017-10-27 1:28 UTC (permalink / raw)
To: James Cameron; +Cc: linux-wireless
In-Reply-To: <20171026220013.GC9888@us.netrek.org>
I opened up the dongle, it has these things inside (aside from 2 coils
and various resistors and capacitors)
1)
48 pin chip (9 pins, 15 pins, 9 pins, 15 pins)
REALTEK
RTL8188CUS
F6J23P2
GF27 TAIWAN
6 pin chip (3 pins,3 pins)
BZ5JA
40.0 mhz crystal oscillator
I was thinking maybe some serial eeprom would be included, but there wasn't one.
-Dave
On 10/26/17, James Cameron <quozl@laptop.org> wrote:
> Base on your evidence, I'd say the device is different to others and
> has firmware included.
>
> On Thu, Oct 26, 2017 at 04:45:54PM -0500, David Ashley wrote:
>> OK I'm completely baffled.
>>
>> I have explicitly removed all rtlwifi/ firmware files from the root
>> filesystem and yet the usb dongle still works, even after a power
>> cycle. How can it possibly be getting its firmware file????????
>>
>> Here are the relevant kernel messages. There is no file
>> rtl8192cufw.bin anywhere for the kernel to find...
>> root@30046:~# ls -l /lib/firmware/rtlwifi/
>> total 0
>>
>> I have ensured there is no *OTHER* route to the internet such that the
>> driver (or udev) can magically get the firmware file from the
>> internet...
>>
>> Here's other info that may be useful...
>>
>> root@30046:~# zcat /proc/config.gz | grep FIRM
>> CONFIG_PREVENT_FIRMWARE_BUILD=y
>> CONFIG_FIRMWARE_IN_KERNEL=y
>> CONFIG_EXTRA_FIRMWARE="am335x-pm-firmware.elf
>> am335x-bone-scale-data.bin am335x-evm-scale-data.bin
>> am43x-evm-scale-data.bin"
>> CONFIG_EXTRA_FIRMWARE_DIR="firmware"
>> # CONFIG_LIBERTAS_THINFIRM is not set
>> # CONFIG_FIRMWARE_MEMMAP is not set
>> # CONFIG_TEST_FIRMWARE is not set
>> root@30046:~# cat /proc/version
>> Linux version 4.1.19-bone20 (dash@DaveDesktop) (gcc version 5.4.0
>> 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) ) #2 Tue Oct 3
>> 17:25:35 CDT 2017
>> root@30046:~# lsusb
>> Bus 001 Device 002: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un
>> 802.11n Wireless Adapter [Realtek RTL8188CUS]
>>
>> ... ifconfig
>> wlan0 Link encap:Ethernet HWaddr 74:da:38:61:f1:2c
>> inet addr:192.168.10.31 Bcast:192.168.10.255
>> Mask:255.255.255.0
>> inet6 addr: fe80::76da:38ff:fe61:f12c/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:509 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:146 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:60812 (59.3 KiB) TX bytes:16365 (15.9 KiB)
>>
>>
>>
>>
>> [ 9.663796] rtl8192cu: Chip version 0x10
>> [ 9.745394] cfg80211: Calling CRDA to update world regulatory domain
>> [ 9.844311] random: nonblocking pool is initialized
>> [ 9.877851] rtl8192cu: MAC address: 74:da:38:61:f1:2c
>> [ 9.877883] rtl8192cu: Board Type 0
>> [ 9.877989] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
>> [ 9.878098] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
>> [ 9.878249] usb 1-1: Direct firmware load for
>> rtlwifi/rtl8192cufw_TMSC.bin failed with error -2
>> [ 9.889781] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
>> [ 9.890862] usbcore: registered new interface driver rtl8192cu
>> [ 9.897667] usb 1-1: Direct firmware load for
>> rtlwifi/rtl8192cufw.bin failed with error -2
>> [ 9.906030] rtlwifi: Loading alternative firmware
>> rtlwifi/rtl8192cufw.bin
>> [ 9.906037] rtlwifi: Firmware rtlwifi/rtl8192cufw_TMSC.bin not
>> available
>> [ 11.316476] rtl8192cu: MAC auto ON okay!
>> [ 11.333847] rtl8192cu: Tx queue select: 0x05
>> [ 12.364722] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> [ 12.905367] cfg80211: Calling CRDA to update world regulatory domain
>> [ 13.413043] rtl8192cu: MAC auto ON okay!
>> [ 13.430371] rtl8192cu: Tx queue select: 0x05
>> [ 15.795679] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> [ 16.065356] cfg80211: Calling CRDA to update world regulatory domain
>> [ 19.225333] cfg80211: Calling CRDA to update world regulatory domain
>> [ 21.582749] wlan0: authenticate with 70:4d:7b:1d:91:40
>> [ 21.600676] wlan0: send auth to 70:4d:7b:1d:91:40 (try 1/3)
>> [ 21.605390] wlan0: authenticated
>> [ 21.615431] wlan0: associate with 70:4d:7b:1d:91:40 (try 1/3)
>> [ 21.667523] wlan0: RX AssocResp from 70:4d:7b:1d:91:40 (capab=0x411
>> status=0 aid=5)
>> [ 21.669000] wlan0: associated
>> [ 21.669671] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
>> [ 22.385320] cfg80211: Calling CRDA to update world regulatory domain
>> [ 25.545336] cfg80211: Calling CRDA to update world regulatory domain
>> [ 28.705312] cfg80211: Calling CRDA to update world regulatory domain
>> [ 31.865335] cfg80211: Calling CRDA to update world regulatory domain
>> [ 35.025348] cfg80211: Exceeded CRDA call max attempts. Not calling
>> CRDA
>>
>>
>> Thanks!!!!!!
>> -Dave
>>
>> On 10/25/17, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> > On 10/25/2017 01:43 PM, David Ashley wrote:
>> >> I'm trying to understand how the linux kernel loads RTL8188CUS
>> >> firmware
>> >> rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin
>> >> when that file isn't available anywhere in my embedded system's
>> >> filesystem.
>> >>
>> >> Basically I'm trying to understand the theory. We have a product that
>> >> is making use of the device
>> >>
>> >> Bus 001 Device 007: ID 7392:7811 Edimax Technology Co., Ltd
>> >> EW-7811Un802.11n Wireless Adapter [Realtek RTL8188CUS]
>> >>
>> >> It has not been especially reliable. I've never provided firmware
>> >> files for the device in the root filesystem. I've started to pay
>> >> attention to the kernel error messages. Now the kernel drivers seem to
>> >> be loading the rtlwifi/rtl8192cufw_TMSC.bin file and I'm trying to
>> >> understand if this is actually working, if it makes any difference in
>> >> reliability...
>> >>
>> >> It's like I can't figure out how the usb dongle even worked without
>> >> its firmware file...
>> >>
>> >> My working theory is that the usb dongle comes from the factory with a
>> >> hardcoded firmware file (rtlwifi/rtl8192cufw.bin) but it is buggy or
>> >> inferior. And the performance and reliability can be improved if the
>> >> driver successfully manages to load the rtl8192cufw_TMSC.bin file. I
>> >> don't know if the firmware load persists across a power cycle (my
>> >> assumption is it doesn't).
>> >
>> > There is NO firmware coded by the factory in the device. It only has
>> > enough
>> >
>> > intelligence to load the real firmware. The exact file that it loads is
>> > determined by the model. If you provide the appropriate section of the
>> > output of
>> > dmesg where the above firmware messages occur, and a file listing of
>> > /lib/firmware/rtlwifi/, I can tell you what firmware is being loaded.
>> >
>> > No, firmware will not persist across a power failure.
>> >
>> > The driver has never been particularly reliable, and the USB group at
>> > Realtek
>> > seems not to care. You might try their other driver, but you will be on
>> > your
>> >
>> > own, as I will not support that particular piece of ****.
>> >
>> > Please reply to all on any followups.
>> >
>> > Larry
>> >
>> >
>
> --
> James Cameron
> http://quozl.netrek.org/
>
^ 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