* Re: [PATCH 1/5] nl80211: fix validation of scheduled scan info for wowlan netdetect
From: Johannes Berg @ 2017-01-27 12:31 UTC (permalink / raw)
To: Arend van Spriel, Kalle Valo; +Cc: linux-wireless
In-Reply-To: <1485518971-28183-2-git-send-email-arend.vanspriel@broadcom.com>
On Fri, 2017-01-27 at 12:09 +0000, Arend van Spriel wrote:
> For wowlan netdetect a separate limit is defined for the number of
> matchsets. Currently, this limit is ignored and the regular limit
> for scheduled scan matchsets, ie. struct wiphy::max_match_sets, is
> used for the net-detect case as well.
>
But .. this patch shouldn't be first in the series, should it? That
leaves brcmfmac broken inbetween.
Also, since you fix the brcmfmac value in patch 2, and it's the same in
both cases, I don't really see a dependency of anything *on* the
nl80211 patch? The brcmfmac changes can go in without it entirely, and
have no effect whatsoever, no?
IOW, I think Kalle can merge 2-5, and I can then pick up this one when
they hit net-next and I've synchronized, no?
johannes
^ permalink raw reply
* Re: [PATCH V2 2/5] brcmfmac: provide a value for struct wowlan_support::max_nd_match_sets
From: Kalle Valo @ 2017-01-27 12:51 UTC (permalink / raw)
To: Johannes Berg; +Cc: Arend van Spriel, linux-wireless
In-Reply-To: <1485521038.5851.10.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> And to make it show up in patchwork at the right place:
>
> Kalle, you can ignore patch 1, I'm handling it, but you need to apply
> these before I can, the patch series order was wrong.
Haha :) Thank you, this is the best way to remind me about something.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Arend Van Spriel @ 2017-01-27 12:53 UTC (permalink / raw)
To: Kalle Valo, Pali Rohár
Cc: Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt,
Michal Kazior, Daniel Wagner, Tony Lindgren, Sebastian Reichel,
Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen, Grazvydas Ignotas,
linux-kernel, linux-wireless, netdev
In-Reply-To: <8737g47kpd.fsf@kamboji.qca.qualcomm.com>
On 27-1-2017 13:26, Kalle Valo wrote:
> Pali Rohár <pali.rohar@gmail.com> writes:
>
>> On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
>>> Pali Rohár <pali.rohar@gmail.com> writes:
>>>
>>>>> So
>>>>> for those other platforms there will be a delay waiting for user-mode
>>>>> helper to fail, before trying to get nvs file from /lib/firmware.
>>>>
>>>> Yes, there will be. But there is no easy way to fix this problem that
>>>> kernel is trying to use default/example NVS data...
>>>
>>> Kernel is doing correctly and requesting NVS data as expected, the
>>> problem here is that linux-firmware claims that the example NVS data is
>>> real calibration data (which it is not). Distros should not use that,
>>> only developers for testing purposes. We should not courage users using
>>> example calibration data.
>>>
>>> The simple fix is to rename the NVS file in linux-firmware to something
>>> like wl1251-nvs.bin.example, no need to workaround this in kernel. If
>>> you send a patch to linux-firmware I'm happy to ack that.
>>
>> I agree with rename and fact that default/example data should not be
>> used.
>>
>> But...
>>
>> 1) Kernel should not read device/model specific data from VFS where
>> are stored not-device-specific files preinstalled by linux
>> distributions.
>>
>> And linux distributions are already putting files into VFS and kernel
>> cannot enforce userspace to not do that (as they are already doing it).
>
> I'm having problems to understand what you are saying here.
This is a personal opinion. I read it as: /lib/firmware can only contain
files for from linux-firmware.
At least the device-specific vs. non-device-specific does not seem to
hold. The firmware files that we have in the linux-firmware repository
are very device-specific. Unless you mean the 'platform' when talking
about 'device'.
Regards,
Arend
^ permalink raw reply
* Re: iwlegacy kernel module with SLES 12 SP1
From: Stanislaw Gruszka @ 2017-01-27 12:53 UTC (permalink / raw)
To: Hassell, William; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <DF4PR84MB007667FC0FD957BA7226C7EAF1770@DF4PR84MB0076.NAMPRD84.PROD.OUTLOOK.COM>
On Thu, Jan 26, 2017 at 10:49:05PM +0000, Hassell, William wrote:
> Hoping you can help.
> I installed SUSE SLES 12 SP1 on a Sony Vaio laptop.
> To my surprise, everything is working with the exception of the wireless device.
> It is an Intel WIFI 4965 AGN device and it works fine with Windows 7 OS.
>
> I have checked that the proper firmware is in /lib/firmware and dmesg shows
> the device is discovered at boot time but no kernel module is loaded.
>
> I see that there is a module iwlwifi in this distro but no iwlegacy.
> Do I need this? If so, how do I go about getting this wireless device to work?
You need iwl4965 and iwlegacy modules. IWL 4965 is pretty old device,
hence distribution might not compile/provide those modules.
Stanislaw
^ permalink raw reply
* Re: [PATCH 4/4] ath9k: fix race condition in enabling/disabling IRQs
From: Felix Fietkau @ 2017-01-27 12:47 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo
In-Reply-To: <20170125163654.66431-4-nbd@nbd.name>
On 2017-01-25 17:36, Felix Fietkau wrote:
> The code currently relies on refcounting to disable IRQs from within the
> IRQ handler and re-enabling them again after the tasklet has run.
>
> However, due to race conditions sometimes the IRQ handler might be
> called twice, or the tasklet may not run at all (if interrupted in the
> middle of a reset).
>
> This can cause nasty imbalances in the irq-disable refcount which will
> get the driver permanently stuck until the entire radio has been stopped
> and started again (ath_reset will not recover from this).
>
> Instead of using this fragile logic, change the code to ensure that
> running the irq handler during tasklet processing is safe, and leave the
> refcount untouched.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Please don't apply this yet, it looks like it might cause some
regressions on other devices. I will investigate.
- Felix
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2017-01-27 13:11 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend Van Spriel, Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <8737g47kpd.fsf@kamboji.qca.qualcomm.com>
On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
> Pali Rohár <pali.rohar@gmail.com> writes:
>
> > On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
> >> Pali Rohár <pali.rohar@gmail.com> writes:
> >>
> >> >> So
> >> >> for those other platforms there will be a delay waiting for user-mode
> >> >> helper to fail, before trying to get nvs file from /lib/firmware.
> >> >
> >> > Yes, there will be. But there is no easy way to fix this problem that
> >> > kernel is trying to use default/example NVS data...
> >>
> >> Kernel is doing correctly and requesting NVS data as expected, the
> >> problem here is that linux-firmware claims that the example NVS data is
> >> real calibration data (which it is not). Distros should not use that,
> >> only developers for testing purposes. We should not courage users using
> >> example calibration data.
> >>
> >> The simple fix is to rename the NVS file in linux-firmware to something
> >> like wl1251-nvs.bin.example, no need to workaround this in kernel. If
> >> you send a patch to linux-firmware I'm happy to ack that.
> >
> > I agree with rename and fact that default/example data should not be
> > used.
> >
> > But...
> >
> > 1) Kernel should not read device/model specific data from VFS where
> > are stored not-device-specific files preinstalled by linux
> > distributions.
> >
> > And linux distributions are already putting files into VFS and kernel
> > cannot enforce userspace to not do that (as they are already doing it).
>
> I'm having problems to understand what you are saying here.
I'm saying that linux distributions are putting files to /lib/firmware
which comes from some sources already released. You cannot force linux
distributions to stop putting particular file to /lib/firmware *now*
after it was already released and recommended.
> > 2) It was already tested that example NVS data can be used for N900 e.g.
> > for SSH connection. If real correct data are not available it is better
> > to use at least those example (and probably log warning message) so user
> > can connect via SSH and start investigating where is problem.
>
> I disagree. Allowing default calibration data to be used can be
> unnoticed by user and left her wondering why wifi works so badly.
So there are only two options:
1) Disallow it and so these users will have non-working wifi.
2) Allow those data to be used as fallback mechanism.
And personally I'm against 1) because it will break wifi support for
*all* Nokia N900 devices right now.
> > 3) If we do rename *now* we will totally break wifi support on Nokia
> > N900.
>
> Then the distro should fix that when updating the linux-firmware
> packages. Can you provide details about the setup, what distro etc?
Debian stable, Ubuntu LTSs 14.04, 16.04. And I think that other
LTS distributions contains that example nvs file too (I'm not going to
verify others, but list will be probably long). Upgrading linux-firmware
is against policy of those distributions. So no this is not an solution.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2017-01-27 13:16 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Kalle Valo, Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <bc26f6a5-2865-356f-7f19-f3a316257759@broadcom.com>
On Friday 27 January 2017 13:53:28 Arend Van Spriel wrote:
> On 27-1-2017 13:26, Kalle Valo wrote:
> > Pali Rohár <pali.rohar@gmail.com> writes:
> >
> >> On Friday 27 January 2017 13:49:03 Kalle Valo wrote:
> >>> Pali Rohár <pali.rohar@gmail.com> writes:
> >>>
> >>>>> So
> >>>>> for those other platforms there will be a delay waiting for user-mode
> >>>>> helper to fail, before trying to get nvs file from /lib/firmware.
> >>>>
> >>>> Yes, there will be. But there is no easy way to fix this problem that
> >>>> kernel is trying to use default/example NVS data...
> >>>
> >>> Kernel is doing correctly and requesting NVS data as expected, the
> >>> problem here is that linux-firmware claims that the example NVS data is
> >>> real calibration data (which it is not). Distros should not use that,
> >>> only developers for testing purposes. We should not courage users using
> >>> example calibration data.
> >>>
> >>> The simple fix is to rename the NVS file in linux-firmware to something
> >>> like wl1251-nvs.bin.example, no need to workaround this in kernel. If
> >>> you send a patch to linux-firmware I'm happy to ack that.
> >>
> >> I agree with rename and fact that default/example data should not be
> >> used.
> >>
> >> But...
> >>
> >> 1) Kernel should not read device/model specific data from VFS where
> >> are stored not-device-specific files preinstalled by linux
> >> distributions.
> >>
> >> And linux distributions are already putting files into VFS and kernel
> >> cannot enforce userspace to not do that (as they are already doing it).
> >
> > I'm having problems to understand what you are saying here.
>
> This is a personal opinion. I read it as: /lib/firmware can only contain
> files for from linux-firmware.
>
> At least the device-specific vs. non-device-specific does not seem to
> hold. The firmware files that we have in the linux-firmware repository
> are very device-specific. Unless you mean the 'platform' when talking
> about 'device'.
Here I'm talking about files which are specific per unit. Every one N900
has different NVS file (stored in CAL) and so every one N900 device
needs its own NVS file. And we cannot store thousands of NVS files into
linux-firmware repository for each N900 which was ever produced in
factory.
Firmware files in linux-firmware repository are "device" specific, but
"filename" of that file describe exactly for which "device" it is
specific.
But there are thousands of different NVS files for one filename
"wl1251-nvs.bin" and we cannot use one particular for another device. In
linux-firmware is stored "wl1251-nvs.bin" file with example data.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* [PATCH] ath10k: fix boot failure in UTF mode/testmode
From: c_traja @ 2017-01-27 13:51 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Tamizh chelvam
From: Tamizh chelvam <c_traja@qti.qualcomm.com>
Rx filter reset and the dynamic tx switch mode (EXT_RESOURCE_CFG)
configuration are causing the following errors when UTF firmware
is loaded to the target.
Error message 1:
[ 598.015629] ath10k_pci 0001:01:00.0: failed to ping firmware: -110
[ 598.020828] ath10k_pci 0001:01:00.0: failed to reset rx filter: -110
[ 598.141556] ath10k_pci 0001:01:00.0: failed to start core (testmode): -110
Error message 2:
[ 668.615839] ath10k_ahb a000000.wifi: failed to send ext resource cfg command : -95
[ 668.618902] ath10k_ahb a000000.wifi: failed to start core (testmode): -95
Avoiding these configurations while bringing the target in
testmode is solving the problem.
Signed-off-by: Tamizh chelvam <c_traja@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/core.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 874c2a7..0d12761 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1922,7 +1922,8 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
ath10k_dbg(ar, ATH10K_DBG_BOOT, "firmware %s booted\n",
ar->hw->wiphy->fw_version);
- if (test_bit(WMI_SERVICE_EXT_RES_CFG_SUPPORT, ar->wmi.svc_map)) {
+ if (test_bit(WMI_SERVICE_EXT_RES_CFG_SUPPORT, ar->wmi.svc_map) &&
+ mode == ATH10K_FIRMWARE_MODE_NORMAL) {
val = 0;
if (ath10k_peer_stats_enabled(ar))
val = WMI_10_4_PEER_STATS;
@@ -1975,10 +1976,13 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
* possible to implicitly make it correct by creating a dummy vdev and
* then deleting it.
*/
- status = ath10k_core_reset_rx_filter(ar);
- if (status) {
- ath10k_err(ar, "failed to reset rx filter: %d\n", status);
- goto err_hif_stop;
+ if (mode == ATH10K_FIRMWARE_MODE_NORMAL) {
+ status = ath10k_core_reset_rx_filter(ar);
+ if (status) {
+ ath10k_err(ar,
+ "failed to reset rx filter: %d\n", status);
+ goto err_hif_stop;
+ }
}
/* If firmware indicates Full Rx Reorder support it must be used in a
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2] rt2x00: avoid introducing a USB dependency in the rt2x00lib module
From: Stanislaw Gruszka @ 2017-01-27 14:14 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, vishalthanki, nbd
As reported by Felix:
Though protected by an ifdef, introducing an usb symbol dependency in
the rt2x00lib module is a major inconvenience for distributions that
package kernel modules split into individual packages.
Get rid of this unnecessary dependency by calling the usb related
function from a more suitable place.
Reported-by: Felix Fietkau <nbd@nbd.name>
Fixes: 8b4c0009313f ("rt2x00usb: Use usb anchor to manage URB")
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 23 ++++++++---------------
drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 5 +++++
2 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
index e464bdc..c0a66af 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
@@ -1417,21 +1417,6 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
cancel_work_sync(&rt2x00dev->intf_work);
cancel_delayed_work_sync(&rt2x00dev->autowakeup_work);
cancel_work_sync(&rt2x00dev->sleep_work);
-#ifdef CONFIG_RT2X00_LIB_USB
- if (rt2x00_is_usb(rt2x00dev)) {
- usb_kill_anchored_urbs(rt2x00dev->anchor);
- hrtimer_cancel(&rt2x00dev->txstatus_timer);
- cancel_work_sync(&rt2x00dev->rxdone_work);
- cancel_work_sync(&rt2x00dev->txdone_work);
- }
-#endif
- if (rt2x00dev->workqueue)
- destroy_workqueue(rt2x00dev->workqueue);
-
- /*
- * Free the tx status fifo.
- */
- kfifo_free(&rt2x00dev->txstatus_fifo);
/*
* Kill the tx status tasklet.
@@ -1447,6 +1432,14 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
*/
rt2x00lib_uninitialize(rt2x00dev);
+ if (rt2x00dev->workqueue)
+ destroy_workqueue(rt2x00dev->workqueue);
+
+ /*
+ * Free the tx status fifo.
+ */
+ kfifo_free(&rt2x00dev->txstatus_fifo);
+
/*
* Free extra components
*/
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
index 838ca58..5a2bf9f 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
@@ -744,6 +744,11 @@ void rt2x00usb_uninitialize(struct rt2x00_dev *rt2x00dev)
{
struct data_queue *queue;
+ usb_kill_anchored_urbs(rt2x00dev->anchor);
+ hrtimer_cancel(&rt2x00dev->txstatus_timer);
+ cancel_work_sync(&rt2x00dev->rxdone_work);
+ cancel_work_sync(&rt2x00dev->txdone_work);
+
queue_for_each(rt2x00dev, queue)
rt2x00usb_free_entries(queue);
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Kalle Valo @ 2017-01-27 15:23 UTC (permalink / raw)
To: Pali Rohár
Cc: Arend Van Spriel, Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <20170127131146.GI24223@pali>
Pali Roh=C3=A1r <pali.rohar@gmail.com> writes:
> On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
>> Pali Roh=C3=A1r <pali.rohar@gmail.com> writes:
>>=20
>> > 2) It was already tested that example NVS data can be used for N900 e.=
g.
>> > for SSH connection. If real correct data are not available it is better
>> > to use at least those example (and probably log warning message) so us=
er
>> > can connect via SSH and start investigating where is problem.
>>=20
>> I disagree. Allowing default calibration data to be used can be
>> unnoticed by user and left her wondering why wifi works so badly.
>
> So there are only two options:
>
> 1) Disallow it and so these users will have non-working wifi.
>
> 2) Allow those data to be used as fallback mechanism.
>
> And personally I'm against 1) because it will break wifi support for
> *all* Nokia N900 devices right now.
All two of them? :)
But not working is exactly my point, if correct calibration data is not
available wifi should not work. And it's not only about functionality
problems, there's also the regulatory aspect.
>> > 3) If we do rename *now* we will totally break wifi support on Nokia
>> > N900.
>>=20
>> Then the distro should fix that when updating the linux-firmware
>> packages. Can you provide details about the setup, what distro etc?
>
> Debian stable, Ubuntu LTSs 14.04, 16.04.=20
You can run these out of box on N900?
> And I think that other LTS distributions contains that example nvs
> file too (I'm not going to verify others, but list will be probably
> long). Upgrading linux-firmware is against policy of those
> distributions. So no this is not an solution.
So instead we should workaround distro policies in kernel? Come on.
Seriously, just rename the file in linux-firmware and file a bug (with a
patch) to distros. If they don't fix the bug you just have to do a
custom hack for N900. But such is life.
--=20
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2017-01-27 15:41 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend Van Spriel, Ming Lei, Luis R. Rodriguez, Greg Kroah-Hartman,
David Gnedt, Michal Kazior, Daniel Wagner, Tony Lindgren,
Sebastian Reichel, Pavel Machek, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <87bmus5xyc.fsf@kamboji.qca.qualcomm.com>
On Friday 27 January 2017 17:23:07 Kalle Valo wrote:
> Pali Rohár <pali.rohar@gmail.com> writes:
>
> > On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
> >> Pali Rohár <pali.rohar@gmail.com> writes:
> >>
> >> > 2) It was already tested that example NVS data can be used for N900 e.g.
> >> > for SSH connection. If real correct data are not available it is better
> >> > to use at least those example (and probably log warning message) so user
> >> > can connect via SSH and start investigating where is problem.
> >>
> >> I disagree. Allowing default calibration data to be used can be
> >> unnoticed by user and left her wondering why wifi works so badly.
> >
> > So there are only two options:
> >
> > 1) Disallow it and so these users will have non-working wifi.
> >
> > 2) Allow those data to be used as fallback mechanism.
> >
> > And personally I'm against 1) because it will break wifi support for
> > *all* Nokia N900 devices right now.
>
> All two of them? :)
Ehm...
> But not working is exactly my point, if correct calibration data is not
> available wifi should not work. And it's not only about functionality
> problems, there's also the regulatory aspect.
About functionality, Pavel confirmed too that SSH is somehow working...
Regulatory aspect is different, but via iw can be manually configured
some settings.
> >> > 3) If we do rename *now* we will totally break wifi support on Nokia
> >> > N900.
> >>
> >> Then the distro should fix that when updating the linux-firmware
> >> packages. Can you provide details about the setup, what distro etc?
> >
> > Debian stable, Ubuntu LTSs 14.04, 16.04.
>
> You can run these out of box on N900?
Out-of-box I can run Kubuntu 12.04 (which is LTS too). They had prepared
special image for N900 and I still have it on uSD card.
I guess that new versions of Ubuntu could somehow work (maybe not
out-of-box but with some changes) and Pavel has working Debian.
Also basic support needed for wifi and SSH server is probably working
with any distribution targeting armv7-a or omap3. So yes, I can say it
is out-of-box. We will not have GSM calls or camera support, but wifi
breakage is there.
> > And I think that other LTS distributions contains that example nvs
> > file too (I'm not going to verify others, but list will be probably
> > long). Upgrading linux-firmware is against policy of those
> > distributions. So no this is not an solution.
>
> So instead we should workaround distro policies in kernel? Come on.
>
> Seriously, just rename the file in linux-firmware and file a bug (with a
> patch) to distros. If they don't fix the bug you just have to do a
> custom hack for N900. But such is life.
I do not see point what will be changed. I rename that file and after
system update (or integrity check) it will be there again.
And if I do that, what prevents kernel to stop using NVS file from
/lib/firmware/? Nothing, original problem (which is going solved by this
patch series) still remains.
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [v2,02/13] wil6210: add disable_ap_sme module parameter
From: Kalle Valo @ 2017-01-27 17:50 UTC (permalink / raw)
To: Maya Erez; +Cc: Kalle Valo, Dedy Lansky, linux-wireless, wil6210, Maya Erez
In-Reply-To: <1484226365-10433-3-git-send-email-qca_merez@qca.qualcomm.com>
Maya Erez <qca_merez@qca.qualcomm.com> wrote:
> From: Dedy Lansky <qca_dlansky@qca.qualcomm.com>
>
> By default, AP SME is handled by driver/FW.
> In case disable_ap_sme is true, driver doesn't turn-on
> WIPHY_FLAG_HAVE_AP_SME and the responsibility for
> AP SME is passed to user space.
>
> With AP SME disabled, driver reports assoc request frame
> to user space which is then responsible for sending assoc
> response frame and for sending NL80211_CMD_NEW_STATION.
> Driver also reports disassoc frame to user space
> which should then send NL80211_CMD_DEL_STATION.
>
> NL80211_CMD_SET_STATION with NL80211_STA_FLAG_AUTHORIZED
> is used by user space to allow/disallow data transmit.
>
> Signed-off-by: Dedy Lansky <qca_dlansky@qca.qualcomm.com>
> Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
11 patches applied to ath-next branch of ath.git, thanks.
849a564b7e28 wil6210: add disable_ap_sme module parameter
a351f2f537b7 wil6210: support loading dedicated image for sparrow-plus devices
af3db60a3033 wil6210: remove __func__ from debug printouts
0d2370e939ac wil6210: support new WMI-only FW capability
4d4c4dc324b4 wil6210: missing reinit_completion in wmi_call
3ee908dc3b48 wil6210: protect against false interrupt during reset sequence
a895cb8b990c wil6210: fix for broadcast workaround in PBSS
a52fb913aee9 wil6210: align to latest auto generated wmi.h
9d865ee232ec wil6210: report association ID (AID) per station in debugfs
c3bfea05a6fd wil6210: option to override A-BFT length in start AP/PCP
78484c44e4b3 wil6210: convert symbolic permissions to octal permissions
--
https://patchwork.kernel.org/patch/9513175/
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] ath10k: remove multiple defines of DIAG_TRANSFER_LIMIT
From: Kalle Valo @ 2017-01-27 18:04 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: netdev, Srinivas Kandagatla, linux-wireless, linux-kernel, ath10k
In-Reply-To: <1485183876-27080-1-git-send-email-srinivas.kandagatla@linaro.org>
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> wrote:
> DIAG_TRANSFER_LIMIT is redefined with same value and comments
> just below this entry, remove this duplicate entry.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
3 patches applied to ath-next branch of ath.git, thanks.
dd51fa3d8a1d ath10k: remove multiple defines of DIAG_TRANSFER_LIMIT
0de4df5ba2ad ath10k: use dma_zalloc_coherent()
1ad38fd719da ath10k: fix typo in addr calculation
--
https://patchwork.kernel.org/patch/9532691/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2] ath10k: Search SMBIOS for OEM board file extension
From: Kalle Valo @ 2017-01-27 19:30 UTC (permalink / raw)
To: Waldemar Rymarkiewicz
Cc: ath10k, alanliu, rwchang, linux-wireless, Waldemar Rymarkiewicz,
bartosz.markowski
In-Reply-To: <20170117150334.8859-1-ext.waldemar.rymarkiewicz@tieto.com>
Waldemar Rymarkiewicz <ext.waldemar.rymarkiewicz@tieto.com> wrote:
> Board Data File (BDF) is loaded upon driver boot-up procedure. The right
> board data file is identified, among others, by device and sybsystem ids.
>
> The problem, however, can occur when the (default) board data file cannot
> fulfill with the vendor requirements and it is necessary to use a different
> board data file.
>
> To solve the issue QCA uses SMBIOS type 0xF8 to store Board Data File Name
> Extension to specify the extension/variant name. The driver will take the
> extension suffix into consideration and will load the right (non-default)
> board data file if necessary.
>
> If it is unnecessary to use extension board data file, please leave the
> SMBIOS field blank and default configuration will be used.
>
> Example:
> If a default board data file for a specific board is identified by a string
> "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028,
> subsystem-device=0310"
> then the OEM specific data file, if used, could be identified by variant
> suffix:
> "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028,
> subsystem-device=0310,variant=DE_1AB"
>
> Signed-off-by: Waldemar Rymarkiewicz <ext.waldemar.rymarkiewicz@tieto.com>
Patch applied to ath-next branch of ath.git, thanks.
f2593cb1b291 ath10k: Search SMBIOS for OEM board file extension
--
https://patchwork.kernel.org/patch/9521307/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH] cfg80211 debugfs: Cleanup some checkpatch issues
From: Pichugin Dmitry @ 2017-01-27 19:26 UTC (permalink / raw)
To: johannes, davem; +Cc: linux-wireless, netdev, linux-kernel
This fixes the checkpatch.pl warnings:
* Macros should not use a trailing semicolon.
* Spaces required around that '='.
* Symbolic permissions 'S_IRUGO' are not preferred.
* Macro argument reuse 'buflen' - possible side-effects
Signed-off-by: Pichugin Dmitry <smokeman85@gmail.com>
---
net/wireless/debugfs.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/net/wireless/debugfs.c b/net/wireless/debugfs.c
index 5d45391..96e3cff 100644
--- a/net/wireless/debugfs.c
+++ b/net/wireless/debugfs.c
@@ -17,11 +17,12 @@
static ssize_t name## _read(struct file *file, char __user *userbuf, \
size_t count, loff_t *ppos) \
{ \
- struct wiphy *wiphy= file->private_data; \
- char buf[buflen]; \
+ struct wiphy *wiphy = file->private_data; \
+ int __buflen = __builtin_constant_p(buflen) ? buflen : -1; \
+ char buf[__buflen]; \
int res; \
\
- res = scnprintf(buf, buflen, fmt "\n", ##value); \
+ res = scnprintf(buf, __buflen, fmt "\n", ##value); \
return simple_read_from_buffer(userbuf, count, ppos, buf, res); \
} \
\
@@ -29,14 +30,14 @@ static const struct file_operations name## _ops = { \
.read = name## _read, \
.open = simple_open, \
.llseek = generic_file_llseek, \
-};
+}
DEBUGFS_READONLY_FILE(rts_threshold, 20, "%d",
- wiphy->rts_threshold)
+ wiphy->rts_threshold);
DEBUGFS_READONLY_FILE(fragmentation_threshold, 20, "%d",
wiphy->frag_threshold);
DEBUGFS_READONLY_FILE(short_retry_limit, 20, "%d",
- wiphy->retry_short)
+ wiphy->retry_short);
DEBUGFS_READONLY_FILE(long_retry_limit, 20, "%d",
wiphy->retry_long);
@@ -103,7 +104,7 @@ static const struct file_operations ht40allow_map_ops = {
};
#define DEBUGFS_ADD(name) \
- debugfs_create_file(#name, S_IRUGO, phyd, &rdev->wiphy, &name## _ops);
+ debugfs_create_file(#name, 0444, phyd, &rdev->wiphy, &name## _ops)
void cfg80211_debugfs_rdev_add(struct cfg80211_registered_device *rdev)
{
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pavel Machek @ 2017-01-27 19:40 UTC (permalink / raw)
To: Kalle Valo
Cc: Pali Rohár, Arend Van Spriel, Ming Lei, Luis R. Rodriguez,
Greg Kroah-Hartman, David Gnedt, Michal Kazior, Daniel Wagner,
Tony Lindgren, Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <87bmus5xyc.fsf@kamboji.qca.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]
On Fri 2017-01-27 17:23:07, Kalle Valo wrote:
> Pali Rohár <pali.rohar@gmail.com> writes:
>
> > On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
> >> Pali Rohár <pali.rohar@gmail.com> writes:
> >>
> >> > 2) It was already tested that example NVS data can be used for N900 e.g.
> >> > for SSH connection. If real correct data are not available it is better
> >> > to use at least those example (and probably log warning message) so user
> >> > can connect via SSH and start investigating where is problem.
> >>
> >> I disagree. Allowing default calibration data to be used can be
> >> unnoticed by user and left her wondering why wifi works so badly.
> >
> > So there are only two options:
> >
> > 1) Disallow it and so these users will have non-working wifi.
> >
> > 2) Allow those data to be used as fallback mechanism.
> >
> > And personally I'm against 1) because it will break wifi support for
> > *all* Nokia N900 devices right now.
>
> All two of them? :)
Umm. You clearly want a flock of angry penguins at your doorsteps :-).
> But not working is exactly my point, if correct calibration data is not
> available wifi should not work. And it's not only about functionality
> problems, there's also the regulatory aspect.
If you break existing configuration that's called "regression".
> >> > 3) If we do rename *now* we will totally break wifi support on Nokia
> >> > N900.
> >>
> >> Then the distro should fix that when updating the linux-firmware
> >> packages. Can you provide details about the setup, what distro etc?
> >
> > Debian stable, Ubuntu LTSs 14.04, 16.04.
>
> You can run these out of box on N900?
Debian stable does.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: iwlwifi: fix kernel crash when unregistering thermal zone
From: Jens Axboe @ 2017-01-27 19:48 UTC (permalink / raw)
To: Kalle Valo; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <20170121125917.2E08F609D0@smtp.codeaurora.org>
On 01/21/2017 05:59 AM, Kalle Valo wrote:
> Jens Axboe <axboe@kernel.dk> wrote:
>> A recent firmware change seems to have enabled thermal zones on the
>> iwlwifi driver. Unfortunately, my device fails when registering the
>> thermal zone. This doesn't stop the driver from attempting to unregister
>> the thermal zone at unload time, triggering a NULL pointer deference in
>> strlen() off the thermal_zone_device_unregister() path.
>>
>> Don't unregister if name is NULL, for that case we failed registering.
>> Do the same for the cooling zone.
>>
>> Signed-off-by: Jens Axboe <axboe@fb.com>
>
> Patch applied to wireless-drivers.git, thanks.
>
> 92549cdc288f iwlwifi: fix kernel crash when unregistering thermal zone
When is this going out?
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH] cfg80211 debugfs: Cleanup some checkpatch issues
From: Joe Perches @ 2017-01-27 19:48 UTC (permalink / raw)
To: Pichugin Dmitry, johannes, davem; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20170127192603.GA13522@gmail.com>
On Fri, 2017-01-27 at 22:26 +0300, Pichugin Dmitry wrote:
> This fixes the checkpatch.pl warnings:
> * Macros should not use a trailing semicolon.
> * Spaces required around that '='.
> * Symbolic permissions 'S_IRUGO' are not preferred.
OK
> * Macro argument reuse 'buflen' - possible side-effects
Not all checkpatch messages need fixing.
This is one of them.
> diff --git a/net/wireless/debugfs.c b/net/wireless/debugfs.c
[]
> @@ -17,11 +17,12 @@
> static ssize_t name## _read(struct file *file, char __user *userbuf, \
> size_t count, loff_t *ppos) \
> { \
> - struct wiphy *wiphy= file->private_data; \
> - char buf[buflen]; \
> + struct wiphy *wiphy = file->private_data; \
> + int __buflen = __builtin_constant_p(buflen) ? buflen : -1; \
> + char buf[__buflen]; \
That's rather an odd change too
^ permalink raw reply
* Re: iwlwifi: fix kernel crash when unregistering thermal zone
From: Jens Axboe @ 2017-01-27 19:55 UTC (permalink / raw)
To: Kalle Valo; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <874m0k46ub.fsf@kamboji.qca.qualcomm.com>
On 01/27/2017 12:54 PM, Kalle Valo wrote:
> Jens Axboe <axboe@kernel.dk> writes:
>
>> On 01/21/2017 05:59 AM, Kalle Valo wrote:
>>> Jens Axboe <axboe@kernel.dk> wrote:
>>>> A recent firmware change seems to have enabled thermal zones on the
>>>> iwlwifi driver. Unfortunately, my device fails when registering the
>>>> thermal zone. This doesn't stop the driver from attempting to unregister
>>>> the thermal zone at unload time, triggering a NULL pointer deference in
>>>> strlen() off the thermal_zone_device_unregister() path.
>>>>
>>>> Don't unregister if name is NULL, for that case we failed registering.
>>>> Do the same for the cooling zone.
>>>>
>>>> Signed-off-by: Jens Axboe <axboe@fb.com>
>>>
>>> Patch applied to wireless-drivers.git, thanks.
>>>
>>> 92549cdc288f iwlwifi: fix kernel crash when unregistering thermal zone
>>
>> When is this going out?
>
> Trying to send a pull request to Dave tomorrow.
Great, thanks!
--
Jens Axboe
^ permalink raw reply
* Re: iwlwifi: fix kernel crash when unregistering thermal zone
From: Kalle Valo @ 2017-01-27 19:54 UTC (permalink / raw)
To: Jens Axboe; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <1e6ae9d2-fef7-1ce0-53fc-4948f81ae27d@kernel.dk>
Jens Axboe <axboe@kernel.dk> writes:
> On 01/21/2017 05:59 AM, Kalle Valo wrote:
>> Jens Axboe <axboe@kernel.dk> wrote:
>>> A recent firmware change seems to have enabled thermal zones on the
>>> iwlwifi driver. Unfortunately, my device fails when registering the
>>> thermal zone. This doesn't stop the driver from attempting to unregister
>>> the thermal zone at unload time, triggering a NULL pointer deference in
>>> strlen() off the thermal_zone_device_unregister() path.
>>>
>>> Don't unregister if name is NULL, for that case we failed registering.
>>> Do the same for the cooling zone.
>>>
>>> Signed-off-by: Jens Axboe <axboe@fb.com>
>>
>> Patch applied to wireless-drivers.git, thanks.
>>
>> 92549cdc288f iwlwifi: fix kernel crash when unregistering thermal zone
>
> When is this going out?
Trying to send a pull request to Dave tomorrow.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] cfg80211 debugfs: Cleanup some checkpatch issues
From: Johannes Berg @ 2017-01-27 21:00 UTC (permalink / raw)
To: Pichugin Dmitry, davem; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20170127192603.GA13522@gmail.com>
On Fri, 2017-01-27 at 22:26 +0300, Pichugin Dmitry wrote:
> This fixes the checkpatch.pl warnings:
> * Macros should not use a trailing semicolon.
> * Spaces required around that '='.
> * Symbolic permissions 'S_IRUGO' are not preferred.
> * Macro argument reuse 'buflen' - possible side-effects
I really see no point in any of this.
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211 debugfs: Cleanup some checkpatch issues
From: Joe Perches @ 2017-01-27 21:10 UTC (permalink / raw)
To: Johannes Berg, Pichugin Dmitry, davem
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <1485550820.14579.2.camel@sipsolutions.net>
On Fri, 2017-01-27 at 22:00 +0100, Johannes Berg wrote:
> On Fri, 2017-01-27 at 22:26 +0300, Pichugin Dmitry wrote:
> > This fixes the checkpatch.pl warnings:
> > * Macros should not use a trailing semicolon.
> > * Spaces required around that '='.
> > * Symbolic permissions 'S_IRUGO' are not preferred.
> > * Macro argument reuse 'buflen' - possible side-effects
>
> I really see no point in any of this.
Look at the uses of DEBUGFS_READONLY_FILE and
see if they are consistent before and after.
DEBUGFS_READONLY_FILE(rts_threshold, 20, "%d",
- wiphy->rts_threshold)
+ wiphy->rts_threshold);
DEBUGFS_READONLY_FILE(fragmentation_threshold, 20, "%d",
wiphy->frag_threshold);
DEBUGFS_READONLY_FILE(short_retry_limit, 20, "%d",
- wiphy->retry_short)
+ wiphy->retry_short);
DEBUGFS_READONLY_FILE(long_retry_limit, 20, "%d",
wiphy->retry_long);
^ permalink raw reply
* [PATCH 1/3] mac80211: fix mesh moving average stuck
From: Rajkumar Manoharan @ 2017-01-28 0:01 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, rmanohar, Rajkumar Manoharan
As moving average is not considering fractional part after
certain ratio, it will stuck at the same 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 bumping up average at stuck state.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
---
net/mac80211/mesh_hwmp.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index b747c9645e43..f0aa1da15bd0 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -300,6 +300,7 @@ void ieee80211s_update_metric(struct ieee80211_local *local,
{
struct ieee80211_tx_info *txinfo = IEEE80211_SKB_CB(skb);
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
+ u32 fail_avg = sta->mesh->fail_avg;
int failed;
if (!ieee80211_is_data(hdr->frame_control))
@@ -308,8 +309,17 @@ 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);
+ fail_avg = ((80 * fail_avg + 5) / 100 + 20 * failed);
+
+ /* bump up fail average since fractional part of average is ignored.
+ * Otherwise fail average always stuck at the same level and
+ * never moves forward.
+ */
+ if (fail_avg && fail_avg == sta->mesh->fail_avg)
+ fail_avg++;
+
+ sta->mesh->fail_avg = fail_avg;
+
if (sta->mesh->fail_avg > 95)
mesh_plink_broken(sta);
}
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] mac80211: Make mesh failure moving average configurable
From: Rajkumar Manoharan @ 2017-01-28 0:01 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, rmanohar, Rajkumar Manoharan
In-Reply-To: <1485561708-31559-1-git-send-email-rmanohar@qca.qualcomm.com>
Currently mesh moving fail average is calculated based on constant
weight factor. In worst case moving average reaches threshold by
considering 16 msdu tx ack status and deactivates mesh path. Having
a constant weight factor might not be suitable for all environments.
So make it tunable parameter and also lower default weight to 10 so
that mesh broken link calculation will consider more packet status
(32 msdus ack status) before dropping mesh path.
In OTA 2-hop topolgy (MP1 <-> MP2 <-> MP3), while running TCP traffic
of window size of 2M where each nodes are operating in VHT80 mode,
mesh path between forwarding node (MP2) and border nodes (MP1/MP3) is
deactivated more often when average weight is 20.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
---
net/mac80211/debugfs_netdev.c | 27 +++++++++++++++++++++++++++
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/mesh.c | 1 +
net/mac80211/mesh.h | 3 +++
net/mac80211/mesh_hwmp.c | 4 +++-
5 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/debugfs_netdev.c b/net/mac80211/debugfs_netdev.c
index 8f5fff8b2040..3923401a85dd 100644
--- a/net/mac80211/debugfs_netdev.c
+++ b/net/mac80211/debugfs_netdev.c
@@ -586,6 +586,32 @@ static ssize_t ieee80211_if_parse_tsf(
#ifdef CONFIG_MAC80211_MESH
IEEE80211_IF_FILE(estab_plinks, u.mesh.estab_plinks, ATOMIC);
+static ssize_t ieee80211_if_fmt_fail_avg_weight(
+ const struct ieee80211_sub_if_data *sdata, char *buf, int buflen)
+{
+ return snprintf(buf, buflen, "%d\n", sdata->u.mesh.fail_avg_weight);
+}
+
+static ssize_t ieee80211_if_parse_fail_avg_weight(
+ struct ieee80211_sub_if_data *sdata, const char *buf, int buflen)
+{
+ u8 val;
+ int ret;
+
+ ret = kstrtou8(buf, 0, &val);
+ if (ret)
+ return ret;
+
+ if (val > 100)
+ return -ERANGE;
+
+ sdata->u.mesh.fail_avg_weight = val;
+
+ return buflen;
+}
+
+IEEE80211_IF_FILE_RW(fail_avg_weight);
+
/* Mesh stats attributes */
IEEE80211_IF_FILE(fwded_mcast, u.mesh.mshstats.fwded_mcast, DEC);
IEEE80211_IF_FILE(fwded_unicast, u.mesh.mshstats.fwded_unicast, DEC);
@@ -711,6 +737,7 @@ static void add_mesh_files(struct ieee80211_sub_if_data *sdata)
{
DEBUGFS_ADD_MODE(tsf, 0600);
DEBUGFS_ADD_MODE(estab_plinks, 0400);
+ DEBUGFS_ADD_MODE(fail_avg_weight, 0600);
}
static void add_mesh_stats(struct ieee80211_sub_if_data *sdata)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 159a1a733725..30babcea3e06 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -711,6 +711,7 @@ struct ieee80211_if_mesh {
struct mesh_table *mpp_paths; /* Store paths for MPP&MAP */
int mesh_paths_generation;
int mpp_paths_generation;
+ u8 fail_avg_weight;
};
#ifdef CONFIG_MAC80211_MESH
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 9c23172feba0..491fd76f91bd 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -1368,6 +1368,7 @@ void ieee80211_mesh_init_sdata(struct ieee80211_sub_if_data *sdata)
ifmsh->last_preq = jiffies;
ifmsh->next_perr = jiffies;
ifmsh->csa_role = IEEE80211_MESH_CSA_ROLE_NONE;
+ ifmsh->fail_avg_weight = MESH_FAIL_AVG_WEIGHT;
/* Allocate all mesh structures when creating the first mesh interface. */
if (!mesh_allocated)
ieee80211s_init();
diff --git a/net/mac80211/mesh.h b/net/mac80211/mesh.h
index 7e5f271e3c30..887746022cc6 100644
--- a/net/mac80211/mesh.h
+++ b/net/mac80211/mesh.h
@@ -185,6 +185,9 @@ struct mesh_rmc {
/* Number of frames buffered per destination for unresolved destinations */
#define MESH_FRAME_QUEUE_LEN 10
+/* Moving failure average weight of mesh peer link (in percent) */
+#define MESH_FAIL_AVG_WEIGHT 10
+
/* Public interfaces */
/* Various */
int ieee80211_fill_mesh_addresses(struct ieee80211_hdr *hdr, __le16 *fc,
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index f0aa1da15bd0..61a824eb2c73 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -301,6 +301,7 @@ void ieee80211s_update_metric(struct ieee80211_local *local,
struct ieee80211_tx_info *txinfo = IEEE80211_SKB_CB(skb);
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
u32 fail_avg = sta->mesh->fail_avg;
+ u8 fail_avg_weight = sta->sdata->u.mesh.fail_avg_weight;
int failed;
if (!ieee80211_is_data(hdr->frame_control))
@@ -309,7 +310,8 @@ void ieee80211s_update_metric(struct ieee80211_local *local,
failed = !(txinfo->flags & IEEE80211_TX_STAT_ACK);
/* moving average, scaled to 100 */
- fail_avg = ((80 * fail_avg + 5) / 100 + 20 * failed);
+ fail_avg = (((100 - fail_avg_weight) * fail_avg + 5) / 100 +
+ fail_avg_weight * failed);
/* bump up fail average since fractional part of average is ignored.
* Otherwise fail average always stuck at the same level and
--
1.9.1
^ permalink raw reply related
* [PATCH 3/3] mac80211: clear failure average upon mesh path deactivation
From: Rajkumar Manoharan @ 2017-01-28 0:01 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, rmanohar, Rajkumar Manoharan
In-Reply-To: <1485561708-31559-1-git-send-email-rmanohar@qca.qualcomm.com>
Mesh moving average should be cleared, whenever mesh paths
to the given station are deactivated due to bad link. This will
give enough room to analysis more tx status than retaining the
current average.
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
---
net/mac80211/mesh_pathtbl.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
index f0e6175a9821..208ad36c0a7f 100644
--- a/net/mac80211/mesh_pathtbl.c
+++ b/net/mac80211/mesh_pathtbl.c
@@ -510,6 +510,7 @@ void mesh_plink_broken(struct sta_info *sta)
struct mesh_path *mpath;
struct rhashtable_iter iter;
int ret;
+ bool paths_deactivated = false;
ret = rhashtable_walk_init(&tbl->rhead, &iter, GFP_ATOMIC);
if (ret)
@@ -535,8 +536,11 @@ void mesh_plink_broken(struct sta_info *sta)
sdata->u.mesh.mshcfg.element_ttl,
mpath->dst, mpath->sn,
WLAN_REASON_MESH_PATH_DEST_UNREACHABLE, bcast);
+ paths_deactivated = true;
}
}
+ if (paths_deactivated)
+ sta->mesh->fail_avg = 0;
out:
rhashtable_walk_stop(&iter);
rhashtable_walk_exit(&iter);
--
1.9.1
^ 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