* 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 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 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 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 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 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] 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] 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: 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] bcma: gpio: set of_node regardless of the host type
From: Rafał Miłecki @ 2017-02-14 22:06 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless@vger.kernel.org, Rafał Miłecki
In-Reply-To: <20170214220346.10479-1-zajec5@gmail.com>
On 14 February 2017 at 23:03, Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> wr=
ote:
> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>
> DT allows describing many device types, not only platform ones. If e.g.
> bcma is hosted on PCI(e) and it has its of_node, let's pass it to the
> GPIO subsystem. This allows GPIO code to handle more hardware details
> not only for bcma on a SoC.
>
> Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
This obviously can wait for 4.12 merge window, no rush.
^ permalink raw reply
* [PATCH] bcma: gpio: set of_node regardless of the host type
From: Rafał Miłecki @ 2017-02-14 22:03 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
DT allows describing many device types, not only platform ones. If e.g.
bcma is hosted on PCI(e) and it has its of_node, let's pass it to the
GPIO subsystem. This allows GPIO code to handle more hardware details
not only for bcma on a SoC.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
drivers/bcma/driver_gpio.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/bcma/driver_gpio.c b/drivers/bcma/driver_gpio.c
index 771a2a253440..7bde8d7a2816 100644
--- a/drivers/bcma/driver_gpio.c
+++ b/drivers/bcma/driver_gpio.c
@@ -185,8 +185,7 @@ int bcma_gpio_init(struct bcma_drv_cc *cc)
chip->owner = THIS_MODULE;
chip->parent = bcma_bus_get_host_dev(bus);
#if IS_BUILTIN(CONFIG_OF)
- if (cc->core->bus->hosttype == BCMA_HOSTTYPE_SOC)
- chip->of_node = cc->core->dev.of_node;
+ chip->of_node = cc->core->dev.of_node;
#endif
switch (bus->chipinfo.id) {
case BCMA_CHIP_ID_BCM4707:
--
2.11.0
^ permalink raw reply related
* [PATCH] rt2500usb: don't mark register accesses as inline
From: Arnd Bergmann @ 2017-02-14 21:28 UTC (permalink / raw)
To: Stanislaw Gruszka, Helmut Schaa, Kalle Valo
Cc: Arnd Bergmann, Mathias Kresin, linux-wireless, netdev,
linux-kernel
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>
---
drivers/net/wireless/ralink/rt2x00/rt2500usb.c | 19 +++++--------------
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2500usb.c b/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
index 62357465fe29..0d2670a56c4c 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2500usb.c
@@ -55,7 +55,7 @@ MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
* If the csr_mutex is already held then the _lock variants must
* be used instead.
*/
-static inline void rt2500usb_register_read(struct rt2x00_dev *rt2x00dev,
+static void rt2500usb_register_read(struct rt2x00_dev *rt2x00dev,
const unsigned int offset,
u16 *value)
{
@@ -66,7 +66,7 @@ static inline void rt2500usb_register_read(struct rt2x00_dev *rt2x00dev,
*value = le16_to_cpu(reg);
}
-static inline void rt2500usb_register_read_lock(struct rt2x00_dev *rt2x00dev,
+static void rt2500usb_register_read_lock(struct rt2x00_dev *rt2x00dev,
const unsigned int offset,
u16 *value)
{
@@ -77,16 +77,7 @@ static inline void rt2500usb_register_read_lock(struct rt2x00_dev *rt2x00dev,
*value = le16_to_cpu(reg);
}
-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);
-}
-
-static inline void rt2500usb_register_write(struct rt2x00_dev *rt2x00dev,
+static void rt2500usb_register_write(struct rt2x00_dev *rt2x00dev,
const unsigned int offset,
u16 value)
{
@@ -96,7 +87,7 @@ static inline void rt2500usb_register_write(struct rt2x00_dev *rt2x00dev,
®, sizeof(reg));
}
-static inline void rt2500usb_register_write_lock(struct rt2x00_dev *rt2x00dev,
+static void rt2500usb_register_write_lock(struct rt2x00_dev *rt2x00dev,
const unsigned int offset,
u16 value)
{
@@ -106,7 +97,7 @@ static inline void rt2500usb_register_write_lock(struct rt2x00_dev *rt2x00dev,
®, sizeof(reg), REGISTER_TIMEOUT);
}
-static inline void rt2500usb_register_multiwrite(struct rt2x00_dev *rt2x00dev,
+static void rt2500usb_register_multiwrite(struct rt2x00_dev *rt2x00dev,
const unsigned int offset,
void *value, const u16 length)
{
--
2.9.0
^ permalink raw reply related
* [PATCH] mac80211: allow overriding station bandwidth.
From: greearb @ 2017-02-14 21:01 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes.berg, Ben Greear
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.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
include/linux/ieee80211.h | 1 +
net/mac80211/main.c | 1 +
net/mac80211/vht.c | 23 +++++++++++++++++++++++
3 files changed, 25 insertions(+)
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index a80516f..e5dc3a8 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -1542,6 +1542,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
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index ec5587d..1447b47 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -464,6 +464,7 @@ static const struct ieee80211_ht_cap mac80211_ht_capa_mod_mask = {
static const struct ieee80211_vht_cap mac80211_vht_capa_mod_mask = {
.vht_cap_info =
cpu_to_le32(IEEE80211_VHT_CAP_RXLDPC |
+ IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK |
IEEE80211_VHT_CAP_SHORT_GI_80 |
IEEE80211_VHT_CAP_SHORT_GI_160 |
IEEE80211_VHT_CAP_RXSTBC_1 |
diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
index 720c64c..5684e13 100644
--- a/net/mac80211/vht.c
+++ b/net/mac80211/vht.c
@@ -56,6 +56,29 @@ void ieee80211_apply_vhtcap_overrides(struct ieee80211_sub_if_data *sdata,
__check_vhtcap_disable(sdata, vht_cap,
IEEE80211_VHT_CAP_TX_ANTENNA_PATTERN);
+ /* Allow disabling 160Mhz or 80+80 */
+ if (sdata->u.mgd.vht_capa_mask.vht_cap_info &
+ cpu_to_le32(IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK)) {
+ u32 cap, n;
+
+ n = le32_to_cpu(sdata->u.mgd.vht_capa.vht_cap_info) &
+ IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK;
+ n >>= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_SHIFT;
+ cap = vht_cap->cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK;
+ cap >>= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_SHIFT;
+
+ if (n < cap) {
+ vht_cap->cap &=
+ ~IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK;
+ vht_cap->cap |=
+ n << IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_SHIFT;
+
+ /* Cannot do short GI 160 if we cannot do 160 or 80+80 */
+ if (n == 0)
+ vht_cap->cap &= ~IEEE80211_VHT_CAP_SHORT_GI_160;
+ }
+ }
+
/* Allow user to decrease AMPDU length exponent */
if (sdata->u.mgd.vht_capa_mask.vht_cap_info &
cpu_to_le32(IEEE80211_VHT_CAP_MAX_A_MPDU_LENGTH_EXPONENT_MASK)) {
--
2.4.11
^ permalink raw reply related
* [PATCH 2/2] mac80211: fix mesh fail_avg check
From: Rajkumar Manoharan @ 2017-02-14 20:27 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, rmanohar, Rajkumar Manoharan
In-Reply-To: <1487104037-24941-1-git-send-email-rmanohar@qca.qualcomm.com>
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;
sta_set_rate_info_tx(sta, &sta->tx_stats.last_rate, &rinfo);
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] mac80211: use DECLARE_EWMA for mesh_fail_avg
From: Rajkumar Manoharan @ 2017-02-14 20:27 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, rmanohar, Rajkumar Manoharan
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.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
---
net/mac80211/mesh_hwmp.c | 21 +++++++++++++++------
net/mac80211/mesh_pathtbl.c | 3 +++
net/mac80211/sta_info.h | 4 +++-
3 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index b747c9645e43..d07ee3ca07ee 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -307,10 +307,11 @@ void ieee80211s_update_metric(struct ieee80211_local *local,
failed = !(txinfo->flags & IEEE80211_TX_STAT_ACK);
- /* moving average, scaled to 100 */
- sta->mesh->fail_avg =
- ((80 * sta->mesh->fail_avg + 5) / 100 + 20 * failed);
- if (sta->mesh->fail_avg > 95)
+ /* moving average, scaled to 100.
+ * feed failure as 100 and success as 0
+ */
+ ewma_mesh_fail_avg_add(&sta->mesh->fail_avg, failed * 100);
+ if (ewma_mesh_fail_avg_read(&sta->mesh->fail_avg) > 95)
mesh_plink_broken(sta);
}
@@ -325,6 +326,8 @@ static u32 airtime_link_metric_get(struct ieee80211_local *local,
int rate, err;
u32 tx_time, estimated_retx;
u64 result;
+ unsigned long fail_avg =
+ ewma_mesh_fail_avg_read(&sta->mesh->fail_avg);
/* Try to get rate based on HW/SW RC algorithm.
* Rate is returned in units of Kbps, correct this
@@ -336,7 +339,7 @@ static u32 airtime_link_metric_get(struct ieee80211_local *local,
if (rate) {
err = 0;
} else {
- if (sta->mesh->fail_avg >= 100)
+ if (fail_avg >= 100)
return MAX_METRIC;
sta_set_rate_info_tx(sta, &sta->tx_stats.last_rate, &rinfo);
@@ -344,7 +347,7 @@ static u32 airtime_link_metric_get(struct ieee80211_local *local,
if (WARN_ON(!rate))
return MAX_METRIC;
- err = (sta->mesh->fail_avg << ARITH_SHIFT) / 100;
+ err = (fail_avg << ARITH_SHIFT) / 100;
}
/* bitrate is in units of 100 Kbps, while we need rate in units of
@@ -484,6 +487,9 @@ static u32 hwmp_route_info_get(struct ieee80211_sub_if_data *sdata,
? mpath->exp_time : exp_time;
mesh_path_activate(mpath);
spin_unlock_bh(&mpath->state_lock);
+ ewma_mesh_fail_avg_init(&sta->mesh->fail_avg);
+ /* init it at a low value - 0 start is tricky */
+ ewma_mesh_fail_avg_add(&sta->mesh->fail_avg, 1);
mesh_path_tx_pending(mpath);
/* draft says preq_id should be saved to, but there does
* not seem to be any use for it, skipping by now
@@ -522,6 +528,9 @@ static u32 hwmp_route_info_get(struct ieee80211_sub_if_data *sdata,
? mpath->exp_time : exp_time;
mesh_path_activate(mpath);
spin_unlock_bh(&mpath->state_lock);
+ ewma_mesh_fail_avg_init(&sta->mesh->fail_avg);
+ /* init it at a low value - 0 start is tricky */
+ ewma_mesh_fail_avg_add(&sta->mesh->fail_avg, 1);
mesh_path_tx_pending(mpath);
} else
spin_unlock_bh(&mpath->state_lock);
diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
index f0e6175a9821..98a3b1c0c338 100644
--- a/net/mac80211/mesh_pathtbl.c
+++ b/net/mac80211/mesh_pathtbl.c
@@ -829,6 +829,9 @@ void mesh_path_fix_nexthop(struct mesh_path *mpath, struct sta_info *next_hop)
mpath->flags = MESH_PATH_FIXED | MESH_PATH_SN_VALID;
mesh_path_activate(mpath);
spin_unlock_bh(&mpath->state_lock);
+ ewma_mesh_fail_avg_init(&next_hop->mesh->fail_avg);
+ /* init it at a low value - 0 start is tricky */
+ ewma_mesh_fail_avg_add(&next_hop->mesh->fail_avg, 1);
mesh_path_tx_pending(mpath);
}
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index dd06ef0b8861..d9010f29de3d 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -322,6 +322,8 @@ struct ieee80211_fast_rx {
struct rcu_head rcu_head;
};
+DECLARE_EWMA(mesh_fail_avg, 64, 8)
+
/**
* struct mesh_sta - mesh STA information
* @plink_lock: serialize access to plink fields
@@ -367,7 +369,7 @@ struct mesh_sta {
enum nl80211_mesh_power_mode nonpeer_pm;
/* moving percentage of failed MSDUs */
- unsigned int fail_avg;
+ struct ewma_mesh_fail_avg fail_avg;
};
DECLARE_EWMA(signal, 1024, 8)
--
1.9.1
^ permalink raw reply related
* Re: [RFC V2 1/5] nl80211: allow multiple active scheduled scan requests
From: Johannes Berg @ 2017-02-14 20:11 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless
In-Reply-To: <e2ec8547-4e0d-881b-5f4e-1e61d4b8b047@broadcom.com>
On Tue, 2017-02-14 at 21:09 +0100, Arend Van Spriel wrote:
> On 14-2-2017 14:12, Johannes Berg wrote:
> > On Tue, 2017-02-14 at 14:07 +0100, Arend Van Spriel wrote:
> >
> > > > No. But there was a size limit on how much older userspace
> > > > could
> > > > process before we did the splitting.
> > >
> > > I see. So basically adding stuff to (split_start == 0) is not
> > > wanted.
> >
> > Correct.
>
> Uhm. Now I am staring at the code there and wonder about following.
> Up until (split_start == 7) I see:
>
> state->split_start++;
> if (state->split)
> break;
>
> For the remaining cases the break is unconditional. Any idea how to
> interpret that?
Yeah, actually, adding stuff to anything where split_start < 7 is
therefore not wanted :-)
The thing is that we if no split is accepted by the userspace tool
(state->split is false) then we have to send everything in one big
message. This is everything until split_start == 7, I guess.
After that, there's only new stuff that such old userspace will be
unable to interpret anyway, so the break is then unconditional - old
userspace without split will never see those new capabilities, and new
userspace can deal with the split.
johannes
^ permalink raw reply
* Re: [RFC V2 1/5] nl80211: allow multiple active scheduled scan requests
From: Arend Van Spriel @ 2017-02-14 20:09 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1487077927.4705.14.camel@sipsolutions.net>
On 14-2-2017 14:12, Johannes Berg wrote:
> On Tue, 2017-02-14 at 14:07 +0100, Arend Van Spriel wrote:
>
>>> No. But there was a size limit on how much older userspace could
>>> process before we did the splitting.
>>
>> I see. So basically adding stuff to (split_start == 0) is not wanted.
>
> Correct.
Uhm. Now I am staring at the code there and wonder about following. Up
until (split_start == 7) I see:
state->split_start++;
if (state->split)
break;
For the remaining cases the break is unconditional. Any idea how to
interpret that?
>> Just trying to get a clear requirement/rule here. Do we (still) know
>> the exact size limit?
>
> No, I don't remember. It's pretty ancient versions of iw/wpa_s that
> weren't able to deal with it. There was also interaction with the
> allocations in the dump function in nl80211 code itself, but we made
> those pretty big already and userspace limits came into play iirc.
Thanks,
Arend
^ permalink raw reply
* Power Save for Multi-VIF
From: Gucea Doru @ 2017-02-14 19:41 UTC (permalink / raw)
To: linux-wireless, ath9k_htc_fw; +Cc: Andra Paraschiv, Costin Raiciu, Dragos N
Hello, everyone
I try to design a Power Save Algorithm in the case of a mobile client
that has multiple virtual interfaces [1] and is connected to multiple
Access Points simultaneously. My implementation is for the Atheros
AR9271 WiFi chip.
The biggest challenge in implementing this algorithm is waking up the
WiFi chip for RX traffic. E.g.: the WiFi chip is in the sleep state
and it has to wake up in order to receive beacons from all the APs
that the client is connected to.
Reading the AR9271 datasheet [2] I noticed that the chip is equipped
with hardware timers for waking up the hardware. The registers for
programming these hardware timers are MAC_PCU_SLP1 and MAC_PCU_SLP2.
After the registers have been programmed, the RTC_FORCE_WAKE bit has
to be cleared in order to allow the card to enter sleep mode (at least
this is how is done in the existing implementation for the single VIF
scenario).
I used the logic above for programming the hardware to wake up for
beacons from multiple APs. I used a power device for measuring the
energy consumption and it seems that the WiFi card wakes up
periodically to receive beacons from multiple APs. The problem is that
after a time, out of nowhere, the WiFi card refuses to enter sleep
mode and stays just in the awake state, although the logic for
programming the hardware timers does not change.
Could someone give more details about the FORCE_WAKE signal and what
is the relation between this signal and the MAC and RTC layers? I
believe that the problem comes from here. The AR9271 datasheet just
references this signal (page 106) but it offers no details about it.
[1] https://github.com/doru91/linux-stable/wiki/Two-Interfaces-Power-Save
[2] https://wikidevi.com/wiki/Atheros_AR9271
[3] http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/hw.c?v=4.9#L2068
Regards,
Doru
^ permalink raw reply
* [RFC-PATCH] ath9k_htc: Adjust beacon timers for Power Save
From: Doru @ 2017-02-14 19:36 UTC (permalink / raw)
To: linux-wireless, ath9k_htc_fw, andra.paraschiv7, costin.raiciu,
dragos.niculescu
Cc: Doru Gucea
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(+)
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 172a9ff..59a76e0 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1521,6 +1521,10 @@ static void ath9k_htc_bss_info_changed(struct ieee80211_hw *hw,
mutex_lock(&priv->mutex);
ath9k_htc_ps_wakeup(priv);
+ /* adjust beacon timers */
+ if (changed && BSS_CHANGED_BEACON_INFO)
+ ath9k_htc_beacon_config(priv, vif);
+
if (changed & BSS_CHANGED_ASSOC) {
ath_dbg(common, CONFIG, "BSS Changed ASSOC %d\n",
bss_conf->assoc);
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index cd7e55e..ce92a39 100644
--- 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);
+
if (ncrc == ifmgd->beacon_crc && ifmgd->beacon_crc_valid)
return;
ifmgd->beacon_crc = ncrc;
--
1.9.1
^ permalink raw reply related
* Re: R92SU - Realtek RTL8192SU/RTL8191SU/RTL8188SU USB Wireless Network Adapters
From: Jes Sorensen @ 2017-02-14 19:22 UTC (permalink / raw)
To: poma, Christian Lamparter; +Cc: David A. De Graaf, Larry Finger, linux-wireless
In-Reply-To: <3255266e-5116-8e5e-bf22-db1dab02c769@gmail.com>
On 02/14/2017 01:28 PM, poma wrote:
> Hello fellows!
>
> https://github.com/chunkeey/rtl8192su/tree/master/r92su
> r92su seems like the simplest and most effective replacement for r8712u.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1421383
> Christian, I can not add you there, so I'm asking here,
> is there any particular reason why r92su is not already accepted in mainline?
>
> Is there an intention to "Realtek RTL8192SU/RTL8191SU/RTL8188SU USB Wireless Network Adapters" join "RTL8XXXu USB mac80211 Wireless LAN Driver" support?
I see no reason why SU support cannot be added to rtl8xxxu, however
given the age of these chips and the amount of time I have to work on
the code, it is pretty far from the top of my priority list.
If someone else is going to work on it, I am happy to work with that
person to integrate the code.
Jes
^ permalink raw reply
* [PATCH] ath9k: use correct OTP register offsets for the AR9340 and AR9550
From: Christian Lamparter @ 2017-02-14 19:10 UTC (permalink / raw)
To: linux-wireless
Cc: Kalle Valo, QCA ath9k Development, Chris Blake, Gabor Juhos,
stable
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>
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
index 7dc7205dc877..bd2269c7de6b 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
@@ -75,13 +75,13 @@
#define AR9300_OTP_BASE \
((AR_SREV_9340(ah) || AR_SREV_9550(ah)) ? 0x30000 : 0x14000)
#define AR9300_OTP_STATUS \
- ((AR_SREV_9340(ah) || AR_SREV_9550(ah)) ? 0x30018 : 0x15f18)
+ ((AR_SREV_9340(ah) || AR_SREV_9550(ah)) ? 0x31018 : 0x15f18)
#define AR9300_OTP_STATUS_TYPE 0x7
#define AR9300_OTP_STATUS_VALID 0x4
#define AR9300_OTP_STATUS_ACCESS_BUSY 0x2
#define AR9300_OTP_STATUS_SM_BUSY 0x1
#define AR9300_OTP_READ_DATA \
- ((AR_SREV_9340(ah) || AR_SREV_9550(ah)) ? 0x3001c : 0x15f1c)
+ ((AR_SREV_9340(ah) || AR_SREV_9550(ah)) ? 0x3101c : 0x15f1c)
enum targetPowerHTRates {
HT_TARGET_RATE_0_8_16,
--
2.11.0
^ permalink raw reply related
* R92SU - Realtek RTL8192SU/RTL8191SU/RTL8188SU USB Wireless Network Adapters
From: poma @ 2017-02-14 18:28 UTC (permalink / raw)
To: Christian Lamparter
Cc: David A. De Graaf, Larry Finger, Jes Sorensen, linux-wireless
Hello fellows!
https://github.com/chunkeey/rtl8192su/tree/master/r92su
r92su seems like the simplest and most effective replacement for r8712u.
https://bugzilla.redhat.com/show_bug.cgi?id=1421383
Christian, I can not add you there, so I'm asking here,
is there any particular reason why r92su is not already accepted in mainline?
Is there an intention to "Realtek RTL8192SU/RTL8191SU/RTL8188SU USB Wireless Network Adapters" join "RTL8XXXu USB mac80211 Wireless LAN Driver" support?
Thanks
^ permalink raw reply
* Re: ath9k: Access rchan::buf only with per_cpu helper
From: Kalle Valo @ 2017-02-14 17:59 UTC (permalink / raw)
To: Sven Eckelmann
Cc: linux-wireless, ath9k-devel, kvalo, netdev, sw, Sven Eckelmann,
Akash Goel, Nick Kossifidis
In-Reply-To: <20170213155648.4821-1-sven@narfation.org>
Sven Eckelmann <sven@narfation.org> wrote:
> The relayfs was changed to use per CPU constructs to handle the rchan
> buffers. But the users of the rchan buffers in other parts of the kernel
> were not modified. This caused crashes like
>
> BUG: unable to handle kernel paging request at 00003a5198a0b910
> IP: [<ffffffffa973cb3a>] ath_cmn_process_fft+0xea/0x610
> PGD 0 [ 179.522449]
> Oops: 0000 [#1] SMP
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-rc5 #1
> [...]
> Call Trace:
> <IRQ> [ 179.656426] [<ffffffffa9704373>] ? ath_rx_tasklet+0x2f3/0xd10
> [<ffffffffa9702106>] ? ath9k_tasklet+0x1b6/0x230
> [<ffffffffa90dcbd1>] ? tasklet_action+0xf1/0x100
> [<ffffffffa9a3cb3f>] ? __do_softirq+0xef/0x284
> [<ffffffffa90dd22e>] ? irq_exit+0xae/0xb0
> [<ffffffffa9a3c89f>] ? do_IRQ+0x4f/0xd0
> [<ffffffffa9a3aa42>] ? common_interrupt+0x82/0x82
> <EOI> [ 179.703152] [<ffffffffa9a39c1d>] ? poll_idle+0x2d/0x57
> [<ffffffffa908c845>] ? sched_clock+0x5/0x10
> [<ffffffffa97bc8d6>] ? cpuidle_enter_state+0xf6/0x2d0
> [<ffffffffa911988e>] ? cpu_startup_entry+0x14e/0x230
> [<ffffffffaa3cdf70>] ? start_kernel+0x461/0x481
> [<ffffffffaa3cd120>] ? early_idt_handler_array+0x120/0x120
> [<ffffffffaa3cd413>] ? x86_64_start_kernel+0x14c/0x170
> Code: 31 db 41 be ff ff ff ff 4c 8b 26 48 8b 6e 08 49 8b 84 24 60 05 00
> 00 48 8b 00 0f b7 40 04 66 89 44 24 48 eb 11 48 8b 55 40 48 98 <48>
> 8b 3c c2 e8 ad a0 a4 ff 01 c3 41 8d 56 01 be 00 02 00 00 48
> RIP [<ffffffffa973cb3a>] ath_cmn_process_fft+0xea/0x610
> RSP <ffff9b43e7003d20>
> CR2: 00003a5198a0b910
>
> Fixes: 017c59c042d0 ("relay: Use per CPU constructs for the relay channel buffer pointers")
> Cc: Akash Goel <akash.goel@intel.com>
> Cc: Nick Kossifidis <mickflemm@gmail.com>
> Reported-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
> Signed-off-by: Sven Eckelmann <sven@narfation.org>
Patch applied to ath-next branch of ath.git, thanks.
07460b92db7c ath9k: Access rchan::buf only with per_cpu helper
--
https://patchwork.kernel.org/patch/9570191/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath9k: clean up and fix ath_tx_count_airtime
From: Kalle Valo @ 2017-02-14 17:58 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, kvalo, toke
In-Reply-To: <20170212132931.43510-1-nbd@nbd.name>
Felix Fietkau <nbd@nbd.name> wrote:
> ath_tx_count_airtime is doing a lot of unnecessary work:
>
> - Redundant station lookup
> - Redundant rcu_read_lock/unlock
> - Useless memcpy of bf->rates
> - Useless NULL check of bf->bf_mpdu
> - Redundant lookup of the skb tid
>
> Additionally, it tries to look up the mac80211 queue index from the txq,
> which fails if the frame was delivered via the power save queue.
>
> This patch fixes all of these issues by passing down the right set of
> pointers instead of doing extra work
>
> Cc: stable@vger.kernel.org
> Fixes: 63fefa050477 ("ath9k: Introduce airtime fairness scheduling between stations")
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Patch applied to ath-next branch of ath.git, thanks.
a6e56d749f1b ath9k: clean up and fix ath_tx_count_airtime
--
https://patchwork.kernel.org/patch/9568369/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath6kl: Use net_device_stats from struct net_device
From: Kalle Valo @ 2017-02-14 17:57 UTC (permalink / raw)
To: Tobias Klauser; +Cc: linux-wireless, netdev
In-Reply-To: <20170209112117.23994-1-tklauser@distanz.ch>
Tobias Klauser <tklauser@distanz.ch> wrote:
> Instead of using a private copy of struct net_device_stats in struct
> ath6kl_vif, 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 ath-next branch of ath.git, thanks.
1235a3b66cbf ath6kl: Use net_device_stats from struct net_device
--
https://patchwork.kernel.org/patch/9564413/
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