* Re: [PATCH] rt2500usb: don't mark register accesses as inline
From: Kalle Valo @ 2017-02-15 5:49 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Stanislaw Gruszka, Helmut Schaa, Mathias Kresin, linux-wireless,
netdev, linux-kernel
In-Reply-To: <20170214212846.2809141-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> When CONFIG_KASAN is set, we get a rather large stack here:
>
> drivers/net/wireless/ralink/rt2x00/rt2500usb.c: In function 'rt2500usb_set_device_state':
> drivers/net/wireless/ralink/rt2x00/rt2500usb.c:1074:1: error: the frame size of 3032 bytes is larger than 100 bytes [-Werror=frame-larger-than=]
>
> If we don't force those functions to be inline, the compiler can figure this
> out better itself and not inline the functions when doing so would be harmful,
> reducing the stack size to a merge 256 bytes.
>
> Note that there is another problem that manifests in this driver, as a result
> of the typecheck() macro causing even larger stack frames.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
[...]
> -static inline void rt2500usb_register_multiread(struct rt2x00_dev *rt2x00dev,
> - const unsigned int offset,
> - void *value, const u16 length)
> -{
> - rt2x00usb_vendor_request_buff(rt2x00dev, USB_MULTI_READ,
> - USB_VENDOR_REQUEST_IN, offset,
> - value, length);
> -}
> -
I guess you removed this because it was not actually used anywhere? Just
checking.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] mac80211: allow overriding station bandwidth.
From: Johannes Berg @ 2017-02-15 7:47 UTC (permalink / raw)
To: greearb, linux-wireless
In-Reply-To: <1487106095-23287-1-git-send-email-greearb@candelatech.com>
On Tue, 2017-02-14 at 13:01 -0800, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> This allows one to disable VHT160 (or 80+80) on hardware
> that might otherwise try to use it. One potential reason
> to do this is that at least some 160Mhz/80+80 hardware can
> only do 2x2 at 160Mhz, but can do 4x4 at 80Mhz. And, due to
> driver and firmware issues, it may effectively be limitted
> to 1x1 at 160Mhz for some NICs.
I think the feature is acceptable and don't mind adding that (though
perhaps we should start thinking about making some of these things
debug-only features), but I think the description of why you might want
to do this is misleading - those issues you're describing really should
be solved differently, and I posted the basis for that yesterday.
johannes
^ permalink raw reply
* Re: [PATCH] rt2500usb: don't mark register accesses as inline
From: Arnd Bergmann @ 2017-02-15 7:48 UTC (permalink / raw)
To: Kalle Valo
Cc: Stanislaw Gruszka, Helmut Schaa, Mathias Kresin, linux-wireless,
Networking, Linux Kernel Mailing List
In-Reply-To: <8760kcovf1.fsf@kamboji.qca.qualcomm.com>
On Wed, Feb 15, 2017 at 6:49 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
>> When CONFIG_KASAN is set, we get a rather large stack here:
>>
>> drivers/net/wireless/ralink/rt2x00/rt2500usb.c: In function 'rt2500usb_set_device_state':
>> drivers/net/wireless/ralink/rt2x00/rt2500usb.c:1074:1: error: the frame size of 3032 bytes is larger than 100 bytes [-Werror=frame-larger-than=]
>>
>> If we don't force those functions to be inline, the compiler can figure this
>> out better itself and not inline the functions when doing so would be harmful,
>> reducing the stack size to a merge 256 bytes.
>>
>> Note that there is another problem that manifests in this driver, as a result
>> of the typecheck() macro causing even larger stack frames.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> [...]
>
>> -static inline void rt2500usb_register_multiread(struct rt2x00_dev *rt2x00dev,
>> - const unsigned int offset,
>> - void *value, const u16 length)
>> -{
>> - rt2x00usb_vendor_request_buff(rt2x00dev, USB_MULTI_READ,
>> - USB_VENDOR_REQUEST_IN, offset,
>> - value, length);
>> -}
>> -
>
> I guess you removed this because it was not actually used anywhere? Just
> checking.
Correct, if I just remove the 'inline' annotation, we get a warning about an
unused function here. Sorry for not mentioning that in the changelog.
Arnd
^ permalink raw reply
* Re: [PATCH v3 1/2] cfg80211: Add support to set tx power for a station associated
From: Johannes Berg @ 2017-02-15 7:53 UTC (permalink / raw)
To: Ashok Raj Nagarajan, linux-wireless; +Cc: ath10k, arnagara
In-Reply-To: <1486554984-25097-1-git-send-email-arnagara@qti.qualcomm.com>
> + * @txpwr: tx power (in mBm) to be used for sending data traffic. If
> tx power
> + * is not provided, the default per-interface tx power
> setting will be
> + * overriding. Driver should be picking up the lowest tx
> power, either tx
> + * power per-interface or per-station.
> */
> struct station_parameters {
> const u8 *supported_rates;
> @@ -876,6 +881,7 @@ struct station_parameters {
> u8 opmode_notif;
> bool opmode_notif_used;
> int support_p2p_ps;
> + u16 txpwr;
> };
Wouldn't it be better to add the tx power type (limited/automatic) here
as well? That way, we don't have to play games with 0 meaning automatic
(which you didn't even document, but seems to be the case), when in
fact 0dBm could technically be a valid TX power as well.
> + idx = NL80211_ATTR_STA_TX_POWER_SETTING;
> + type = nla_get_u32(info->attrs[idx]);
> +
> + if (!info->attrs[NL80211_ATTR_STA_TX_POWER] &&
> + (type != NL80211_TX_POWER_AUTOMATIC))
> + return -EINVAL;
> +
> + if (type != NL80211_TX_POWER_AUTOMATIC) {
> + if (type == NL80211_TX_POWER_LIMITED) {
> + idx = NL80211_ATTR_STA_TX_POWER;
> + params->txpwr = nla_get_u32(info-
> >attrs[idx]);
> + } else {
> + return -EINVAL;
> + }
> + } else {
> + params->txpwr = 0;
> + }
This could be nicer using a switch on the type, perhaps?
> + if (info->attrs[NL80211_ATTR_STA_TX_POWER_SETTING]) {
> + err = nl80211_parse_sta_txpower_setting(info,
¶ms);
> + if (err)
> + return err;
> + }
Why not move the check that the attribute exists into the function?
johannes
^ permalink raw reply
* Re: [PATCH v3 2/2] mac80211: store tx power value from user to station
From: Johannes Berg @ 2017-02-15 7:56 UTC (permalink / raw)
To: Ashok Raj Nagarajan, linux-wireless; +Cc: ath10k, arnagara
In-Reply-To: <1486555011-25143-1-git-send-email-arnagara@qti.qualcomm.com>
> + * @txpwr: indicates the tx power, in mBm, to be used when sending data frames
+ * to the STA. Value of 0 means, automatic (default) tx power.
Similarly here, I'm not too sure about 0 meaning automatic.
johannes
^ permalink raw reply
* Re: [PATCH v3] ath10k: add support for controlling tx power to a station
From: Johannes Berg @ 2017-02-15 8:00 UTC (permalink / raw)
To: Ashok Raj Nagarajan, ath10k; +Cc: linux-wireless, arnagara
In-Reply-To: <1486555117-25196-1-git-send-email-arnagara@qti.qualcomm.com>
On Wed, 2017-02-08 at 17:28 +0530, Ashok Raj Nagarajan wrote:
> This patch will add the support to control the transmit power for
> traffic
> to a station associated with the AP. Userspace provide the transmit
> power
> value in mBm units. ath10k firmware expects the value to be in dBm
> and
> hence will convert the value from to dBm before passing down to
> firmware.
>
> Underlying FW will enforce that the maximum tx power will be based on
> the
> regulatory requirements. If the user given transmit power is greater
> than
> the allowed tx power in the given channel, then the FW will use the
> maximum
> tx power in the same channel.
The firmware command has a bit of a misleading name, but if this really
is the behaviour then all should be OK.
> When 0 is sent to the FW as tx power, it will revert to the automatic
> tx power for the station.
So this is where the 0 comes from, perhaps - but I think it'd be better
to do that translation in the driver.
Come to think of it, you're also missing range-checks entirely, so if I
give you some insane value you'd still send it down - no chance the
firmware will be unhappy?
Also, you should probably accept negative values for the TX power, and
make that an s32 instead of u32 across the patchset.
johannes
> Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>
> ---
> v3:
> - reword commit log
> - remove range check for the input from user. (Ben Greear)
>
> drivers/net/wireless/ath/ath10k/mac.c | 31
> +++++++++++++++++++++++++++++++
> drivers/net/wireless/ath/ath10k/wmi.h | 1 +
> 2 files changed, 32 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
> b/drivers/net/wireless/ath/ath10k/mac.c
> index 9977829..3b91468 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -5985,6 +5985,32 @@ static int ath10k_mac_tdls_vifs_count(struct
> ieee80211_hw *hw)
> return num_tdls_vifs;
> }
>
> +static int ath10k_sta_set_txpwr(struct ieee80211_hw *hw,
> + struct ieee80211_vif *vif,
> + struct ieee80211_sta *sta)
> +{
> + struct ath10k *ar = hw->priv;
> + struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
> + int ret = 0;
> + u16 txpwr;
> +
> + txpwr = MBM_TO_DBM(sta->txpwr);
> +
> + mutex_lock(&ar->conf_mutex);
> +
> + ret = ath10k_wmi_peer_set_param(ar, arvif->vdev_id, sta-
> >addr,
> + WMI_PEER_USE_FIXED_PWR,
> txpwr);
> + if (ret) {
> + ath10k_warn(ar, "failed to set tx power for station
> ret: %d\n",
> + ret);
> + goto out;
> + }
> +
> +out:
> + mutex_unlock(&ar->conf_mutex);
> + return ret;
> +}
> +
> static int ath10k_sta_state(struct ieee80211_hw *hw,
> struct ieee80211_vif *vif,
> struct ieee80211_sta *sta,
> @@ -7550,6 +7576,7 @@ static void
> ath10k_mac_op_sta_pre_rcu_remove(struct ieee80211_hw *hw,
> .set_key = ath10k_set_key,
> .set_default_unicast_key =
> ath10k_set_default_unicast_key,
> .sta_state = ath10k_sta_state,
> + .sta_set_txpwr =
> ath10k_sta_set_txpwr,
> .conf_tx = ath10k_conf_tx,
> .remain_on_channel =
> ath10k_remain_on_channel,
> .cancel_remain_on_channel =
> ath10k_cancel_remain_on_channel,
> @@ -8193,11 +8220,15 @@ int ath10k_mac_register(struct ath10k *ar)
> ar->hw->wiphy->iface_combinations =
> ath10k_10x_if_comb;
> ar->hw->wiphy->n_iface_combinations =
> ARRAY_SIZE(ath10k_10x_if_comb);
> + wiphy_ext_feature_set(ar->hw->wiphy,
> + NL80211_EXT_FEATURE_STA_TX_PWR
> );
> break;
> case ATH10K_FW_WMI_OP_VERSION_10_4:
> ar->hw->wiphy->iface_combinations =
> ath10k_10_4_if_comb;
> ar->hw->wiphy->n_iface_combinations =
> ARRAY_SIZE(ath10k_10_4_if_comb);
> + wiphy_ext_feature_set(ar->hw->wiphy,
> + NL80211_EXT_FEATURE_STA_TX_PWR
> );
> break;
> case ATH10K_FW_WMI_OP_VERSION_UNSET:
> case ATH10K_FW_WMI_OP_VERSION_MAX:
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
> b/drivers/net/wireless/ath/ath10k/wmi.h
> index 861c2d8..1ccb6bf 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.h
> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
> @@ -5811,6 +5811,7 @@ enum wmi_peer_param {
> WMI_PEER_CHAN_WIDTH = 0x4,
> WMI_PEER_NSS = 0x5,
> WMI_PEER_USE_4ADDR = 0x6,
> + WMI_PEER_USE_FIXED_PWR = 0x8,
> WMI_PEER_DUMMY_VAR = 0xff, /* dummy parameter for STA PS
> workaround */
> };
>
^ permalink raw reply
* Re: [PATCH v3] iw: Add support for controlling tx power for per station
From: Johannes Berg @ 2017-02-15 8:03 UTC (permalink / raw)
To: Ashok Raj Nagarajan; +Cc: linux-wireless, ath10k, arnagara
In-Reply-To: <1486555277-25258-1-git-send-email-arnagara@qti.qualcomm.com>
> + sta_txpwr = strtoul(argv[0], &err, 0);
you should error-check this.
> + NLA_PUT_U32(msg, NL80211_ATTR_STA_TX_POWER,
> sta_txpwr);
> + }
> +}
> +COMMAND_ALIAS(station, set, "<MAC address> txpwr <auto|limit> [<tx
> power mBm>]",
>
Seems like that should be
<MAC address> txpwr <auto|limit <tx power dBm>>
or so?
I made that dBm there, doing that and parsing floating point numbers
would be nice I think.
johannes
^ permalink raw reply
* Re: [PATCH 1/2] mac80211: use DECLARE_EWMA for mesh_fail_avg
From: Johannes Berg @ 2017-02-15 8:13 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: linux-wireless, rmanohar
In-Reply-To: <1487104037-24941-1-git-send-email-rmanohar@qca.qualcomm.com>
On Tue, 2017-02-14 at 12:27 -0800, Rajkumar Manoharan wrote:
> As moving average is not considering fractional part, it
> will stuck at the same level after certain state. For example
> with current values, moving average stuck at 96 and it will
> not move forward. Fortunately current threshold is matching
> against 95%. If thresold is increased more than 96, mesh path
> never be deactivated under worst case. Fix failure average
> movement by using EWMA helpers.
Thanks, applied.
> +DECLARE_EWMA(mesh_fail_avg, 64, 8)
Since we only feed in small values (0-100), I picked a much larger
factor (1<<20) to give more precision here.
johannes
^ permalink raw reply
* Re: [PATCH 2/2] mac80211: fix mesh fail_avg check
From: Johannes Berg @ 2017-02-15 8:14 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: linux-wireless, rmanohar
In-Reply-To: <1487104037-24941-2-git-send-email-rmanohar@qca.qualcomm.com>
On Tue, 2017-02-14 at 12:27 -0800, Rajkumar Manoharan wrote:
> Mesh failure average never be more than 100. Only in case of
> fixed path, average will be more than threshold limit (95%).
> With recent EWMA changes it may go upto 99 as it is scaled to
> 100. It make sense to return maximum metric when average is
> greater than threshold limit.
>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
> ---
> net/mac80211/mesh_hwmp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
> index d07ee3ca07ee..02c30a21eb66 100644
> --- a/net/mac80211/mesh_hwmp.c
> +++ b/net/mac80211/mesh_hwmp.c
> @@ -339,7 +339,7 @@ static u32 airtime_link_metric_get(struct
> ieee80211_local *local,
> if (rate) {
> err = 0;
> } else {
> - if (fail_avg >= 100)
> + if (fail_avg >= 95)
> return MAX_METRIC;
Why is this >= and the other place is >?
Also, I think it'd be good to introduce a #define for this value now,
perhaps something like "LINK_FAIL_THRESH".
johannes
^ permalink raw reply
* Re: [PATCH v6 1/3] cfg80211: Accept multiple RSSI thresholds for CQM
From: Johannes Berg @ 2017-02-15 8:27 UTC (permalink / raw)
To: Andrew Zaborowski, linux-wireless
In-Reply-To: <20170210090231.14696-1-andrew.zaborowski@intel.com>
On Fri, 2017-02-10 at 10:02 +0100, Andrew Zaborowski wrote:
> Change the SET CQM command's RSSI threshold attribute to accept any
> number of thresholds as a sorted array. The API should be backwards
> compatible so that if one s32 threshold value is passed, the old
> mechanism is enabled. The netlink event generated is the same in
> both cases.
I've applied this now, thanks for your patience :)
I got a bit confused - and then fixed it up - patchwork has giving your
name as "Andrzej Zaborowski" which apparently you didn't really want
(any more). I've fixed it for these patches to be as the patches you
sent, but no guarantees I've done this before or will remember to do
that in the future - if you can somehow change your name in patchwork
(patchwork.kernel.org) that would be good.
johannes
^ permalink raw reply
* Re: [PATCH v5 3/3] wireless: Set NL80211_EXT_FEATURE_CQM_RSSI_LIST in multiple drivers
From: Johannes Berg @ 2017-02-15 8:28 UTC (permalink / raw)
To: Andrew Zaborowski, linux-wireless
In-Reply-To: <20170210035023.11471-3-andrew.zaborowski@intel.com>
On Fri, 2017-02-10 at 04:50 +0100, Andrew Zaborowski wrote:
> Set the NL80211_EXT_FEATURE_CQM_RSSI_LIST wiphy extended feature
> wholesale in all mac80211-based drivers that do not set the
> IEEE80211_VIF_BEACON_FILTER flags on their interfaces. mac80211 will
> be processing supplied RSSI values in ieee80211_rx_mgmt_beacon and
> will detect when the thresholds set by
> ieee80211_set_cqm_rssi_range_config are crossed. Remaining (few)
> drivers need code to enable the firmware to monitor the thresholds.
> This is mostly only compile-tested.
>
Also applied 2 & 3 of this set, but I removed the staging driver
changes since I don't really want to deal with those. If you care much
send them to Greg separately, I guess.
johannes
^ permalink raw reply
* [PATCH] average: change to declare precision, not factor
From: Johannes Berg @ 2017-02-15 8:49 UTC (permalink / raw)
To: linux-wireless
Cc: netdev, Michael S . Tsirkin, Jason Wang, virtualization,
Marek Lindner, Simon Wunderlich, Antonio Quartulli,
Stanislaw Gruszka, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Declaring the factor is counter-intuitive, and people are prone
to using small(-ish) values even when that makes no sense.
Change the DECLARE_EWMA() macro to take the fractional precision,
in bits, rather than a factor, and update all users.
While at it, add some more documentation.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
Unless I hear any objections, I will take this through my tree.
---
drivers/net/virtio_net.c | 2 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 2 +-
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 2 +-
include/linux/average.h | 61 +++++++++++++++++++----------
net/batman-adv/types.h | 2 +-
net/mac80211/ieee80211_i.h | 2 +-
net/mac80211/sta_info.h | 6 +--
7 files changed, 49 insertions(+), 28 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 11e28530c83c..5e0cc9ec0f81 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -49,7 +49,7 @@ module_param(gso, bool, 0444);
* at once, the weight is chosen so that the EWMA will be insensitive to short-
* term, transient changes in packet size.
*/
-DECLARE_EWMA(pkt_len, 1, 64)
+DECLARE_EWMA(pkt_len, 0, 64)
/* With mergeable buffers we align buffer address and use the low bits to
* encode its true size. Buffer size is up to 1 page so we need to align to
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index 67fedb61fcc0..979800c6f57f 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -1252,7 +1252,7 @@ struct ath5k_statistics {
#define ATH5K_TXQ_LEN_MAX (ATH_TXBUF / 4) /* bufs per queue */
#define ATH5K_TXQ_LEN_LOW (ATH5K_TXQ_LEN_MAX / 2) /* low mark */
-DECLARE_EWMA(beacon_rssi, 1024, 8)
+DECLARE_EWMA(beacon_rssi, 10, 8)
/* Driver state associated with an instance of a device */
struct ath5k_hw {
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00.h b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
index 26869b3bef45..340787894c69 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
@@ -257,7 +257,7 @@ struct link_qual {
int tx_failed;
};
-DECLARE_EWMA(rssi, 1024, 8)
+DECLARE_EWMA(rssi, 10, 8)
/*
* Antenna settings about the currently active link.
diff --git a/include/linux/average.h b/include/linux/average.h
index d04aa58280de..7ddaf340d2ac 100644
--- a/include/linux/average.h
+++ b/include/linux/average.h
@@ -1,45 +1,66 @@
#ifndef _LINUX_AVERAGE_H
#define _LINUX_AVERAGE_H
-/* Exponentially weighted moving average (EWMA) */
+/*
+ * Exponentially weighted moving average (EWMA)
+ *
+ * This implements a fixed-precision EWMA algorithm, with both the
+ * precision and fall-off coefficient determined at compile-time
+ * and built into the generated helper funtions.
+ *
+ * The first argument to the macro is the name that will be used
+ * for the struct and helper functions.
+ *
+ * The second argument, the precision, expresses how many bits are
+ * used for the fractional part of the fixed-precision values.
+ *
+ * The third argument, the weight reciprocal, determines how the
+ * new values will be weighed vs. the old state, new values will
+ * get weight 1/weight_rcp and old values 1-1/weight_rcp. Note
+ * that this parameter must be a power of two for efficiency.
+ */
-#define DECLARE_EWMA(name, _factor, _weight) \
+#define DECLARE_EWMA(name, _precision, _weight_rcp) \
struct ewma_##name { \
unsigned long internal; \
}; \
static inline void ewma_##name##_init(struct ewma_##name *e) \
{ \
- BUILD_BUG_ON(!__builtin_constant_p(_factor)); \
- BUILD_BUG_ON(!__builtin_constant_p(_weight)); \
- BUILD_BUG_ON_NOT_POWER_OF_2(_factor); \
- BUILD_BUG_ON_NOT_POWER_OF_2(_weight); \
+ BUILD_BUG_ON(!__builtin_constant_p(_precision)); \
+ BUILD_BUG_ON(!__builtin_constant_p(_weight_rcp)); \
+ /* \
+ * Even if you want to feed it just 0/1 you should have \
+ * some bits for the non-fractional part... \
+ */ \
+ BUILD_BUG_ON((_precision) > 30); \
+ BUILD_BUG_ON_NOT_POWER_OF_2(_weight_rcp); \
e->internal = 0; \
} \
static inline unsigned long \
ewma_##name##_read(struct ewma_##name *e) \
{ \
- BUILD_BUG_ON(!__builtin_constant_p(_factor)); \
- BUILD_BUG_ON(!__builtin_constant_p(_weight)); \
- BUILD_BUG_ON_NOT_POWER_OF_2(_factor); \
- BUILD_BUG_ON_NOT_POWER_OF_2(_weight); \
- return e->internal >> ilog2(_factor); \
+ BUILD_BUG_ON(!__builtin_constant_p(_precision)); \
+ BUILD_BUG_ON(!__builtin_constant_p(_weight_rcp)); \
+ BUILD_BUG_ON((_precision) > 30); \
+ BUILD_BUG_ON_NOT_POWER_OF_2(_weight_rcp); \
+ return e->internal >> (_precision); \
} \
static inline void ewma_##name##_add(struct ewma_##name *e, \
unsigned long val) \
{ \
unsigned long internal = ACCESS_ONCE(e->internal); \
- unsigned long weight = ilog2(_weight); \
- unsigned long factor = ilog2(_factor); \
+ unsigned long weight_rcp = ilog2(_weight_rcp); \
+ unsigned long precision = _precision; \
\
- BUILD_BUG_ON(!__builtin_constant_p(_factor)); \
- BUILD_BUG_ON(!__builtin_constant_p(_weight)); \
- BUILD_BUG_ON_NOT_POWER_OF_2(_factor); \
- BUILD_BUG_ON_NOT_POWER_OF_2(_weight); \
+ BUILD_BUG_ON(!__builtin_constant_p(_precision)); \
+ BUILD_BUG_ON(!__builtin_constant_p(_weight_rcp)); \
+ BUILD_BUG_ON((_precision) > 30); \
+ BUILD_BUG_ON_NOT_POWER_OF_2(_weight_rcp); \
\
ACCESS_ONCE(e->internal) = internal ? \
- (((internal << weight) - internal) + \
- (val << factor)) >> weight : \
- (val << factor); \
+ (((internal << weight_rcp) - internal) + \
+ (val << precision)) >> weight_rcp : \
+ (val << precision); \
}
#endif /* _LINUX_AVERAGE_H */
diff --git a/net/batman-adv/types.h b/net/batman-adv/types.h
index 8f64a5c01345..66b25e410a41 100644
--- a/net/batman-adv/types.h
+++ b/net/batman-adv/types.h
@@ -402,7 +402,7 @@ struct batadv_gw_node {
struct rcu_head rcu;
};
-DECLARE_EWMA(throughput, 1024, 8)
+DECLARE_EWMA(throughput, 10, 8)
/**
* struct batadv_hardif_neigh_node_bat_v - B.A.T.M.A.N. V private neighbor
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 159a1a733725..0e718437d080 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -428,7 +428,7 @@ struct ieee80211_sta_tx_tspec {
bool downgraded;
};
-DECLARE_EWMA(beacon_signal, 16, 4)
+DECLARE_EWMA(beacon_signal, 4, 4)
struct ieee80211_if_managed {
struct timer_list timer;
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 71fa41a1368a..90a2c4deb00c 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -322,8 +322,8 @@ struct ieee80211_fast_rx {
struct rcu_head rcu_head;
};
-/* we use only values in the range 0-100, so pick a large factor */
-DECLARE_EWMA(mesh_fail_avg, 1048576, 8)
+/* we use only values in the range 0-100, so pick a large precision */
+DECLARE_EWMA(mesh_fail_avg, 20, 8)
/**
* struct mesh_sta - mesh STA information
@@ -373,7 +373,7 @@ struct mesh_sta {
struct ewma_mesh_fail_avg fail_avg;
};
-DECLARE_EWMA(signal, 1024, 8)
+DECLARE_EWMA(signal, 10, 8)
struct ieee80211_sta_rx_stats {
unsigned long packets;
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v6 1/3] cfg80211: Accept multiple RSSI thresholds for CQM
From: Kalle Valo @ 2017-02-15 8:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: Andrew Zaborowski, linux-wireless
In-Reply-To: <1487147264.4026.13.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Fri, 2017-02-10 at 10:02 +0100, Andrew Zaborowski wrote:
>> Change the SET CQM command's RSSI threshold attribute to accept any
>> number of thresholds as a sorted array.=C2=A0=C2=A0The API should be bac=
kwards
>> compatible so that if one s32 threshold value is passed, the old
>> mechanism is enabled.=C2=A0=C2=A0The netlink event generated is the same=
in
>> both cases.
>
> I've applied this now, thanks for your patience :)
>
> I got a bit confused - and then fixed it up - patchwork has giving your
> name as "Andrzej Zaborowski" which apparently you didn't really want
> (any more). I've fixed it for these patches to be as the patches you
> sent, but no guarantees I've done this before or will remember to do
> that in the future - if you can somehow change your name in patchwork
> (patchwork.kernel.org) that would be good.
IIRC if you haven't registered to patchwork.kernel.org it's possible to
change the name easily. But after registration the user needs to contact
helpdesk to change the name.
Please let me know if there's an easier way to change the name. This is
not the first time this comes up.
--=20
Kalle Valo
^ permalink raw reply
* Re: [RFC-PATCH] ath9k_htc: Adjust beacon timers for Power Save
From: Kalle Valo @ 2017-02-15 9:02 UTC (permalink / raw)
To: Doru
Cc: linux-wireless, ath9k_htc_fw, andra.paraschiv7, costin.raiciu,
dragos.niculescu
In-Reply-To: <1487100985-4194-1-git-send-email-gucea.doru@gmail.com>
Doru <gucea.doru@gmail.com> writes:
> From: Doru Gucea <gucea.doru@gmail.com>
>
> Each time we receive a beacon we need to adjust the hardware
> timers for next DTIM and next TBTT.
>
> Before this commit, the Power Save behaviour was incorrect.
> The scenario was:
> - STA receives a beacon from AP with TIM unset;
> - mac80211 layers puts the chip to sleep;
> - chip is woken up by mac80211's software timer reponsible for
> beacon miss after 7 * beacon_interval period.
>
> Normally the chip should sleep at most DTIM period. This commit
> configures hardware timers for waking up the chip correctly.
>
> More details on the wiki:
> https://github.com/doru91/linux-stable/wiki/Single-Interface-Power-Save
>
> Signed-off-by: Doru Gucea <gucea.doru@gmail.com>
> ---
> drivers/net/wireless/ath/ath9k/htc_drv_main.c | 4 ++++
> net/mac80211/mlme.c | 6 ++++++
> 2 files changed, 10 insertions(+)
[...]
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -3536,6 +3536,12 @@ static void ieee80211_rx_mgmt_beacon(struct ieee80211_sub_if_data *sdata,
> sdata->vif.bss_conf.sync_dtim_count = 0;
> }
>
> + /* trigger hardware timers adjustment
> + * this needs to be done before beacon filtering
> + */
> + changed |= BSS_CHANGED_BEACON_INFO;
> + ieee80211_bss_info_change_notify(sdata, changed);
You shouldn't mix driver and mac80211 changes in the same patch, I
suspect Johannes didn't even notice this change because of that. Create
a new patchset with two patches, one for ath9k and another for mac80211.
--
Kalle Valo
^ permalink raw reply
* Re: [RFC v2 3/7] ieee80211: add new VHT capability fields/parsing
From: Arend Van Spriel @ 2017-02-15 9:08 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: j, greearb, Johannes Berg
In-Reply-To: <20170214132208.8715-4-johannes@sipsolutions.net>
On 14-2-2017 14:22, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> IEEE 802.11-2016 extended the VHT capability fields to allow
> indicating the number of spatial streams depending on the
> actually used bandwidth, add support for decoding this.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> include/linux/ieee80211.h | 105 +++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 103 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
> index 4a7200c6c9ea..c51d309a45e7 100644
> --- a/include/linux/ieee80211.h
> +++ b/include/linux/ieee80211.h
> @@ -1457,13 +1457,16 @@ struct ieee80211_ht_operation {
> * STA can receive. Rate expressed in units of 1 Mbps.
> * If this field is 0 this value should not be used to
> * consider the highest RX data rate supported.
> - * The top 3 bits of this field are reserved.
> + * The top 3 bits of this field indicate the Maximum NSTS,total
> + * (a beamformee capability.)
> * @tx_mcs_map: TX MCS map 2 bits for each stream, total 8 streams
> * @tx_highest: Indicates highest long GI VHT PPDU data rate
> * STA can transmit. Rate expressed in units of 1 Mbps.
> * If this field is 0 this value should not be used to
> * consider the highest TX data rate supported.
> - * The top 3 bits of this field are reserved.
> + * The top 2 bits of this field are reserved, the
> + * 3rd bit from the top indiciates VHT Extended NSS BW
> + * Capability.
> */
> struct ieee80211_vht_mcs_info {
> __le16 rx_mcs_map;
> @@ -1472,6 +1475,13 @@ struct ieee80211_vht_mcs_info {
> __le16 tx_highest;
> } __packed;
>
> +/* for rx_highest */
> +#define IEEE80211_VHT_MAX_NSTS_TOTAL_SHIFT 13
> +#define IEEE80211_VHT_MAX_NSTS_TOTAL_MASK (7 << IEEE80211_VHT_MAX_NSTS_TOTAL_SHIFT)
> +
> +/* for tx_highest */
> +#define IEEE80211_VHT_EXT_NSS_BW_CAPABLE (1 << 13)
> +
> /**
> * enum ieee80211_vht_mcs_support - VHT MCS support definitions
> * @IEEE80211_VHT_MCS_SUPPORT_0_7: MCSes 0-7 are supported for the
> @@ -1547,6 +1557,7 @@ struct ieee80211_vht_operation {
> #define IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ 0x00000004
> #define IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ 0x00000008
> #define IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK 0x0000000C
> +#define IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_SHIFT 2
> #define IEEE80211_VHT_CAP_RXLDPC 0x00000010
> #define IEEE80211_VHT_CAP_SHORT_GI_80 0x00000020
> #define IEEE80211_VHT_CAP_SHORT_GI_160 0x00000040
> @@ -1575,6 +1586,96 @@ struct ieee80211_vht_operation {
> #define IEEE80211_VHT_CAP_VHT_LINK_ADAPTATION_VHT_MRQ_MFB 0x0c000000
> #define IEEE80211_VHT_CAP_RX_ANTENNA_PATTERN 0x10000000
> #define IEEE80211_VHT_CAP_TX_ANTENNA_PATTERN 0x20000000
> +#define IEEE80211_VHT_CAP_EXT_NSS_BW_SHIFT 30
> +#define IEEE80211_VHT_CAP_EXT_NSS_BW_MASK 0xc0000000
> +
> +static int __maybe_unused
> +ieee80211_get_vht_max_nss(struct ieee80211_vht_cap *cap,
> + enum ieee80211_vht_chanwidth bw,
> + int mcs)
> +{
> + u16 map = le16_to_cpu(cap->supp_mcs.rx_mcs_map);
> + int max_vht_nss;
> + int ext_nss_bw;
> + int supp_width;
> + int i, mcs_encoding;
> +
> + if (map == 0xffff)
> + return 0;
> +
> + if (WARN_ON(mcs > 9))
> + return 0;
> + if (mcs <= 7)
> + mcs_encoding = 0;
> + else if (mcs == 8)
> + mcs_encoding = 1;
> + else
> + mcs_encoding = 2;
> +
> + /* find max_vht_nss for the given MCS */
> + for (i = 7; i >= 0; i--) {
> + int supp = (map >> (2*i)) & 3;
> +
> + if (supp == 3)
> + continue;
> +
> + if (supp >= mcs_encoding) {
> + max_vht_nss = i;
> + break;
> + }
> + }
> +
> + if (!(cap->supp_mcs.tx_mcs_map & cpu_to_le16(IEEE80211_VHT_EXT_NSS_BW_CAPABLE)))
> + return max_vht_nss;
> +
> + ext_nss_bw = (le32_to_cpu(cap->vht_cap_info) &
> + IEEE80211_VHT_CAP_EXT_NSS_BW_MASK)
> + >> IEEE80211_VHT_CAP_EXT_NSS_BW_SHIFT;
> + supp_width = (le32_to_cpu(cap->vht_cap_info) &
> + IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK)
> + >> IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_SHIFT;
> +
> + /*
> + * Cover all the special cases according to IEEE 802.11-2016 Table 9-250.
> + * All other cases are either factor of 1 or not valid/supported.
> + */
> + switch (bw) {
> + case IEEE80211_VHT_CHANWIDTH_USE_HT:
> + case IEEE80211_VHT_CHANWIDTH_80MHZ:
> + if ((supp_width == 1 || supp_width == 2) &&
> + ext_nss_bw == 3)
> + return 2 * max_vht_nss;
> + break;
> + case IEEE80211_VHT_CHANWIDTH_160MHZ:
> + if (supp_width == 0 &&
> + (ext_nss_bw == 1 || ext_nss_bw == 2))
> + return DIV_ROUND_UP(max_vht_nss, 2);
> + if (supp_width == 0 &&
> + ext_nss_bw == 3)
> + return DIV_ROUND_UP(3 * max_vht_nss, 4);
> + if (supp_width == 1 &&
> + ext_nss_bw == 3)
> + return 2 * max_vht_nss;
> + break;
> + case IEEE80211_VHT_CHANWIDTH_80P80MHZ:
> + if (supp_width == 0 &&
> + ext_nss_bw == 2)
> + return DIV_ROUND_UP(max_vht_nss, 2);
> + if (supp_width == 0 &&
> + ext_nss_bw == 3)
> + return DIV_ROUND_UP(3 * max_vht_nss, 4);
> + if (supp_width == 1 &&
> + ext_nss_bw == 1)
> + return DIV_ROUND_UP(max_vht_nss, 2);
> + if (supp_width == 1 &&
> + ext_nss_bw == 2)
> + return DIV_ROUND_UP(3 * max_vht_nss, 4);
> + break;
> + }
Looks good to me.
> + /* not covered or invalid combination received */
Do you want to inform about the invalid/reserved combination.
Regards,
Arend
> + return max_vht_nss;
> +}
>
> /* Authentication algorithms */
> #define WLAN_AUTH_OPEN 0
>
^ permalink raw reply
* Re: [v5] wlcore: disable multicast filter in AP mode
From: Kalle Valo @ 2017-02-15 9:12 UTC (permalink / raw)
To: Iain Hunter; +Cc: linux-wireless, kvalo, Iain Hunter
In-Reply-To: <20170209143728.22831-1-i-hunter1@ti.com>
Iain Hunter <drhunter95@gmail.com> wrote:
> Enable AP support for allmulticast for MDNS. It can be enabled by bringing
> up the interface with ip command with argument allmulticast on
>
> Signed-off-by: Iain Hunter <i-hunter1@ti.com>
Patch applied to wireless-drivers-next.git, thanks.
1f8665320fa1 wlcore: disable multicast filter in AP mode
--
https://patchwork.kernel.org/patch/9564711/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rtlwifi: btcoexist: fix semicolon.cocci warnings
From: Kalle Valo @ 2017-02-15 9:12 UTC (permalink / raw)
To: Julia Lawall
Cc: Larry Finger, Chaoming Li, Joe Perches, netdev, linux-wireless,
linux-kernel, kbuild-all
In-Reply-To: <alpine.DEB.2.20.1702092111340.1985@hadrien>
Julia Lawall <Julia.Lawall@lip6.fr> wrote:
> Remove unneeded semicolon.
>
> Generated by: scripts/coccinelle/misc/semicolon.cocci
>
> CC: Larry Finger <Larry.Finger@lwfinger.net>
> Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
> Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Patch applied to wireless-drivers-next.git, thanks.
7546bba385b4 rtlwifi: btcoexist: fix semicolon.cocci warnings
--
https://patchwork.kernel.org/patch/9565451/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: orinoco: Use net_device_stats from struct net_device
From: Kalle Valo @ 2017-02-15 9:13 UTC (permalink / raw)
To: Tobias Klauser; +Cc: linux-wireless, netdev
In-Reply-To: <20170210130313.27821-1-tklauser@distanz.ch>
Tobias Klauser <tklauser@distanz.ch> wrote:
> Instead of using a private copy of struct net_device_stats in
> struct orinoco_private, use stats from struct net_device. Also remove
> the now unnecessary .ndo_get_stats function.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Patch applied to wireless-drivers-next.git, thanks.
3a6282045b22 orinoco: Use net_device_stats from struct net_device
--
https://patchwork.kernel.org/patch/9566717/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [-, REGRESSION] mwifiex: don't enable/disable IRQ 0 during suspend/resume
From: Kalle Valo @ 2017-02-15 9:14 UTC (permalink / raw)
To: Brian Norris
Cc: Amitkumar Karwar, Nishant Sarmukadam, linux-kernel,
linux-wireless, Rajat Jain, Brian Norris
In-Reply-To: <20170210215525.139701-1-briannorris@chromium.org>
Brian Norris <briannorris@chromium.org> wrote:
> If we don't have an out-of-band wakeup IRQ configured through DT (as
> most platforms don't), then we fall out of this function with
> 'irq_wakeup == 0'. Other code (e.g., mwifiex_disable_wake() and
> mwifiex_enable_wake()) treats 'irq_wakeup >= 0' as a valid IRQ, and so
> we end up calling {enable,disable}_irq() on IRQ 0.
>
> That seems bad, so let's not do that.
>
> Same problem as fixed in this patch:
>
> https://patchwork.kernel.org/patch/9531693/
> [PATCH v2 2/3] btmrvl: set irq_bt to -1 when failed to parse it
>
> with the difference that:
> (a) this one is actually a regression and
> (b) this affects both device tree and non-device-tree systems
>
> While fixing the regression, also drop the verbosity on the parse
> failure, so we don't see this when a DT node is present but doesn't have
> an interrupt property (this is perfectly legal):
>
> [ 21.999000] mwifiex_pcie 0000:01:00.0: fail to parse irq_wakeup from device tree
>
> Fixes: 853402a00823 ("mwifiex: Enable WoWLAN for both sdio and pcie")
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> Acked-by: Rajat Jain <rajatja@google.com>
Patch applied to wireless-drivers-next.git, thanks.
2447e2cad752 mwifiex: don't enable/disable IRQ 0 during suspend/resume
--
https://patchwork.kernel.org/patch/9567543/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/3] rtlwifi: btcoexist: Fix if == else warnings in halbtc8821a2ant.c
From: Kalle Valo @ 2017-02-15 9:15 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Larry Finger, Julia Lawall
In-Reply-To: <20170212004605.1308-2-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> The 0-DAY kernel test infrastructure reports the following:
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3023:1-3: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3035:2-4: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3037:3-5: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3047:3-5: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3075:3-5: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3085:3-5: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3129:1-3: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3141:2-4: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3143:3-5: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3153:3-5: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3179:2-4: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3181:3-5: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:3192:3-5: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2677:1-3: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2833:1-3: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2847:3-5: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2857:3-5: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2885:3-5: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2895:3-5: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2940:1-3: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2788:2-4: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2391:2-4: WARNING: possible condition with no effect (if == else)
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c:2417:2-4: WARNING: possible condition with no effect (if == else)
>
> Reported-by: kbuild-all@01.org
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Julia Lawall <julia.lawall@lip6.fr>
3 patches applied to wireless-drivers-next.git, thanks.
ac0ca72c6f53 rtlwifi: btcoexist: Fix if == else warnings in halbtc8821a2ant.c
42e74946f016 rtlwifi: btcoexist: Fix if == else warnings in halbtc8821a1ant.c
b686784d03e6 rtlwifi: btcoexist: Fix if == else warnings in halbtc8723b1ant.c
--
https://patchwork.kernel.org/patch/9568225/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: brcmfmac: Use net_device_stats from struct net_device
From: Kalle Valo @ 2017-02-15 9:15 UTC (permalink / raw)
To: Tobias Klauser
Cc: arend.vanspriel, franky.lin, hante.meuleman, linux-wireless,
brcm80211-dev-list.pdl, netdev
In-Reply-To: <20170213101409.8205-1-tklauser@distanz.ch>
Tobias Klauser <tklauser@distanz.ch> wrote:
> Instead of using a private copy of struct net_device_stats in struct
> brcm_if, use stats from struct net_device. Also remove the now
> unnecessary .ndo_get_stats function.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Patch applied to wireless-drivers-next.git, thanks.
91b632803ee4 brcmfmac: Use net_device_stats from struct net_device
--
https://patchwork.kernel.org/patch/9569271/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rt2500usb: don't mark register accesses as inline
From: Kalle Valo @ 2017-02-15 9:16 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Stanislaw Gruszka, Helmut Schaa, Arnd Bergmann, Mathias Kresin,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20170214212846.2809141-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> When CONFIG_KASAN is set, we get a rather large stack here:
>
> drivers/net/wireless/ralink/rt2x00/rt2500usb.c: In function 'rt2500usb_set_device_state':
> drivers/net/wireless/ralink/rt2x00/rt2500usb.c:1074:1: error: the frame size of 3032 bytes is larger than 100 bytes [-Werror=frame-larger-than=]
>
> If we don't force those functions to be inline, the compiler can figure this
> out better itself and not inline the functions when doing so would be harmful,
> reducing the stack size to a merge 256 bytes.
>
> Note that there is another problem that manifests in this driver, as a result
> of the typecheck() macro causing even larger stack frames.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Patch applied to wireless-drivers-next.git, thanks.
727241660912 rt2500usb: don't mark register accesses as inline
--
https://patchwork.kernel.org/patch/9572947/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [RFC v2 3/7] ieee80211: add new VHT capability fields/parsing
From: Johannes Berg @ 2017-02-15 9:16 UTC (permalink / raw)
To: Arend Van Spriel, linux-wireless; +Cc: j, greearb
In-Reply-To: <281180d5-2a7e-00b5-f12b-13bf568812da@broadcom.com>
On Wed, 2017-02-15 at 10:08 +0100, Arend Van Spriel wrote:
> [snip]
>
> Looks good to me.
Thanks for checking :)
> > + /* not covered or invalid combination received */
>
> Do you want to inform about the invalid/reserved combination.
I'm not really sure what to do - we don't really want to print a
message on something that might have been received from the peer, I
think? Though I suppose we should return 0 for the invalid
combinations, indicating that they're not supported.
johannes
^ permalink raw reply
* Re: ath9k: use correct OTP register offsets for the AR9340 and AR9550
From: Kalle Valo @ 2017-02-15 9:22 UTC (permalink / raw)
To: Christian Lamparter
Cc: linux-wireless, Kalle Valo, QCA ath9k Development, Chris Blake,
Gabor Juhos, stable
In-Reply-To: <20170214191030.31070-1-chunkeey@googlemail.com>
Christian Lamparter <chunkeey@googlemail.com> wrote:
> This patch fixes the OTP register definitions for the AR934x and AR9550
> WMAC SoC.
>
> Previously, the ath9k driver was unable to initialize the integrated
> WMAC on an Aerohive AP121:
>
> | ath: phy0: timeout (1000 us) on reg 0x30018: 0xbadc0ffe & 0x00000007 != 0x00000004
> | ath: phy0: timeout (1000 us) on reg 0x30018: 0xbadc0ffe & 0x00000007 != 0x00000004
> | ath: phy0: Unable to initialize hardware; initialization status: -5
> | ath9k ar934x_wmac: failed to initialize device
> | ath9k: probe of ar934x_wmac failed with error -5
>
> It turns out that the AR9300_OTP_STATUS and AR9300_OTP_DATA
> definitions contain a typo.
>
> Cc: Gabor Juhos <juhosg@openwrt.org>
> Cc: stable@vger.kernel.org
> Fixes: add295a4afbdf5852d0 "ath9k: use correct OTP register offsets for AR9550"
> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
Patch applied to ath-next branch of ath.git, thanks.
c9f1e3260081 ath9k: use correct OTP register offsets for the AR9340 and AR9550
--
https://patchwork.kernel.org/patch/9572541/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: Configure rxnss_override for 10.4 firmware.
From: Kalle Valo @ 2017-02-15 9:26 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, Ben Greear, ath10k
In-Reply-To: <1486771745-15150-1-git-send-email-greearb@candelatech.com>
Ben Greear <greearb@candelatech.com> wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> QCA9984 hardware can do 4x4 at 80Mhz, but only 2x2 at 160Mhz.
>
> First, report this to user-space by setting the max-tx-speed
> and max-rx-speed vht capabilities.
>
> Second, if the peer rx-speed is configured, and if we
> are in 160 or 80+80 mode, and the peer rx-speed matches
> the max speed for 2x2 or 1x1 at 160Mhz (long guard interval),
> then use that info to set the peer_bw_rxnss_override appropriately.
>
> Without this, a 9984 firmware will not use 2x2 ratesets when
> transmitting to peer (it will be stuck at 1x1), because
> the firmware would not have configured the rxnss_override.
>
> This could use some testing....
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
Does not apply:
error: patch failed: drivers/net/wireless/ath/ath10k/mac.c:2760
error: drivers/net/wireless/ath/ath10k/mac.c: patch does not apply
error: patch failed: drivers/net/wireless/ath/ath10k/wmi.h:6173
error: drivers/net/wireless/ath/ath10k/wmi.h: patch does not apply
stg import: Diff does not apply cleanly
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9567655/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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