* Re: [PATCH] cfg80211 debugfs: Cleanup some checkpatch issues
From: Dmitriy Pichugin @ 2017-01-28 11:49 UTC (permalink / raw)
To: Joe Perches; +Cc: johannes, davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <1485546515.12563.138.camel@perches.com>
On Fri, Jan 27, 2017 at 11:48:35AM -0800, Joe Perches 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.
>
> 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
>
OK. I will update the patch.
Best Regards,
Dmitriy.
^ permalink raw reply
* Re: [v2, 01/14] rt2x00: rt2800lib: move rt2800_drv_data declaration into rt2800lib.h
From: Kalle Valo @ 2017-01-28 8:48 UTC (permalink / raw)
To: Daniel Golle
Cc: linux-wireless, Johannes Berg, Stanislaw Gruszka, roman,
michel.stempin, c.mignanti, evaxige, Felix Fietkau, John Crispin,
Gabor Juhos
In-Reply-To: <20170116025444.GA32156@makrotopia.org>
Daniel Golle <daniel@makrotopia.org> wrote:
> From: Gabor Juhos <juhosg@openwrt.org>
>
> The rt2800_drv_data structure contains driver specific
> information. Move the declaration into the rt2800lib.h
> header which is a more logical place for it. Also fix
> the comment style to avoid checkpatch warning.
>
> The patch contains no functional changes, it is in
> preparation for the next patch.
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
I didn't quite get what patches (if any) I should take, so I'm dropping
the ones below. Please resend the patches which are ok as a new
pathchset.
9 patches set to Changes Requested.
9517997 [v2,01/14] rt2x00: rt2800lib: move rt2800_drv_data declaration into rt2800lib.h
9518001 [v2,02/14] rt2x00: rt2800lib: introduce RT2800_HAS_HIGH_SHARED_MEM flag
9518003 [v2,03/14] rt2x00: rt2800: serialize shared memory access
9518005 [v2,04/14] rt2x00: rt2800lib: fix beacon generation on RT3593
9518007 [v2,05/14] rt2x00: rt2800lib: add hw_beacon_count field to struct rt2800_drv_data
9518009 [v2,06/14] rt2x00: rt2800lib: init additional beacon offset registers
9518011 [v2,07/14] rt2x00: rt2800lib: fix max supported beacon count for RT3593
9518013 [v2,08/14] rt2x00: rt2800mmio: add a workaround for spurious TX_FIFO_STATUS interrupts
9518015 [v2,09/14] rt2x00: rt2x00pci: set PCI MWI only if supported
--
https://patchwork.kernel.org/patch/9517997/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: MAINTAINERS: ath9k-devel is closed
From: Kalle Valo @ 2017-01-28 7:16 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <1485519565-21402-1-git-send-email-kvalo@codeaurora.org>
Kalle Valo <kvalo@codeaurora.org> wrote:
> ath9k-devel list is now closed, only linux-wireless should be used.
>
> Reported-by: Michael Renzmann <mrenzmann@madwifi-project.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to wireless-drivers.git, thanks.
2b1d530cb315 MAINTAINERS: ath9k-devel is closed
--
https://patchwork.kernel.org/patch/9541737/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rtlwifi: rtl_usb: Fix for URB leaking when doing ifconfig up/down
From: Kalle Valo @ 2017-01-28 7:11 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Michael Schenk, Larry Finger, Stable
In-Reply-To: <20170126172504.17492-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> From: Michael Schenk <michael.schenk@albis-elcon.com>
>
> In the function rtl_usb_start we pre-allocate a certain number of urbs
> for RX path but they will not be freed when calling rtl_usb_stop. This
> results in leaking urbs when doing ifconfig up and down. Eventually,
> the system has no available urbs.
>
> Signed-off-by: Michael Schenk <michael.schenk@albis-elcon.com>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable <stable@vger.kernel.org>
Patch applied to wireless-drivers-next.git, thanks.
575ddce05077 rtlwifi: rtl_usb: Fix for URB leaking when doing ifconfig up/down
--
https://patchwork.kernel.org/patch/9539941/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: wlcore: print the sdio buffer after reading it
From: Kalle Valo @ 2017-01-28 7:11 UTC (permalink / raw)
To: Guy Mishol; +Cc: linux-wireless, Guy Mishol
In-Reply-To: <20170126153513.25007-1-guym@ti.com>
Guy Mishol <guym@ti.com> wrote:
> fix an issue where we printed the sdio buffer before
> actually read it.
>
> Signed-off-by: Guy Mishol <guym@ti.com>
Patch applied to wireless-drivers-next.git, thanks.
64ad08605e84 wlcore: print the sdio buffer after reading it
--
https://patchwork.kernel.org/patch/9539423/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/2] mwifiex: mwifiex_unmap_pci_memory() handling for sleep confirm
From: Kalle Valo @ 2017-01-28 7:10 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, rajatja,
briannorris, dmitry.torokhov, Amitkumar Karwar
In-Reply-To: <1485264945-1248-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> Sleep confirm is a special command for which "adapter->cur_cmd" pointer
> is not set. When it's response is received, host writes SLEEP confirm done
> to a register. Firmware will perform DMA for writing sleep cookie signature
> on same buffer after this.
>
> Let's not immediately call mwifiex_unmap_pci_memory() for this special
> command. Unmapping will be done when firmware completes writing sleep
> cookie signature.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
2 patches applied to wireless-drivers-next.git, thanks.
3e66849865ed mwifiex: mwifiex_unmap_pci_memory() handling for sleep confirm
cc37d8efd2ba mwifiex: use pci_dma_sync_single* APIs
--
https://patchwork.kernel.org/patch/9535189/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v4,1/3] rt2x00: add copy of clk for soc devices
From: Kalle Valo @ 2017-01-28 7:09 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linux-wireless, Helmut Schaa, Daniel Golle, Gabor Juhos,
Serge Vasilugin, Mathias Kresin, Michel Stempin, John Crispin
In-Reply-To: <1484918906-21856-2-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> Since clk_get() is not trivial add copy of clk pointer to rt2x00dev
> for System On Chip devices and initialize it on probe routine.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> Acked-by: Daniel Golle <daniel@makrotopia.org>
3 patches applied to wireless-drivers-next.git, thanks.
34db70b92fae rt2x00: add copy of clk for soc devices
5c4412e07280 rt2x00: rt2800lib: add support for RT3352 with 20MHz crystal
98e71f44c51d rt2x00: add support for RT5350 WiSoC
--
https://patchwork.kernel.org/patch/9528399/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 11/11] rtlwifi: Add work queue for c2h cmd.
From: Kalle Valo @ 2017-01-28 6:55 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Ping-Ke Shih
In-Reply-To: <20170120212716.29887-12-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> From: Ping-Ke Shih <pkshih@realtek.com>
>
> btcoex needs to sleep, thus it must run in thread context.
>
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
[...]
> +void rtl_c2hcmd_launcher(struct ieee80211_hw *hw, int exec)
> +{
> + struct rtl_priv *rtlpriv = rtl_priv(hw);
> + unsigned long flags;
> + struct rtl_c2hcmd *c2hcmd;
> +
> + while (true) {
> + /* dequeue a task */
> + spin_lock_irqsave(&rtlpriv->locks.c2hcmd_lock, flags);
> +
> + c2hcmd = list_first_entry_or_null(&rtlpriv->c2hcmd_list,
> + struct rtl_c2hcmd, list);
> +
> + if (c2hcmd)
> + list_del(&c2hcmd->list);
> +
> + spin_unlock_irqrestore(&rtlpriv->locks.c2hcmd_lock, flags);
> +
> + /* do it */
> + if (!c2hcmd)
> + break;
> +
> + if (rtlpriv->cfg->ops->c2h_content_parsing && exec)
> + rtlpriv->cfg->ops->c2h_content_parsing(hw,
> + c2hcmd->tag, c2hcmd->len, c2hcmd->val);
> +
> + /* free */
> + kfree(c2hcmd->val);
> +
> + kfree(c2hcmd);
> + }
> +}
Never ending loops are not really preferred in kernel, with a simple bug
it could cause annoying system-wide problems. Can you add a some sort of
failsafe mechanism, for example bailing out from the loop if it has been
running more than 200 ms or something like that?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 05/11] rtlwifi: btcoexist: Change logging in halbtc8192e2ant.c
From: Kalle Valo @ 2017-01-28 6:46 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Ping-Ke Shih
In-Reply-To: <20170120212716.29887-6-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> This routine uses its own debugging macros These are changed to use the
> the recently rewritten RT_TRACE macro. There are also some renamed
> variables that were missed in the previous step.
>
> The only functional change is that some debugging statements have been
> dropped based on the final code supplied by Realtek.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Ping-Ke Shih <pkshih@realtek.com>
> ---
> .../wireless/realtek/rtlwifi/btcoexist/Makefile | 1 +
> .../realtek/rtlwifi/btcoexist/halbtc8192e2ant.c | 825 +++++++++++----------
> 2 files changed, 417 insertions(+), 409 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile b/drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile
> index d1454d4..0ef0d31 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile
> +++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile
> @@ -1,4 +1,5 @@
> btcoexist-objs := halbtc8723b2ant.o \
> + halbtc8192e2ant.o \
> halbtcoutsrc.o \
> rtl_btc.o
This is what I don't get, why is it needed?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 01/13] wil6210: add sysfs file for FTM calibration
From: Valo, Kalle @ 2017-01-28 6:32 UTC (permalink / raw)
To: Lior David
Cc: Arend Van Spriel, qca_merez, qca_liord,
linux-wireless@vger.kernel.org, wil6210
In-Reply-To: <7da1de20-8040-fc3b-0c1d-77c5fa98d0f5@codeaurora.org>
Lior David <liord@codeaurora.org> writes:
> On 1/19/2017 3:14 PM, Arend Van Spriel wrote:
>> On 19-1-2017 13:36, Lior David wrote:
>>> On 1/19/2017 2:24 PM, Valo, Kalle wrote:
>>>> Maya Erez <qca_merez@qca.qualcomm.com> writes:
>>>>
>>>>> From: Lior David <qca_liord@qca.qualcomm.com>
>>>>>
>>>>> In fine timing measurements, the calculation is affected by
>>>>> 2 parts: timing of packets over the air, which is platform
>>>>> independent, and platform-specific delays, which are dependent
>>>>> on things like antenna cable length and type.
>>>>> Add a sysfs file which allows to get/set these platform specific
>>>>> delays, separated into the TX and RX components.
>>>>> There are 2 key scenarios where the file can be used:
>>>>> 1. Calibration - start with some initial values (for example,
>>>>> the default values at startup), make measurements at a known
>>>>> distance, then iteratively change the values until the
>>>>> measurement results match the known distance.
>>>>> 2. Adjust the delays when platform starts up, based on known
>>>>> values.
>>>>>
>>>>> Signed-off-by: Lior David <qca_liord@qca.qualcomm.com>
>>>>> Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
>>>>
>>>> Can't this go via nl80211? sysfs is not really supposed to be used for
>>>> something like this.
>>>>
>>> There is no nl80211 API for this (yet?).
>>=20
>> So come up with one...?
> I checked this further and had some more internal discussion.
> This change is only about FTM calibration which is highly vendor specific=
so I
> don't think NL80211 API is appropriate for it. Since it is needed in prod=
uction
> (to calibrate the platform after boot using pre-computed values)
For calibration and manufacturing testing we have NL80211_CMD_TESTMODE,
which is a vendor specific interface.
> I think sysfs is a reasonable place for it.
Wireless drivers really should not use sysfs. I guess there might be
valid cases when using sysfs is ok but I can't really come up with
anything right now.
--=20
Kalle Valo=
^ permalink raw reply
* Re: brcmfmac: drop duplicated core selection from brcmf_pcie_attach
From: Kalle Valo @ 2017-01-28 6:37 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki, Hante Meuleman
In-Reply-To: <20170119095125.12276-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> It was left after reworking PCIe reset in commit 07fe2e38c7fd
> ("brcmfmac: Reset PCIE devices after recognition.").
>
> Cc: Hante Meuleman <meuleman@broadcom.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Patch applied to wireless-drivers-next.git, thanks.
b3d75a81f07c brcmfmac: drop duplicated core selection from brcmf_pcie_attach
--
https://patchwork.kernel.org/patch/9525365/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [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
* [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 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
* 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
* 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: 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: 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: [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: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 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
* [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: [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
* 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,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
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