[ath6kl:pending] BUILD SUCCESS 8d251747ae09ae3505d04bd129dc7100df4cabac
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git pending branch HEAD: 8d251747ae09ae3505d04bd129dc7100df4cabac wcn36xx: Use sequence number allocated by mac80211 elapsed time: 2727m configs tested: 74 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 i386 allnoconfig ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68kdefconfig m68k allyesconfig m68k sun3_defconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allyesconfig sparc64 allmodconfig x86_64rhel-7.6-kselftests x86_64 rhel-8.3 x86_64 kexec x86_64 rhel x86_64lkp x86_64 fedora-25 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[PATCH v2 1/2] nl80211: vendor-cmd: qca: add dynamic SAR power limits
The vendor commands is to add API for user to configure dynamic SAR
power limits, it will not replace the existing power control
functionality, it is to make more convenient to configure power.
For different chips and drivers, they has different configuration, such
as dBm units, 5G Hz subbands, valid range, etc. so user space can not
know what configuration should be used. If use a common API for all
chips and drivers, then it need a reporting API too, so drivers can
tell what configuration it support. Recently it is better to use this
vendor-cmd for different chips and drivers.
An example of usage(wlan0 is the wireless interface dev name):
iw dev wlan0 vendor send 0x1374 0x92 0x2C 0x00 0x03 0x00 0x14 0x00 0x01
0x00 0x08 0x00 0x07 0x00 0x22 0x00 0x00 0x00 0x08 0x00 0x04 0x00 0x00
0x00 0x00 0x00 0x14 0x00 0x02 0x00 0x08 0x00 0x07 0x00 0x11 0x00 0x00
0x00 0x08 0x00 0x04 0x00 0x01 0x00 0x00 0x00
means of bytes:
0x1374: vendor id
0x92: vendor subcmd id
0x22: 2.4G power limit
0x11: 5G power limit
Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029.
Signed-off-by: Wen Gong
Signed-off-by: Kalle Valo
---
include/uapi/nl80211-vnd-qca.h | 68 ++
1 file changed, 68 insertions(+)
create mode 100644 include/uapi/nl80211-vnd-qca.h
diff --git a/include/uapi/nl80211-vnd-qca.h b/include/uapi/nl80211-vnd-qca.h
new file mode 100644
index ..482c9409a2c0
--- /dev/null
+++ b/include/uapi/nl80211-vnd-qca.h
@@ -0,0 +1,68 @@
+/* SPDX-License-Identifier: ISC */
+/*
+ * Copyright (c) 2019 The Linux Foundation. All rights reserved.
+ */
+
+#ifndef _UAPI_NL80211_VND_QCA_H
+#define _UAPI_NL80211_VND_QCA_H
+
+/* Vendor id to be used in vendor specific command and events to user space
+ * NOTE: The authoritative place for definition of QCA_NL80211_VENDOR_ID,
+ * vendor subcmd definitions prefixed with QCA_NL80211_VENDOR_SUBCMD, and
+ * qca_wlan_vendor_attr is open source file src/common/qca-vendor.h in
+ * git://w1.fi/srv/git/hostap.git; the values here are just a copy of that
+ */
+#define QCA_NL80211_VENDOR_ID 0x001374
+
+/**
+ * enum qca_nl80211_vendor_subcmds - QCA nl80211 vendor command identifiers
+ *
+ *@QCA_NL80211_VENDOR_SUBCMD_SET_SAR_LIMITS and is used to retrieve the
+ * settings currently in use. The attributes returned by this command are
+ * defined by enum qca_vendor_attr_sar_limits.
+ */
+enum qca_nl80211_vendor_subcmds {
+ QCA_NL80211_VENDOR_SUBCMD_SET_SAR_LIMITS = 146,
+ };
+
+/**
+ * enum qca_vendor_attr_sar_limits - Attributes for SAR power limits
+ *
+ * @QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC: Nested array of SAR power
+ * limit specifications. The number of specifications is
+ * specified by @QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_NUM_SPECS. Each
+ * specification contains a set of
+ * QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC_* attributes. A
+ * specification is uniquely identified by the attributes
+ * %QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC_BAND and always
+ * contains as a payload the attribute
+ * %QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC_POWER_LIMIT.
+ *
+ * @QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC_BAND: Optional (u32) value to
+ * indicate for which band this specification applies. Valid
+ * values are enumerated in enum %nl80211_band (although not all
+ * bands may be supported by a given device). If the attribute is
+ * not supplied then the specification will be applied to all
+ * supported bands.
+ *
+ * @QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC_POWER_LIMIT: Required (u32)
+ * value to specify the actual power limit value in units of 0.5
+ * dBm (i.e., a value of 11 represents 5.5 dBm).
+ * This is required, when %QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SELECT is
+ * %QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SELECT_USER.
+ *
+ * These attributes are used with %QCA_NL80211_VENDOR_SUBCMD_SET_SAR_LIMITS
+ * and %QCA_NL80211_VENDOR_SUBCMD_GET_SAR_LIMITS.
+ */
+enum qca_vendor_attr_sar_limits {
+ QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_INVALID = 0,
+ QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC = 3,
+ QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC_BAND = 4,
+ QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_SPEC_POWER_LIMIT = 7,
+
+ QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_AFTER_LAST,
+ QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_MAX =
+ QCA_WLAN_VENDOR_ATTR_SAR_LIMITS_AFTER_LAST - 1
+};
+
+#endif /* _UAPI_NL80211_VND_QCA_H_ */
--
2.23.0
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
[PATCH v2 2/2] ath10k: allow dynamic SAR power limits to be configured
Add support for a vendor command for STATION, the command
QCA_NL80211_VENDOR_SUBCMD_SET_SAR_LIMITS which is already defined in
git://w1.fi/hostap.git (src/command/qca-vendor.h). This allows user
space to configure power limits for 2.4 GHz and 5 GHz bands.
ath10k set pdev parameter WMI_PDEV_PARAM_TXPOWER_LIMIT2G and
WMI_PDEV_PARAM_TXPOWER_LIMIT5G to firmware, the 2 value will
be used as one input source to affect the tx power.
When QCA_NL80211_VENDOR_SUBCMD_SET_SAR_LIMITS set to ath10k, it will
be saved the 2.4G and 5G limit value, If STATION is connected meanwhile,
then the 2.4G and 5G WMI command will be set to firmware, otherwise
it will not set to firmware at this moment. When STATION connect
next time, it will set to firmware.
Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029.
Signed-off-by: Wen Gong
Signed-off-by: Kalle Valo
---
drivers/net/wireless/ath/ath10k/Makefile | 1 +
drivers/net/wireless/ath/ath10k/core.c | 2 +
drivers/net/wireless/ath/ath10k/core.h | 2 +
drivers/net/wireless/ath/ath10k/hw.h | 3 +
drivers/net/wireless/ath/ath10k/mac.c| 64 +
drivers/net/wireless/ath/ath10k/mac.h| 2 +-
drivers/net/wireless/ath/ath10k/vendor.c | 114 +++
drivers/net/wireless/ath/ath10k/vendor.h | 13 +++
8 files changed, 200 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/wireless/ath/ath10k/vendor.c
create mode 100644 drivers/net/wireless/ath/ath10k/vendor.h
diff --git a/drivers/net/wireless/ath/ath10k/Makefile
b/drivers/net/wireless/ath/ath10k/Makefile
index 142c777b287f..6cdc7eba5d25 100644
--- a/drivers/net/wireless/ath/ath10k/Makefile
+++ b/drivers/net/wireless/ath/ath10k/Makefile
@@ -13,6 +13,7 @@ ath10k_core-y += mac.o \
bmi.o \
hw.o \
p2p.o \
+vendor.o \
swap.o
ath10k_core-$(CONFIG_ATH10K_SPECTRAL) += spectral.o
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 22b6937ac225..1bab901a28ab 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -25,6 +25,7 @@
#include "testmode.h"
#include "wmi-ops.h"
#include "coredump.h"
+#include "vendor.h"
unsigned int ath10k_debug_mask;
EXPORT_SYMBOL(ath10k_debug_mask);
@@ -191,6 +192,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.tx_stats_over_pktlog = false,
.bmi_large_size_download = true,
.supports_peer_stats_info = true,
+ .dynamic_sar_support = true,
},
{
.id = QCA6174_HW_2_1_VERSION,
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 5c18f6c20462..c8b8e1398ead 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -1016,6 +1016,8 @@ struct ath10k {
u8 ps_state_enable;
bool nlo_enabled;
+ u32 tx_power_2g_limit;
+ u32 tx_power_5g_limit;
bool p2p;
struct {
diff --git a/drivers/net/wireless/ath/ath10k/hw.h
b/drivers/net/wireless/ath/ath10k/hw.h
index f16edcb9f326..4bc929e3ed67 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -626,6 +626,9 @@ struct ath10k_hw_params {
/* provides bitrates for sta_statistics using
WMI_TLV_PEER_STATS_INFO_EVENTID */
bool supports_peer_stats_info;
+
+ /* support dynamic sar */
+ bool dynamic_sar_support;
};
struct htt_rx_desc;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 3e3896214e8b..74ee81e21559 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -24,6 +24,7 @@
#include "wmi-tlv.h"
#include "wmi-ops.h"
#include "wow.h"
+#include "vendor.h"
/*/
/* Rates */
@@ -2885,6 +2886,65 @@ static int ath10k_mac_vif_recalc_txbf(struct ath10k *ar,
return 0;
}
+static bool ath10k_mac_get_connected(struct ath10k *ar)
+{
+ struct ath10k_vif *arvif;
+
+ list_for_each_entry(arvif, &ar->arvifs, list) {
+ if (arvif->is_up && arvif->vdev_type == WMI_VDEV_TYPE_STA)
+ return true;
+ }
+
+ return false;
+}
+
+int ath10k_mac_set_sar_power_limit(struct ath10k *ar)
+{
+ u32 ret, param, pwr_limit_2G, pwr_limit_5G;
+ bool connected, tx_power_valid;
+
+ if (!ar->hw_params.dynamic_sar_support)
+ return 0;
+
+ connected = ath10k_mac_get_connected(ar);
+ tx_power_valid = (ar->tx_power_2g_limit != 0 && ar->tx_power_5g_limit
!= 0);
+
+ ath10k_dbg(ar, ATH10K_DBG_MAC, "mac connected %d sar power valid %d\n",
+ connected, tx_power_valid);
+
+ if (!connected || !tx_power_valid)
+ return 0;
+
+ pwr_limit_2G = ar->tx_power_2g_limit;
+ pwr_limit_5G = ar->tx_power_5g_limit;
+
+
[PATCH v2 0/2] ath10k: SAR power limit vendor command
v2: change description of "nl80211: vendor-cmd: qca: add dynamic SAR power limits" remove ATH10K_WMI_SAR_*G_0_MASK of wmi.h here's a patchset adding dynamic SAR power limit vendor command to ath10k. This follows the new process documented in the wiki: https://wireless.wiki.kernel.org/en/developers/documentation/nl80211#vendor-specific_api Wen Gong (2): nl80211: vendor-cmd: qca: add dynamic SAR power limits ath10k: allow dynamic SAR power limits to be configured drivers/net/wireless/ath/ath10k/Makefile | 1 + drivers/net/wireless/ath/ath10k/core.c | 2 + drivers/net/wireless/ath/ath10k/core.h | 2 + drivers/net/wireless/ath/ath10k/hw.h | 3 + drivers/net/wireless/ath/ath10k/mac.c| 64 + drivers/net/wireless/ath/ath10k/mac.h| 2 +- drivers/net/wireless/ath/ath10k/vendor.c | 114 +++ drivers/net/wireless/ath/ath10k/vendor.h | 13 +++ include/uapi/nl80211-vnd-qca.h | 68 ++ 9 files changed, 268 insertions(+), 1 deletion(-) create mode 100644 drivers/net/wireless/ath/ath10k/vendor.c create mode 100644 drivers/net/wireless/ath/ath10k/vendor.h create mode 100644 include/uapi/nl80211-vnd-qca.h -- 2.23.0 ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[ath6kl:master-pending] BUILD SUCCESS 20bc0ea7f0d3ea61945cac2ff0bb840eb1191a7d
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git master-pending branch HEAD: 20bc0ea7f0d3ea61945cac2ff0bb840eb1191a7d Merge branch 'pending' into master-pending elapsed time: 2642m configs tested: 74 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 i386 allnoconfig ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allyesconfig sparc64 allmodconfig x86_64rhel-7.6-kselftests x86_64 rhel-8.3 x86_64 kexec x86_64 rhel x86_64lkp x86_64 fedora-25 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
RE: [RFC 1/7] mac80211: Add check for napi handle before WARN_ON
> -Original Message- > From: Rakesh Pillai > Sent: Friday, July 24, 2020 11:51 AM > To: 'Johannes Berg' ; > 'ath10k@lists.infradead.org' > Cc: 'linux-wirel...@vger.kernel.org' ; > 'linux-ker...@vger.kernel.org' ; > 'kv...@codeaurora.org' ; 'da...@davemloft.net' > ; 'k...@kernel.org' ; > 'net...@vger.kernel.org' ; > 'diand...@chromium.org' ; > 'evgr...@chromium.org' > Subject: RE: [RFC 1/7] mac80211: Add check for napi handle before > WARN_ON > > > > > -Original Message- > > From: Johannes Berg > > Sent: Friday, July 24, 2020 1:37 AM > > To: Rakesh Pillai ; ath10k@lists.infradead.org > > Cc: linux-wirel...@vger.kernel.org; linux-ker...@vger.kernel.org; > > kv...@codeaurora.org; da...@davemloft.net; k...@kernel.org; > > net...@vger.kernel.org; diand...@chromium.org; > evgr...@chromium.org > > Subject: Re: [RFC 1/7] mac80211: Add check for napi handle before > > WARN_ON > > > > On Thu, 2020-07-23 at 23:56 +0530, Rakesh Pillai wrote: > > > > > > > - WARN_ON_ONCE(softirq_count() == 0); > > > > > + WARN_ON_ONCE(napi && softirq_count() == 0); > > > > > > > > FWIW, I'm pretty sure this is incorrect - we make assumptions on > > > > softirqs being disabled in mac80211 for serialization and in place of > > > > some locking, I believe. > > > > > > > > > > I checked this, but let me double confirm. > > > But after this change, no packet is submitted from driver in a softirq > > context. > > > So ideally this should take care of serialization. > > > > I'd guess that we have some reliance on BHs already being disabled, for > > things like u64 sync updates, or whatnot. I mean, we did "rx_ni()" for a > > reason ... Maybe lockdep can help catch some of the issues. > > > > But couldn't you be in a thread and have BHs disabled too? > > This would ideally beat the purpose and possibly hurt the other subsystems > running on the same core. > Hi Johannes, We do have the usage of napi_gro_receive and netif_receive_skb in mac80211. /* deliver to local stack */ if (rx->napi) napi_gro_receive(rx->napi, skb); else netif_receive_skb(skb); Also all the rx_handlers are called under the " rx->local->rx_path_lock" lock. Is the BH disable still required ? > > > > johannes ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
RE: [RFC 0/7] Add support to process rx packets in thread
From: Sebastian Gottschall > Sent: 25 July 2020 16:42 > >> i agree. i just can say that i tested this patch recently due this > >> discussion here. and it can be changed by sysfs. but it doesnt work for > >> wifi drivers which are mainly using dummy netdev devices. for this i > >> made a small patch to get them working using napi_set_threaded manually > >> hardcoded in the drivers. (see patch bellow) > > By CONFIG_THREADED_NAPI, there is no need to consider what you did here > > in the napi core because device drivers know better and are responsible > > for it before calling napi_schedule(n). > yeah. but that approach will not work for some cases. some stupid > drivers are using locking context in the napi poll function. > in that case the performance will runto shit. i discovered this with the > mvneta eth driver (marvell) and mt76 tx polling (rx works) > for mvneta is will cause very high latencies and packet drops. for mt76 > it causes packet stop. doesnt work simply (on all cases no crashes) > so the threading will only work for drivers which are compatible with > that approach. it cannot be used as drop in replacement from my point of > view. > its all a question of the driver design Why should it make (much) difference whether the napi callbacks (etc) are done in the context of the interrupted process or that of a specific kernel thread. The process flags (or whatever) can even be set so that it appears to be the expected 'softint' context. In any case running NAPI from a thread will just show up the next piece of code that runs for ages in softint context. I think I've seen the tail end of memory being freed under rcu finally happening under softint and taking absolutely ages. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC 0/7] Add support to process rx packets in thread
On 2020-07-26 10:32, Hillf Danton wrote: > > On Sun, 26 Jul 2020 10:10:15 +0200 Felix Fietkau wrote: >> On 2020-07-26 03:22, Hillf Danton wrote: >> > >> > Feel free to do that. Is it likely for me to select a Cc? >> > >> Shall I use Signed-off-by: Hillf Danton ? > > s/Signed-off-by/Cc/ > >> What Cc do you want me to add? > > I prefer Cc over other tags. Ah, okay. I was planning on adding you as the author of the patch, since you did most of the work on it. If you want to be attributed as author (or in Co-developed-by), I'd need your Signed-off-by. If you don't want that, I can submit it under my name and leave you in as Cc only. - Felix ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC 0/7] Add support to process rx packets in thread
On Sun, 26 Jul 2020 10:10:15 +0200 Felix Fietkau wrote: > On 2020-07-26 03:22, Hillf Danton wrote: > > > > Feel free to do that. Is it likely for me to select a Cc? > > > Shall I use Signed-off-by: Hillf Danton ? s/Signed-off-by/Cc/ > What Cc do you want me to add? I prefer Cc over other tags. ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC 0/7] Add support to process rx packets in thread
On 2020-07-26 03:22, Hillf Danton wrote:
>> - add a state bit for threaded NAPI
>> - make netif_threaded_napi_add inline
>> - run queue_work outside of local_irq_save/restore (it does that
>> internally already)
>>
>> If you don't mind, I'd like to propose this to netdev soon. Can I have
>> your Signed-off-by for that?
>
> Feel free to do that. Is it likely for me to select a Cc?
Shall I use Signed-off-by: Hillf Danton ?
What Cc do you want me to add?
>> ---
>> --- a/include/linux/netdevice.h
>> +++ b/include/linux/netdevice.h
>> @@ -347,6 +347,7 @@ struct napi_struct {
>> struct list_headdev_list;
>> struct hlist_node napi_hash_node;
>> unsigned intnapi_id;
>> +struct work_struct work;
>> };
>>
>> enum {
>> @@ -357,6 +358,7 @@ enum {
>> NAPI_STATE_HASHED, /* In NAPI hash (busy polling possible) */
>> NAPI_STATE_NO_BUSY_POLL,/* Do not add in napi_hash, no busy polling */
>> NAPI_STATE_IN_BUSY_POLL,/* sk_busy_loop() owns this NAPI */
>> +NAPI_STATE_THREADED,/* Use threaded NAPI */
>> };
>>
>> enum {
>> @@ -367,6 +369,7 @@ enum {
>> NAPIF_STATE_HASHED = BIT(NAPI_STATE_HASHED),
>> NAPIF_STATE_NO_BUSY_POLL = BIT(NAPI_STATE_NO_BUSY_POLL),
>> NAPIF_STATE_IN_BUSY_POLL = BIT(NAPI_STATE_IN_BUSY_POLL),
>> +NAPIF_STATE_THREADED = BIT(NAPI_STATE_THREADED),
>> };
>>
>> enum gro_result {
>> @@ -2315,6 +2318,26 @@ static inline void *netdev_priv(const struct
>> net_device *dev)
>> void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
>> int (*poll)(struct napi_struct *, int), int weight);
>>
>> +/**
>> + * netif_threaded_napi_add - initialize a NAPI context
>> + * @dev: network device
>> + * @napi: NAPI context
>> + * @poll: polling function
>> + * @weight: default weight
>> + *
>> + * This variant of netif_napi_add() should be used from drivers using NAPI
>> + * with CPU intensive poll functions.
>> + * This will schedule polling from a high priority workqueue that
>> + */
>> +static inline void netif_threaded_napi_add(struct net_device *dev,
>> + struct napi_struct *napi,
>> + int (*poll)(struct napi_struct *,
>> int),
>> + int weight)
>> +{
>> +set_bit(NAPI_STATE_THREADED, &napi->state);
>> +netif_napi_add(dev, napi, poll, weight);
>> +}
>> +
>> /**
>> * netif_tx_napi_add - initialize a NAPI context
>> * @dev: network device
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -158,6 +158,7 @@ static DEFINE_SPINLOCK(offload_lock);
>> struct list_head ptype_base[PTYPE_HASH_SIZE] __read_mostly;
>> struct list_head ptype_all __read_mostly; /* Taps */
>> static struct list_head offload_base __read_mostly;
>> +static struct workqueue_struct *napi_workq;
>
> Is __read_mostly missing?
Yes, thanks. I will add that before sending the patch.
- Felix
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
