* Re: [PATCH 1/4] ath9k: dyanck: introduce ath_dynack_set_timeout routine
From: Kalle Valo @ 2019-09-04 6:20 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: lorenzo.bianconi, linux-wireless, koen.vandeputte
In-Reply-To: <4d64a2f91fcb8dbadaad8fef2e693abde47e6b5c.1566317488.git.lorenzo@kernel.org>
Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> Introduce ath_dynack_set_timeout routine to configure slottime/ack/cts
> timeouts and remove duplicated code
>
> Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
4 patches applied to ath-next branch of ath.git, thanks.
5df65dd52dd5 ath9k: dyanck: introduce ath_dynack_set_timeout routine
6999e40d5f1d ath9k: dynack: properly set last timeout timestamp in ath_dynack_reset
86e392994dee ath9k: dynack: set max timeout according to channel width
72bb1aa91ff8 ath9k: dynack: set ackto to max timeout in ath_dynack_reset
--
https://patchwork.kernel.org/patch/11104373/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH] mac80211: Store max_mtu in ieee80211_hw
From: Wen Gong @ 2019-09-04 6:15 UTC (permalink / raw)
To: ath10k, johannes; +Cc: linux-wireless
Make it possibly for drivers to adjust the default mat_mtu
by storing it in the hardware struct.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
---
include/net/mac80211.h | 3 +++
net/mac80211/iface.c | 5 ++++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index d26da01..8545b03 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2454,6 +2454,8 @@ enum ieee80211_hw_flags {
*
* @weight_multiplier: Driver specific airtime weight multiplier used while
* refilling deficit of each TXQ.
+ *
+ * @max_mtu: the max mtu could be set.
*/
struct ieee80211_hw {
struct ieee80211_conf conf;
@@ -2491,6 +2493,7 @@ struct ieee80211_hw {
u8 max_nan_de_entries;
u8 tx_sk_pacing_shift;
u8 weight_multiplier;
+ u32 max_mtu;
};
static inline bool _ieee80211_hw_check(struct ieee80211_hw *hw,
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 06aac0a..00c33e6 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1877,7 +1877,10 @@ int ieee80211_if_add(struct ieee80211_local *local, const char *name,
/* MTU range: 256 - 2304 */
ndev->min_mtu = 256;
- ndev->max_mtu = IEEE80211_MAX_DATA_LEN;
+ if (local->hw.max_mtu)
+ ndev->max_mtu = local->hw.max_mtu;
+ else
+ ndev->max_mtu = IEEE80211_MAX_DATA_LEN;
ret = register_netdevice(ndev);
if (ret) {
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] ath9k: dynack: fix possible deadlock in ath_dynack_node_{de}init
From: Kalle Valo @ 2019-09-04 6:14 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: lorenzo.bianconi, linux-wireless
In-Reply-To: <3c5c90cd62da2db9a661b3045391da537dccf90f.1566200274.git.lorenzo@kernel.org>
Lorenzo Bianconi <lorenzo@kernel.org> wrote:
> Fix following lockdep warning disabling bh in
> ath_dynack_node_init/ath_dynack_node_deinit
>
> [ 75.955878] --------------------------------
> [ 75.955880] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
> [ 75.955884] swapper/0/0 [HC0[0]:SC1[3]:HE1:SE0] takes:
> [ 75.955888] 00000000792a7ee0 (&(&da->qlock)->rlock){+.?.}, at: ath_dynack_sample_ack_ts+0x4d/0xa0 [ath9k_hw]
> [ 75.955905] {SOFTIRQ-ON-W} state was registered at:
> [ 75.955912] lock_acquire+0x9a/0x160
> [ 75.955917] _raw_spin_lock+0x2c/0x70
> [ 75.955927] ath_dynack_node_init+0x2a/0x60 [ath9k_hw]
> [ 75.955934] ath9k_sta_state+0xec/0x160 [ath9k]
> [ 75.955976] drv_sta_state+0xb2/0x740 [mac80211]
> [ 75.956008] sta_info_insert_finish+0x21a/0x420 [mac80211]
> [ 75.956039] sta_info_insert_rcu+0x12b/0x2c0 [mac80211]
> [ 75.956069] sta_info_insert+0x7/0x70 [mac80211]
> [ 75.956093] ieee80211_prep_connection+0x42e/0x730 [mac80211]
> [ 75.956120] ieee80211_mgd_auth.cold+0xb9/0x15c [mac80211]
> [ 75.956152] cfg80211_mlme_auth+0x143/0x350 [cfg80211]
> [ 75.956169] nl80211_authenticate+0x25e/0x2b0 [cfg80211]
> [ 75.956172] genl_family_rcv_msg+0x198/0x400
> [ 75.956174] genl_rcv_msg+0x42/0x90
> [ 75.956176] netlink_rcv_skb+0x35/0xf0
> [ 75.956178] genl_rcv+0x1f/0x30
> [ 75.956180] netlink_unicast+0x154/0x200
> [ 75.956182] netlink_sendmsg+0x1bf/0x3d0
> [ 75.956186] ___sys_sendmsg+0x2c2/0x2f0
> [ 75.956187] __sys_sendmsg+0x44/0x80
> [ 75.956190] do_syscall_64+0x55/0x1a0
> [ 75.956192] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 75.956194] irq event stamp: 2357092
> [ 75.956196] hardirqs last enabled at (2357092): [<ffffffff818c62de>] _raw_spin_unlock_irqrestore+0x3e/0x50
> [ 75.956199] hardirqs last disabled at (2357091): [<ffffffff818c60b1>] _raw_spin_lock_irqsave+0x11/0x80
> [ 75.956202] softirqs last enabled at (2357072): [<ffffffff8106dc09>] irq_enter+0x59/0x60
> [ 75.956204] softirqs last disabled at (2357073): [<ffffffff8106dcbe>] irq_exit+0xae/0xc0
> [ 75.956206]
> other info that might help us debug this:
> [ 75.956207] Possible unsafe locking scenario:
>
> [ 75.956208] CPU0
> [ 75.956209] ----
> [ 75.956210] lock(&(&da->qlock)->rlock);
> [ 75.956213] <Interrupt>
> [ 75.956214] lock(&(&da->qlock)->rlock);
> [ 75.956216]
> *** DEADLOCK ***
>
> [ 75.956217] 1 lock held by swapper/0/0:
> [ 75.956219] #0: 000000003bb5675c (&(&sc->sc_pcu_lock)->rlock){+.-.}, at: ath9k_tasklet+0x55/0x240 [ath9k]
> [ 75.956225]
> stack backtrace:
> [ 75.956228] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.0-rc1-wdn+ #13
> [ 75.956229] Hardware name: Dell Inc. Studio XPS 1340/0K183D, BIOS A11 09/08/2009
> [ 75.956231] Call Trace:
> [ 75.956233] <IRQ>
> [ 75.956236] dump_stack+0x67/0x90
> [ 75.956239] mark_lock+0x4c1/0x640
> [ 75.956242] ? check_usage_backwards+0x130/0x130
> [ 75.956245] ? sched_clock_local+0x12/0x80
> [ 75.956247] __lock_acquire+0x484/0x7a0
> [ 75.956250] ? __lock_acquire+0x3b9/0x7a0
> [ 75.956252] lock_acquire+0x9a/0x160
> [ 75.956259] ? ath_dynack_sample_ack_ts+0x4d/0xa0 [ath9k_hw]
> [ 75.956262] _raw_spin_lock_bh+0x34/0x80
> [ 75.956268] ? ath_dynack_sample_ack_ts+0x4d/0xa0 [ath9k_hw]
> [ 75.956275] ath_dynack_sample_ack_ts+0x4d/0xa0 [ath9k_hw]
> [ 75.956280] ath_rx_tasklet+0xd09/0xe90 [ath9k]
> [ 75.956286] ath9k_tasklet+0x102/0x240 [ath9k]
> [ 75.956288] tasklet_action_common.isra.0+0x6d/0x170
> [ 75.956291] __do_softirq+0xcc/0x425
> [ 75.956294] irq_exit+0xae/0xc0
> [ 75.956296] do_IRQ+0x8a/0x110
> [ 75.956298] common_interrupt+0xf/0xf
> [ 75.956300] </IRQ>
> [ 75.956303] RIP: 0010:cpuidle_enter_state+0xb2/0x400
> [ 75.956308] RSP: 0018:ffffffff82203e70 EFLAGS: 00000202 ORIG_RAX: ffffffffffffffd7
> [ 75.956310] RAX: ffffffff82219800 RBX: ffffffff822bd0a0 RCX: 0000000000000000
> [ 75.956312] RDX: 0000000000000046 RSI: 0000000000000006 RDI: ffffffff82219800
> [ 75.956314] RBP: ffff888155a01c00 R08: 00000011af51aabe R09: 0000000000000000
> [ 75.956315] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002
> [ 75.956317] R13: 00000011af51aabe R14: 0000000000000003 R15: ffffffff82219800
> [ 75.956321] cpuidle_enter+0x24/0x40
> [ 75.956323] do_idle+0x1ac/0x220
> [ 75.956326] cpu_startup_entry+0x14/0x20
> [ 75.956329] start_kernel+0x482/0x489
> [ 75.956332] secondary_startup_64+0xa4/0xb0
>
> Fixes: c774d57fd47c ("ath9k: add dynamic ACK timeout estimation")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
e1aa1a1db3b0 ath9k: dynack: fix possible deadlock in ath_dynack_node_{de}init
--
https://patchwork.kernel.org/patch/11100409/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v4] ath9k: add loader for AR92XX (and older) pci(e)
From: Kalle Valo @ 2019-09-04 6:13 UTC (permalink / raw)
To: Christian Lamparter
Cc: QCA ath9k Development, linux-wireless, Julian Calaby,
Martin Blumenstingl
In-Reply-To: <20190705175313.19482-1-chunkeey@gmail.com>
Christian Lamparter <chunkeey@gmail.com> wrote:
> Atheros cards with a AR92XX generation (and older) chip usually
> store their pci(e) initialization vectors on an external eeprom chip.
> However these chips technically don't need the eeprom chip attached,
> the AR9280 Datasheet in section "6.1.2 DEVICE_ID" describes that
> "... if the EEPROM content is not valid, a value of 0xFF1C returns
> when read from the register". So, they will show up on the system's
> pci bus. However in that state, ath9k can't load, since it relies
> on having the correct pci-id, otherwise it doesn't know what chip it
> actually is. This happens on many embedded devices like routers
> and accesspoint since they want to keep the BOM low and store the
> pci(e) initialization vectors together with the calibration data
> on the system's FLASH, which is out of reach of the ath9k chip.
>
> Furthermore, Some devices (like the Cisco Meraki Z1 Cloud Managed
> Teleworker Gateway) need to be able to initialize the PCIe wifi device.
> Normally, this should be done as a pci quirk during the early stages of
> booting linux. However, this isn't possible for devices which have the
> init code for the Atheros chip stored on NAND in an UBI volume.
> Hence, this module can be used to initialize the chip when the
> user-space is ready to extract the init code.
>
> Martin Blumenstingl prodived the following fixes:
> owl-loader: add support for OWL emulation PCI devices
> owl-loader: don't re-scan the bus when ath9k_pci_fixup failed
> owl-loader: use dev_* instead of pr_* logging functions
> owl-loader: auto-generate the eeprom filename as fallback
> owl-loader: add a debug message when swapping the eeprom data
> owl-loader: add missing newlines in log messages
>
> Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
5a4f2040fd07 ath9k: add loader for AR92XX (and older) pci(e)
--
https://patchwork.kernel.org/patch/11033133/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH -next] carl9170: remove set but not used variable 'udev'
From: Kalle Valo @ 2019-09-04 6:10 UTC (permalink / raw)
To: YueHaibing
Cc: chunkeey, linux-kernel, netdev, linux-wireless, davem, YueHaibing
In-Reply-To: <20190702141207.47552-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/ath/carl9170/usb.c: In function carl9170_usb_disconnect:
> drivers/net/wireless/ath/carl9170/usb.c:1110:21:
> warning: variable udev set but not used [-Wunused-but-set-variable]
>
> It is not use since commit feb09b293327 ("carl9170:
> fix misuse of device driver API")
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> Acked-by: Christian Lamparter <chunkeey@gmail.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
68092f9cf932 carl9170: remove set but not used variable 'udev'
--
https://patchwork.kernel.org/patch/11027909/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] wil6210: Delete an unnecessary kfree() call in wil_tid_ampdu_rx_alloc()
From: Kalle Valo @ 2019-09-04 6:08 UTC (permalink / raw)
To: Markus Elfring
Cc: linux-wireless, netdev, wil6210, David S. Miller, Maya Erez, LKML,
kernel-janitors
In-Reply-To: <b9620e49-618d-b392-6456-17de5807df75@web.de>
Markus Elfring <Markus.Elfring@web.de> wrote:
> A null pointer would be passed to a call of the function “kfree”
> directly after a call of the function “kcalloc” failed at one place.
> Remove this superfluous function call.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> Reviewed-by: Maya Erez <merez@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
d20b1e6c8307 wil6210: Delete an unnecessary kfree() call in wil_tid_ampdu_rx_alloc()
--
https://patchwork.kernel.org/patch/11117119/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v8 2/2] wil6210: Add EDMG channel support
From: Kalle Valo @ 2019-09-04 6:06 UTC (permalink / raw)
To: Alexei Avshalom Lazar
Cc: Johannes Berg, Alexei Avshalom Lazar, linux-wireless, wil6210
In-Reply-To: <1566138918-3823-3-git-send-email-ailizaro@codeaurora.org>
Alexei Avshalom Lazar <ailizaro@codeaurora.org> wrote:
> Add support for Enhanced Directional Multi-Gigabit (EDMG) channels 9-11.
> wil6210 reports it's EDMG capabilities (that are also based on FW
> capability) to cfg80211 by filling
> wiphy->bands[NL80211_BAND_60GHZ]->edmg_cap.
> wil6210 handles edmg.channels and edmg.bw_config requested in connect
> and start_ap operations.
>
> Signed-off-by: Alexei Avshalom Lazar <ailizaro@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
9abe3e306ecc wil6210: Add EDMG channel support
--
https://patchwork.kernel.org/patch/11099621/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH][next] wil6210: fix wil_cid_valid with negative cid values
From: Kalle Valo @ 2019-09-04 6:05 UTC (permalink / raw)
To: Colin King
Cc: Maya Erez, David S . Miller, linux-wireless, wil6210, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20190702144026.13013-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> There are several occasions where a negative cid value is passed
> into wil_cid_valid and this is converted into a u8 causing the
> range check of cid >= 0 to always succeed. Fix this by making
> the cid argument an int to handle any -ve error value of cid.
>
> An example of this behaviour is in wil_cfg80211_dump_station,
> where cid is assigned -ENOENT if the call to wil_find_cid_by_idx
> fails, and this -ve value is passed to wil_cid_valid. I believe
> that the conversion of -ENOENT to the u8 value 254 which is
> greater than wil->max_assoc_sta causes wil_find_cid_by_idx to
> currently work fine, but I think is by luck and not the
> intended behaviour.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Reviewed-by: Maya Erez <merez@codeaurora.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
23bb9f692b66 wil6210: fix wil_cid_valid with negative cid values
--
https://patchwork.kernel.org/patch/11027989/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* RE: [PATCH 2/7] ath10k: change max RX bundle size from 8 to 32 for sdio
From: Wen Gong @ 2019-09-04 4:43 UTC (permalink / raw)
To: Dave Taht, ath10k@lists.infradead.org,
linux-wireless@vger.kernel.org
In-Reply-To: <87k1apnyyo.fsf@taht.net>
> -----Original Message-----
> From: Dave Taht <dave@taht.net>
> Sent: Wednesday, September 4, 2019 12:10 AM
> To: Wen Gong <wgong@qti.qualcomm.com>; ath10k@lists.infradead.org;
> linux-wireless@vger.kernel.org
> Subject: [EXT] Re: [PATCH 2/7] ath10k: change max RX bundle size from 8 to
> 32 for sdio
>
>
> In terms of deeply grokking what increasing buffering to achieve high
> bandwidth on a testbench, vs what it can do to clobber latency in the
> real world at low bandwidths, I tend to point folk at:
>
> https://www.youtube.com/watch?v=Rb-UnHDw02o&t=25m40s
>
> where I got a whole bunch of hackers to stand up and act like packets
> in an aggregating FIFO wifi queue.
>
> This key section is only 8 minutes long, and I promise, y'all laugh
> at least 3 times at the demonstration.
>
> At the time, also, the ath10k was so overbuffered that on one test
> I could try to start 100 flows, and only get five.
>
> https://lwn.net/Articles/705884/
>
> and on my slides:
>
> https://blog.linuxplumbersconf.org/2016/ocw//system/presentations/3963/
> original/linuxplumbers_wifi_latency-3Nov.pdf
>
Hi Dave,
So your mean is change 8 to 32 will impact latency? It will increase latency of rx?
>
> 0xFFFEFFFF
^ permalink raw reply
* RE: [PATCH v3 8/8] ath10k: enable napi on RX path for sdio
From: Wen Gong @ 2019-09-04 2:59 UTC (permalink / raw)
To: Nicolas Boichat, Wen Gong
Cc: open list:NETWORKING DRIVERS (WIRELESS),
ath10k@lists.infradead.org
In-Reply-To: <CANMq1KBXWydTR50fVqF7ks5gBTpUAS8Ga-8_MzeMGAknnyoVzg@mail.gmail.com>
> -----Original Message-----
> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Nicolas
> Boichat
> Sent: Friday, August 30, 2019 11:20 AM
> To: Wen Gong <wgong@codeaurora.org>
> Cc: open list:NETWORKING DRIVERS (WIRELESS) <linux-
> wireless@vger.kernel.org>; ath10k@lists.infradead.org
> Subject: [EXT] Re: [PATCH v3 8/8] ath10k: enable napi on RX path for sdio
>
> On Fri, Aug 30, 2019 at 1:50 AM Wen Gong <wgong@codeaurora.org> wrote:
Patch v4 sent, https://patchwork.kernel.org/patch/11126239/
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* RE: [PATCH v3 7/8] ath10k: enable alt data of TX path for sdio
From: Wen Gong @ 2019-09-04 2:58 UTC (permalink / raw)
To: Wen Gong, ath10k@lists.infradead.org; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1566998177-2658-8-git-send-email-wgong@codeaurora.org>
> -----Original Message-----
> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Wen Gong
> Sent: Wednesday, August 28, 2019 9:16 PM
> To: ath10k@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org
> Subject: [EXT] [PATCH v3 7/8] ath10k: enable alt data of TX path for sdio
>
Patch v4 sent, https://patchwork.kernel.org/patch/11126235/
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* RE: [PATCH v3 6/8] ath10k: add htt TX bundle for sdio
From: Wen Gong @ 2019-09-04 2:56 UTC (permalink / raw)
To: Wen Gong, ath10k@lists.infradead.org; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1566998177-2658-7-git-send-email-wgong@codeaurora.org>
> -----Original Message-----
> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Wen Gong
> Sent: Wednesday, August 28, 2019 9:16 PM
> To: ath10k@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org
> Subject: [EXT] [PATCH v3 6/8] ath10k: add htt TX bundle for sdio
>
Patch v4 sent, https://patchwork.kernel.org/patch/11126233/
> 1.9.1
>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* RE: [PATCH v3 5/8] ath10k: disable TX complete indication of htt for sdio
From: Wen Gong @ 2019-09-04 2:54 UTC (permalink / raw)
To: Wen Gong, ath10k@lists.infradead.org; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1566998177-2658-6-git-send-email-wgong@codeaurora.org>
> -----Original Message-----
> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Wen Gong
> Sent: Wednesday, August 28, 2019 9:16 PM
> To: ath10k@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org
> Subject: [EXT] [PATCH v3 5/8] ath10k: disable TX complete indication of htt
> for sdio
Patch v4 sent, https://patchwork.kernel.org/patch/11126231/
>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* RE: [PATCH v3 4/8] ath10k: add workqueue for RX path of sdio
From: Wen Gong @ 2019-09-04 2:53 UTC (permalink / raw)
To: Wen Gong, ath10k@lists.infradead.org; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1566998177-2658-5-git-send-email-wgong@codeaurora.org>
> -----Original Message-----
> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Wen Gong
> Sent: Wednesday, August 28, 2019 9:16 PM
> To: ath10k@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org
> Subject: [EXT] [PATCH v3 4/8] ath10k: add workqueue for RX path of sdio
>
Patch v4 sent, https://patchwork.kernel.org/patch/11126229/
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* RE: [PATCH v3 3/8] ath10k: change max RX bundle size from 8 to 32 for sdio
From: Wen Gong @ 2019-09-04 2:52 UTC (permalink / raw)
To: Nicolas Boichat, Wen Gong
Cc: open list:NETWORKING DRIVERS (WIRELESS),
ath10k@lists.infradead.org
In-Reply-To: <CANMq1KDLXsar1AqU=mfce-2LGD7SRDmC5phkKtz92D3BG35Eog@mail.gmail.com>
> -----Original Message-----
> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Nicolas
> Boichat
> Sent: Friday, August 30, 2019 11:11 AM
> To: Wen Gong <wgong@codeaurora.org>
> Cc: open list:NETWORKING DRIVERS (WIRELESS) <linux-
> wireless@vger.kernel.org>; ath10k@lists.infradead.org
> Subject: [EXT] Re: [PATCH v3 3/8] ath10k: change max RX bundle size from 8
> to 32 for sdio
Patch v4 sent, https://patchwork.kernel.org/patch/11126225/
>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* RE: [PATCH v4 3/8] ath10k: change max RX bundle size from 8 to 32 for sdio
From: Wen Gong @ 2019-09-04 2:50 UTC (permalink / raw)
To: Wen Gong, ath10k@lists.infradead.org; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1567416146-14403-4-git-send-email-wgong@codeaurora.org>
> -----Original Message-----
> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Wen Gong
> Sent: Monday, September 2, 2019 5:22 PM
> To: ath10k@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org
> Subject: [EXT] [PATCH v4 3/8] ath10k: change max RX bundle size from 8 to
> 32 for sdio
>
Patch v4 sent, https://patchwork.kernel.org/patch/11126225/
>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* RE: [PATCH v3 2/8] ath10k: enable RX bundle receive for sdio
From: Wen Gong @ 2019-09-04 2:48 UTC (permalink / raw)
To: Wen Gong, ath10k@lists.infradead.org; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1566998177-2658-3-git-send-email-wgong@codeaurora.org>
> -----Original Message-----
> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Wen Gong
> Sent: Wednesday, August 28, 2019 9:16 PM
> To: ath10k@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org
> Subject: [EXT] [PATCH v3 2/8] ath10k: enable RX bundle receive for sdio
>
Patch v4 sent, https://patchwork.kernel.org/patch/11126223/
>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* RE: [PATCH v3 2/8] ath10k: enable RX bundle receive for sdio
From: Wen Gong @ 2019-09-04 2:43 UTC (permalink / raw)
To: Wen Gong, ath10k@lists.infradead.org; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1566998177-2658-3-git-send-email-wgong@codeaurora.org>
> -----Original Message-----
> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Wen Gong
> Sent: Wednesday, August 28, 2019 9:16 PM
> To: ath10k@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org
> Subject: [EXT] [PATCH v3 2/8] ath10k: enable RX bundle receive for sdio
>
Patch v4 sent, https://patchwork.kernel.org/patch/11126223/
> 1.9.1
>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* RE: [PATCH v3 1/8] ath10k: adjust skb length in ath10k_sdio_mbox_rx_packet
From: Wen Gong @ 2019-09-04 2:42 UTC (permalink / raw)
To: Wen Gong, ath10k@lists.infradead.org; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1566998177-2658-2-git-send-email-wgong@codeaurora.org>
> -----Original Message-----
> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Wen Gong
> Sent: Wednesday, August 28, 2019 9:16 PM
> To: ath10k@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org
> Subject: [EXT] [PATCH v3 1/8] ath10k: adjust skb length in
> ath10k_sdio_mbox_rx_packet
>
Patch v4 sent, https://patchwork.kernel.org/patch/11126221/
>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* RE: [PATCH 7/7] ath10k: enable napi on RX path for sdio
From: Wen Gong @ 2019-09-04 2:37 UTC (permalink / raw)
To: Wen Gong, ath10k@lists.infradead.org; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1566302108-18219-8-git-send-email-wgong@codeaurora.org>
> -----Original Message-----
> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Wen Gong
> Sent: Tuesday, August 20, 2019 7:55 PM
> To: ath10k@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org
> Subject: [EXT] [PATCH 7/7] ath10k: enable napi on RX path for sdio
>
Patch v2 sent, https://patchwork.kernel.org/patch/11116669/
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* RE: [PATCH 6/7] ath10k: enable alt data of TX path for sdio
From: Wen Gong @ 2019-09-04 2:36 UTC (permalink / raw)
To: Wen Gong, ath10k@lists.infradead.org; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1566302108-18219-7-git-send-email-wgong@codeaurora.org>
> -----Original Message-----
> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Wen Gong
> Sent: Tuesday, August 20, 2019 7:55 PM
> To: ath10k@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org
> Subject: [EXT] [PATCH 6/7] ath10k: enable alt data of TX path for sdio
>
Patch v2 sent, https://patchwork.kernel.org/patch/11116683/
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* RE: [PATCH 5/7] ath10k: add htt TX bundle for sdio
From: Wen Gong @ 2019-09-04 2:34 UTC (permalink / raw)
To: Wen Gong, ath10k@lists.infradead.org; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1566302108-18219-6-git-send-email-wgong@codeaurora.org>
> -----Original Message-----
> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Wen Gong
> Sent: Tuesday, August 20, 2019 7:55 PM
> To: ath10k@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org
> Subject: [EXT] [PATCH 5/7] ath10k: add htt TX bundle for sdio
>
Patch v2 sent, https://patchwork.kernel.org/patch/11116687/
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* RE: [PATCH 4/7] ath10k: disable TX complete indication of htt for sdio
From: Wen Gong @ 2019-09-04 2:33 UTC (permalink / raw)
To: Wen Gong, ath10k@lists.infradead.org; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1566302108-18219-5-git-send-email-wgong@codeaurora.org>
> -----Original Message-----
> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Wen Gong
> Sent: Tuesday, August 20, 2019 7:55 PM
> To: ath10k@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org
> Subject: [EXT] [PATCH 4/7] ath10k: disable TX complete indication of htt for
> sdio
>
Patch v2 sent, https://patchwork.kernel.org/patch/11116685/
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* RE: [PATCH 4/8] rtw88: 8822c: add FW IQK support
From: Tony Chuang @ 2019-09-04 2:31 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless@vger.kernel.org, briannorris@chromium.org,
sgruszka@redhat.com
In-Reply-To: <20190903125324.4CDC76085C@smtp.codeaurora.org>
>
> <yhchuang@realtek.com> wrote:
>
> > From: Yan-Hsuan Chuang <yhchuang@realtek.com>
> >
> > Add support for doing IQK in firmware
> >
> > Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
>
> The commit log does not answer "Why?". What is IQK and how does it help?
>
> No need to resend, I can update the commit log but just let me know what to
> add.
>
Ideally the RF component's I/Q vectors should be orthogonal, but usually they are not.
So we need to calibrate for the RF components, ex. PA/LNA, ADC/DAC.
And if the I/Q vectors are more orthogonal, the mixed signal will have less deviation.
This helps with those rates with higher modulation (MCS8-9), because they have more
strict EVM/SNR requirement. Also the better of the quality of the signal, the longer it
can propagate, and the better throughput performance we can get.
Yan-Hsuan
^ permalink raw reply
* RE: [PATCH 3/7] ath10k: add workqueue for RX path of sdio
From: Wen Gong @ 2019-09-04 2:31 UTC (permalink / raw)
To: Wen Gong, ath10k@lists.infradead.org; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1566302108-18219-4-git-send-email-wgong@codeaurora.org>
> -----Original Message-----
> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Wen Gong
> Sent: Tuesday, August 20, 2019 7:55 PM
> To: ath10k@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org
> Subject: [EXT] [PATCH 3/7] ath10k: add workqueue for RX path of sdio
>
Patch v2 sent, https://patchwork.kernel.org/patch/11116671/
> --
> 1.9.1
>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ 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