* Re: [PATCH] RFC: Universal scan proposal
From: Arend Van Spriel @ 2016-12-07 20:51 UTC (permalink / raw)
To: Dmitry Shmidt, Johannes Berg; +Cc: linux-wireless
In-Reply-To: <CAH7ZN-wP+9AGrXFUS4RY65-RyfP-J46svBvLdytP2c=QPtiaug@mail.gmail.com>
On 7-12-2016 19:39, Dmitry Shmidt wrote:
> On Tue, Dec 6, 2016 at 10:44 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>>
>>> Indeed, results are results. I just want to take care of two things:
>>> 1) Memory consumption - we can clear stale scan results for
>>> connection, but not for location if we are using history scan.
>>
>> Well eventually we also have to clear for location if we run out of
>> memory, that usually means dumping them out to the host, no?
>
> Being out of memory and consuming more memory are different
> things, but I agree - maybe we don't need to worry about it.
>
>>> 2) Use of insufficient results for connection - in case we had
>>> history or hotlist scan only for very limited amount of channels,
>>> then we may not have enough APs in our result for "sterling"
>>> connection decision.
>>
>> I'm not entirely sure about this case - surely noticing "we can do
>> better now" is still better than waiting for being able to make the
>> perfect decision?
>
> Maybe we can just keep flag saying that currently available results
> were not received by usual full scan.
>
>>>>> Report: none / batch / immediate
>>>>
>>>> Not sure I see much point in "none"??
>>>>
>>>> Can you define these more clearly? Do you think "batch" reporting
>>>> should be like the gscan buckets? Or actually have full
>>>> information?
>>>
>>> None - means that there is not need to report. It can be useful
>>> in case of roaming scan, scheduling or hotlist scan - you didn't find
>>> anything suitable - don't report that there is no scan results.
>>
>> But that seems more of a filtering thing, combined with "immediate" for
>> anything passing the filter?
>
> We can use this approach as well.
>
>>>>> Request may have priority and can be inserted into
>>>>> the head of the queue.
>>>>> Types of scans:
>>>>> - Normal scan
>>>>> - Scheduled scan
>>>>> - Hotlist (BSSID scan)
>>>>> - Roaming
>>>>> - AutoJoin
>>>>
>>>> I think somebody else said this but I didn't find it now - I think
>>>> this would make more sense to define in terms of expected behaviour
>>>> than use cases for each type of scan.
>>>
>>> I think Luca made this statement.
>>
>> Yeah - I just couldn't find it again on re-reading the thread :)
>>
>>> It is totally ok from SW point of
>>> view - especially due to the fact that scan is scan. However,
>>> I suspect it will be harder to handle from user experience. I mean
>>> at the end wireless framework / driver / FW will convert special
>>> scan type to usual scan with special params and response, but why
>>> to put this burden on user?
I don't think this will put burden on the user although it depends
who/what you mean by this. If you mean the mere mortal end-user I would
say no as indeed there must be some software entity (in user-space) that
will have to initiate a nl80211 command with appropriate attributes
according to whatever user-space is trying to accomplish.
>> I just think it's more flexible and open-ended. The actual definition
>> of the resulting parameters needs to be somewhere anyway - putting it
>> into driver/firmware (vs. wifi framework or so) seems to duplicate it
>> and certainly makes it harder to modify/extend in the future, no?
>
> So, let's summarize:
> Instead of creating new type of generic scan with special types,
> we want to go with additional expansion of scheduled scan options and
> parameters (in order not to "multiply entities"), including ability to send
> new scheduled scan request without stopping previous one.
>
> Is it Ok?
Sounds ok. To me a generic scan command with type attribute is
equivalent to having seperate commands for each type so there seems to
be no gain. Now whether this all can be accomplished by extending the
scheduled scan depends on the problem that you are trying to solve.
Main purpose seems to be offloading different scanning tasks which could
make scheduled scan a good candidate. Now I want to add gscan to this
mix as it seems some concepts for that are in play in this discussion as
well, eg. hotlist. gscan is like scheduled scan, but it supports
multiple schedules. However, it is still a single request from a single
user-space process. I think Luca mentioned supporting requests from
different user-space processes. Is that also what you mean by "ability
to send new scheduled scan request without stopping previous one" or is
that still from a single user-space process. Do we need a limit to the
amount of scheduled scan requests that can be handled simultaneously.
A maybe more important aspect of gscan is user-space control of result
reporting and thus the frequency of waking up host and/or user-space. I
suspect this would be needed in the scheduled scan extension as well, right?
Regards,
Arend
^ permalink raw reply
* Re: [PATCH v2 2/2] cfg80211: Add support to sched scan to report better BSSs
From: Arend Van Spriel @ 2016-12-07 20:11 UTC (permalink / raw)
To: Jouni Malinen, Johannes Berg; +Cc: linux-wireless, vamsi krishna
In-Reply-To: <1480715949-20169-2-git-send-email-jouni@qca.qualcomm.com>
On 2-12-2016 22:59, Jouni Malinen wrote:
> From: vamsi krishna <vamsin@qti.qualcomm.com>
>
> Enhance sched scan to support option of finding a better BSS while in
> connected state. Firmware scans the medium and reports when it finds a
> known BSS which has better RSSI than the current connected BSS. New
> attributes to specify the relative RSSI (compared to the current BSS)
> are added to the sched scan to implement this.
>
> Signed-off-by: vamsi krishna <vamsin@qti.qualcomm.com>
> Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
> ---
> include/net/cfg80211.h | 19 +++++++++++++++++++
> include/uapi/linux/nl80211.h | 18 ++++++++++++++++++
> net/wireless/nl80211.c | 29 +++++++++++++++++++++++++++--
> 3 files changed, 64 insertions(+), 2 deletions(-)
>
> v2: address comments from Luca, Arend, and Johannes
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index ef42749..dcdd0c4 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -1626,6 +1626,22 @@ struct cfg80211_sched_scan_plan {
> * cycle. The driver may ignore this parameter and start
> * immediately (or at any other time), if this feature is not
> * supported.
> + * @relative_rssi: Relative RSSI threshold in dB to restrict scan result
> + * reporting in connected state to cases where a matching BSS is determined
> + * to have better RSSI than the current connected BSS. The relative RSSI
> + * threshold values are ignored in disconnected state.
> + * @relative_rssi_5g_pref: The amount of RSSI preference in dB that is given to
> + * a 5 GHz BSS over 2.4 GHz BSS while looking for better BSSs in connected
> + * state. A negative value can be passed if 2.4 GHz band should be given
> + * priority to 5 GHz band.
> + * If the current connected BSS is in the 2.4 GHz band, other BSSs in the
> + * 2.4 GHz band to be reported should have better RSSI by @relative_rssi
> + * and other BSSs in the 5 GHz band to be reported should have better RSSI
> + * by (@relative_rssi - @relative_rssi_5g_pref).
> + * If the current connected BSS is in the 5 GHz band, other BSSs in the
> + * 2.4 GHz band to be reported should have better RSSI by
> + * (@relative_rssi + @relative_rssi_5g_pref) and other BSSs in the 5 GHz
> + * band to be reported should have better RSSI by by @relative_rssi.
The choice of these attributes makes the implicit assumption that the
BSS-es in 5G are preferred. The relative_rssi_5g_pref is actually more a
bonus or penalty is negative value is used. I guess for speed junkies
that want their 11ac card maxed out that is true, but if you need to
cross a couple of concrete floors you might want to stick with 2.4G.
I introduced a similar attribute to be provided in the
NL80211_CMD_CONNECT (see [1]).
Regards,
Arend
[1] http://lxr.free-electrons.com/source/include/uapi/linux/nl80211.h#L1815
> */
> struct cfg80211_sched_scan_request {
> struct cfg80211_ssid *ssids;
> @@ -1645,6 +1661,9 @@ struct cfg80211_sched_scan_request {
> u8 mac_addr[ETH_ALEN] __aligned(2);
> u8 mac_addr_mask[ETH_ALEN] __aligned(2);
>
> + s8 relative_rssi;
> + s8 relative_rssi_5g_pref;
> +
> /* internal */
> struct wiphy *wiphy;
> struct net_device *dev;
> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
> index 6b76e3b..fc29bdb 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -1980,6 +1980,17 @@ enum nl80211_commands {
> * @NL80211_ATTR_BSSID: The BSSID of the AP. Note that %NL80211_ATTR_MAC is also
> * used in various commands/events for specifying the BSSID.
> *
> + * @NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI: Relative RSSI threshold by which
> + * other BSSs has to be better than the current connected BSS so that they
> + * get reported to user space. This will give an opportunity to userspace
> + * to consider connecting to other matching BSSs which have better RSSI
> + * than the current connected BSS by using an offloaded operation to avoid
> + * unnecessary wakeups.
> + *
> + * @NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF: The amount of RSSI preference
> + * to be given to 5 GHz APs over 2.4 GHz APs while searching for better
> + * BSSs than the current connected BSS.
> + *
> * @NUM_NL80211_ATTR: total number of nl80211_attrs available
> * @NL80211_ATTR_MAX: highest attribute number currently defined
> * @__NL80211_ATTR_AFTER_LAST: internal use
> @@ -2386,6 +2397,9 @@ enum nl80211_attrs {
>
> NL80211_ATTR_BSSID,
>
> + NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI,
> + NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF,
> +
> /* add attributes here, update the policy in nl80211.c */
>
> __NL80211_ATTR_AFTER_LAST,
> @@ -4697,6 +4711,9 @@ enum nl80211_feature_flags {
> * configuration (AP/mesh) with VHT rates.
> * @NL80211_EXT_FEATURE_FILS_STA: This driver supports Fast Initial Link Setup
> * with user space SME (NL80211_CMD_AUTHENTICATE) in station mode.
> + * @NL80211_EXT_FEATURE_SCHED_SCAN_RELATIVE_RSSI: The driver supports sched_scan
> + * for reporting BSSs with better RSSI than the current connected BSS
> + * (%NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI).
> *
> * @NUM_NL80211_EXT_FEATURES: number of extended features.
> * @MAX_NL80211_EXT_FEATURES: highest extended feature index.
> @@ -4712,6 +4729,7 @@ enum nl80211_ext_feature_index {
> NL80211_EXT_FEATURE_BEACON_RATE_HT,
> NL80211_EXT_FEATURE_BEACON_RATE_VHT,
> NL80211_EXT_FEATURE_FILS_STA,
> + NL80211_EXT_FEATURE_SCHED_SCAN_RELATIVE_RSSI,
>
> /* add new features before the definition below */
> NUM_NL80211_EXT_FEATURES,
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 7762231..549f239 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -405,6 +405,8 @@ enum nl80211_multicast_groups {
> [NL80211_ATTR_FILS_NONCES] = { .len = 2 * FILS_NONCE_LEN },
> [NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED] = { .type = NLA_FLAG, },
> [NL80211_ATTR_BSSID] = { .len = ETH_ALEN },
> + [NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI] = { .type = NLA_S8 },
> + [NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF] = { .type = NLA_S8 },
> };
>
> /* policy for the key attributes */
> @@ -6950,6 +6952,12 @@ static int nl80211_abort_scan(struct sk_buff *skb, struct genl_info *info)
> if (!n_plans || n_plans > wiphy->max_sched_scan_plans)
> return ERR_PTR(-EINVAL);
>
> + if (!wiphy_ext_feature_isset(
> + wiphy, NL80211_EXT_FEATURE_SCHED_SCAN_RELATIVE_RSSI) &&
> + (attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI] ||
> + attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF]))
> + return ERR_PTR(-EINVAL);
> +
> request = kzalloc(sizeof(*request)
> + sizeof(*request->ssids) * n_ssids
> + sizeof(*request->match_sets) * n_match_sets
> @@ -7156,6 +7164,14 @@ static int nl80211_abort_scan(struct sk_buff *skb, struct genl_info *info)
> request->delay =
> nla_get_u32(attrs[NL80211_ATTR_SCHED_SCAN_DELAY]);
>
> + if (attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI])
> + request->relative_rssi = nla_get_s8(
> + attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI]);
> +
> + if (attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF])
> + request->relative_rssi_5g_pref = nla_get_s8(
> + attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF]);
> +
> err = nl80211_parse_sched_scan_plans(wiphy, n_plans, request, attrs);
> if (err)
> goto out_free;
> @@ -9649,7 +9665,8 @@ static int nl80211_send_wowlan_tcp(struct sk_buff *msg,
> return 0;
> }
>
> -static int nl80211_send_wowlan_nd(struct sk_buff *msg,
> +static int nl80211_send_wowlan_nd(struct wiphy *wiphy,
> + struct sk_buff *msg,
> struct cfg80211_sched_scan_request *req)
> {
> struct nlattr *nd, *freqs, *matches, *match, *scan_plans, *scan_plan;
> @@ -9670,6 +9687,14 @@ static int nl80211_send_wowlan_nd(struct sk_buff *msg,
> if (nla_put_u32(msg, NL80211_ATTR_SCHED_SCAN_DELAY, req->delay))
> return -ENOBUFS;
>
> + if (wiphy_ext_feature_isset(
> + wiphy, NL80211_EXT_FEATURE_SCHED_SCAN_RELATIVE_RSSI) &&
> + (nla_put_s8(msg, NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI,
> + req->relative_rssi) ||
> + nla_put_s8(msg, NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF,
> + req->relative_rssi_5g_pref)))
> + return -ENOBUFS;
> +
> freqs = nla_nest_start(msg, NL80211_ATTR_SCAN_FREQUENCIES);
> if (!freqs)
> return -ENOBUFS;
> @@ -9783,7 +9808,7 @@ static int nl80211_get_wowlan(struct sk_buff *skb, struct genl_info *info)
> goto nla_put_failure;
>
> if (nl80211_send_wowlan_nd(
> - msg,
> + &rdev->wiphy, msg,
> rdev->wiphy.wowlan_config->nd_config))
> goto nla_put_failure;
>
>
^ permalink raw reply
* Re: [PATCH v2 2/2] cfg80211: Add support to sched scan to report better BSSs
From: Arend Van Spriel @ 2016-12-07 20:03 UTC (permalink / raw)
To: Vamsi, Krishna, Johannes Berg, Malinen, Jouni
Cc: linux-wireless@vger.kernel.org
In-Reply-To: <dc960243db2b452f97721dad49f0a63b@aphydexm01b.ap.qualcomm.com>
On 7-12-2016 10:33, Vamsi, Krishna wrote:
>> -----Original Message-----
>> From: Johannes Berg [mailto:johannes@sipsolutions.net]
>
>> What about Arend's comment regarding this functionality overlapping with the
>> BSS selection offload configuration?
>>
>> Do you think there's any ability to share attributes/functionality?
>
> Hi Johannes,
>
> I think the later comment from Luca on this which I pasted below is more agreeable.
>
> Yes, similar but not quite the same. The existing case is for finding BSSs that are worth waking the host up for (while disconnected), so it needs to be better than the RSSI passed (absolute number). Now this is about relative RSSI as compared to the current connection, so RELATIVE_RSSI is different than RSSI and I think the same attribute should not be used, to avoid confusion.
I noticed the response from Luca, but did not get back on this. I know
it is not the same, but what I meant is whether we could extend it so it
also covers your scenario.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] RFC: Universal scan proposal
From: Dmitry Shmidt @ 2016-12-07 18:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1481093061.4092.17.camel@sipsolutions.net>
On Tue, Dec 6, 2016 at 10:44 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>
>> Indeed, results are results. I just want to take care of two things:
>> 1) Memory consumption - we can clear stale scan results for
>> connection, but not for location if we are using history scan.
>
> Well eventually we also have to clear for location if we run out of
> memory, that usually means dumping them out to the host, no?
Being out of memory and consuming more memory are different
things, but I agree - maybe we don't need to worry about it.
>> 2) Use of insufficient results for connection - in case we had
>> history or hotlist scan only for very limited amount of channels,
>> then we may not have enough APs in our result for "sterling"
>> connection decision.
>
> I'm not entirely sure about this case - surely noticing "we can do
> better now" is still better than waiting for being able to make the
> perfect decision?
Maybe we can just keep flag saying that currently available results
were not received by usual full scan.
>> > > Report: none / batch / immediate
>> >
>> > Not sure I see much point in "none"??
>> >
>> > Can you define these more clearly? Do you think "batch" reporting
>> > should be like the gscan buckets? Or actually have full
>> > information?
>>
>> None - means that there is not need to report. It can be useful
>> in case of roaming scan, scheduling or hotlist scan - you didn't find
>> anything suitable - don't report that there is no scan results.
>
> But that seems more of a filtering thing, combined with "immediate" for
> anything passing the filter?
We can use this approach as well.
>> > > Request may have priority and can be inserted into
>> > > the head of the queue.
>> > > Types of scans:
>> > > - Normal scan
>> > > - Scheduled scan
>> > > - Hotlist (BSSID scan)
>> > > - Roaming
>> > > - AutoJoin
>> >
>> > I think somebody else said this but I didn't find it now - I think
>> > this would make more sense to define in terms of expected behaviour
>> > than use cases for each type of scan.
>>
>> I think Luca made this statement.
>
> Yeah - I just couldn't find it again on re-reading the thread :)
>
>> It is totally ok from SW point of
>> view - especially due to the fact that scan is scan. However,
>> I suspect it will be harder to handle from user experience. I mean
>> at the end wireless framework / driver / FW will convert special
>> scan type to usual scan with special params and response, but why
>> to put this burden on user?
>
> I just think it's more flexible and open-ended. The actual definition
> of the resulting parameters needs to be somewhere anyway - putting it
> into driver/firmware (vs. wifi framework or so) seems to duplicate it
> and certainly makes it harder to modify/extend in the future, no?
So, let's summarize:
Instead of creating new type of generic scan with special types,
we want to go with additional expansion of scheduled scan options and
parameters (in order not to "multiply entities"), including ability to send
new scheduled scan request without stopping previous one.
Is it Ok?
> johannes
^ permalink raw reply
* Re: [PATCH 2/4] cfg80211: Add new NL80211_CMD_SET_BTCOEX_PRIORITY to support BTCOEX
From: Tamizh chelvam @ 2016-12-07 17:59 UTC (permalink / raw)
To: Johannes Berg; +Cc: c_traja, linux-wireless, ath10k
In-Reply-To: <1480949353.31788.27.camel@sipsolutions.net>
Hi Johannes,
Thanks for the comments.
On 2016-12-05 20:19, Johannes Berg wrote:
> On Tue, 2016-11-08 at 18:45 +0530, c_traja@qti.qualcomm.com wrote:
>>
>> + * struct cfg80211_btcoex_priority - BTCOEX support frame type
>> + *
>> + * This structure defines the driver supporting frame types for
>> BTCOEX
>> + *
>> + * @wlan_be_preferred: best effort frames preferred over bt traffic
>> + * @wlan_bk_preferred: background frames preferred over bt traffic
>> + * @wlan_vi_preferred: video frames preferred over bt traffic
>> + * @wlan_vo_preferred: voice frames preferred over bt traffic
>> + * @wlan_beacon_preferred: beacon preferred over bt traffic
>> + * @wlan_mgmt_preferred: management frames preferred ovet bt traffic
>
> typo: over
>
Okay
>>
>> /**
>> + * wiphy_btcoex_support_flags
>> + * This enum has the driver supported frame types for BTCOEX.
>> + * @WIPHY_WLAN_BE_PREFERRED - Supports Best Effort frame for BTCOEX
>> + * @WIPHY_WLAN_BK_PREFERRED - supports Background frame for BTCOEX
>> + * @WIPHY_WLAN_VI_PREFERRED - supports Video frame for BTCOEX
>> + * @WIPHY_WLAN_VO_PREFERRED - supports Voice frame for BTCOEX
>> + * @WIPHY_WLAN_BEACON_PREFERRED - supports Beacon frame for BTCOEX
>> + * @WIPHY_WLAN_MGMT_PREFERRED - supports Management frames for
>> BTCOEX.
>> + */
>
> That's not making much sense to me?
>
is it fine to have as WIPHY_BTCOEX_BE_PREFERRED ?
>> +/**
>> + * enum wiphy_btcoex_priority - BTCOEX priority level
>> + * This enum defines priority level for BTCOEX
>> + * WIPHY_WLAN_PREFERRED_LOW - low priority frames over BT traffic
>> + * WIPHY_WLAN_PREFERRED_HIGH - high priority frames over BT traffic
>> + */
>> +
>> +enum wiphy_btcoex_priority {
>> + WIPHY_WLAN_PREFERRED_LOW = false,
>> + WIPHY_WLAN_PREFERRED_HIGH = true,
>> +};
>
> That false/true seems just strange.
>
I will just use as a enum without assigning false/true.
>> + * @btcoex_support_flags: This will have the driver supported
>> + * frame types for BTCOEX. This value filled by using
>> + * %enum wiphy_btcoex_support_flags while driver
>> + * initialization.
>
> The whole "will have" isn't really clear.
>
>> + * @NL80211_ATTR_SET_BTCOEX_PRIORITY: nested attribute for driver
>> supporting
>> + * the BTCOEX. When used with
>> %NL80211_CMD_SET_BTCOEX_PRIORITY it contains
>> + * attributes according &enum nl80211_btcoex_priority to
>> indicate
>> + * which frame has high priority over BT.
>
> There should be no "SET" in there.
>
Okay sure.
>> /**
>> + * enum nl80211_btcoex_priority - BTCOEX parameter attributes
>> + * This strcuture has enum values for driver supported wlan
>> + * frame type for BTCOEX.
>> + * @NL80211_WLAN_BE_PREFERRED - Best Effort frame
>> + * @NL80211_WLAN_BK_PREFERRED - Background frame
>> + * @NL80211_WLAN_VI_PREFERRED - Video frame
>> + * @NL80211_WLAN_VO_PREFERRED - Voice frame
>> + * @NL80211_WLAN_BEACON_PREFERRED - BEACON frame
>> + * @NL80211_WLAN_MGMT_PREFERRED - MGMT frame
>> + */
>> +
>> +enum nl80211_btcoex_priority {
>> + __NL80211_WLAN_PREFERRED_INVALID,
>> + NL80211_WLAN_BE_PREFERRED,
>> + NL80211_WLAN_BK_PREFERRED,
>> + NL80211_WLAN_VI_PREFERRED,
>> + NL80211_WLAN_VO_PREFERRED,
>> + NL80211_WLAN_BEACON_PREFERRED,
>> + NL80211_WLAN_MGMT_PREFERRED,
>> + __NL80211_WLAN_PREFERRED_LAST,
>> + NL80211_WLAN_PREFERRED_MAX =
>> + __NL80211_WLAN_PREFERRED_LAST - 1,
>> +};
>
> Wouldn't a bitmap be easier?
>
since this is to distinguish between different btcoex priorities and we
are not going to do any manipulations on these parameters.
It is just used as flag attribute.
^ permalink raw reply
* [PATCH 5/5] ath10k: add debug trace to rts/cts set function
From: Bartosz Markowski @ 2016-12-07 17:07 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Bartosz Markowski
In-Reply-To: <1481130454-27244-1-git-send-email-bartosz.markowski@tieto.com>
Align it with the cts protection call.
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 6f1825964177..508366f139f1 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1275,6 +1275,9 @@ static int ath10k_recalc_rtscts_prot(struct ath10k_vif *arvif)
rts_cts |= SM(WMI_RTSCTS_FOR_SECOND_RATESERIES,
WMI_RTSCTS_PROFILE);
+ ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vdev %d recalc rts/cts prot %d\n",
+ arvif->vdev_id, rts_cts);
+
return ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param,
rts_cts);
}
--
2.1.2
^ permalink raw reply related
* [PATCH 4/5] ath10k: set CTS protection VDEV param only if VDEV is up
From: Bartosz Markowski @ 2016-12-07 17:07 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Bartosz Markowski
In-Reply-To: <1481130454-27244-1-git-send-email-bartosz.markowski@tieto.com>
The cts protection vdev parameter, in new QCA9377 TF2.0 firmware,
requires bss peer to be created for the STATION vdev type.
bss peer is being allocated by the firmware after vdev_start/_up commands.
mac80211 may call the cts protection setup at any time, so the
we needs to track the situation and defer the cts configuration
to prevent firmware asserts, like below:
[00]: 0x05020001 0x000015B3 0x0099ACE2 0x00955B31
[04]: 0x0099ACE2 0x00060730 0x00000004 0x00000000
[08]: 0x0044C754 0x00412C10 0x00000000 0x00409C54
[12]: 0x00000009 0x00000000 0x00952F6C 0x00952F77
[16]: 0x00952CC4 0x00910712 0x00000000 0x00000000
[20]: 0x4099ACE2 0x0040E858 0x00421254 0x004127F4
[24]: 0x8099B9B2 0x0040E8B8 0x00000000 0xC099ACE2
[28]: 0x800B75CB 0x0040E8F8 0x00000007 0x00005008
[32]: 0x809B048A 0x0040E958 0x00000010 0x00433B10
[36]: 0x809AFBBC 0x0040E9A8 0x0042BB74 0x0042BBBC
[40]: 0x8091D252 0x0040E9C8 0x0042BBBC 0x00000001
[44]: 0x809FFA45 0x0040EA78 0x0043D3E4 0x0042C2C8
[48]: 0x809FCEF4 0x0040EA98 0x0043D3E4 0x00000001
[52]: 0x80911210 0x0040EAE8 0x00000010 0x004041D0
[56]: 0x80911154 0x0040EB28 0x00400000 0x00000000
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 51 +++++++++++++++++++++++++++++------
1 file changed, 43 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index d06a12d548fd..6f1825964177 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1227,6 +1227,36 @@ static int ath10k_monitor_recalc(struct ath10k *ar)
return ath10k_monitor_stop(ar);
}
+static bool ath10k_mac_can_set_cts_prot(struct ath10k_vif *arvif)
+{
+ struct ath10k *ar = arvif->ar;
+
+ lockdep_assert_held(&ar->conf_mutex);
+
+ if (!arvif->is_started) {
+ ath10k_dbg(ar, ATH10K_DBG_MAC, "defer cts setup, vdev is not ready yet\n");
+ return false;
+ }
+
+ return true;
+}
+
+static int ath10k_mac_set_cts_prot(struct ath10k_vif *arvif)
+{
+ struct ath10k *ar = arvif->ar;
+ u32 vdev_param;
+
+ lockdep_assert_held(&ar->conf_mutex);
+
+ vdev_param = ar->wmi.vdev_param->protection_mode;
+
+ ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vdev %d cts_protection %d\n",
+ arvif->vdev_id, arvif->use_cts_prot);
+
+ return ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param,
+ arvif->use_cts_prot ? 1 : 0);
+}
+
static int ath10k_recalc_rtscts_prot(struct ath10k_vif *arvif)
{
struct ath10k *ar = arvif->ar;
@@ -5329,20 +5359,18 @@ static void ath10k_bss_info_changed(struct ieee80211_hw *hw,
if (changed & BSS_CHANGED_ERP_CTS_PROT) {
arvif->use_cts_prot = info->use_cts_prot;
- ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vdev %d cts_prot %d\n",
- arvif->vdev_id, info->use_cts_prot);
ret = ath10k_recalc_rtscts_prot(arvif);
if (ret)
ath10k_warn(ar, "failed to recalculate rts/cts prot for vdev %d: %d\n",
arvif->vdev_id, ret);
- vdev_param = ar->wmi.vdev_param->protection_mode;
- ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param,
- info->use_cts_prot ? 1 : 0);
- if (ret)
- ath10k_warn(ar, "failed to set protection mode %d on vdev %i: %d\n",
- info->use_cts_prot, arvif->vdev_id, ret);
+ if (ath10k_mac_can_set_cts_prot(arvif)) {
+ ret = ath10k_mac_set_cts_prot(arvif);
+ if (ret)
+ ath10k_warn(ar, "failed to set cts protection for vdev %d: %d\n",
+ arvif->vdev_id, ret);
+ }
}
if (changed & BSS_CHANGED_ERP_SLOT) {
@@ -7365,6 +7393,13 @@ ath10k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw,
arvif->is_up = true;
}
+ if (ath10k_mac_can_set_cts_prot(arvif)) {
+ ret = ath10k_mac_set_cts_prot(arvif);
+ if (ret)
+ ath10k_warn(ar, "failed to set cts protection for vdev %d: %d\n",
+ arvif->vdev_id, ret);
+ }
+
mutex_unlock(&ar->conf_mutex);
return 0;
--
2.1.2
^ permalink raw reply related
* [PATCH 3/5] ath10k: decrease num of peers support
From: Bartosz Markowski @ 2016-12-07 17:07 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Bartosz Markowski
In-Reply-To: <1481130454-27244-1-git-send-email-bartosz.markowski@tieto.com>
The correct number for QCA9377 chip is 33 VDEVs.
This impacts also QCA6174 chip and it's max VDEV number.
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
---
drivers/net/wireless/ath/ath10k/hw.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 883547f3347c..7feffec531cc 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -512,7 +512,7 @@ ath10k_rx_desc_get_l3_pad_bytes(struct ath10k_hw_params *hw,
/* Target specific defines for WMI-TLV firmware */
#define TARGET_TLV_NUM_VDEVS 4
#define TARGET_TLV_NUM_STATIONS 32
-#define TARGET_TLV_NUM_PEERS 35
+#define TARGET_TLV_NUM_PEERS 33
#define TARGET_TLV_NUM_TDLS_VDEVS 1
#define TARGET_TLV_NUM_TIDS ((TARGET_TLV_NUM_PEERS) * 2)
#define TARGET_TLV_NUM_MSDU_DESC (1024 + 32)
--
2.1.2
^ permalink raw reply related
* [PATCH 1/5] ath10k: fix IRAM banks number for QCA9377
From: Bartosz Markowski @ 2016-12-07 17:07 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Bartosz Markowski
QCA9377 firmware shall alloc 4 IRAM banks
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
---
drivers/net/wireless/ath/ath10k/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 0457e315d336..983f65bbb7fb 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1973,7 +1973,7 @@ static int ath10k_pci_get_num_banks(struct ath10k *ar)
}
break;
case QCA9377_1_0_DEVICE_ID:
- return 2;
+ return 4;
}
ath10k_warn(ar, "unknown number of banks, assuming 1\n");
--
2.1.2
^ permalink raw reply related
* [PATCH 2/5] ath10k: override CE5 config for QCA9377
From: Bartosz Markowski @ 2016-12-07 17:07 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Bartosz Markowski
In-Reply-To: <1481130454-27244-1-git-send-email-bartosz.markowski@tieto.com>
Similarly to QCA6174, QCA9377 requires the CE5 configuration to be
available for other feature. Use the ath10k_pci_override_ce_config()
for it as well.
This is required for TF2.0 firmware. Previous FW revisions were
working fine without this patch.
Fixes: a70587b3389a ("ath10k: configure copy engine 5 for HTT messages")
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
---
drivers/net/wireless/ath/ath10k/pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 983f65bbb7fb..85367006a80a 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -3132,7 +3132,7 @@ int ath10k_pci_setup_resource(struct ath10k *ar)
setup_timer(&ar_pci->rx_post_retry, ath10k_pci_rx_replenish_retry,
(unsigned long)ar);
- if (QCA_REV_6174(ar))
+ if (QCA_REV_6174(ar) || QCA_REV_9377(ar))
ath10k_pci_override_ce_config(ar);
ret = ath10k_pci_alloc_pipes(ar);
--
2.1.2
^ permalink raw reply related
* Re: [PATCH 10/14] rtlwifi: Add BTC_TRACE_STRING to new btcoex
From: Larry Finger @ 2016-12-07 16:41 UTC (permalink / raw)
To: Dan Carpenter, Kalle Valo; +Cc: Greg KH, devel, Ping-Ke Shih, linux-wireless
In-Reply-To: <20161207133219.GM8176@mwanda>
On 12/07/2016 07:32 AM, Dan Carpenter wrote:
> On Wed, Dec 07, 2016 at 02:16:06PM +0200, Kalle Valo wrote:
>> We have disccused this before, but for wireless it's not really that
>> simple. AFAIK with dyndbg you can only control the messages per line
>> (painful to enable group of messages) or per file (enables too many
>> messages). In wireless we have cases when we need to enable group of
>> messages, but not all.
>
> You can turn them on by the function or a range of lines, then disable
> the spammy lines. With these new debug macros you can't do that so this
> is a step backwards.
>
> If I'm totally honest, I've never seen uglier macros than these. I work
> in staging and I've spent a lot of time in ancient code but these ones
> really take the cake.
They will be coming out. The Realtek engineer and I are learning more about the
various options to see what to use. The dynamic debugging options seem to be the
best at the moment.
Larry
^ permalink raw reply
* Re: [v3,3/3] mt76: add driver code for MT76x2e
From: Felix Fietkau @ 2016-12-07 14:13 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <20161004164509.4DC5B61AF5@smtp.codeaurora.org>
On 2016-10-04 18:45, Kalle Valo wrote:
> Felix Fietkau <nbd@nbd.name> wrote:
>> From: Felix Fietkau <nbd@openwrt.org>
>>
>> This is a 2x2 PCIe 802.11ac chipset by MediaTek
>>
>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>
> I already asked this in v2, but what about firmware images? Will they be
> available from linux-firmware.git?
Seems that I forgot to submit it to linux-firmware@. I already had
permission from MediaTek to do so, so I just took sent it out.
- Felix
^ permalink raw reply
* Re: [v3,3/3] mt76: add driver code for MT76x2e
From: Felix Fietkau @ 2016-12-07 14:11 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <20161004163457.08D6861A06@smtp.codeaurora.org>
On 2016-10-04 18:34, Kalle Valo wrote:
> Felix Fietkau <nbd@nbd.name> wrote:
>> From: Felix Fietkau <nbd@openwrt.org>
>>
>> This is a 2x2 PCIe 802.11ac chipset by MediaTek
>>
>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>
> A summary of what feature work would be nice to have. Also if there's something
> notable which is not working it's good also to mention that.
>
> I don't know why I didn't see this earlier but this fails to build for me:
>
> ERROR: "mtd_read" [drivers/net/wireless/mediatek/mt76/mt76.ko] undefined!
> ERROR: "put_mtd_device" [drivers/net/wireless/mediatek/mt76/mt76.ko] undefined!
> ERROR: "get_mtd_device_nm" [drivers/net/wireless/mediatek/mt76/mt76.ko] undefined!
>
> Dependency to mtd missing?
Will fix the #ifdef in v4.
- Felix
^ permalink raw reply
* Re: [PATCH 23/39] Annotate hardware config module parameters in drivers/net/wireless/
From: David Howells @ 2016-12-07 13:45 UTC (permalink / raw)
To: Kalle Valo
Cc: dhowells, linux-kernel, gnomes, minyard, netdev, linux-wireless,
linux-security-module, keyrings
In-Reply-To: <8737i6syzq.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> wrote:
> Via which tree are you planning to submit this, should I take it to
> wireless-drivers or will someone else handle it? I didn't get the cover
> letter so I have no idea.
I'll see if I can get patch 1 (which defines the macros) in a window prior to
the others - or maybe I can get Linus to apply all of these together.
David
^ permalink raw reply
* Re: [PATCH] mac80211: Remove invalid flag operations in mesh TSF synchronization
From: Bob Copeland @ 2016-12-07 13:33 UTC (permalink / raw)
To: Masashi Honma; +Cc: Johannes Berg, Thomas Pedersen, linux-wireless
In-Reply-To: <9197b711-3d48-071a-57d8-53e2a11c26de@gmail.com>
On Wed, Dec 07, 2016 at 09:55:41PM +0900, Masashi Honma wrote:
> >It's called mesh_sync_offset_adjust_tbtt() which matches more closely
> >"TBTT adjustment" than "neighbor offset synchronization"?
>
> I think so. Because there is not any code creating "TBTT Adjustment Request
> frame" even though the frame is required by "TBTT adjustment".
This mesh_sync_offset_adjust_tbtt is definitely doing offset
synchronization, so probably "tbtt" should be renamed "tsf" here.
> >The code
> >looks more like offset synchronization though. Perhaps there's some
> >confusing and it's kinda doing both?
>
> In theory, updating the flag with 1) looks not correct because it is not
> clearly defined in spec.
>
> In practice, I could consider extending the meaning of the flag over the
> spec to use it to avoid referring the updating TSF value by peer as Thomas
> said. I have took the statistics how many TSF drift
> (ifmsh->sync_offset_clockdrift_max) happens. The attached file shows the
> stats. The horizontal axis shows TSF drift time(usec) and vertical axis
> shows how many time the drift occurred. The graph shows almost drifts are
> under 20usec. In contrast, 2) could causes more than 1000usec drift. So 1)
> looks not so large enough to protect with the flag.
Yes, offset synchronization is (given decent clocks) supposed to be only
for small tweaks. We will do it up to .8 ms drift though -- above .8 ms, we
just reset drift to zero and adopt the new timing offset. You can see this
kind of large "drift" by restarting a station.
Actually, looking at the code now it doesn't make a lot of sense to set
this flag for offset sync because TOFFSET_KNOWN flag is completely cleared
whenever that is set, so we have to be forgetting the current t_offset all
the time?
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* Re: [PATCH 10/14] rtlwifi: Add BTC_TRACE_STRING to new btcoex
From: Dan Carpenter @ 2016-12-07 13:32 UTC (permalink / raw)
To: Kalle Valo; +Cc: Greg KH, devel, Ping-Ke Shih, linux-wireless, Larry Finger
In-Reply-To: <871sxkdjeh.fsf@kamboji.qca.qualcomm.com>
On Wed, Dec 07, 2016 at 02:16:06PM +0200, Kalle Valo wrote:
> We have disccused this before, but for wireless it's not really that
> simple. AFAIK with dyndbg you can only control the messages per line
> (painful to enable group of messages) or per file (enables too many
> messages). In wireless we have cases when we need to enable group of
> messages, but not all.
You can turn them on by the function or a range of lines, then disable
the spammy lines. With these new debug macros you can't do that so this
is a step backwards.
If I'm totally honest, I've never seen uglier macros than these. I work
in staging and I've spent a lot of time in ancient code but these ones
really take the cake.
regards,
dan carpenter
^ permalink raw reply
* [patch] adm80211: return an error if adm8211_alloc_rings() fails
From: Dan Carpenter @ 2016-12-07 11:21 UTC (permalink / raw)
To: Kalle Valo, Michael Wu
Cc: Alexey Khoroshilov, Johannes Berg, linux-wireless,
kernel-janitors
We accidentally return success when adm8211_alloc_rings() fails but we
should preserve the error code.
Fixes: cc0b88cf5ecf ("[PATCH] Add adm8211 802.11b wireless driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/wireless/admtek/adm8211.c b/drivers/net/wireless/admtek/adm8211.c
index 2b4a3eb38dfa..098c814e22c8 100644
--- a/drivers/net/wireless/admtek/adm8211.c
+++ b/drivers/net/wireless/admtek/adm8211.c
@@ -1863,7 +1863,8 @@ static int adm8211_probe(struct pci_dev *pdev,
priv->rx_ring_size = rx_ring_size;
priv->tx_ring_size = tx_ring_size;
- if (adm8211_alloc_rings(dev)) {
+ err = adm8211_alloc_rings(dev);
+ if (err) {
printk(KERN_ERR "%s (adm8211): Cannot allocate TX/RX ring\n",
pci_name(pdev));
goto err_iounmap;
^ permalink raw reply related
* Re: [PATCH] mac80211: Remove invalid flag operations in mesh TSF synchronization
From: Masashi Honma @ 2016-12-07 12:55 UTC (permalink / raw)
To: Johannes Berg, Thomas Pedersen; +Cc: Bob Copeland, linux-wireless
In-Reply-To: <1481102652.4092.33.camel@sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]
On 2016年12月07日 18:24, Johannes Berg wrote:
>>> And the flag is refered by 1) as you said.
>>>
>>>
>>> The purpose of the flag is to prevent 1) while 2) is ongoing.
>>>
>>> In other words, 1) has only read access authority to the flag.
>>> However,
>>> previous code updated the flag in 1). In addition, there is no code
>>> for
>>> 2). So I just remove the invalid accessing codes.
>>
>> I don't think 1) has read only access to that flag. A TSF adjust will
>> by definition move the TBTT as well.
>
> It seems that the wording in the spec disagrees with that - it says
> (twice) to set the bit only while the TBTT adjustment procedure is
> ongoing, which isn't the case here?
>
> Then again, what exactly *is* this code doing?
>
> It's called mesh_sync_offset_adjust_tbtt() which matches more closely
> "TBTT adjustment" than "neighbor offset synchronization"?
I think so. Because there is not any code creating "TBTT Adjustment
Request frame" even though the frame is required by "TBTT adjustment".
> The code
> looks more like offset synchronization though. Perhaps there's some
> confusing and it's kinda doing both?
In theory, updating the flag with 1) looks not correct because it is not
clearly defined in spec.
In practice, I could consider extending the meaning of the flag over the
spec to use it to avoid referring the updating TSF value by peer as
Thomas said. I have took the statistics how many TSF drift
(ifmsh->sync_offset_clockdrift_max) happens. The attached file shows the
stats. The horizontal axis shows TSF drift time(usec) and vertical axis
shows how many time the drift occurred. The graph shows almost drifts
are under 20usec. In contrast, 2) could causes more than 1000usec drift.
So 1) looks not so large enough to protect with the flag.
Masashi Honma.
[-- Attachment #2: clockdrift.png --]
[-- Type: image/png, Size: 7951 bytes --]
^ permalink raw reply
* Re: [PATCH 10/14] rtlwifi: Add BTC_TRACE_STRING to new btcoex
From: Kalle Valo @ 2016-12-07 12:16 UTC (permalink / raw)
To: Greg KH; +Cc: Larry Finger, Dan Carpenter, devel, Ping-Ke Shih, linux-wireless
In-Reply-To: <20161206071340.GB10292@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Mon, Dec 05, 2016 at 04:34:08PM -0600, Larry Finger wrote:
>> On 12/05/2016 03:34 PM, Dan Carpenter wrote:
>> > On Thu, Dec 01, 2016 at 07:48:29PM -0600, Larry Finger wrote:
>> > > --- wireless-drivers-next.orig/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
>> > > +++ wireless-drivers-next/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
>> > > @@ -27,6 +27,29 @@
>> > >
>> > > #include "../wifi.h"
>> > >
>> > > +#ifdef CONFIG_RTLWIFI_DEBUG
>> > > +
>> > > +#define BTC_SPRINTF(ptr, ...) snprintf(ptr, ##__VA_ARGS__)
>> > > +#define BTC_TRACE(fmt) \
>> > > +do { \
>> > > + struct rtl_priv *rtlpriv = gl_bt_coexist.adapter; \
>> > > + if (!rtlpriv) \
>> > > + break; \
>> > > + RT_TRACE_STRING(rtlpriv, COMP_COEX, DBG_LOUD, fmt); \
>> > > +} while (0)
>> > > +
>> >
>> > This sort of macro is exactly when the rtl drivers spent so long in
>> > staging... Subsystems should not invent their own tracing but in
>> > particular these macros are so very very ugly.
>> >
>> > It's just super frustrating to even look at this...
>> >
>> > There are a lot of staging drivers I feel good about when they leave.
>> > The HyperV drivers. The IIO stuff. A lot of the media stuff and
>> > generally the media tree is getting better and better. I like comedi
>> > and unisys, those are in staging, but they are great and could move out
>> > any time as far as I'm concerned.
>> >
>> > But this patch just makes me super discouraged. What are we doing???
>>
>> Dan,
>>
>> It would not matter to me if these drivers got moved to staging, but there
>> are a lot of users whose distros do not build staging drivers that would be
>> very unhappy.
>>
>> Can you point me to a driver with a better way to conditionally dump a
>> debugging string to the logs?
>
> Just use 'dev_dbg()', or 'pr_debug()' if you don't have a device pointer
> (hint, all drivers should have that pointer). That can be turned on or
> off by a user dynamically as the kernel runs. No need to invent fancy
> custom macros for things we have already for many many years.
We have disccused this before, but for wireless it's not really that
simple. AFAIK with dyndbg you can only control the messages per line
(painful to enable group of messages) or per file (enables too many
messages). In wireless we have cases when we need to enable group of
messages, but not all. For example, some of the messages can slow down
the system so much that the bug is not reproducable anymore. So unless
dyndbg gets some sort of grouping support logging wrappers are needed
with wireless code.
(I'm talking in general here, I haven't looked at rtlwifi patches in
detail yet.)
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/1] net: wireless: intersil: fix improper return value
From: Kalle Valo @ 2016-12-07 12:00 UTC (permalink / raw)
To: Pan Bian; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <1480760572-4444-1-git-send-email-bianpan2016@163.com>
Pan Bian <bianpan2016@163.com> writes:
> Function orinoco_ioctl_commit() returns 0 (indicates success) when the
> call to orinoco_lock() fails. Thus, the return value is inconsistent with
> the execution status. It may be better to return "-EBUSY" when the call
> to orinoco_lock() fails.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188671
>
> Signed-off-by: Pan Bian <bianpan2016@163.com>
> ---
> drivers/net/wireless/intersil/orinoco/wext.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Please use prefix "orinoco:", more info:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#subject_name
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] iwlegacy: make il3945_mac_ops __ro_after_init
From: Stanislaw Gruszka @ 2016-12-07 10:53 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <20161207063646.30969-1-johannes@sipsolutions.net>
On Wed, Dec 07, 2016 at 07:36:46AM +0100, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> There's no need for this to be only __read_mostly, since
> it's only written in a single way depending on the module
> parameter, so that can be moved into the module's __init
> function, and the ops can be __ro_after_init.
>
> This is a little bit safer since it means the ops can't
> be overwritten (accidentally or otherwise), which would
> otherwise cause an arbitrary function or bad pointer to
> be called.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
^ permalink raw reply
* Re: [PATCH 1/4] cfg80211: Add support to enable or disable btcoex
From: Tamizh chelvam @ 2016-12-07 11:04 UTC (permalink / raw)
To: Johannes Berg; +Cc: c_traja, linux-wireless, ath10k
In-Reply-To: <1480949161.31788.23.camel@sipsolutions.net>
Hi Johannes,
Thanks for the comments.
On 2016-12-05 20:16, Johannes Berg wrote:
> On Tue, 2016-11-08 at 18:45 +0530, c_traja@qti.qualcomm.com wrote:
>> From: Tamizh chelvam <c_traja@qti.qualcomm.com>
>>
>> This patch adds support to enable or disable btcoex by
>> adding NL80211_ATTR_WIPHY_BTCOEX_ENABLE attribute in
>> NL80211_CMD_SET_WIPHY command. By default BTCOEX disabled in driver.
>
> I think overloading SET_WIPHY even more is a mistake - why not group
> this with the new command you're introducing in the second patch?
>
Sure.
> Also, can have a flag attribute to enable/disable, or better even
> disable when you're not setting any other parameters.
BTCOEX will be disabled by default. I will use
NL80211_ATTR_WIPHY_BTCOEX_ENABLE
attribute to enable/disable BTCOEX.
^ permalink raw reply
* RE: [1/2] mwifiex: code rearrangement in pcie.c and sdio.c
From: Amitkumar Karwar @ 2016-12-07 10:52 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam,
rajatja@google.com, briannorris@google.com,
dmitry.torokhov@gmail.com, Xinming Hu
In-Reply-To: <20161205110906.28C706034F@smtp.codeaurora.org>
SGkgS2FsbGUsDQoNCj4gRnJvbTogbGludXgtd2lyZWxlc3Mtb3duZXJAdmdlci5rZXJuZWwub3Jn
IFttYWlsdG86bGludXgtd2lyZWxlc3MtDQo+IG93bmVyQHZnZXIua2VybmVsLm9yZ10gT24gQmVo
YWxmIE9mIEthbGxlIFZhbG8NCj4gU2VudDogTW9uZGF5LCBEZWNlbWJlciAwNSwgMjAxNiA0OjM5
IFBNDQo+IFRvOiBBbWl0a3VtYXIgS2Fyd2FyDQo+IENjOiBsaW51eC13aXJlbGVzc0B2Z2VyLmtl
cm5lbC5vcmc7IENhdGh5IEx1bzsgTmlzaGFudCBTYXJtdWthZGFtOw0KPiByYWphdGphQGdvb2ds
ZS5jb207IGJyaWFubm9ycmlzQGdvb2dsZS5jb207IGRtaXRyeS50b3Jva2hvdkBnbWFpbC5jb207
DQo+IFhpbm1pbmcgSHU7IEFtaXRrdW1hciBLYXJ3YXINCj4gU3ViamVjdDogUmU6IFsxLzJdIG13
aWZpZXg6IGNvZGUgcmVhcnJhbmdlbWVudCBpbiBwY2llLmMgYW5kIHNkaW8uYw0KPiANCj4gQW1p
dGt1bWFyIEthcndhciA8YWthcndhckBtYXJ2ZWxsLmNvbT4gd3JvdGU6DQo+ID4gRnJvbTogWGlu
bWluZyBIdSA8aHV4bUBtYXJ2ZWxsLmNvbT4NCj4gPg0KPiA+IE5leHQgcGF0Y2ggaW4gdGhpcyBz
ZXJpZXMgaXMgZ29pbmcgdG8gdXNlIG13aWZpZXhfcmVhZF9yZWcoKSBpbg0KPiByZW1vdmUNCj4g
PiBoYW5kbGVycy4gVGhlIGNoYW5nZXMgaGVyZSBhcmUgcHJlcmVxdWlzaXRlcyB0byBhdm9pZCBm
b3J3YXJkDQo+ID4gZGVjbGFyYXRpb25zLg0KPiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogWGlubWlu
ZyBIdSA8aHV4bUBtYXJ2ZWxsLmNvbT4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBBbWl0a3VtYXIgS2Fy
d2FyIDxha2Fyd2FyQG1hcnZlbGwuY29tPg0KPiANCj4gRmFpbGVkIHRvIGFwcGx5Og0KPiANCj4g
ZmF0YWw6IHNoYTEgaW5mb3JtYXRpb24gaXMgbGFja2luZyBvciB1c2VsZXNzDQo+IChkcml2ZXJz
L25ldC93aXJlbGVzcy9tYXJ2ZWxsL213aWZpZXgvcGNpZS5jKS4NCj4gQXBwbHlpbmc6IG13aWZp
ZXg6IGdldCByaWQgb2YgZ2xvYmFsIHVzZXJfcm1tb2QgZmxhZyBSZXBvc2l0b3J5IGxhY2tzDQo+
IG5lY2Vzc2FyeSBibG9icyB0byBmYWxsIGJhY2sgb24gMy13YXkgbWVyZ2UuDQo+IENhbm5vdCBm
YWxsIGJhY2sgdG8gdGhyZWUtd2F5IG1lcmdlLg0KPiBQYXRjaCBmYWlsZWQgYXQgMDAwMSBtd2lm
aWV4OiBnZXQgcmlkIG9mIGdsb2JhbCB1c2VyX3JtbW9kIGZsYWcNCj4gDQo+IDIgcGF0Y2hlcyBz
ZXQgdG8gQ2hhbmdlcyBSZXF1ZXN0ZWQuDQo+IA0KPiA5NDU0NDkxIFsxLzJdIG13aWZpZXg6IGNv
ZGUgcmVhcnJhbmdlbWVudCBpbiBwY2llLmMgYW5kIHNkaW8uYw0KPiA5NDU0NDkzIFsyLzJdIG13
aWZpZXg6IGdldCByaWQgb2YgZ2xvYmFsIHVzZXJfcm1tb2QgZmxhZw0KPiANCj4gLS0NCj4gaHR0
cHM6Ly9wYXRjaHdvcmsua2VybmVsLm9yZy9wYXRjaC85NDU0NDkxLw0KPiANCj4gRG9jdW1lbnRh
dGlvbiBhYm91dCBzdWJtaXR0aW5nIHdpcmVsZXNzIHBhdGNoZXMgYW5kIGNoZWNraW5nIHN0YXR1
cw0KPiBmcm9tIHBhdGNod29yazoNCj4gDQo+IGh0dHBzOi8vd2lyZWxlc3Mud2lraS5rZXJuZWwu
b3JnL2VuL2RldmVsb3BlcnMvZG9jdW1lbnRhdGlvbi9zdWJtaXR0aW5nDQo+IHBhdGNoZXMNCg0K
DQpUaGVzZSB0d28gcGF0Y2hlcyBoYXZlIGRlcGVuZGVuY3kgd2l0aCBvdGhlciBwYXRjaCBzZXJp
ZXMuIEkgd2FudCB5b3UgdG8gY29uc2lkZXIgcGF0Y2hlcyBpbiBmb2xsb3dpbmcgb3JkZXIoZmly
c3QgYmVpbmcgcmVjZW50KS4NCg0KbXdpZmlleDogc2RpbzogZml4IHVzZSBhZnRlciBmcmVlIGlz
c3VlIGZvciBzYXZlX2FkYXB0ZXINCm13aWZpZXg6IHVzZSBtb2R1bGVfKl9kcml2ZXIgaGVscGVy
IG1hY3Jvcw0KDQpbMi8yXSBtd2lmaWV4OiBnZXQgcmlkIG9mIGdsb2JhbCB1c2VyX3JtbW9kIGZs
YWcNClsxLzJdIG13aWZpZXg6IGNvZGUgcmVhcnJhbmdlbWVudCBpbiBwY2llLmMgYW5kIHNkaW8u
Yw0KDQpbdjMsNS81XSBtd2lmaWV4OiBtb3ZlIHBjaWVfd29yayBhbmQgcmVsYXRlZCB2YXJpYWJs
ZXMgaW5zaWRlIGNhcmQgLS0tLS0tLS0gVGhpcyBzZXJpZXMgY2FuIGJlIGFjY2VwdGVkIGlmIHRo
ZXJlIGFyZSBubyBmdXJ0aGVyIGNvbmNlcm5zL2NvbW1lbnRzIGZyb20gQnJpYW4vRG1pdHJ5LiAN
Clt2Myw0LzVdIG13aWZpZXg6IHdhaXQgZmlybXdhcmUgZHVtcCBjb21wbGV0ZSBkdXJpbmcgY2Fy
ZCByZW1vdmUgcHJvY2Vzcw0KW3YzLDMvNV0gbXdpZmlleDogZ2V0IHJpZCBvZiBkcnZfaW5mbyog
YWRhcHRlciB2YXJpYWJsZXMNClt2MywyLzVdIG13aWZpZXg6IGRvIG5vdCBmcmVlIGZpcm13YXJl
IGR1bXAgbWVtb3J5IGluIHNodXRkb3duX2Rydg0KW3YzLDEvNV0gbXdpZmlleDogZG9uJ3Qgd2Fp
dCBmb3IgbWFpbl9wcm9jZXNzIGluIHNodXRkb3duX2Rydg0KDQpSZWdhcmRzLA0KQW1pdGt1bWFy
DQo=
^ permalink raw reply
* RE: [PATCH] mac80211: Ensure enough headroom when forwarding mesh pkt
From: Cedric Izoard @ 2016-12-07 9:57 UTC (permalink / raw)
To: Johannes Berg, linux-wireless@vger.kernel.org; +Cc: Laurent Trarieux
In-Reply-To: <1481103603.4092.38.camel@sipsolutions.net>
PiA+IC0JZndkX3NrYiA9IHNrYl9jb3B5KHNrYiwgR0ZQX0FUT01JQyk7DQo+ID4gKwlpZiAoc2ti
X2hlYWRyb29tKHNrYikgPj0gbG9jYWwtPnR4X2hlYWRyb29tKQ0KPiA+ICsJCWZ3ZF9za2IgPSBz
a2JfY29weShza2IsIEdGUF9BVE9NSUMpOw0KPiA+ICsJZWxzZQ0KPiA+ICsJCWZ3ZF9za2IgPSBz
a2JfY29weV9leHBhbmQoc2tiLCBsb2NhbC0+dHhfaGVhZHJvb20sDQo+ID4gKwkJCQkJwqDCoDAs
IEdGUF9BVE9NSUMpOw0KPiANCj4gV2h5IGJvdGhlciBtYWtpbmcgdGhpcyBjb25kaXRpb25hbD8g
SXQgc2VlbXMgdGhhdCBhbHdheXMgdXNpbmcNCj4gc2tiX2NvcHlfZXhwYW5kKCkgc2hvdWxkIGJl
IHN1ZmZpY2llbnQ/IFRoZSBjb2RlIGJldHdlZW4gdGhlIHR3byAoc2tiX2NvcHksDQo+IHNrYl9j
b3B5X2V4cGFuZCkgaXMgYWxtb3N0IGlkZW50aWNhbCBhbnl3YXksIGFwYXJ0IGZyb20gdGhlIGxh
dHRlciBzZXR0aW5nDQo+IHRoZSBoZWFkcm9vbSAoYW5kIHRhaWxyb29tKS4NCg0KSW5kZWVkLCBj
YWxsaW5nIHNrYl9jb3B5X2V4cGFuZCgpIHdvdWxkIHdvcmsgaW4gYW55IGNhc2UuDQpJIHdpbGwg
c2VuZCBuZXcgcGF0Y2gNCg0KY2VkcmljDQo=
^ permalink raw reply
* [PATCH v2] mac80211: Ensure enough headroom when forwarding mesh pkt
From: Cedric Izoard @ 2016-12-07 9:59 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
When a buffer is duplicated during MESH packet forwarding,
this patch ensures that the new buffer has enough headroom.
Signed-off-by: Cedric Izoard <cedric.izoard@ceva-dsp.com>
---
net/mac80211/rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index d2a00f2..bfa5f4d 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2468,7 +2468,7 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
if (!ifmsh->mshcfg.dot11MeshForwarding)
goto out;
- fwd_skb = skb_copy(skb, GFP_ATOMIC);
+ fwd_skb = skb_copy_expand(skb, local->tx_headroom, 0, GFP_ATOMIC);
if (!fwd_skb) {
net_info_ratelimited("%s: failed to clone mesh frame\n",
sdata->name);
--
2.7.4
^ permalink raw reply related
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