* [PATCH V2 1/3] mac80211: allow turning TWT responder support on and off via netlink
From: John Crispin @ 2019-04-26 9:41 UTC (permalink / raw)
To: Johannes Berg, Kalle Valo
Cc: Srini Kode, Rajkumar Manoharan, linux-wireless, ath11k,
John Crispin, Shashidhar Lakkavalli
In-Reply-To: <20190426094150.18078-1-john@phrozen.org>
Allow the userland daemon to en/disable TWT support for an AP.
Signed-off-by: Shashidhar Lakkavalli <slakkavalli@datto.com>
Signed-off-by: John Crispin <john@phrozen.org>
---
include/net/cfg80211.h | 2 ++
include/net/mac80211.h | 5 +++++
include/uapi/linux/nl80211.h | 4 ++++
net/mac80211/cfg.c | 6 ++++++
net/wireless/nl80211.c | 6 ++++++
5 files changed, 23 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index bb307a11ee63..8a20f5a42977 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1511,6 +1511,7 @@ struct mpath_info {
* (u16 = opmode, -1 = do not change)
* @p2p_ctwindow: P2P CT Window (-1 = no change)
* @p2p_opp_ps: P2P opportunistic PS (-1 = no change)
+ * @twt_responder: HE Target Wait Time support.
*/
struct bss_parameters {
int use_cts_prot;
@@ -1521,6 +1522,7 @@ struct bss_parameters {
int ap_isolate;
int ht_opmode;
s8 p2p_ctwindow, p2p_opp_ps;
+ int twt_responder;
};
/**
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index ac2ed8ec662b..87a6e149abda 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -317,6 +317,7 @@ struct ieee80211_vif_chanctx_switch {
* @BSS_CHANGED_MCAST_RATE: Multicast Rate setting changed for this interface
* @BSS_CHANGED_FTM_RESPONDER: fime timing reasurement request responder
* functionality changed for this BSS (AP mode).
+ * @BSS_CHANGED_TWT: TWT enable status changed
*
*/
enum ieee80211_bss_change {
@@ -347,6 +348,7 @@ enum ieee80211_bss_change {
BSS_CHANGED_KEEP_ALIVE = 1<<24,
BSS_CHANGED_MCAST_RATE = 1<<25,
BSS_CHANGED_FTM_RESPONDER = 1<<26,
+ BSS_CHANGED_TWT = 1<<27,
/* when adding here, make sure to change ieee80211_reconfig */
};
@@ -504,6 +506,8 @@ struct ieee80211_ftm_responder_params {
* @he_support: does this BSS support HE
* @twt_requester: does this BSS support TWT requester (relevant for managed
* mode only, set if the AP advertises TWT responder role)
+ * @twt_responder: does this BSS support TWT responder (relevant for AP
+ * mode only, set if the AP advertises TWT responder role)
* @assoc: association status
* @ibss_joined: indicates whether this station is part of an IBSS
* or not
@@ -611,6 +615,7 @@ struct ieee80211_bss_conf {
u16 frame_time_rts_th;
bool he_support;
bool twt_requester;
+ bool twt_responder;
/* association related data */
bool assoc, ibss_joined;
bool ibss_creator;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index dd4f86ee286e..ba1f69751a4a 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2308,6 +2308,8 @@ enum nl80211_commands {
* @NL80211_ATTR_AIRTIME_WEIGHT: Station's weight when scheduled by the airtime
* scheduler.
*
+ * @NL80211_ATTR_TWT_RESPONDER: Enable target wait time responder support.
+ *
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2759,6 +2761,8 @@ enum nl80211_attrs {
NL80211_ATTR_AIRTIME_WEIGHT,
+ NL80211_ATTR_TWT_RESPONDER,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 09dd1c2860fc..a66600bf9cef 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2176,6 +2176,12 @@ static int ieee80211_change_bss(struct wiphy *wiphy,
changed |= BSS_CHANGED_P2P_PS;
}
+ if (params->twt_responder >= 0) {
+ sdata->vif.bss_conf.twt_responder =
+ params->twt_responder;
+ changed |= BSS_CHANGED_TWT;
+ }
+
ieee80211_bss_info_change_notify(sdata, changed);
return 0;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 25a9e3b5c154..afd04a98a601 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -541,6 +541,7 @@ const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = {
[NL80211_ATTR_PEER_MEASUREMENTS] =
NLA_POLICY_NESTED(nl80211_pmsr_attr_policy),
[NL80211_ATTR_AIRTIME_WEIGHT] = NLA_POLICY_MIN(NLA_U16, 1),
+ [NL80211_ATTR_BSS_SHORT_PREAMBLE] = NLA_POLICY_RANGE(NLA_U8, 0, 1),
};
/* policy for the key attributes */
@@ -6105,6 +6106,7 @@ static int nl80211_set_bss(struct sk_buff *skb, struct genl_info *info)
params.ht_opmode = -1;
params.p2p_ctwindow = -1;
params.p2p_opp_ps = -1;
+ params.twt_responder = -1;
if (info->attrs[NL80211_ATTR_BSS_CTS_PROT])
params.use_cts_prot =
@@ -6149,6 +6151,10 @@ static int nl80211_set_bss(struct sk_buff *skb, struct genl_info *info)
return -EINVAL;
}
+ if (info->attrs[NL80211_ATTR_TWT_RESPONDER])
+ params.twt_responder =
+ nla_get_u8(info->attrs[NL80211_ATTR_TWT_RESPONDER]);
+
if (!rdev->ops->change_bss)
return -EOPNOTSUPP;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2 25/79] docs: convert docs to ReST and rename to *.rst
From: Mauro Carvalho Chehab @ 2019-04-26 9:46 UTC (permalink / raw)
To: Mark Brown
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Sebastian Reichel, Bjorn Helgaas,
Rafael J. Wysocki, Viresh Kumar, Len Brown, Pavel Machek,
Nishanth Menon, Stephen Boyd, Liam Girdwood, Mathieu Poirier,
Suzuki K Poulose, Harry Wei, Alex Shi, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, x86, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, David Airlie, Daniel Vetter,
Johannes Berg, David S. Miller, linux-pm, linux-pci,
linux-arm-kernel, intel-gfx, dri-devel, linux-wireless, netdev
In-Reply-To: <20190425180758.GC23183@sirena.org.uk>
Hi Mark,
Em Thu, 25 Apr 2019 19:07:58 +0100
Mark Brown <broonie@kernel.org> escreveu:
> On Mon, Apr 22, 2019 at 10:27:14AM -0300, Mauro Carvalho Chehab wrote:
> > Convert the PM documents to ReST, in order to allow them to
> > build with Sphinx.
>
> This is massively CCed covering a large range of subsystems and is patch
> 25 of a 79 patch series so I've no context for what's going on here or
> why...
There are two goals of this series:
1) to prepare for placing the new *.rst files under Documentation/ into an
index file, being part of one of the books. Most of the stuff covered
on this series either fit at the system admin guide or at the
Kernel API documentation book;
2) to ensure that, if some edition on a file would cause warnings at
Sphinx build, someone will notice and submit a followup patch.
You can see more details at patch 00/79:
https://lore.kernel.org/lkml/20190422115110.26443b44@coco.lan/
In order to do that, this series has one patch per Documentation/*
sub-directory. This specific one is for the documents under
Documentation/power/ [1].
[1] btw, the title of this specific patch should be, instead:
docs: power: convert docs to ReST and rename to *.rst
The series is long because I'm trying to cover a significant part
of the documentation files. In any case, except if an eventual
conflict might rise on some file, this patch is independent from
all other files, and should be safe to apply directly via the
subsystem git tree.
I'm working on a follow-up patch series that should be adding the
power/index.rst file into another index file - probably at
Documentation/index.rst[1]. As such patch will be adding a lot of other
index files, the best would be to merge it via the docs tree, in
order to avoid conflicts.
[1] such patch will be removing the ":orphan:" meta-tag from it
(that basically tells the build system to not produce warnings if
the file is not directly or indirectly referenced by the main
index file).
Thanks,
Mauro
^ permalink raw reply
* [ANN] resend patches or respond to 0-day reports
From: Johannes Berg @ 2019-04-26 9:48 UTC (permalink / raw)
To: linux-wireless
Hi all,
Just in case it wasn't clear already - if you get a 0-day report with
something that's trivially fixed (like missing documentation etc.)
please resend the patches immediately.
I'd rather have a resend than to comment and then wait later for both
changes, or to have to double-check that those things were later
addressed (or wait for 0-day again).
Thanks,
johannes
^ permalink raw reply
* [PATCH] cfg80211: Handle bss expiry during connection
From: chaitanya.mgit @ 2019-04-26 9:54 UTC (permalink / raw)
To: linux-wireless; +Cc: Chaitanya Tata
From: Chaitanya Tata <chaitanya.tata@bluwireless.co.uk>
If the BSS is expired during connection, the connect result will
trigger a kernel warning. Ideally cfg80211 should hold the BSS
before the connection is attempted, but as the BSSID is not known
in case of auth/assoc MLME offload (connect op) it doesn't.
For those drivers without the connect op cfg80211 holds down the
reference so it wil not be removed from list.
Fix this by removing the warning and silently adding the BSS back to
the bss list which is return by the driver (with proper BSSID set).
The requirements for drivers are documented in the API's.
Signed-off-by: Chaitanya Tata <chaitanya.tata@bluwireless.co.uk>
---
Tested this using the below hack in cfg80211_connect_done():
cfg80211_bss_age(rdev, get_seconds() - 30);
cfg80211_bss_expire(rdev);
---
include/net/cfg80211.h | 13 ++++++++++---
net/wireless/core.h | 5 +++++
net/wireless/scan.c | 2 +-
net/wireless/sme.c | 13 ++++++++-----
4 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index bb307a11ee63..91fee5ab2433 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -6137,8 +6137,12 @@ struct cfg80211_fils_resp_params {
* case.
* @bssid: The BSSID of the AP (may be %NULL)
* @bss: Entry of bss to which STA got connected to, can be obtained through
- * cfg80211_get_bss() (may be %NULL). Only one parameter among @bssid and
- * @bss needs to be specified.
+ * cfg80211_get_bss() (may be %NULL) but it is recommended to store the
+ * bss from the connect_request and hold a reference to it and return
+ * through this param to avoid warning if the bss is expired during the
+ * connection, esp. for those drivers implementing connect op.
+ * Only one parameter among @bssid and @bss needs to be specified.
+
* @req_ie: Association request IEs (may be %NULL)
* @req_ie_len: Association request IEs length
* @resp_ie: Association response IEs (may be %NULL)
@@ -6187,7 +6191,10 @@ void cfg80211_connect_done(struct net_device *dev,
* @dev: network device
* @bssid: the BSSID of the AP
* @bss: entry of bss to which STA got connected to, can be obtained
- * through cfg80211_get_bss (may be %NULL)
+ * through cfg80211_get_bss (may be %NULL), but it is recommended to store
+ * the bss from the connect_request and hold a reference to it and return
+ * through this param to avoid warning if the bss is expired during the
+ * connection, esp. for those drivers implementing connect op.
* @req_ie: association request IEs (maybe be %NULL)
* @req_ie_len: association request IEs length
* @resp_ie: association response IEs (may be %NULL)
diff --git a/net/wireless/core.h b/net/wireless/core.h
index 84d36ca7a7ab..7ad461845d07 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -531,6 +531,11 @@ void cfg80211_stop_p2p_device(struct cfg80211_registered_device *rdev,
void cfg80211_stop_nan(struct cfg80211_registered_device *rdev,
struct wireless_dev *wdev);
+struct cfg80211_internal_bss *
+cfg80211_bss_update(struct cfg80211_registered_device *rdev,
+ struct cfg80211_internal_bss *tmp,
+ bool signal_valid);
+
#ifdef CONFIG_CFG80211_DEVELOPER_WARNINGS
#define CFG80211_DEV_WARN_ON(cond) WARN_ON(cond)
#else
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 287518c6caa4..0f5ae54c7644 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -1035,7 +1035,7 @@ struct cfg80211_non_tx_bss {
};
/* Returned bss is reference counted and must be cleaned up appropriately. */
-static struct cfg80211_internal_bss *
+struct cfg80211_internal_bss *
cfg80211_bss_update(struct cfg80211_registered_device *rdev,
struct cfg80211_internal_bss *tmp,
bool signal_valid)
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index 7d34cb884840..6881d0b151b2 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -795,14 +795,17 @@ void cfg80211_connect_done(struct net_device *dev,
unsigned long flags;
u8 *next;
+ /* bss is not NULL, so even though bss might have expired, the driver
+ * is still holding a reference to it.
+ */
if (params->bss) {
- /* Make sure the bss entry provided by the driver is valid. */
struct cfg80211_internal_bss *ibss = bss_from_pub(params->bss);
- if (WARN_ON(list_empty(&ibss->list))) {
- cfg80211_put_bss(wdev->wiphy, params->bss);
- return;
- }
+ /* Meanwhile if BSS is expired then add it back to the list as
+ * we have just connected with it.
+ */
+ if (list_empty(&ibss->list))
+ cfg80211_bss_update(rdev, ibss, ibss->pub.signal);
}
ev = kzalloc(sizeof(*ev) + (params->bssid ? ETH_ALEN : 0) +
--
2.17.1
^ permalink raw reply related
* Re: [PATCHv4 0/2] cfg80211/mac80211: Add support to configure and monitor station's rssi threshold
From: Johannes Berg @ 2019-04-26 10:03 UTC (permalink / raw)
To: Tamizh chelvam; +Cc: linux-wireless
In-Reply-To: <1555492880-26457-1-git-send-email-tamizhr@codeaurora.org>
On Wed, 2019-04-17 at 14:51 +0530, Tamizh chelvam wrote:
> This patchsets introduced new NL command and api to support
> configuring rssi for the connected stations and api to notify
> userspace application upon crossing the configured threshold.
> This will be useful for the application which requires
> station's current signal strength change information.
What is "the application"?
Given all our discussions at the summit and my thinking on all of this
recently, I'm _very_ tempted to just reject this patchset after all, and
ask you to (help) implement appropriate eBPF hooks in the stack that can
be used to implement it instead.
Why is this better than programmable infrastructure for it?
johannes
^ permalink raw reply
* Re: [PATCHv4 2/2] mac80211: Implement API to configure station specific rssi threshold
From: Johannes Berg @ 2019-04-26 10:04 UTC (permalink / raw)
To: Tamizh chelvam; +Cc: linux-wireless
In-Reply-To: <1555492880-26457-3-git-send-email-tamizhr@codeaurora.org>
> +void ieee80211_update_rssi_config(struct sta_info *sta)
> +{
> + s32 last;
> + u32 hyst;
> + int i, n;
> +
> + if (!sta->rssi_config || sta->rssi_config->fixed_thold)
> + return;
sparse is also giving various complaints about the RCU usage here.
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: Handle bss expiry during connection
From: Johannes Berg @ 2019-04-26 10:14 UTC (permalink / raw)
To: chaitanya.mgit, linux-wireless; +Cc: Chaitanya Tata
In-Reply-To: <20190426095448.3169-1-chaitanya.mgit@gmail.com>
On Fri, 2019-04-26 at 15:24 +0530, chaitanya.mgit@gmail.com wrote:
> From: Chaitanya Tata <chaitanya.tata@bluwireless.co.uk>
>
> If the BSS is expired during connection, the connect result will
> trigger a kernel warning. Ideally cfg80211 should hold the BSS
> before the connection is attempted, but as the BSSID is not known
> in case of auth/assoc MLME offload (connect op) it doesn't.
>
> For those drivers without the connect op cfg80211 holds down the
> reference so it wil not be removed from list.
>
> Fix this by removing the warning and silently adding the BSS back to
> the bss list which is return by the driver (with proper BSSID set).
> The requirements for drivers are documented in the API's.
This looks good, mostly :-)
> * @bssid: The BSSID of the AP (may be %NULL)
> * @bss: Entry of bss to which STA got connected to, can be obtained through
> - * cfg80211_get_bss() (may be %NULL). Only one parameter among @bssid and
> - * @bss needs to be specified.
> + * cfg80211_get_bss() (may be %NULL) but it is recommended to store the
> + * bss from the connect_request and hold a reference to it and return
> + * through this param to avoid warning if the bss is expired during the
> + * connection, esp. for those drivers implementing connect op.
> + * Only one parameter among @bssid and @bss needs to be specified.
So while we're at it, we should probably amend the documentation to say
that the reference to the BSS passes from the driver to cfg80211, right?
> + /* bss is not NULL, so even though bss might have expired, the driver
> + * is still holding a reference to it.
> + */
is -> was? It's our reference now.
> if (params->bss) {
> - /* Make sure the bss entry provided by the driver is valid. */
> struct cfg80211_internal_bss *ibss = bss_from_pub(params->bss);
>
> - if (WARN_ON(list_empty(&ibss->list))) {
> - cfg80211_put_bss(wdev->wiphy, params->bss);
That's why we had a put_bss() here.
> + /* Meanwhile if BSS is expired then add it back to the list as
> + * we have just connected with it.
> + */
> + if (list_empty(&ibss->list))
> + cfg80211_bss_update(rdev, ibss, ibss->pub.signal);
But I think this adds *another* reference, which is wrong? We do need
one reference (the original one the driver gave us) but not a second
one?
Also, not sure the last argument (signal_valid) is right?
Basically all that really just means that cfg80211_bss_update() is
probably not the right function to call. It also updates the timestamp,
which is not true, we haven't received updated information we just used
it and thus held on to it.
I think we should probably just instead of a "cfg80211_bss_relink()"
function exposed, and that just does something like
list_add_tail(&new->list, &rdev->bss_list);
rdev->bss_entries++;
rb_insert_bss(rdev, new);
rdev->bss_generation++;
though I'm not - off the top of my head - sure about
cfg80211_combine_bsses() being needed or not.
Maybe the copy we do in cfg80211_bss_update() isn't so bad, but then I'd
probably expose it without the signal_valid part and signal/timestamp
updates, and just copy the information raw there? However, the "if
(found)" part should never be possible here, right? Actually, maybe it
is, if we got a *new* entry in the meantime, but then we'd override the
newer information with the older, which is kinda bad?
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: Handle bss expiry during connection
From: Krishna Chaitanya @ 2019-04-26 10:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Chaitanya Tata
In-Reply-To: <cb1c3fcafc7addf0ed8d8d946658801472ad8a1b.camel@sipsolutions.net>
On Fri, Apr 26, 2019 at 3:44 PM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> On Fri, 2019-04-26 at 15:24 +0530, chaitanya.mgit@gmail.com wrote:
> > From: Chaitanya Tata <chaitanya.tata@bluwireless.co.uk>
> >
> > If the BSS is expired during connection, the connect result will
> > trigger a kernel warning. Ideally cfg80211 should hold the BSS
> > before the connection is attempted, but as the BSSID is not known
> > in case of auth/assoc MLME offload (connect op) it doesn't.
> >
> > For those drivers without the connect op cfg80211 holds down the
> > reference so it wil not be removed from list.
> >
> > Fix this by removing the warning and silently adding the BSS back to
> > the bss list which is return by the driver (with proper BSSID set).
> > The requirements for drivers are documented in the API's.
>
> This looks good, mostly :-)
>
> > * @bssid: The BSSID of the AP (may be %NULL)
> > * @bss: Entry of bss to which STA got connected to, can be obtained through
> > - * cfg80211_get_bss() (may be %NULL). Only one parameter among @bssid and
> > - * @bss needs to be specified.
> > + * cfg80211_get_bss() (may be %NULL) but it is recommended to store the
> > + * bss from the connect_request and hold a reference to it and return
> > + * through this param to avoid warning if the bss is expired during the
> > + * connection, esp. for those drivers implementing connect op.
> > + * Only one parameter among @bssid and @bss needs to be specified.
>
> So while we're at it, we should probably amend the documentation to say
> that the reference to the BSS passes from the driver to cfg80211, right?
Yes
>
> > + /* bss is not NULL, so even though bss might have expired, the driver
> > + * is still holding a reference to it.
> > + */
>
> is -> was? It's our reference now.
Yes
>
> > if (params->bss) {
> > - /* Make sure the bss entry provided by the driver is valid. */
> > struct cfg80211_internal_bss *ibss = bss_from_pub(params->bss);
> >
> > - if (WARN_ON(list_empty(&ibss->list))) {
> > - cfg80211_put_bss(wdev->wiphy, params->bss);
>
> That's why we had a put_bss() here.
I will add a change to put bss after we update.
>
> > + /* Meanwhile if BSS is expired then add it back to the list as
> > + * we have just connected with it.
> > + */
> > + if (list_empty(&ibss->list))
> > + cfg80211_bss_update(rdev, ibss, ibss->pub.signal);
>
> But I think this adds *another* reference, which is wrong? We do need
> one reference (the original one the driver gave us) but not a second
> one?
This was assuming found will be false so refcnt will be reset and a fresh ref
is taken.
> Also, not sure the last argument (signal_valid) is right?
>
> Basically all that really just means that cfg80211_bss_update() is
> probably not the right function to call. It also updates the timestamp,
> which is not true, we haven't received updated information we just used
> it and thus held on to it.
>
> I think we should probably just instead of a "cfg80211_bss_relink()"
> function exposed, and that just does something like
>
> list_add_tail(&new->list, &rdev->bss_list);
> rdev->bss_entries++;
> rb_insert_bss(rdev, new);
>
> rdev->bss_generation++;
>
> though I'm not - off the top of my head - sure about
> cfg80211_combine_bsses() being needed or not.
>
> Maybe the copy we do in cfg80211_bss_update() isn't so bad, but then I'd
> probably expose it without the signal_valid part and signal/timestamp
> updates, and just copy the information raw there? However, the "if
> (found)" part should never be possible here, right? Actually, maybe it
> is, if we got a *new* entry in the meantime, but then we'd override the
> newer information with the older, which is kinda bad?
If we get new information (scan during connection) the bss would not have
expired right? so this code will not be triggered.
My initial stab was in similar lines, something like below: But as the
bss is expired
we need to udpate ts, signal and other fields anyway, so I went ahead
with full update.
+void cfg80211_add_expired_bss(struct cfg80211_registered_device *rdev,
+ struct cfg80211_internal_bss *new)
+{
+ if (!new)
+ return;
+
+ spin_lock_bh(&rdev->bss_lock);
+ new->ts = jiffies
+ list_add_tail(&new->list, &rdev->bss_list);
+ rdev->bss_entries++;
+
+ rb_insert_bss(rdev, new);
+ rdev->bss_generation++;
+
+ bss_ref_get(rdev, new);
+
+ spin_unlock_bh(&rdev->bss_lock);
+}
> johannes
>
--
Thanks,
Regards,
Chaitanya T K.
^ permalink raw reply
* Re: [PATCH] cfg80211: Handle bss expiry during connection
From: Johannes Berg @ 2019-04-26 10:45 UTC (permalink / raw)
To: Krishna Chaitanya; +Cc: linux-wireless, Chaitanya Tata
In-Reply-To: <CABPxzYK3MuJT=r3o6UgBqv-m1B2pqCACwq+i1DDRkC2ZHExvxQ@mail.gmail.com>
On Fri, 2019-04-26 at 16:05 +0530, Krishna Chaitanya wrote:
> > > + /* Meanwhile if BSS is expired then add it back to the list as
> > > + * we have just connected with it.
> > > + */
> > > + if (list_empty(&ibss->list))
> > > + cfg80211_bss_update(rdev, ibss, ibss->pub.signal);
> >
> > But I think this adds *another* reference, which is wrong? We do need
> > one reference (the original one the driver gave us) but not a second
> > one?
>
> This was assuming found will be false so refcnt will be reset and a fresh ref
> is taken.
Yes, it actually adds a new entry entirely, not refs the old entry. But
then you have a new entry returned from cfg80211_bss_update() with a
reference, and leak that reference in the code as written.
You probably need to unref the old one, and keep the new one to pass on
to the next function etc.
> > Maybe the copy we do in cfg80211_bss_update() isn't so bad, but then I'd
> > probably expose it without the signal_valid part and signal/timestamp
> > updates, and just copy the information raw there? However, the "if
> > (found)" part should never be possible here, right? Actually, maybe it
> > is, if we got a *new* entry in the meantime, but then we'd override the
> > newer information with the older, which is kinda bad?
>
> If we get new information (scan during connection) the bss would not have
> expired right? so this code will not be triggered.
It could have expired and been re-added, no? Ok, I'll admit that's a
stretch since the driver is busy connecting and not scanning, but I
suppose it could happen with multiple VIFs etc?
> My initial stab was in similar lines, something like below: But as the
> bss is expired
> we need to udpate ts, signal and other fields anyway, so I went ahead
> with full update.
Why would we want to update ts, signal etc.? We just keep the old
information, and then the entry will be held for the duration of the
connection, presumably it'll get new updates while you're connected.
> +void cfg80211_add_expired_bss(struct cfg80211_registered_device *rdev,
> + struct cfg80211_internal_bss *new)
> +{
> + if (!new)
> + return;
> +
> + spin_lock_bh(&rdev->bss_lock);
> + new->ts = jiffies
> + list_add_tail(&new->list, &rdev->bss_list);
> + rdev->bss_entries++;
> +
> + rb_insert_bss(rdev, new);
> + rdev->bss_generation++;
> +
> + bss_ref_get(rdev, new);
> +
> + spin_unlock_bh(&rdev->bss_lock);
> +}
Yeah, I was thinking along those lines too, except there's a bit of an
issue with the hidden and non-transmitting lists?
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: Handle bss expiry during connection
From: Krishna Chaitanya @ 2019-04-26 10:56 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Chaitanya Tata
In-Reply-To: <d569a6171e50a8bdb026a2ec86c78268c9d7e989.camel@sipsolutions.net>
On Fri, Apr 26, 2019 at 4:15 PM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> On Fri, 2019-04-26 at 16:05 +0530, Krishna Chaitanya wrote:
>
> > > > + /* Meanwhile if BSS is expired then add it back to the list as
> > > > + * we have just connected with it.
> > > > + */
> > > > + if (list_empty(&ibss->list))
> > > > + cfg80211_bss_update(rdev, ibss, ibss->pub.signal);
> > >
> > > But I think this adds *another* reference, which is wrong? We do need
> > > one reference (the original one the driver gave us) but not a second
> > > one?
> >
> > This was assuming found will be false so refcnt will be reset and a fresh ref
> > is taken.
>
> Yes, it actually adds a new entry entirely, not refs the old entry. But
> then you have a new entry returned from cfg80211_bss_update() with a
> reference, and leak that reference in the code as written.
>
> You probably need to unref the old one, and keep the new one to pass on
> to the next function etc.
>
Right, we should unref after the update.
> > > Maybe the copy we do in cfg80211_bss_update() isn't so bad, but then I'd
> > > probably expose it without the signal_valid part and signal/timestamp
> > > updates, and just copy the information raw there? However, the "if
> > > (found)" part should never be possible here, right? Actually, maybe it
> > > is, if we got a *new* entry in the meantime, but then we'd override the
> > > newer information with the older, which is kinda bad?
> >
> > If we get new information (scan during connection) the bss would not have
> > expired right? so this code will not be triggered.
>
> It could have expired and been re-added, no? Ok, I'll admit that's a
> stretch since the driver is busy connecting and not scanning, but I
> suppose it could happen with multiple VIFs etc?
Yes, it might be possible with multiple VIF's, when one VIF is connecting
and other VIF is scanning, it can find the connecting bssid in its scan results.
> > My initial stab was in similar lines, something like below: But as the
> > bss is expired
> > we need to udpate ts, signal and other fields anyway, so I went ahead
> > with full update.
>
> Why would we want to update ts, signal etc.? We just keep the old
> information, and then the entry will be held for the duration of the
> connection, presumably it'll get new updates while you're connected.
If we are holding it, then we will not be using ts anyway, so updating or
not should not matter. But as its old info better to leave it that way, and
update these fields only from scan results.
> > +void cfg80211_add_expired_bss(struct cfg80211_registered_device *rdev,
> > + struct cfg80211_internal_bss *new)
> > +{
> > + if (!new)
> > + return;
> > +
> > + spin_lock_bh(&rdev->bss_lock);
> > + new->ts = jiffies
> > + list_add_tail(&new->list, &rdev->bss_list);
> > + rdev->bss_entries++;
> > +
> > + rb_insert_bss(rdev, new);
> > + rdev->bss_generation++;
> > +
> > + bss_ref_get(rdev, new);
> > +
> > + spin_unlock_bh(&rdev->bss_lock);
> > +}
>
> Yeah, I was thinking along those lines too, except there's a bit of an
> issue with the hidden and non-transmitting lists?
Ok, let me think for a bit and will send you V2. Thanks for quick review.
> johannes
>
--
Thanks,
Regards,
Chaitanya T K.
^ permalink raw reply
* pull-request: mac80211-next 2019-04-26
From: Johannes Berg @ 2019-04-26 11:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
And another set for -next, not that big this time.
See below for a summary of the highlights.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 1f17f7742eeba73dbd5ae8bdec1a85ce5877001e:
net: sched: flower: insert filter to ht before offloading it to hw (2019-04-07 19:33:07 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2019-04-26
for you to fetch changes up to 8828f81ad4a2f4e89ebe6e7793c06ed767c31d53:
mac80211: probe unexercised mesh links (2019-04-26 13:02:11 +0200)
----------------------------------------------------------------
Various updates, notably:
* extended key ID support (from 802.11-2016)
* per-STA TX power control support
* mac80211 TX performance improvements
* HE (802.11ax) updates
* mesh link probing support
* enhancements of multi-BSSID support (also related to HE)
* OWE userspace processing support
----------------------------------------------------------------
Alexander Wetzel (6):
mac80211: Optimize tailroom_needed update checks
nl80211/cfg80211: Extended Key ID support
mac80211: IEEE 802.11 Extended Key ID support
mac80211: Fix Extended Key ID auto activation
mac80211_hwsim: Extended Key ID support
mac80211: Set CAN_REPLACE_PTK0 for SW crypto only drivers
Ashok Raj Nagarajan (2):
cfg80211: Add support to set tx power for a station associated
mac80211: store tx power value from user to station
Avraham Stern (1):
mac80211_hwsim: set p2p device interface support indication
Colin Ian King (1):
cfg80211: remove redundant zero check on variable 'changed'
Dan Carpenter (1):
cfg80211: don't pass pointer to pointer unnecessarily
Felix Fietkau (7):
mac80211: mesh: drop redundant rcu_read_lock/unlock calls
mac80211: calculate hash for fq without holding fq->lock in itxq enqueue
mac80211: run late dequeue late tx handlers without holding fq->lock
mac80211: set NETIF_F_LLTX when using intermediate tx queues
mac80211: when using iTXQ, select the queue in ieee80211_subif_start_xmit
mac80211: minstrel_ht: add support for rates with 4 spatial streams
mac80211: minstrel_ht: automatically calculate rate duration shift
Gustavo A. R. Silva (2):
cfg80211: Use struct_size() in kzalloc()
nl80211: Use struct_size() in kzalloc()
Johannes Berg (2):
nl80211: reindent some sched scan code
mac80211: only allocate one queue when using iTXQs
Julius Niedworok (1):
mac80211: debugfs option to force TX status frames
Liad Kaufman (1):
ieee80211: update HE IEs to D4.0 spec
Luca Coelho (1):
nl80211: do a struct assignment to radar_chandef instead of memcpy()
Narayanraddi Masti (1):
mac80211: Add support for NL80211_STA_INFO_AIRTIME_LINK_METRIC
Rajkumar Manoharan (3):
cfg80211: add support to probe unexercised mesh link
mac80211: add option for setting control flags
mac80211: probe unexercised mesh links
Sara Sharon (5):
cfg80211: don't skip multi-bssid index element
cfg80211: support non-inheritance element
mac80211: support non-inheritance element
cfg80211: support profile split between elements
mac80211: support profile split between elements
Sergey Matyukevich (1):
mac80211/cfg80211: update bss channel on channel switch
Shaul Triebitz (1):
nl80211: increase NL80211_MAX_SUPP_REG_RULES
Sunil Dutt (1):
cfg80211/nl80211: Offload OWE processing to user space in AP mode
vamsi krishna (1):
nl80211/cfg80211: Specify band specific min RSSI thresholds with sched scan
drivers/net/wireless/mac80211_hwsim.c | 8 +
include/linux/ieee80211.h | 14 +-
include/net/cfg80211.h | 104 +++++++++++
include/net/fq_impl.h | 18 +-
include/net/mac80211.h | 30 +++
include/uapi/linux/nl80211.h | 86 ++++++++-
net/mac80211/cfg.c | 46 +++++
net/mac80211/debugfs.c | 54 ++++++
net/mac80211/driver-ops.c | 21 +++
net/mac80211/driver-ops.h | 5 +
net/mac80211/ieee80211_i.h | 9 +-
net/mac80211/iface.c | 11 +-
net/mac80211/key.c | 87 ++++++---
net/mac80211/key.h | 2 +
net/mac80211/main.c | 16 ++
net/mac80211/mesh.h | 2 +
net/mac80211/mesh_hwmp.c | 34 ++--
net/mac80211/mesh_pathtbl.c | 2 +-
net/mac80211/mlme.c | 3 -
net/mac80211/rc80211_minstrel_ht.c | 124 ++++++++-----
net/mac80211/rc80211_minstrel_ht.h | 2 +-
net/mac80211/rx.c | 74 ++++----
net/mac80211/sta_info.c | 15 ++
net/mac80211/tdls.c | 2 +-
net/mac80211/trace.h | 30 +++
net/mac80211/tx.c | 113 +++++++++---
net/mac80211/util.c | 162 ++++++++++-------
net/mac80211/wme.c | 82 +++++----
net/mac80211/wme.h | 2 +
net/wireless/nl80211.c | 331 +++++++++++++++++++++++++++++-----
net/wireless/rdev-ops.h | 29 ++-
net/wireless/reg.c | 23 +--
net/wireless/scan.c | 173 +++++++++++++++++-
net/wireless/trace.h | 87 ++++++++-
net/wireless/util.c | 21 ++-
net/wireless/wext-compat.c | 3 -
36 files changed, 1465 insertions(+), 360 deletions(-)
^ permalink raw reply
* Re: [wireless-drivers-next:master 28/45] drivers/net/wireless/rsi/rsi_91x_usb.c:229:27: sparse: restricted __le32 degrades to integer
From: Siva Rebbagondla @ 2019-04-26 11:34 UTC (permalink / raw)
To: Kalle Valo; +Cc: kbuild test robot, kbuild-all, Linux Wireless
In-Reply-To: <875zr1wi3z.fsf@kamboji.qca.qualcomm.com>
Hi Kalle,
On Fri, Apr 26, 2019 at 9:09 AM Kalle Valo <kvalo@codeaurora.org> wrote:
>
> + linux-wireless
>
> Siva Rebbagondla <siva8118@gmail.com> writes:
>
> > Hi Kalle,
> >
> > On Fri, Apr 26, 2019 at 1:06 AM kbuild test robot <lkp@intel.com> wrote:
> >>
> >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git master
> >> head: 147b502bda338f4f2dff19faaa5829b691305ea5
> >> commit: 0a60014b76f512f18e48cfb4efc71e07c6791996 [28/45] rsi: miscallaneous changes for 9116 and common
> >> reproduce:
> >> # apt-get install sparse
> >> git checkout 0a60014b76f512f18e48cfb4efc71e07c6791996
> >> make ARCH=x86_64 allmodconfig
> >> make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
> >>
> >> If you fix the issue, kindly add following tag
> >> Reported-by: kbuild test robot <lkp@intel.com>
> >>
> >>
> >> sparse warnings: (new ones prefixed by >>)
> >>
> >> >> drivers/net/wireless/rsi/rsi_91x_usb.c:229:27: sparse: restricted __le32 degrades to integer
> >> drivers/net/wireless/rsi/rsi_91x_usb.c:230:27: sparse: restricted __le32 degrades to integer
> >> drivers/net/wireless/rsi/rsi_91x_usb.c:231:27: sparse: restricted __le32 degrades to integer
> >> drivers/net/wireless/rsi/rsi_91x_usb.c:232:27: sparse: restricted __le32 degrades to integer
> >> drivers/net/wireless/rsi/rsi_91x_usb.c:238:36: sparse: restricted __le32 degrades to integer
> >> drivers/net/wireless/rsi/rsi_91x_usb.c:239:35: sparse: restricted __le32 degrades to integer
> >> drivers/net/wireless/rsi/rsi_91x_usb.c:354:28: sparse: expression using sizeof(void)
> >> drivers/net/wireless/rsi/rsi_91x_usb.c:401:28: sparse: expression using sizeof(void)
> >>
> >> vim +229 drivers/net/wireless/rsi/rsi_91x_usb.c
> >>
> >> 203
> >> 204 /**
> >> 205 * rsi_usb_reg_write() - This function writes the given data into the given
> >> 206 * register address.
> >> 207 * @usbdev: Pointer to the usb_device structure.
> >> 208 * @reg: Address of the register.
> >> 209 * @value: Value to write.
> >> 210 * @len: Length of data to be written.
> >> 211 *
> >> 212 * Return: status: 0 on success, a negative error code on failure.
> >> 213 */
> >> 214 static int rsi_usb_reg_write(struct usb_device *usbdev,
> >> 215 u32 reg,
> >> 216 u32 value,
> >> 217 u16 len)
> >> 218 {
> >> 219 u8 *usb_reg_buf;
> >> 220 int status = -ENOMEM;
> >> 221
> >> 222 if (len > RSI_USB_CTRL_BUF_SIZE)
> >> 223 return -EINVAL;
> >> 224
> >> 225 usb_reg_buf = kmalloc(RSI_USB_CTRL_BUF_SIZE, GFP_KERNEL);
> >> 226 if (!usb_reg_buf)
> >> 227 return status;
> >> 228
> >> > 229 usb_reg_buf[0] = (cpu_to_le32(value) & 0x00ff);
> >> 230 usb_reg_buf[1] = (cpu_to_le32(value) & 0xff00) >> 8;
> >> 231 usb_reg_buf[2] = (cpu_to_le32(value) & 0x00ff0000) >> 16;
> >> 232 usb_reg_buf[3] = (cpu_to_le32(value) & 0xff000000) >> 24;
> >> 233
> >> 234 status = usb_control_msg(usbdev,
> >> 235 usb_sndctrlpipe(usbdev, 0),
> >> 236 USB_VENDOR_REGISTER_WRITE,
> >> 237 RSI_USB_REQ_OUT,
> >> 238 ((cpu_to_le32(reg) & 0xffff0000) >> 16),
> >> 239 (cpu_to_le32(reg) & 0xffff),
> >> 240 (void *)usb_reg_buf,
> >> 241 len,
> >> 242 USB_CTRL_SET_TIMEOUT);
> >> 243 if (status < 0) {
> >> 244 rsi_dbg(ERR_ZONE,
> >> 245 "%s: Reg write failed with error code :%d\n",
> >> 246 __func__, status);
> >> 247 }
> >> 248 kfree(usb_reg_buf);
> >> 249
> >> 250 return status;
> >> 251 }
> >> 252
> >>
> >> ---
> >> 0-DAY kernel test infrastructure Open Source Technology Center
> >> https://lists.01.org/pipermail/kbuild-all Intel Corporation
> >
> > Some where went wrong. I fixed this one. I will resend you the patches
> > with changes.
>
> Your patches are now applied and cannot be changed, so no point of
> resending them anymore. You need to send followup patches which fix the
> issues and apply to wireless-drivers-next.
>
> And remember to use Fixes tag so that we know which commit patch fixes.
Sure. I will send a patch which fixes this.
Best regards,
Siva Rebbagondla
^ permalink raw reply
* Re: [PATCH] net: wireless: fix missing checks for ioremap
From: Kalle Valo @ 2019-04-26 11:48 UTC (permalink / raw)
To: Kangjie Lu
Cc: kjlu, pakki001, David S. Miller, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20190311075440.1513-1-kjlu@umn.edu>
Kangjie Lu <kjlu@umn.edu> wrote:
> ioremap could fail and returns NULL. The fix actively checks
> its return value and handles potential failures.
>
> Signed-off-by: Kangjie Lu <kjlu@umn.edu>
The prefix should be "ray_cs: ":
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#commit_title_is_wrong
Also I don't see the point of setting the ret variable as it's ignored in the failed label:
failed:
ray_release(link);
return -ENODEV;
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/10846851/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] net: ath: fix missing checks for bmi reads and writes
From: Kalle Valo @ 2019-04-26 11:51 UTC (permalink / raw)
To: Kangjie Lu
Cc: netdev, linux-wireless, linux-kernel, ath10k, pakki001,
David S. Miller
In-Reply-To: <20190315051903.10664-1-kjlu@umn.edu>
Kangjie Lu <kjlu@umn.edu> writes:
> ath10k_bmi_write32 and ath10k_bmi_read32 can fail. The fix
> checks their statuses to avoid potential undefined behaviors.
>
> Signed-off-by: Kangjie Lu <kjlu@umn.edu>
[...]
> @@ -2500,8 +2515,15 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
> if (status)
> goto err;
>
> - if (ar->hif.bus == ATH10K_BUS_SDIO)
> - ath10k_init_sdio(ar);
> + if (ar->hif.bus == ATH10K_BUS_SDIO) {
> + status = ath10k_init_sdio(ar);
> + if (status) {
> + ath10k_err(ar,
> + "could not init HTC (%d)\n",
> + status);
I'll fix the warning message as well, we are not initialisating HTC
here.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/3] qtnfmac: handle channel switch events for connected stations only
From: Kalle Valo @ 2019-04-26 11:53 UTC (permalink / raw)
To: Sergey Matyukevich
Cc: linux-wireless@vger.kernel.org, Igor Mitsyanko,
Sergey Matyukevich
In-Reply-To: <20190409073500.16402-2-sergey.matyukevich.os@quantenna.com>
Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> wrote:
> Channel switch events from firmware should be processed only when STA
> is already connected to BSS. On connect this notification is not needed
> since full BSS info will be supplied by cfg80211_connect_result.
>
> Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
3 patches applied to wireless-drivers-next.git, thanks.
4f87d486faf1 qtnfmac: handle channel switch events for connected stations only
888f1564a272 qtnfmac: allow to control DFS slave radar detection
0b68fe10b8e8 qtnfmac: modify debugfs to support multiple cards
--
https://patchwork.kernel.org/patch/10890667/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mwl8k: move spin_lock_bh to spin_lock in tasklet
From: Kalle Valo @ 2019-04-26 11:57 UTC (permalink / raw)
To: Jeff Xie; +Cc: buytenh, davem, chongguiguzi, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1553012645-28989-1-git-send-email-chongguiguzi@gmail.com>
Jeff Xie <chongguiguzi@gmail.com> wrote:
> It is unnecessary to call spin_lock_bh in a tasklet.
>
> Signed-off-by: Jeff Xie <chongguiguzi@gmail.com>
Patch applied to wireless-drivers-next.git, thanks.
0b2ff1ff64c8 mwl8k: move spin_lock_bh to spin_lock in tasklet
--
https://patchwork.kernel.org/patch/10859991/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rtlwifi: rtl8192cu: remove set but not used variable 'turbo_scanoff'
From: Kalle Valo @ 2019-04-26 11:59 UTC (permalink / raw)
To: Yue Haibing
Cc: pkshih, Larry.Finger, linux-kernel, netdev, linux-wireless, davem,
YueHaibing
In-Reply-To: <20190423143214.39392-1-yuehaibing@huawei.com>
Yue Haibing <yuehaibing@huawei.com> wrote:
> From: YueHaibing <yuehaibing@huawei.com>
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c: In function 'rtl92cu_phy_rf6052_set_cck_txpower':
> drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c:45:7: warning: variable 'turbo_scanoff' set but not used [-Wunused-but-set-variable]
>
> It is not used any more since
> commit e9b0784bb9de ("rtlwifi: rtl8192cu: Fix some code in RF handling")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
a0656c6ec2fd rtlwifi: rtl8192cu: remove set but not used variable 'turbo_scanoff'
--
https://patchwork.kernel.org/patch/10913203/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v3] brcmfmac: send mailbox interrupt twice for specific hardware device
From: Kalle Valo @ 2019-04-26 12:01 UTC (permalink / raw)
To: Wright Feng
Cc: arend.vanspriel@broadcom.com, franky.lin@broadcom.com,
hante.meuleman@broadcom.com, Chi-Hsien Lin, Wright Feng,
linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com
In-Reply-To: <1556248345-146837-1-git-send-email-wright.feng@cypress.com>
Wright Feng <Wright.Feng@cypress.com> wrote:
> For PCIE wireless device with core revision less than 14, device may miss
> PCIE to System Backplane Interrupt via PCIEtoSBMailbox. So add sending
> mail box interrupt twice as a hardware workaround.
>
> Signed-off-by: Wright Feng <wright.feng@cypress.com>
Patch applied to wireless-drivers-next.git, thanks.
9ef77fbedad9 brcmfmac: send mailbox interrupt twice for specific hardware device
--
https://patchwork.kernel.org/patch/10917993/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v9 14/14] staging: rtlwifi: remove staging rtlwifi driver
From: Kalle Valo @ 2019-04-26 12:09 UTC (permalink / raw)
To: yhchuang
Cc: linux-wireless, johannes, pkshih, tehuang, Larry.Finger, sgruszka,
briannorris, gregkh
In-Reply-To: <1555653004-1795-15-git-send-email-yhchuang@realtek.com>
<yhchuang@realtek.com> writes:
> From: Yan-Hsuan Chuang <yhchuang@realtek.com>
>
> The rtlwifi driver is conflicting with Realtek's new 802.11ac chip
> series driver rtw88, remove it to avoid racing with the same ID.
>
> The rtw88 driver can be found at drivers/net/wireless/realtek/rtw88
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
BTW, this patch does not apply to wireless-drivers-next anymore. To
avoid any conflicts, would be it be safer that the driver is removed
directly from Greg's tree? After rtw88 is applied to
wireless-drivers-next, of course.
error: patch failed: drivers/staging/rtlwifi/Kconfig:1
error: drivers/staging/rtlwifi/Kconfig: patch does not apply
error: patch failed: drivers/staging/rtlwifi/efuse.c:1
error: drivers/staging/rtlwifi/efuse.c: patch does not apply
error: patch failed: drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c:1
error: drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c: patch does not apply
error: patch failed: drivers/staging/rtlwifi/pci.h:1
error: drivers/staging/rtlwifi/pci.h: patch does not apply
error: patch failed: drivers/staging/rtlwifi/phydm/phydm_rainfo.c:1
error: drivers/staging/rtlwifi/phydm/phydm_rainfo.c: patch does not apply
error: patch failed: drivers/staging/rtlwifi/phydm/rtl_phydm.c:1
error: drivers/staging/rtlwifi/phydm/rtl_phydm.c: patch does not apply
error: patch failed: drivers/staging/rtlwifi/rtl8822be/fw.c:1
error: drivers/staging/rtlwifi/rtl8822be/fw.c: patch does not apply
Patch failed at 0014 staging: rtlwifi: remove staging rtlwifi driver
--
Kalle Valo
^ permalink raw reply
* RE: [PATCH v9 14/14] staging: rtlwifi: remove staging rtlwifi driver
From: Tony Chuang @ 2019-04-26 12:19 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless@vger.kernel.org, johannes@sipsolutions.net, Pkshih,
Andy Huang, Larry.Finger@lwfinger.net, sgruszka@redhat.com,
briannorris@chromium.org, gregkh@linuxfoundation.org
In-Reply-To: <87d0l9ufw5.fsf@kamboji.qca.qualcomm.com>
Hi Greg,
> -----Original Message-----
> From: Kalle Valo [mailto:kvalo@codeaurora.org]
> Sent: Friday, April 26, 2019 8:10 PM
> To: Tony Chuang
> Cc: linux-wireless@vger.kernel.org; johannes@sipsolutions.net; Pkshih; Andy
> Huang; Larry.Finger@lwfinger.net; sgruszka@redhat.com;
> briannorris@chromium.org; gregkh@linuxfoundation.org
> Subject: Re: [PATCH v9 14/14] staging: rtlwifi: remove staging rtlwifi driver
>
> <yhchuang@realtek.com> writes:
>
> > From: Yan-Hsuan Chuang <yhchuang@realtek.com>
> >
> > The rtlwifi driver is conflicting with Realtek's new 802.11ac chip
> > series driver rtw88, remove it to avoid racing with the same ID.
> >
> > The rtw88 driver can be found at drivers/net/wireless/realtek/rtw88
> >
> > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
>
> BTW, this patch does not apply to wireless-drivers-next anymore. To
> avoid any conflicts, would be it be safer that the driver is removed
> directly from Greg's tree? After rtw88 is applied to
> wireless-drivers-next, of course.
>
> error: patch failed: drivers/staging/rtlwifi/Kconfig:1
> error: drivers/staging/rtlwifi/Kconfig: patch does not apply
> error: patch failed: drivers/staging/rtlwifi/efuse.c:1
> error: drivers/staging/rtlwifi/efuse.c: patch does not apply
> error: patch failed:
> drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c:1
> error: drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c: patch
> does not apply
> error: patch failed: drivers/staging/rtlwifi/pci.h:1
> error: drivers/staging/rtlwifi/pci.h: patch does not apply
> error: patch failed: drivers/staging/rtlwifi/phydm/phydm_rainfo.c:1
> error: drivers/staging/rtlwifi/phydm/phydm_rainfo.c: patch does not apply
> error: patch failed: drivers/staging/rtlwifi/phydm/rtl_phydm.c:1
> error: drivers/staging/rtlwifi/phydm/rtl_phydm.c: patch does not apply
> error: patch failed: drivers/staging/rtlwifi/rtl8822be/fw.c:1
> error: drivers/staging/rtlwifi/rtl8822be/fw.c: patch does not apply
> Patch failed at 0014 staging: rtlwifi: remove staging rtlwifi driver
>
Hi Greg,
Can you help us to remove the staging driver rtlwifi in your tree ?
I think Kalle can issue a signal to you when he has done reviewing
the rtw88 driver and merge it into wireless-drivers-next.
Thanks
Yan-Hsuan
^ permalink raw reply
* [PATCH] mt7603: wait for pre_tbtt_tasklet before scanning
From: Lorenzo Bianconi @ 2019-04-26 12:40 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless
In-Reply-To: <cover.1556280002.git.lorenzo@kernel.org>
Disable pre_tbtt_tasklet tasklet before performing frequency scanning
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt7603/main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/main.c b/drivers/net/wireless/mediatek/mt76/mt7603/main.c
index 18a33d921601..184ed4cead0a 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/main.c
@@ -535,6 +535,7 @@ mt7603_sw_scan(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
struct mt7603_dev *dev = hw->priv;
set_bit(MT76_SCANNING, &dev->mt76.state);
+ tasklet_disable(&dev->pre_tbtt_tasklet);
mt7603_beacon_set_timer(dev, -1, 0);
}
@@ -545,6 +546,7 @@ mt7603_sw_scan_complete(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
clear_bit(MT76_SCANNING, &dev->mt76.state);
mt7603_beacon_set_timer(dev, -1, dev->beacon_int);
+ tasklet_enable(&dev->pre_tbtt_tasklet);
}
static void
--
2.20.1
^ permalink raw reply related
* [PATCHv2] ath10k: Add wrapper function to ath10k debug
From: Venkateswara Naralasetty @ 2019-04-26 12:58 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Venkateswara Naralasetty, Kan Yan
ath10k_dbg() is called in ath10k_process_rx() with huge set of arguments
which is causing CPU overhead even when debug_mask is not set.
Good improvement was observed in the receive side performance when call
to ath10k_dbg() is avoided in the RX path.
Since currently all debug messages are sent via tracing infrastructure,
we cannot entirely avoid calling ath10k_dbg. Therefore, call to
ath10k_dbg() is made conditional based on tracing config in the driver.
Trasmit performance remains unchanged with this patch; below are some
experimental results with this patch and tracing disabled.
mesh mode:
w/o this patch with this patch
Traffic TP CPU Usage TP CPU usage
TCP 840Mbps 76.53% 960Mbps 78.14%
UDP 1030Mbps 74.58% 1132Mbps 74.31%
Infra mode:
w/o this patch with this patch
Traffic TP CPU Usage TP CPU usage
TCP Rx 1241Mbps 80.89% 1270Mbps 73.50%
UDP Rx 1433Mbps 81.77% 1472Mbps 72.80%
Tested platform : IPQ8064
hardware used : QCA9984
firmware ver : ver 10.4-3.5.3-00057
Signed-off-by: Kan Yan <kyan@chromium.org>
Signed-off-by: Venkateswara Naralasetty <vnaralas@codeaurora.org>
---
v2:
* changed trace enabled check from IS_ENABLED(CONFIG_ATH10K_TRACING)
* to trace_ath10k_log_dbg_enabled().
drivers/net/wireless/ath/ath10k/core.c | 2 ++
drivers/net/wireless/ath/ath10k/debug.c | 8 ++++----
drivers/net/wireless/ath/ath10k/debug.h | 22 ++++++++++++++++------
drivers/net/wireless/ath/ath10k/trace.c | 1 +
drivers/net/wireless/ath/ath10k/trace.h | 6 +++++-
5 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index cfd7bb2..ab709bf 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -26,6 +26,8 @@
#include "coredump.h"
unsigned int ath10k_debug_mask;
+EXPORT_SYMBOL(ath10k_debug_mask);
+
static unsigned int ath10k_cryptmode_param;
static bool uart_print;
static bool skip_otp;
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 32d967a..1b63929 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -2620,8 +2620,8 @@ void ath10k_debug_unregister(struct ath10k *ar)
#endif /* CONFIG_ATH10K_DEBUGFS */
#ifdef CONFIG_ATH10K_DEBUG
-void ath10k_dbg(struct ath10k *ar, enum ath10k_debug_mask mask,
- const char *fmt, ...)
+void __ath10k_dbg(struct ath10k *ar, enum ath10k_debug_mask mask,
+ const char *fmt, ...)
{
struct va_format vaf;
va_list args;
@@ -2638,7 +2638,7 @@ void ath10k_dbg(struct ath10k *ar, enum ath10k_debug_mask mask,
va_end(args);
}
-EXPORT_SYMBOL(ath10k_dbg);
+EXPORT_SYMBOL(__ath10k_dbg);
void ath10k_dbg_dump(struct ath10k *ar,
enum ath10k_debug_mask mask,
@@ -2651,7 +2651,7 @@ void ath10k_dbg_dump(struct ath10k *ar,
if (ath10k_debug_mask & mask) {
if (msg)
- ath10k_dbg(ar, mask, "%s\n", msg);
+ __ath10k_dbg(ar, mask, "%s\n", msg);
for (ptr = buf; (ptr - buf) < len; ptr += 16) {
linebuflen = 0;
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index db78e85..a5b2039 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -240,18 +240,18 @@ void ath10k_sta_update_rx_tid_stats_ampdu(struct ath10k *ar,
#endif /* CONFIG_MAC80211_DEBUGFS */
#ifdef CONFIG_ATH10K_DEBUG
-__printf(3, 4) void ath10k_dbg(struct ath10k *ar,
- enum ath10k_debug_mask mask,
- const char *fmt, ...);
+__printf(3, 4) void __ath10k_dbg(struct ath10k *ar,
+ enum ath10k_debug_mask mask,
+ const char *fmt, ...);
void ath10k_dbg_dump(struct ath10k *ar,
enum ath10k_debug_mask mask,
const char *msg, const char *prefix,
const void *buf, size_t len);
#else /* CONFIG_ATH10K_DEBUG */
-static inline int ath10k_dbg(struct ath10k *ar,
- enum ath10k_debug_mask dbg_mask,
- const char *fmt, ...)
+static inline int __ath10k_dbg(struct ath10k *ar,
+ enum ath10k_debug_mask dbg_mask,
+ const char *fmt, ...)
{
return 0;
}
@@ -263,4 +263,14 @@ static inline void ath10k_dbg_dump(struct ath10k *ar,
{
}
#endif /* CONFIG_ATH10K_DEBUG */
+
+/* Avoid calling __ath10k_dbg() if debug_mask is not set and tracing
+ * disabled.
+ */
+#define ath10k_dbg(ar, dbg_mask, fmt, ...) \
+do { \
+ if ((ath10k_debug_mask & dbg_mask) || \
+ trace_ath10k_log_dbg_enabled()) \
+ __ath10k_dbg(ar, dbg_mask, fmt, ##__VA_ARGS__); \
+} while (0)
#endif /* _DEBUG_H_ */
diff --git a/drivers/net/wireless/ath/ath10k/trace.c b/drivers/net/wireless/ath/ath10k/trace.c
index 3ecdff1..c7d4c97 100644
--- a/drivers/net/wireless/ath/ath10k/trace.c
+++ b/drivers/net/wireless/ath/ath10k/trace.c
@@ -7,3 +7,4 @@
#define CREATE_TRACE_POINTS
#include "trace.h"
+EXPORT_SYMBOL(__tracepoint_ath10k_log_dbg);
diff --git a/drivers/net/wireless/ath/ath10k/trace.h b/drivers/net/wireless/ath/ath10k/trace.h
index ba977bb..ab91645 100644
--- a/drivers/net/wireless/ath/ath10k/trace.h
+++ b/drivers/net/wireless/ath/ath10k/trace.h
@@ -29,7 +29,11 @@ static inline u32 ath10k_frm_hdr_len(const void *buf, size_t len)
#if !defined(CONFIG_ATH10K_TRACING)
#undef TRACE_EVENT
#define TRACE_EVENT(name, proto, ...) \
-static inline void trace_ ## name(proto) {}
+static inline void trace_ ## name(proto) {} \
+static inline bool trace_##name##_enabled(void) \
+{ \
+ return false; \
+}
#undef DECLARE_EVENT_CLASS
#define DECLARE_EVENT_CLASS(...)
#undef DEFINE_EVENT
--
2.7.4
^ permalink raw reply related
* Re: [PATCHv2] ath10k: Add wrapper function to ath10k debug
From: Ben Greear @ 2019-04-26 13:21 UTC (permalink / raw)
To: Venkateswara Naralasetty, ath10k; +Cc: linux-wireless, Kan Yan
In-Reply-To: <1556283505-29539-1-git-send-email-vnaralas@codeaurora.org>
On 4/26/19 5:58 AM, Venkateswara Naralasetty wrote:
> ath10k_dbg() is called in ath10k_process_rx() with huge set of arguments
> which is causing CPU overhead even when debug_mask is not set.
> Good improvement was observed in the receive side performance when call
> to ath10k_dbg() is avoided in the RX path.
>
> Since currently all debug messages are sent via tracing infrastructure,
> we cannot entirely avoid calling ath10k_dbg. Therefore, call to
> ath10k_dbg() is made conditional based on tracing config in the driver.
>
> Trasmit performance remains unchanged with this patch; below are some
> experimental results with this patch and tracing disabled.
>
> mesh mode:
>
> w/o this patch with this patch
> Traffic TP CPU Usage TP CPU usage
>
> TCP 840Mbps 76.53% 960Mbps 78.14%
> UDP 1030Mbps 74.58% 1132Mbps 74.31%
>
> Infra mode:
>
> w/o this patch with this patch
> Traffic TP CPU Usage TP CPU usage
>
> TCP Rx 1241Mbps 80.89% 1270Mbps 73.50%
> UDP Rx 1433Mbps 81.77% 1472Mbps 72.80%
>
> Tested platform : IPQ8064
> hardware used : QCA9984
> firmware ver : ver 10.4-3.5.3-00057
>
> Signed-off-by: Kan Yan <kyan@chromium.org>
> Signed-off-by: Venkateswara Naralasetty <vnaralas@codeaurora.org>
> ---
> v2:
> * changed trace enabled check from IS_ENABLED(CONFIG_ATH10K_TRACING)
> * to trace_ath10k_log_dbg_enabled().
>
> drivers/net/wireless/ath/ath10k/core.c | 2 ++
> drivers/net/wireless/ath/ath10k/debug.c | 8 ++++----
> drivers/net/wireless/ath/ath10k/debug.h | 22 ++++++++++++++++------
> drivers/net/wireless/ath/ath10k/trace.c | 1 +
> drivers/net/wireless/ath/ath10k/trace.h | 6 +++++-
> 5 files changed, 28 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
> index cfd7bb2..ab709bf 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -26,6 +26,8 @@
> #include "coredump.h"
>
> unsigned int ath10k_debug_mask;
> +EXPORT_SYMBOL(ath10k_debug_mask);
> +
> static unsigned int ath10k_cryptmode_param;
> static bool uart_print;
> static bool skip_otp;
> diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> index 32d967a..1b63929 100644
> --- a/drivers/net/wireless/ath/ath10k/debug.c
> +++ b/drivers/net/wireless/ath/ath10k/debug.c
> @@ -2620,8 +2620,8 @@ void ath10k_debug_unregister(struct ath10k *ar)
> #endif /* CONFIG_ATH10K_DEBUGFS */
>
> #ifdef CONFIG_ATH10K_DEBUG
> -void ath10k_dbg(struct ath10k *ar, enum ath10k_debug_mask mask,
> - const char *fmt, ...)
> +void __ath10k_dbg(struct ath10k *ar, enum ath10k_debug_mask mask,
> + const char *fmt, ...)
> {
> struct va_format vaf;
> va_list args;
Do you still need the check later in this method:
if (ath10k_debug_mask & mask)
since you already checked in the ath10k_dbg() macro?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* RE: [PATCHv2] ath10k: Add wrapper function to ath10k debug
From: Venkateswara Naralasetty @ 2019-04-26 13:38 UTC (permalink / raw)
To: Ben Greear, Venkateswara Naralasetty, ath10k@lists.infradead.org
Cc: Kan Yan, linux-wireless@vger.kernel.org
In-Reply-To: <b9f263a4-e9da-18bb-5932-941a018ee860@candelatech.com>
> -----Original Message-----
> From: ath10k <ath10k-bounces@lists.infradead.org> On Behalf Of Ben
> Greear
> Sent: Friday, April 26, 2019 6:52 PM
> To: Venkateswara Naralasetty <vnaralas@codeaurora.org>;
> ath10k@lists.infradead.org
> Cc: Kan Yan <kyan@chromium.org>; linux-wireless@vger.kernel.org
> Subject: [EXT] Re: [PATCHv2] ath10k: Add wrapper function to ath10k debug
>
> On 4/26/19 5:58 AM, Venkateswara Naralasetty wrote:
> > ath10k_dbg() is called in ath10k_process_rx() with huge set of
> > arguments which is causing CPU overhead even when debug_mask is not
> set.
> > Good improvement was observed in the receive side performance when
> > call to ath10k_dbg() is avoided in the RX path.
> >
> > Since currently all debug messages are sent via tracing
> > infrastructure, we cannot entirely avoid calling ath10k_dbg.
> > Therefore, call to
> > ath10k_dbg() is made conditional based on tracing config in the driver.
> >
> > Trasmit performance remains unchanged with this patch; below are some
> > experimental results with this patch and tracing disabled.
> >
> > mesh mode:
> >
> > w/o this patch with this patch
> > Traffic TP CPU Usage TP CPU usage
> >
> > TCP 840Mbps 76.53% 960Mbps 78.14%
> > UDP 1030Mbps 74.58% 1132Mbps 74.31%
> >
> > Infra mode:
> >
> > w/o this patch with this patch
> > Traffic TP CPU Usage TP CPU usage
> >
> > TCP Rx 1241Mbps 80.89% 1270Mbps 73.50%
> > UDP Rx 1433Mbps 81.77% 1472Mbps 72.80%
> >
> > Tested platform : IPQ8064
> > hardware used : QCA9984
> > firmware ver : ver 10.4-3.5.3-00057
> >
> > Signed-off-by: Kan Yan <kyan@chromium.org>
> > Signed-off-by: Venkateswara Naralasetty <vnaralas@codeaurora.org>
> > ---
> > v2:
> > * changed trace enabled check from
> IS_ENABLED(CONFIG_ATH10K_TRACING)
> > * to trace_ath10k_log_dbg_enabled().
> >
> > drivers/net/wireless/ath/ath10k/core.c | 2 ++
> > drivers/net/wireless/ath/ath10k/debug.c | 8 ++++----
> > drivers/net/wireless/ath/ath10k/debug.h | 22 ++++++++++++++++------
> > drivers/net/wireless/ath/ath10k/trace.c | 1 +
> > drivers/net/wireless/ath/ath10k/trace.h | 6 +++++-
> > 5 files changed, 28 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath10k/core.c
> > b/drivers/net/wireless/ath/ath10k/core.c
> > index cfd7bb2..ab709bf 100644
> > --- a/drivers/net/wireless/ath/ath10k/core.c
> > +++ b/drivers/net/wireless/ath/ath10k/core.c
> > @@ -26,6 +26,8 @@
> > #include "coredump.h"
> >
> > unsigned int ath10k_debug_mask;
> > +EXPORT_SYMBOL(ath10k_debug_mask);
> > +
> > static unsigned int ath10k_cryptmode_param;
> > static bool uart_print;
> > static bool skip_otp;
> > diff --git a/drivers/net/wireless/ath/ath10k/debug.c
> > b/drivers/net/wireless/ath/ath10k/debug.c
> > index 32d967a..1b63929 100644
> > --- a/drivers/net/wireless/ath/ath10k/debug.c
> > +++ b/drivers/net/wireless/ath/ath10k/debug.c
> > @@ -2620,8 +2620,8 @@ void ath10k_debug_unregister(struct ath10k *ar)
> > #endif /* CONFIG_ATH10K_DEBUGFS */
> >
> > #ifdef CONFIG_ATH10K_DEBUG
> > -void ath10k_dbg(struct ath10k *ar, enum ath10k_debug_mask mask,
> > - const char *fmt, ...)
> > +void __ath10k_dbg(struct ath10k *ar, enum ath10k_debug_mask mask,
> > + const char *fmt, ...)
> > {
> > struct va_format vaf;
> > va_list args;
>
> Do you still need the check later in this method:
>
> if (ath10k_debug_mask & mask)
>
> since you already checked in the ath10k_dbg() macro?
Yes, we need this check.
Otherwise all debug messages will be printed even without any debug mask set in case of tracing enabled.
>
> Thanks,
> Ben
>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* Re: [PATCHv2] ath10k: Add wrapper function to ath10k debug
From: Michał Kazior @ 2019-04-26 13:44 UTC (permalink / raw)
To: Venkateswara Naralasetty; +Cc: ath10k, linux-wireless, Kan Yan
In-Reply-To: <1556283505-29539-1-git-send-email-vnaralas@codeaurora.org>
On Fri, 26 Apr 2019 at 14:58, Venkateswara Naralasetty
<vnaralas@codeaurora.org> wrote:
>
> ath10k_dbg() is called in ath10k_process_rx() with huge set of arguments
> which is causing CPU overhead even when debug_mask is not set.
> Good improvement was observed in the receive side performance when call
> to ath10k_dbg() is avoided in the RX path.
[...]
> +/* Avoid calling __ath10k_dbg() if debug_mask is not set and tracing
> + * disabled.
> + */
> +#define ath10k_dbg(ar, dbg_mask, fmt, ...) \
> +do { \
> + if ((ath10k_debug_mask & dbg_mask) || \
> + trace_ath10k_log_dbg_enabled()) \
> + __ath10k_dbg(ar, dbg_mask, fmt, ##__VA_ARGS__); \
> +} while (0)
Did you consider using jump labels (see include/linux/jump_label.h)?
It's what tracing uses under the hood. I wonder if you could squeeze
out a bit more performance with that? I guess you'd need to add
`struct static_key ath10k_dbg_mask_keys[ATH10K_DBG_MAX]` and re-do
ath10k_debug_mask enum a bit.
Michal
^ 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