* Re: [PATCH v2 04/21] ath10k: rate-limit packet tx errors
From: Valo, Kalle @ 2016-09-15 13:59 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <57D96669.20209@candelatech.com>
Ben Greear <greearb@candelatech.com> writes:
> On 09/14/2016 07:07 AM, Valo, Kalle wrote:
>> greearb@candelatech.com writes:
>>
>>> From: Ben Greear <greearb@candelatech.com>
>>>
>>> When firmware crashes, stack can continue to send packets
>>> for a bit, and existing code was spamming logs.
>>>
>>> So, rate-limit the error message for tx failures.
>>>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>> ---
>>> drivers/net/wireless/ath/ath10k/mac.c | 5 +++--
>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wirele=
ss/ath/ath10k/mac.c
>>> index cd3016d..42cac32 100644
>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>> @@ -3432,8 +3432,9 @@ static int ath10k_mac_tx_submit(struct ath10k *ar=
,
>>> }
>>>
>>> if (ret) {
>>> - ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
>>> - ret);
>>> + if (net_ratelimit())
>>> + ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
>>> + ret);
>>> ieee80211_free_txskb(ar->hw, skb);
>>> }
>>
>> ath10k_warn() is already rate limited. If there's something wrong then
>> that function should be fixed, not the callers.
>>
>> void ath10k_warn(struct ath10k *ar, const char *fmt, ...)
>> {
>> struct va_format vaf =3D {
>> .fmt =3D fmt,
>> };
>> va_list args;
>>
>> va_start(args, fmt);
>> vaf.va =3D &args;
>> dev_warn_ratelimited(ar->dev, "%pV", &vaf);
>> trace_ath10k_log_warn(ar, &vaf);
>>
>> va_end(args);
>> }
>
> The problem with having the ratelimit here is that you may miss
> rare warnings due to a flood of common warnings.
>
> That is why it is still useful to ratelimit potential floods
> of warnings.
I think this is a common problem in kernel, not specific to ath10k. For
starters you could configure the limits dev_warn_ratelimited() has, not
trying to workaround it in the driver.
> I would like to remove the ratelimit from ath10k_warn eventually.
I think that's not a good idea, it might cause unnecessary host reboots
in problem cases. Rate limitting the messages is much better option.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH] brcm: add firmware for BCM43430 802.11n chipset
From: Kyle McMartin @ 2016-09-15 14:01 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless, Wright Feng, linux-firmware
In-Reply-To: <69f27369-86dc-dc01-67d6-0e8fc1a6616c@broadcom.com>
On Wed, Sep 14, 2016 at 11:30:33AM +0200, Arend Van Spriel wrote:
> On 14-9-2016 11:04, Arend van Spriel wrote:
> > This patch releases firmware for the BCM43430 and BCM43438 chipset. The
> > latter is found on the Raspberry Pi 3.
> >
> > Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> > Change-Id: I80aa84bf984b2d5572680b6f7febe94de22bd720
> > Reviewed-on: http://hnd-swgit.sj.broadcom.com:8080/7766
>
> Yikes. Forgot to remove those Gerrit related tags. Do I need to send a
> V2 or can firmware-group take care of this?
>
no big deal, i also switched the permissions to 644.
--kyle
^ permalink raw reply
* Re: [PATCH v2 08/21] ath10k: make firmware text debug messages more verbose.
From: Valo, Kalle @ 2016-09-15 14:02 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <57D9677E.5030704@candelatech.com>
Ben Greear <greearb@candelatech.com> writes:
> On 09/14/2016 07:12 AM, Valo, Kalle wrote:
>> greearb@candelatech.com writes:
>>
>>> From: Ben Greear <greearb@candelatech.com>
>>>
>>> There are not many of these messages producted by the
>>> firmware, but they are generally fairly useful, so print
>>> them at info level.
>>>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>> ---
>>> drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wirele=
ss/ath/ath10k/wmi.c
>>> index 1758b4a..d9e4b77 100644
>>> --- a/drivers/net/wireless/ath/ath10k/wmi.c
>>> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
>>> @@ -4050,7 +4050,7 @@ void ath10k_wmi_event_debug_print(struct ath10k *=
ar, struct sk_buff *skb)
>>> /* the last byte is always reserved for the null character */
>>> buf[i] =3D '\0';
>>>
>>> - ath10k_dbg(ar, ATH10K_DBG_WMI_PRINT, "wmi print '%s'\n", buf);
>>> + ath10k_info(ar, "wmi print '%s'\n", buf);
>>
>> Useful to whom and how? I understand that for firmware developers this
>> is very valuable information and that's why we have a special debug
>> level for it. But I suspect that for normal users these are just
>> confusing and unnecessarily spam the log.
>
> CT firmare will print out some memory usage info on firmware boot, and th=
at can
> allow a discerning individual to tune their vdev, peer, rate-ctrl, and ot=
her
> object usage in order to make best use of resources in the firmware.
>
> These few lines can greatly aid debugging certain types of crashes and pe=
rformance
> loss in the firmware, so having them readily available in 'dmesg' or simi=
lar
> for bug reports from the field helps me.
>
> Stock firmware will also print out some resource usage info. It is just
> a few lines on firmware boot, but it is quite useful in my experience.
I'm sure it's useful for you, but we have quite a few firmware versions
to support. We do not know what kind of messages they print.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
From: Valo, Kalle @ 2016-09-15 14:06 UTC (permalink / raw)
To: Ben Greear
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org,
emmanuel.grumbach@intel.com
In-Reply-To: <57D96910.2010608@candelatech.com>
Ben Greear <greearb@candelatech.com> writes:
> On 09/14/2016 07:18 AM, Valo, Kalle wrote:
>> greearb@candelatech.com writes:
>>
>>> From: Ben Greear <greearb@candelatech.com>
>>>
>>> This allows user-space tools to decode debug-log
>>> messages by parsing dmesg or /var/log/messages.
>>>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>
>> Don't tracing points already provide the same information?
>
> Tracing tools are difficult to set up and may not be available on
> random embedded devices. And if we are dealing with bug reports from
> the field, most users will not be able to set it up regardless.
>
> There are similar ways to print out hex, but the logic below creates
> specific and parseable logs in the 'dmesg' output and similar.
>
> I have written a tool that can decode these messages into useful human-re=
adable
> text so that I can debug firmware issues both locally and from field repo=
rts.
>
> Stock firmware generates similar logs and QCA could write their own decod=
e logic
> for their firmware versions.
Reinventing the wheel by using printk as the delivery mechanism doesn't
sound like a good idea. IIRC Emmanuel talked about some kind of firmware
debugging framework, he might have some ideas.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH v2 10/21] ath10k: support logging ath10k_info as KERN_DEBUG
From: Valo, Kalle @ 2016-09-15 14:12 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <57D9696B.10103@candelatech.com>
Ben Greear <greearb@candelatech.com> writes:
> On 09/14/2016 07:19 AM, Valo, Kalle wrote:
>> greearb@candelatech.com writes:
>>
>>> From: Ben Greear <greearb@candelatech.com>
>>>
>>> Helps keep messages off of (serial) console when
>>> that is desired.
>>>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>
>> Isn't /proc/sys/kernel/print exactly for this purpose? At least I recall
>> using it.
>
> I just wanted to hide some ath10k logs from the console, not all
> system logs. I don't think that /proc/sys/kernel/print has any
> granularity?
It should be based on KERN_ log levels. I don't know what your kernel
does, but ath10k should be printing only very few messages with level
KERN_INFO or above, all of of the debug messages. So you should be
easily able to filter out all ath10k debug messages as they are sent
with KERN_DEBUG.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH v2 15/21] ath10k: support CT firmware flag.
From: Valo, Kalle @ 2016-09-15 14:15 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <57D96BC7.1080609@candelatech.com>
Ben Greear <greearb@candelatech.com> writes:
> On 09/14/2016 07:30 AM, Valo, Kalle wrote:
>> greearb@candelatech.com writes:
>>
>>> From: Ben Greear <greearb@candelatech.com>
>>>
>>> Add placeholder so CT firmware can more easily co-exist with upstream
>>> kernel. CT firmware should be backwards compatible with existing kerne=
ls,
>>> but it also has many new features. Subsequent patches, if acceptable f=
or
>>> upstream, can enable and further describe those features.
>>>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>> ---
>>> drivers/net/wireless/ath/ath10k/core.c | 1 +
>>> drivers/net/wireless/ath/ath10k/core.h | 3 +++
>>> 2 files changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wirel=
ess/ath/ath10k/core.c
>>> index fa71d57..49c85c3 100644
>>> --- a/drivers/net/wireless/ath/ath10k/core.c
>>> +++ b/drivers/net/wireless/ath/ath10k/core.c
>>> @@ -235,6 +235,7 @@ static const char *const ath10k_core_fw_feature_str=
[] =3D {
>>> [ATH10K_FW_FEATURE_SUPPORTS_ADAPTIVE_CCA] =3D "adaptive-cca",
>>> [ATH10K_FW_FEATURE_MFP_SUPPORT] =3D "mfp",
>>> [ATH10K_FW_FEATURE_PEER_FLOW_CONTROL] =3D "peer-flow-ctrl",
>>> + [ATH10K_FW_FEATURE_WMI_10X_CT] =3D "wmi-10.x-CT",
>>> };
>>>
>>> static unsigned int ath10k_core_get_fw_feature_str(char *buf,
>>> diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wirel=
ess/ath/ath10k/core.h
>>> index cb6aa8c..f9e3b20 100644
>>> --- a/drivers/net/wireless/ath/ath10k/core.h
>>> +++ b/drivers/net/wireless/ath/ath10k/core.h
>>> @@ -566,6 +566,9 @@ enum ath10k_fw_features {
>>> */
>>> ATH10K_FW_FEATURE_PEER_FLOW_CONTROL =3D 13,
>>>
>>> + /* Firmware from Candela Technologies, enables more VIFs, etc */
>>> + ATH10K_FW_FEATURE_WMI_10X_CT =3D 31,
>>
>> The idea of firmware feature flags to enable (or disable) one particular
>> feature, not a group of features. This way it's easy to enable certain
>> features on different firmware branches. It also makes the maintenance
>> easier as you don't need to remember all the different features one flag
>> enables.
>
> One potential use for this flag: Bug reports could be automatically dire=
cted to me instead
> of QCA.
>
> I have actually re-written much of my earlier logic so that it uses speci=
fic
> feature flags now. I still like the idea of having the driver (and user)
> know it is using CT firmware, but I can live without this flag if needed.
You can do with firmware version string, add something like "-CT" (maybe
you already have?) and it's clearly visible in boot logs and also when
firmware crashes.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH v2 03/21] ath10k: Allow changing ath10k debug mask at runtime.
From: Valo, Kalle @ 2016-09-15 14:19 UTC (permalink / raw)
To: Ben Greear; +Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <57D96DB1.5040003@candelatech.com>
Ben Greear <greearb@candelatech.com> writes:
> On 09/14/2016 07:06 AM, Valo, Kalle wrote:
>> greearb@candelatech.com writes:
>>
>>> From: Ben Greear <greearb@candelatech.com>
>>>
>>> Using debugfs. More convenient than module options
>>> in some cases.
>>>
>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>> ---
>>> drivers/net/wireless/ath/ath10k/debug.c | 62 ++++++++++++++++++++++++=
+++++++++
>>> 1 file changed, 62 insertions(+)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wire=
less/ath/ath10k/debug.c
>>> index e251155..d552a4a 100644
>>> --- a/drivers/net/wireless/ath/ath10k/debug.c
>>> +++ b/drivers/net/wireless/ath/ath10k/debug.c
>>> @@ -870,6 +870,65 @@ static const struct file_operations fops_reg_addr =
=3D {
>>> .llseek =3D default_llseek,
>>> };
>>>
>>> +static ssize_t ath10k_read_debug_level(struct file *file,
>>> + char __user *user_buf,
>>> + size_t count, loff_t *ppos)
>>> +{
>>> + int sz;
>>> + const char buf[] =3D
>>> + "To change debug level, set value adding up desired flags:\n"
>>> + "PCI: 0x1\n"
>>> + "WMI: 0x2\n"
>>> + "HTC: 0x4\n"
>>> + "HTT: 0x8\n"
>>> + "MAC: 0x10\n"
>>> + "BOOT: 0x20\n"
>>> + "PCI-DUMP: 0x40\n"
>>> + "HTT-DUMP: 0x80\n"
>>> + "MGMT: 0x100\n"
>>> + "DATA: 0x200\n"
>>> + "BMI: 0x400\n"
>>> + "REGULATORY: 0x800\n"
>>> + "TESTMODE: 0x1000\n"
>>> + "INFO-AS-DBG: 0x40000000\n"
>>> + "FW: 0x80000000\n"
>>> + "ALL: 0xFFFFFFFF\n";
>>> + char wbuf[sizeof(buf) + 60];
>>> + sz =3D snprintf(wbuf, sizeof(wbuf), "Current debug level: 0x%x\n\n%s"=
,
>>> + ath10k_debug_mask, buf);
>>> + wbuf[sizeof(wbuf) - 1] =3D 0;
>>> +
>>> + return simple_read_from_buffer(user_buf, count, ppos, wbuf, sz);
>>> +}
>>> +
>>> +/* Set logging level.
>>> + */
>>> +static ssize_t ath10k_write_debug_level(struct file *file,
>>> + const char __user *user_buf,
>>> + size_t count, loff_t *ppos)
>>> +{
>>> + struct ath10k *ar =3D file->private_data;
>>> + int ret;
>>> + unsigned long mask;
>>> +
>>> + ret =3D kstrtoul_from_user(user_buf, count, 0, &mask);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ath10k_warn(ar, "Setting debug-mask to: 0x%lx old: 0x%x\n",
>>> + mask, ath10k_debug_mask);
>>> + ath10k_debug_mask =3D mask;
>>> + return count;
>>> +}
>>
>> There are already sysfs files for module parameters which seems to work
>> just fine for this case:
>>
>> # echo 0xffffffff > /sys/module/ath10k_core/parameters/debug_mask
>
>
> Ok, but it is still nice to have the printout info of what log levels
> means. Otherwise, you have to go look at firmware source to even know ho=
w
> to enable the proper flags. And as these flags are internal and might ch=
ange,
> we could change the printout text to match the specific kernel that is ru=
nning.
The debug log levels are documented in the wiki:
https://wireless.wiki.kernel.org/en/users/drivers/ath10k/debug#debug_log_me=
ssages
And they are not supposed to change, there should be only additions.
--=20
Kalle Valo=
^ permalink raw reply
* Re: AMPDU stalls with brcmfmac4366b-pcie.bin triggering WARNINGs
From: Rafał Miłecki @ 2016-09-15 14:27 UTC (permalink / raw)
To: Hante Meuleman, Arend van Spriel, brcm80211-dev-list; +Cc: linux-wireless
In-Reply-To: <20160915114836.12364-1-zajec5@gmail.com>
On 09/15/2016 01:48 PM, Rafał Miłecki wrote:
> On 09/14/2016 08:28 PM, Arend Van Spriel wrote:
>> It would be great to have a timestamp for these skb when they arrive in
>> brcmfmac or transferred to firmware (or both).
>
> You ask and you have it :) I saved kernel's local time and printed it the same
> way print_time function does it. Let me paste the most important lines:
> [ 1876.496770] brcmfmac: CONSOLE: 028605.731 wl0: wlc_ampdu_watchdog: cleaning up ini tid 0 due to no progress for 2 secs tx_in_transit 1
> [ 1877.958898] brcmfmac: [brcmf_cfg80211_add_key -> __send_key_to_dongle] ifp:c71c5480 brcmf_ifname(ifp):wlan1-1
> [ 1878.923359] WARNING: CPU: 1 PID: 1140 at compat-wireless-2016-06-20/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c:1256 brcmf_netdev_wait_pend8021x+0xbc/0x184 [brcmfmac]()
> [ 1880.659840] brcmfmac: [brcmf_netdev_wait_pend8021x] ifp:c71c5480 brcmf_ifname(ifp):wlan1-1 brcmf_get_pend_8021x_cnt(ifp):3
> [ 1880.670922] brcmfmac: [brcmf_netdev_wait_pend8021x] List of pending 802.1x skbs:
> [ 1880.678333] brcmfmac: [brcmf_netdev_wait_pend8021x] skb:c6b18d80 skb->dev:c71c5000 skb->dev->name:wlan1-1
> [ 1880.687935] brcmfmac: [brcmf_netdev_wait_pend8021x] skb:c6b18900 skb->dev:c71c5000 skb->dev->name:wlan1-1
> [ 1880.697530] brcmfmac: [brcmf_netdev_wait_pend8021x] skb:c721fc00 skb->dev:c71c5000 skb->dev->name:wlan1-1
> [ 1881.439614] brcmfmac: [brcmf_msgbuf_process_txstatus -> __brcmf_txfinalize] Finally finalizing skb:c6b18d80 skb->dev:c71c5000 skb->dev->name:wlan1-1 (start_time:[ 1874.928858]; commit_time:[ 1874.928994])
> [ 1881.457852] brcmfmac: [brcmf_msgbuf_process_txstatus -> __brcmf_txfinalize] Finally finalizing skb:c6b18900 skb->dev:c71c5000 skb->dev->name:wlan1-1 (start_time:[ 1875.938806]; commit_time:[ 1875.938858])
> [ 1881.476074] brcmfmac: [brcmf_msgbuf_process_txstatus -> __brcmf_txfinalize] Finally finalizing skb:c721fc00 skb->dev:c71c5000 skb->dev->name:wlan1-1 (start_time:[ 1876.948805]; commit_time:[ 1876.948855])
>
> For the first skb brcmf_netdev_start_xmit was called at 1874.928858.
> It was commited to firmware with brcmf_msgbuf_txflow at 1874.928994.
> Then there was A-MPDU hang in firmware.
> Finally brcmf_msgbuf_process_txstatus was called and it called
> brcmf_txfinalize and this one logged everything at 1881.439614.
>
> You'll find full log at the end.
I kept thinking about this. Some more timing info:
1) wlc_ampdu_watchdog probably started with ampdu_dbg, so we can assume the
beginning was about 1876.423494.
2) brcmf_netdev_wait_pend8021x waits for 950 ms, so it probably started about
1877.973359
So the closest timeline I can guess/restore is:
1874.423494: A-MPDU stalls
1874.928994: Passing 802.1x packet #1 to the firmware
1875.938858: Passing 802.1x packet #2 to the firmware
1876.423494: A-MPDU stall detected
1876.508943: Firmware sends DELBA
1876.948855: Passing 802.1x packet #3 to the firmware
1877.973359: brcmf_netdev_wait_pend8021x starts waiting
1881.439614: TX status of 802.1x packet #1
1881.457852: TX status of 802.1x packet #2
1881.476074: TX status of 802.1x packet #3
Now I'm more thinking about this, maybe this A-MPDU stall wasn't any firmware
bug at all? Could it be firmware wasn't getting BA reply e.g. because STA simply
lost the signal?
5 seconds of firmware delay between noticing A-MPDU stall and finally sending
802.1x packets still sound like a big one, but maybe it's not *that* critical?
What's the real problem then is brcmfmac waiting for too long in
brcmf_netdev_wait_pend8021x. It prevents keys from updating and current timeout
of 950 ms sounds like quite a lot. Increasing it to few seconds would stop
WARNINGs from appearing, but would make keys update take even more time.
I guess ideally we should:
1) Have firmware quickly recover from A-MPDU stall (currently: 2 + 5 seconds)
2) Don't have to wait for so long to update keys
^ permalink raw reply
* [PATCH] ath10k: Provide provision to get Transmit Power Control stats for 10.4
From: c_mkenna @ 2016-09-15 14:30 UTC (permalink / raw)
To: ath10k, linux-wireless; +Cc: mkenna, Maharaja Kennadyrajan
From: Maharaja Kennadyrajan <c_mkenna@qti.qualcomm.com>
This patch helps to get the TPC stats for 10.4 fw variants.
Signed-off-by: Maharaja Kennadyrajan <c_mkenna@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/wmi.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 38993d7..44a1a8d 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -5391,6 +5391,9 @@ static void ath10k_wmi_10_4_op_rx(struct ath10k *ar, struct sk_buff *skb)
case WMI_10_4_PDEV_BSS_CHAN_INFO_EVENTID:
ath10k_wmi_event_pdev_bss_chan_info(ar, skb);
break;
+ case WMI_10_4_PDEV_TPC_CONFIG_EVENTID:
+ ath10k_wmi_event_pdev_tpc_config(ar, skb);
+ break;
default:
ath10k_warn(ar, "Unknown eventid: %d\n", id);
break;
@@ -8147,6 +8150,7 @@ static const struct wmi_ops wmi_10_4_ops = {
.get_vdev_subtype = ath10k_wmi_10_4_op_get_vdev_subtype,
.gen_pdev_bss_chan_info_req = ath10k_wmi_10_2_op_gen_pdev_bss_chan_info,
.gen_echo = ath10k_wmi_op_gen_echo,
+ .gen_pdev_get_tpc_config = ath10k_wmi_10_2_4_op_gen_pdev_get_tpc_config,
};
int ath10k_wmi_attach(struct ath10k *ar)
--
1.7.9.5
^ permalink raw reply related
* brcmfmac MAC address change delay and 500ms down delay
From: Dan Williams @ 2016-09-15 14:42 UTC (permalink / raw)
To: linux-wireless; +Cc: Arend van Spriel
Hi,
While refining NetworkManager's MAC address randomization behavior we
came across two issues with brcmfmac:
1) when changing the MAC address, the driver schedules work for the new
change and returns success, but doesn't actually change the MAC until
the work is scheduled. Because it returns 0 from the
ndo_set_mac_address hook the net core will generate a NETDEV_CHANGEADDR
event and rtnetlink will send out an RTM_NEWLINK with the old MAC
address. No event for the new address will be sent. So it's pretty
hard to figure out when the address actually changed, and when its safe
to associate, without polling the device's MAC address. Ugly.
2) when closing the device (eg, set !IFF_UP) the driver unconditionally
blocks for 500ms in __brcmf_cfg80211_down():
if (check_vif_up(ifp->vif)) {
brcmf_link_down(ifp->vif, WLAN_REASON_UNSPECIFIED);
/* Make sure WPA_Supplicant receives all the event
generated due to DISASSOC call to the fw to keep
the state fw and WPA_Supplicant state consistent
*/
brcmf_delay(500);
}
Should I dump these into kernel bugzilla, or is there some internal bug
tracker they could get stuffed into?
Thanks!
Dan
^ permalink raw reply
* Re: [PATCH v2 15/21] ath10k: support CT firmware flag.
From: Ben Greear @ 2016-09-15 14:43 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <87bmzpb667.fsf@kamboji.qca.qualcomm.com>
On 09/15/2016 07:15 AM, Valo, Kalle wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 09/14/2016 07:30 AM, Valo, Kalle wrote:
>>> greearb@candelatech.com writes:
>>>
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> Add placeholder so CT firmware can more easily co-exist with upstream
>>>> kernel. CT firmware should be backwards compatible with existing kernels,
>>>> but it also has many new features. Subsequent patches, if acceptable for
>>>> upstream, can enable and further describe those features.
>>>>
>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>> ---
>>>> drivers/net/wireless/ath/ath10k/core.c | 1 +
>>>> drivers/net/wireless/ath/ath10k/core.h | 3 +++
>>>> 2 files changed, 4 insertions(+)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
>>>> index fa71d57..49c85c3 100644
>>>> --- a/drivers/net/wireless/ath/ath10k/core.c
>>>> +++ b/drivers/net/wireless/ath/ath10k/core.c
>>>> @@ -235,6 +235,7 @@ static const char *const ath10k_core_fw_feature_str[] = {
>>>> [ATH10K_FW_FEATURE_SUPPORTS_ADAPTIVE_CCA] = "adaptive-cca",
>>>> [ATH10K_FW_FEATURE_MFP_SUPPORT] = "mfp",
>>>> [ATH10K_FW_FEATURE_PEER_FLOW_CONTROL] = "peer-flow-ctrl",
>>>> + [ATH10K_FW_FEATURE_WMI_10X_CT] = "wmi-10.x-CT",
>>>> };
>>>>
>>>> static unsigned int ath10k_core_get_fw_feature_str(char *buf,
>>>> diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
>>>> index cb6aa8c..f9e3b20 100644
>>>> --- a/drivers/net/wireless/ath/ath10k/core.h
>>>> +++ b/drivers/net/wireless/ath/ath10k/core.h
>>>> @@ -566,6 +566,9 @@ enum ath10k_fw_features {
>>>> */
>>>> ATH10K_FW_FEATURE_PEER_FLOW_CONTROL = 13,
>>>>
>>>> + /* Firmware from Candela Technologies, enables more VIFs, etc */
>>>> + ATH10K_FW_FEATURE_WMI_10X_CT = 31,
>>>
>>> The idea of firmware feature flags to enable (or disable) one particular
>>> feature, not a group of features. This way it's easy to enable certain
>>> features on different firmware branches. It also makes the maintenance
>>> easier as you don't need to remember all the different features one flag
>>> enables.
>>
>> One potential use for this flag: Bug reports could be automatically directed to me instead
>> of QCA.
>>
>> I have actually re-written much of my earlier logic so that it uses specific
>> feature flags now. I still like the idea of having the driver (and user)
>> know it is using CT firmware, but I can live without this flag if needed.
>
> You can do with firmware version string, add something like "-CT" (maybe
> you already have?) and it's clearly visible in boot logs and also when
> firmware crashes.
Yes, that is a worse hack, but it works.
Thing is, I have years of older, tested firmware around, with this feature flag
set. So, it is going to warn when booting in a kernel that does not understand
this flag.
So, if you want CT firmware support at all in the upstream kernel, then I wish
you would let me add the enum and string to make it work as expected. That will also
let these old firmware do IBSS with one of the other patches I posted. Yes, it would
be nice to have an IBSS feature flag, but we have not for years, and again, this would
let my older firmware work.
It feels a bit like pulling teeth to get patches upstream. You are basically
waving through this huge hack to set registers for ack-timing and stuff, but
then you are arguing about a simple feature flag enum?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2 03/21] ath10k: Allow changing ath10k debug mask at runtime.
From: Ben Greear @ 2016-09-15 15:07 UTC (permalink / raw)
To: Valo, Kalle; +Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <874m5hb5zn.fsf@kamboji.qca.qualcomm.com>
On 09/15/2016 07:19 AM, Valo, Kalle wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 09/14/2016 07:06 AM, Valo, Kalle wrote:
>>> greearb@candelatech.com writes:
>>>
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> Using debugfs. More convenient than module options
>>>> in some cases.
>>>>
>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>> ---
>>>> drivers/net/wireless/ath/ath10k/debug.c | 62 +++++++++++++++++++++++++++++++++
>>>> 1 file changed, 62 insertions(+)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
>>>> index e251155..d552a4a 100644
>>>> --- a/drivers/net/wireless/ath/ath10k/debug.c
>>>> +++ b/drivers/net/wireless/ath/ath10k/debug.c
>>>> @@ -870,6 +870,65 @@ static const struct file_operations fops_reg_addr = {
>>>> .llseek = default_llseek,
>>>> };
>>>>
>>>> +static ssize_t ath10k_read_debug_level(struct file *file,
>>>> + char __user *user_buf,
>>>> + size_t count, loff_t *ppos)
>>>> +{
>>>> + int sz;
>>>> + const char buf[] =
>>>> + "To change debug level, set value adding up desired flags:\n"
>>>> + "PCI: 0x1\n"
>>>> + "WMI: 0x2\n"
>>>> + "HTC: 0x4\n"
>>>> + "HTT: 0x8\n"
>>>> + "MAC: 0x10\n"
>>>> + "BOOT: 0x20\n"
>>>> + "PCI-DUMP: 0x40\n"
>>>> + "HTT-DUMP: 0x80\n"
>>>> + "MGMT: 0x100\n"
>>>> + "DATA: 0x200\n"
>>>> + "BMI: 0x400\n"
>>>> + "REGULATORY: 0x800\n"
>>>> + "TESTMODE: 0x1000\n"
>>>> + "INFO-AS-DBG: 0x40000000\n"
>>>> + "FW: 0x80000000\n"
>>>> + "ALL: 0xFFFFFFFF\n";
>>>> + char wbuf[sizeof(buf) + 60];
>>>> + sz = snprintf(wbuf, sizeof(wbuf), "Current debug level: 0x%x\n\n%s",
>>>> + ath10k_debug_mask, buf);
>>>> + wbuf[sizeof(wbuf) - 1] = 0;
>>>> +
>>>> + return simple_read_from_buffer(user_buf, count, ppos, wbuf, sz);
>>>> +}
>>>> +
>>>> +/* Set logging level.
>>>> + */
>>>> +static ssize_t ath10k_write_debug_level(struct file *file,
>>>> + const char __user *user_buf,
>>>> + size_t count, loff_t *ppos)
>>>> +{
>>>> + struct ath10k *ar = file->private_data;
>>>> + int ret;
>>>> + unsigned long mask;
>>>> +
>>>> + ret = kstrtoul_from_user(user_buf, count, 0, &mask);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + ath10k_warn(ar, "Setting debug-mask to: 0x%lx old: 0x%x\n",
>>>> + mask, ath10k_debug_mask);
>>>> + ath10k_debug_mask = mask;
>>>> + return count;
>>>> +}
>>>
>>> There are already sysfs files for module parameters which seems to work
>>> just fine for this case:
>>>
>>> # echo 0xffffffff > /sys/module/ath10k_core/parameters/debug_mask
>>
>>
>> Ok, but it is still nice to have the printout info of what log levels
>> means. Otherwise, you have to go look at firmware source to even know how
>> to enable the proper flags. And as these flags are internal and might change,
>> we could change the printout text to match the specific kernel that is running.
>
> The debug log levels are documented in the wiki:
>
> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/debug#debug_log_messages
>
> And they are not supposed to change, there should be only additions.
Ahh, I remember the best part of this patch. It pre-positions for another patch
that makes the debug-mask per NIC instance instead of per driver.
This can be quite useful for testing with multiple radios, maybe only one of
which you want to see logging for.
And regardless of what is in a wiki somewhere, having a debugfs file to cat out is
more user friendly.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* pull-request: wireless-drivers-next 2016-09-15
From: Kalle Valo @ 2016-09-15 15:09 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's the first pull request for 4.9. The ones I want to point out are
the FIELD_PREP() and FIELD_GET() macros added to bitfield.h, which are
reviewed by Linus, and make it possible to remove util.h from mt7601u.
Also we have new HW support to various drivers and other smaller
features, the signed tag below contains more information. And I pulled
my ath-current (uses older net tree as the baseline) branch to fix a
conflict in ath10k.
Once again the diffstat from git request-pull was wrong. I fixed it by
manually copying the diffstat from a test pull against net-next, so
everything should be ok. But please let me know if there are any
problems.
Kalle
The following changes since commit e34f2ff40e0339f6a379e1ecf49e8f2759056453:
ath9k: bring back direction setting in ath9k_{start_stop} (2016-09-07 16:21:04 +0300)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2016-09-15
for you to fetch changes up to b7450e248d71067e0c1a09614cf3d7571f7e10fa:
mwifiex: firmware name correction for usb8997 chipset (2016-09-14 20:02:14 +0300)
----------------------------------------------------------------
wireless-drivers-next patches for 4.9
Major changes:
iwlwifi
* preparation for new a000 HW continues
* some DQA improvements
* add support for GMAC
* add support for 9460, 9270 and 9170 series
mwifiex
* support random MAC address for scanning
* add HT aggregation support for adhoc mode
* add custom regulatory domain support
* add manufacturing mode support via nl80211 testmode interface
bcma
* support BCM53573 series of wireless SoCs
bitfield.h
* add FIELD_PREP() and FIELD_GET() macros
mt7601u
* convert to use the new bitfield.h macros
brcmfmac
* add support for bcm4339 chip with modalias sdio:c00v02D0d4339
ath10k
* add nl80211 testmode support for 10.4 firmware
* hide kernel addresses from logs using %pK format specifier
* implement NAPI support
* enable peer stats by default
ath9k
* use ieee80211_tx_status_noskb where possible
wil6210
* extract firmware capabilities from the firmware file
ath6kl
* enable firmware crash dumps on the AR6004
ath-current is also merged to fix a conflict in ath10k.
----------------------------------------------------------------
Amitkumar Karwar (8):
mwifiex: fix failed to reconnect after interface disabled/enabled
mwifiex: remove misleading disconnect message
mwifiex: add CHAN_REGION_CFG command
mwifiex: add custom regulatory domain support
mwifiex: add PCIe function level reset support
mwifiex: PCIe8997 chip specific handling
mwifiex: handle error if IRQ request fails in mwifiex_sdio_of()
mwifiex: correction in Rx STBC field of htcapinfo
Arend Van Spriel (2):
brcmfmac: add support for bcm4339 chip with modalias sdio:c00v02D0d4339
brcmfmac: sdio: shorten retry loop in brcmf_sdio_kso_control()
Arnd Bergmann (1):
bcma: use of_dma_configure() to set initial dma mask
Ashok Raj Nagarajan (2):
ath10k: fix sending frame in management path in push txq logic
ath10k: fix reporting channel survey data
Ayala Beker (1):
iwlwifi: mvm: support GMAC protocol
Baoyou Xie (2):
ath9k: mark ath_fill_led_pin() static
brcmfmac: add missing header dependencies
Ben Greear (1):
ath10k: improve logging message
Bob Copeland (2):
ath9k: fix misleading indent
ath9k: remove repetitions of mask array size
Chaehyun Lim (1):
ath10k: remove unused variable ar_pci
Christian Engelmayer (2):
rtlwifi: rtl8192de: Fix leak in _rtl92de_read_adapter_info()
rtlwifi: rtl8723ae: Fix leak in _rtl8723e_read_adapter_info()
Christophe Jaillet (4):
mwifiex: fix the length parameter of a memset
mwifiex: simplify length computation for some memset
rt2x00usb: Fix error return code
mwifiex: scan: Simplify code
Colin Ian King (5):
ath10k: fix spelling mistake "montior" -> "monitor"
mwifiex: fix missing break on IEEE80211_STYPE_ACTION case
zd1211rw: fix spelling mistake "firmeware" -> "firmware"
ath10k: fix memory leak on caldata on error exit path
rtl8xxxu: fix spelling mistake "firmare" -> "firmware"
Dan Kephart (1):
ath6kl: enable firmware crash dumps on the AR6004
Daniel Wagner (2):
ath10k: use complete() instead complete_all()
carl9170: Fix wrong completion usage
Eduardo Abinader (1):
ath9k: consider return code on
Eric Bentley (1):
ath6kl: Allow the radio to report 0 dbm txpower without timing out
Felix Fietkau (2):
ath9k: use ieee80211_tx_status_noskb where possible
ath9k: improve powersave filter handling
Ganapathi Bhat (4):
mwifiex: support random MAC address for scanning
mwifiex: fix radar detection issue
mwifiex: Command 7 handling for USB chipsets
mwifiex: firmware name correction for usb8997 chipset
Guy Mishol (1):
wl18xx: add time sync configuration api
Hans de Goede (1):
rtl8xxxu: Make rtl8xxxu_ampdu_action less chatty
Heinrich Schuchardt (3):
mwifiex: remove superfluous condition
mwifiex: key_material_v2 remove superfluous condition
rtlwifi: remove superfluous condition
Ismael Luceno (1):
brcmfmac: Add USB ID for Cisco Linksys AE1200
Jakub Kicinski (4):
add basic register-field manipulation macros
mt7601u: remove redefinition of GENMASK
mt7601u: remove unnecessary include
mt7601u: use linux/bitfield.h
Jes Sorensen (19):
rtl8xxxu: Mark 0x20f4:0x648b as tested
rtl8xxxu: Mark 0x2001:0x3308 as tested
rtl8xxxu: Fix error handling if rtl8xxxu_init_device() fails
rtl8xxxu: Add TP-Link TL-WN823N v2 to list of supported devices
rtl8xxxu: Add TX page defines for 8723b
rtl8xxxu: Switch 8723a to use new rtl8xxxu_init_queue_reserved_page() routine
rtl8xxxu: Switch 8192cu/8188cu devices to use rtl8xxxu_init_queue_reserved_page()
rtl8xxxu: Remove now obsolete rtl8xxxu_old_init_queue_reserved_page()
rtl8xxxu: Simplify code setting TX buffer boundary
rtl8xxxu: Add bit definitions for REG_FPGA0_TX_INFO
rtl8xxxu: Add interrupt bit definitions for gen2 parts
rtl8xxxu: Use flag to indicate whether device has TX report timer support
rtl8xxxu: Convert flags in rtl8xxxu_fileops to bitflags
rtl8xxxu: Introduce fops bitflag indicating type of thermal meter
rtl8xxxu: Simplify calculating of hw value used for setting TX rate
rtl8xxxu: Determine the need for SGI before handling specific TX desc formats
rtl8xxxu: Determine need for shore preamble before updating TX descriptors
rtl8xxxu: Split filling of TX descriptors into separate functions
rtl8xxxu: Reset device on module unload if still attached
Julia Lawall (3):
ath: constify local structures
iwlegacy: constify local structures
rtlwifi: rtl818x: constify local structures
Kalle Valo (3):
Merge tag 'iwlwifi-next-for-kalle-2016-08-30-2' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge branch 'ath-current' into ath-next
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Karthik D A (2):
mwifiex: Fixed endianness problem for big endian platform
mwifiex: add region code information in debugfs
Larry Finger (1):
rtlwifi: Fix missing country code for Great Britain
Lazar Alexei (1):
wil6210: Fix driver down flow
Liad Kaufman (5):
iwlwifi: mvm: re-aggregate shared queue after unsharing
iwlwifi: mvm: keep track of tid associated with each queue
iwlwifi: mvm: re-assign old queues after hw restart in dqa mode
iwlwifi: mvm: use defines for SCD_CONFIG_CMD enablement
iwlwifi: mvm: support txq tid owner change
Lior David (6):
wil6210: change HALP logging category to IRQ
wil6210: fix wiphy registration sequence
wil6210: fix protection of wil->scan_request
wil6210: align to latest auto generated wmi.h
wil6210: extract firmware capabilities from FW file
wil6210: extract firmware version from file header
Maharaja Kennadyrajan (2):
ath10k: hide kernel addresses from logs using %pK format specifier
ath10k: Added support for extended dbglog module id for 10.4
Masahiro Yamada (1):
ath10k: replace config_enabled() with IS_REACHABLE()
Maxim Altshul (1):
wlcore: Remove wl pointer from wl_sta structure
Maya Erez (5):
wil6210: align to latest auto generated wmi.h
wil6210: fix HALP handling in case of HALP vote time-out
wil6210: support rx key setting for all TIDs
wil6210: fix stop p2p device handling
wil6210: prevent usage of incorrect TX hwtail
Michal Kazior (4):
ath10k: implement wmi echo command
ath10k: implement wmi echo event
ath10k: add wmi command barrier utility
ath10k: fix spurious tx/rx during boot
Mohammed Shafi Shajakhan (3):
ath10k: suppress warnings when getting wmi WDS peer event id
ath10k: Fix broken NULL func data frame status for 10.4
ath10k: remove unnecessary error code assignment
Nicolas Iooss (1):
brcmfmac: fix pmksa->bssid usage
Oleg Drokin (1):
rtlwifi/rtl8192de: Fix print format string
Oren Givon (5):
iwlwifi: rename and reorder 9000 series configuration structs
iwlwifi: add a new series 9460 with new PCI ID
iwlwifi: add new 9460 series PCI IDs
iwlwifi: add the new 9270 series
iwlwifi: add the new 9170 series
Pavel Andrianov (1):
wl3501_cs: Add spinlock to wl3501_reset
Rafał Miłecki (1):
bcma: support BCM53573 series of wireless SoCs
Rajan Vaja (1):
hostap: Use memdup_user() to reuse code
Rajkumar Manoharan (4):
ath10k: fix group privacy action frame decryption for qca4019
ath10k: improve wake_tx_queue ops performance
ath10k: implement NAPI support
ath10k: fix throughput regression in multi client mode
Sara Sharon (5):
iwlwifi: mvm: allow same PN for de-aggregated AMSDU
iwlwifi: mvm: support new paging command format
iwlwifi: pcie: refrain from SCD accesses
iwlwifi: pcie: fix ucode load flow for a000 devices
iwlwifi: pcie: remove dead code
Sergey Ryazanov (1):
ath5k: fix EEPROM dumping via debugfs
Stanislaw Gruszka (3):
mwifiex: make "PCI-E is not the winner" print more informative
mwifiex: print status of FW ready event
mwifiex: do not print dot when downloading FW
Tamizh chelvam (4):
ath10k: move firmware_swap_code_seg_info to ath10k_fw_file
ath10k: handle testmode events for 10.2 and 10.4 based firmware
ath10k: add testmode support for 10.4 firmware
ath10k: Add WMI_SERVICE_PERIODIC_CHAN_STAT_SUPPORT wmi service
Thomas Pedersen (1):
ath10k: enable peer stats by default
Vasanthakumar Thiagarajan (4):
ath10k: move ath10k_hw_params definition to hw.h
ath10k: add provision for Rx descriptor abstraction
ath10k: properly remove padding from the start of rx payload
ath10k: remove 4-addr padding related hw_param configuration
Wei Yongjun (2):
wlcore: spi: fix non static symbol warning
rtl8xxxu: gen1: Fix non static symbol warning
Xinming Hu (5):
mwifiex: process rxba_sync event
mwifiex: add HT aggregation support for adhoc mode
mwifiex: correct aid value during tdls setup
mwifiex: add manufacturing mode support
mwifiex: add cfg80211 testmode support
>From git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
* tag wireless-drivers-next-for-davem-2016-09-15 -> FETCH_HEAD
Removing drivers/net/wireless/mediatek/mt7601u/util.h
Auto-merging drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
Auto-merging drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
Auto-merging drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
Merge made by the 'recursive' strategy.
drivers/bcma/driver_chipcommon.c | 32 +-
drivers/bcma/main.c | 6 +-
drivers/net/wireless/ath/ath10k/ahb.c | 12 +-
drivers/net/wireless/ath/ath10k/bmi.c | 4 +-
drivers/net/wireless/ath/ath10k/ce.c | 4 +-
drivers/net/wireless/ath/ath10k/core.c | 125 ++-
drivers/net/wireless/ath/ath10k/core.h | 79 +-
drivers/net/wireless/ath/ath10k/debug.c | 11 +-
drivers/net/wireless/ath/ath10k/htc.c | 6 +-
drivers/net/wireless/ath/ath10k/htt.h | 2 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 194 ++--
drivers/net/wireless/ath/ath10k/htt_tx.c | 2 -
drivers/net/wireless/ath/ath10k/hw.c | 13 +
drivers/net/wireless/ath/ath10k/hw.h | 76 +-
drivers/net/wireless/ath/ath10k/mac.c | 70 +-
drivers/net/wireless/ath/ath10k/pci.c | 77 +-
drivers/net/wireless/ath/ath10k/pci.h | 6 +-
drivers/net/wireless/ath/ath10k/swap.c | 26 +-
drivers/net/wireless/ath/ath10k/swap.h | 11 +-
drivers/net/wireless/ath/ath10k/testmode.c | 27 +-
drivers/net/wireless/ath/ath10k/thermal.c | 2 +-
drivers/net/wireless/ath/ath10k/txrx.c | 4 +-
drivers/net/wireless/ath/ath10k/wmi-ops.h | 33 +-
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 59 +-
drivers/net/wireless/ath/ath10k/wmi.c | 186 +++-
drivers/net/wireless/ath/ath10k/wmi.h | 24 +
drivers/net/wireless/ath/ath5k/debug.c | 6 +-
drivers/net/wireless/ath/ath6kl/cfg80211.c | 4 +-
drivers/net/wireless/ath/ath6kl/hif.c | 11 +-
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 9 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 6 +-
drivers/net/wireless/ath/ath9k/gpio.c | 2 +-
drivers/net/wireless/ath/ath9k/main.c | 2 +-
drivers/net/wireless/ath/ath9k/xmit.c | 104 ++-
drivers/net/wireless/ath/carl9170/usb.c | 6 +-
drivers/net/wireless/ath/dfs_pattern_detector.c | 2 +-
drivers/net/wireless/ath/wil6210/cfg80211.c | 151 ++--
drivers/net/wireless/ath/wil6210/debugfs.c | 53 +-
drivers/net/wireless/ath/wil6210/fw.h | 14 +-
drivers/net/wireless/ath/wil6210/fw_inc.c | 92 +-
drivers/net/wireless/ath/wil6210/interrupt.c | 15 +-
drivers/net/wireless/ath/wil6210/main.c | 63 +-
drivers/net/wireless/ath/wil6210/netdev.c | 34 +-
drivers/net/wireless/ath/wil6210/p2p.c | 46 +
drivers/net/wireless/ath/wil6210/pcie_bus.c | 9 +-
drivers/net/wireless/ath/wil6210/txrx.c | 9 +-
drivers/net/wireless/ath/wil6210/wil6210.h | 11 +-
drivers/net/wireless/ath/wil6210/wmi.c | 12 +-
drivers/net/wireless/ath/wil6210/wmi.h | 932 ++++++++++++++++++--
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 1 +
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 4 +-
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 14 +-
.../broadcom/brcm80211/brcmfmac/tracepoint.c | 1 +
.../net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 4 +
.../broadcom/brcm80211/include/brcm_hw_ids.h | 2 +
drivers/net/wireless/intel/iwlegacy/3945.c | 4 +-
drivers/net/wireless/intel/iwlwifi/iwl-9000.c | 83 +-
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 6 +-
drivers/net/wireless/intel/iwlwifi/iwl-fh.h | 15 +-
drivers/net/wireless/intel/iwlwifi/iwl-prph.h | 19 +-
.../net/wireless/intel/iwlwifi/mvm/fw-api-sta.h | 31 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h | 12 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h | 8 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 28 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 18 +-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 26 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 6 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 342 ++++++-
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 4 +
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 38 +-
drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 24 +-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 41 +-
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 45 +-
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 13 +-
.../net/wireless/intersil/hostap/hostap_ioctl.c | 20 +-
drivers/net/wireless/marvell/mwifiex/11h.c | 27 +-
drivers/net/wireless/marvell/mwifiex/11n.h | 7 +-
.../net/wireless/marvell/mwifiex/11n_rxreorder.c | 78 +-
.../net/wireless/marvell/mwifiex/11n_rxreorder.h | 3 +-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 143 ++-
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 26 +-
drivers/net/wireless/marvell/mwifiex/debugfs.c | 2 +
drivers/net/wireless/marvell/mwifiex/fw.h | 73 +-
drivers/net/wireless/marvell/mwifiex/init.c | 22 +-
drivers/net/wireless/marvell/mwifiex/join.c | 3 +-
drivers/net/wireless/marvell/mwifiex/main.c | 270 +++++-
drivers/net/wireless/marvell/mwifiex/main.h | 7 +
drivers/net/wireless/marvell/mwifiex/pcie.c | 182 +++-
drivers/net/wireless/marvell/mwifiex/pcie.h | 13 +-
drivers/net/wireless/marvell/mwifiex/scan.c | 28 +-
drivers/net/wireless/marvell/mwifiex/sdio.c | 6 +-
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 61 +-
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 134 ++-
drivers/net/wireless/marvell/mwifiex/sta_event.c | 144 ++-
drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 6 +-
drivers/net/wireless/marvell/mwifiex/uap_event.c | 7 +-
drivers/net/wireless/marvell/mwifiex/usb.c | 6 +-
drivers/net/wireless/marvell/mwifiex/usb.h | 3 +-
drivers/net/wireless/marvell/mwifiex/util.c | 1 +
drivers/net/wireless/mediatek/mt7601u/dma.c | 2 +-
drivers/net/wireless/mediatek/mt7601u/dma.h | 10 +-
drivers/net/wireless/mediatek/mt7601u/eeprom.c | 12 +-
drivers/net/wireless/mediatek/mt7601u/init.c | 10 +-
drivers/net/wireless/mediatek/mt7601u/mac.c | 38 +-
drivers/net/wireless/mediatek/mt7601u/main.c | 1 -
drivers/net/wireless/mediatek/mt7601u/mcu.c | 20 +-
drivers/net/wireless/mediatek/mt7601u/mt7601u.h | 4 +-
drivers/net/wireless/mediatek/mt7601u/phy.c | 44 +-
drivers/net/wireless/mediatek/mt7601u/regs.h | 4 -
drivers/net/wireless/mediatek/mt7601u/tx.c | 19 +-
drivers/net/wireless/mediatek/mt7601u/util.h | 77 --
drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 4 +-
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 22 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c | 5 +
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 2 +
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c | 5 +
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 7 +
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 328 +++----
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h | 60 ++
drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/regd.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/sw.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/phy.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/sw.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/sw.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/sw.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/sw.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/sw.c | 2 +-
drivers/net/wireless/ti/wl18xx/acx.c | 29 +
drivers/net/wireless/ti/wl18xx/acx.h | 13 +
drivers/net/wireless/ti/wl18xx/event.c | 1 +
drivers/net/wireless/ti/wlcore/main.c | 1 -
drivers/net/wireless/ti/wlcore/spi.c | 2 +-
drivers/net/wireless/ti/wlcore/wlcore.h | 3 +
drivers/net/wireless/ti/wlcore/wlcore_i.h | 1 -
drivers/net/wireless/wl3501_cs.c | 7 +-
drivers/net/wireless/zydas/zd1211rw/zd_usb.c | 2 +-
include/linux/bitfield.h | 93 ++
include/linux/bug.h | 3 +
include/linux/mmc/sdio_ids.h | 1 +
144 files changed, 4390 insertions(+), 1218 deletions(-)
delete mode 100644 drivers/net/wireless/mediatek/mt7601u/util.h
create mode 100644 include/linux/bitfield.h
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 10/21] ath10k: support logging ath10k_info as KERN_DEBUG
From: Ben Greear @ 2016-09-15 15:11 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <87fup1b6ao.fsf@kamboji.qca.qualcomm.com>
On 09/15/2016 07:12 AM, Valo, Kalle wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 09/14/2016 07:19 AM, Valo, Kalle wrote:
>>> greearb@candelatech.com writes:
>>>
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> Helps keep messages off of (serial) console when
>>>> that is desired.
>>>>
>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>
>>> Isn't /proc/sys/kernel/print exactly for this purpose? At least I recall
>>> using it.
>>
>> I just wanted to hide some ath10k logs from the console, not all
>> system logs. I don't think that /proc/sys/kernel/print has any
>> granularity?
>
> It should be based on KERN_ log levels. I don't know what your kernel
> does, but ath10k should be printing only very few messages with level
> KERN_INFO or above, all of of the debug messages. So you should be
> easily able to filter out all ath10k debug messages as they are sent
> with KERN_DEBUG.
I originally added this when I was testing .11r associating timing. Just
having a few lines of ath10k printk on the serial console added several 10s
of milliseconds to the time it took to associate, and that was throwing off my
results. I still wanted to see the messges in 'dmesg', just not on the console.
I did not want to hide other WARN level logs from the console, just the ath10k
ones.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
From: Ben Greear @ 2016-09-15 15:14 UTC (permalink / raw)
To: Valo, Kalle
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org,
emmanuel.grumbach@intel.com
In-Reply-To: <87k2edb6kp.fsf@kamboji.qca.qualcomm.com>
On 09/15/2016 07:06 AM, Valo, Kalle wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 09/14/2016 07:18 AM, Valo, Kalle wrote:
>>> greearb@candelatech.com writes:
>>>
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> This allows user-space tools to decode debug-log
>>>> messages by parsing dmesg or /var/log/messages.
>>>>
>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>
>>> Don't tracing points already provide the same information?
>>
>> Tracing tools are difficult to set up and may not be available on
>> random embedded devices. And if we are dealing with bug reports from
>> the field, most users will not be able to set it up regardless.
>>
>> There are similar ways to print out hex, but the logic below creates
>> specific and parseable logs in the 'dmesg' output and similar.
>>
>> I have written a tool that can decode these messages into useful human-readable
>> text so that I can debug firmware issues both locally and from field reports.
>>
>> Stock firmware generates similar logs and QCA could write their own decode logic
>> for their firmware versions.
>
> Reinventing the wheel by using printk as the delivery mechanism doesn't
> sound like a good idea. IIRC Emmanuel talked about some kind of firmware
> debugging framework, he might have some ideas.
Waiting for magical frameworks to fix problems is even worse.
It has been years since ath10k has been in the kernel. There is basically
still no way to debug what the firmware is doing.
My patch gives you something that can work right now, with the standard 'dmesg'
framework found in virtually all kernels new and old, and it has been proven
to be useful in the field. The messages are also nicely interleaved with the
rest of the mac80211 stack messages and any other driver messages, so you have
context.
If someone wants to add support for a framework later, then by all means, post
the patches when it is ready.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] cfg80211: add helper to find an IE that matches a byte-array
From: Luca Coelho @ 2016-09-15 15:15 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Luca Coelho
From: Luca Coelho <luciano.coelho@intel.com>
There are a few places where an IE that matches not only the EID, but
also other bytes inside the element, needs to be found. To simplify
that and reduce the amount of similar code, implement a new helper
function to match the EID and an extra array of bytes.
Additionally, simplify cfg80211_find_vendor_ie() by using the new
match function.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
include/net/cfg80211.h | 33 +++++++++++++++++++++++++++-
net/wireless/scan.c | 58 +++++++++++++++++++++++---------------------------
2 files changed, 59 insertions(+), 32 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index d5e7f69..533cb64 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3947,6 +3947,34 @@ unsigned int cfg80211_classify8021d(struct sk_buff *skb,
struct cfg80211_qos_map *qos_map);
/**
+ * cfg80211_find_ie_match - match information element and byte array in data
+ *
+ * @eid: element ID
+ * @ies: data consisting of IEs
+ * @len: length of data
+ * @match: byte array to match
+ * @match_len: number of bytes in the match array
+ * @match_offset: offset in the IE where the byte array should match.
+ * If match_len is zero, this must also be set to zero.
+ * Otherwise this must be set to 2 or more, because the first
+ * byte is the element id, which is already compared to eid, and
+ * the second byte is the IE length.
+ *
+ * Return: %NULL if the element ID could not be found or if
+ * the element is invalid (claims to be longer than the given
+ * data) or if the byte array doesn't match, or a pointer to the first
+ * byte of the requested element, that is the byte containing the
+ * element ID.
+ *
+ * Note: There are no checks on the element length other than
+ * having to fit into the given data and being large enough for the
+ * byte array to match.
+ */
+const u8 *cfg80211_find_ie_match(u8 eid, const u8 *ies, int len,
+ const u8 *match, int match_len,
+ int match_offset);
+
+/**
* cfg80211_find_ie - find information element in data
*
* @eid: element ID
@@ -3961,7 +3989,10 @@ unsigned int cfg80211_classify8021d(struct sk_buff *skb,
* Note: There are no checks on the element length other than
* having to fit into the given data.
*/
-const u8 *cfg80211_find_ie(u8 eid, const u8 *ies, int len);
+static inline const u8 *cfg80211_find_ie(u8 eid, const u8 *ies, int len)
+{
+ return cfg80211_find_ie_match(eid, ies, len, NULL, 0, 0);
+}
/**
* cfg80211_find_vendor_ie - find vendor specific information element in data
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 0358e12..b5bd58d 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -352,52 +352,48 @@ void cfg80211_bss_expire(struct cfg80211_registered_device *rdev)
__cfg80211_bss_expire(rdev, jiffies - IEEE80211_SCAN_RESULT_EXPIRE);
}
-const u8 *cfg80211_find_ie(u8 eid, const u8 *ies, int len)
+const u8 *cfg80211_find_ie_match(u8 eid, const u8 *ies, int len,
+ const u8 *match, int match_len,
+ int match_offset)
{
- while (len > 2 && ies[0] != eid) {
+ /* match_offset can't be smaller than 2, unless match_len is
+ * zero, in which case match_offset must be zero as well.
+ */
+ if (WARN_ON((match_len && match_offset < 2) ||
+ (!match_len && match_offset)))
+ return NULL;
+
+ while (len >= 2 && len >= ies[1] + 2) {
+ if ((ies[0] == eid) &&
+ (ies[1] + 2 >= match_offset + match_len) &&
+ !memcmp(ies + match_offset, match, match_len))
+ return ies;
+
len -= ies[1] + 2;
ies += ies[1] + 2;
}
- if (len < 2)
- return NULL;
- if (len < 2 + ies[1])
- return NULL;
- return ies;
+
+ return NULL;
}
-EXPORT_SYMBOL(cfg80211_find_ie);
+EXPORT_SYMBOL(cfg80211_find_ie_match);
const u8 *cfg80211_find_vendor_ie(unsigned int oui, int oui_type,
const u8 *ies, int len)
{
- struct ieee80211_vendor_ie *ie;
- const u8 *pos = ies, *end = ies + len;
- int ie_oui;
+ const u8 *ie;
+ u8 match[] = { oui >> 16, oui >> 8, oui, oui_type };
+ int match_len = (oui_type < 0) ? 3 : sizeof(match);
if (WARN_ON(oui_type > 0xff))
return NULL;
- while (pos < end) {
- pos = cfg80211_find_ie(WLAN_EID_VENDOR_SPECIFIC, pos,
- end - pos);
- if (!pos)
- return NULL;
-
- ie = (struct ieee80211_vendor_ie *)pos;
-
- /* make sure we can access ie->len */
- BUILD_BUG_ON(offsetof(struct ieee80211_vendor_ie, len) != 1);
+ ie = cfg80211_find_ie_match(WLAN_EID_VENDOR_SPECIFIC, ies, len,
+ match, match_len, 2);
- if (ie->len < sizeof(*ie))
- goto cont;
+ if (ie && (ie[1] < 4))
+ return NULL;
- ie_oui = ie->oui[0] << 16 | ie->oui[1] << 8 | ie->oui[2];
- if (ie_oui == oui &&
- (oui_type < 0 || ie->oui_type == oui_type))
- return pos;
-cont:
- pos += 2 + ie->len;
- }
- return NULL;
+ return ie;
}
EXPORT_SYMBOL(cfg80211_find_vendor_ie);
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v2 08/21] ath10k: make firmware text debug messages more verbose.
From: Ben Greear @ 2016-09-15 15:17 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <87oa3pb6rd.fsf@kamboji.qca.qualcomm.com>
On 09/15/2016 07:02 AM, Valo, Kalle wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 09/14/2016 07:12 AM, Valo, Kalle wrote:
>>> greearb@candelatech.com writes:
>>>
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> There are not many of these messages producted by the
>>>> firmware, but they are generally fairly useful, so print
>>>> them at info level.
>>>>
>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>> ---
>>>> drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
>>>> index 1758b4a..d9e4b77 100644
>>>> --- a/drivers/net/wireless/ath/ath10k/wmi.c
>>>> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
>>>> @@ -4050,7 +4050,7 @@ void ath10k_wmi_event_debug_print(struct ath10k *ar, struct sk_buff *skb)
>>>> /* the last byte is always reserved for the null character */
>>>> buf[i] = '\0';
>>>>
>>>> - ath10k_dbg(ar, ATH10K_DBG_WMI_PRINT, "wmi print '%s'\n", buf);
>>>> + ath10k_info(ar, "wmi print '%s'\n", buf);
>>>
>>> Useful to whom and how? I understand that for firmware developers this
>>> is very valuable information and that's why we have a special debug
>>> level for it. But I suspect that for normal users these are just
>>> confusing and unnecessarily spam the log.
>>
>> CT firmare will print out some memory usage info on firmware boot, and that can
>> allow a discerning individual to tune their vdev, peer, rate-ctrl, and other
>> object usage in order to make best use of resources in the firmware.
>>
>> These few lines can greatly aid debugging certain types of crashes and performance
>> loss in the firmware, so having them readily available in 'dmesg' or similar
>> for bug reports from the field helps me.
>>
>> Stock firmware will also print out some resource usage info. It is just
>> a few lines on firmware boot, but it is quite useful in my experience.
>
> I'm sure it's useful for you, but we have quite a few firmware versions
> to support. We do not know what kind of messages they print.
And how does that matter? You think you can break something by printing
a string the logs?
Even if you do see problems, you can hide the logging messages again.
It's not like it is even 'secret', it is trivial for someone to print out
this info with a patch like mine.
I have tested this on 10.1, 10.2, 10.4.3 firmware. Mine are similar to those
usptreams with regard to what they print out in this manner.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2 04/21] ath10k: rate-limit packet tx errors
From: Ben Greear @ 2016-09-15 15:22 UTC (permalink / raw)
To: Valo, Kalle; +Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <87sht1b6wc.fsf@kamboji.qca.qualcomm.com>
On 09/15/2016 06:59 AM, Valo, Kalle wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> On 09/14/2016 07:07 AM, Valo, Kalle wrote:
>>> greearb@candelatech.com writes:
>>>
>>>> From: Ben Greear <greearb@candelatech.com>
>>>>
>>>> When firmware crashes, stack can continue to send packets
>>>> for a bit, and existing code was spamming logs.
>>>>
>>>> So, rate-limit the error message for tx failures.
>>>>
>>>> Signed-off-by: Ben Greear <greearb@candelatech.com>
>>>> ---
>>>> drivers/net/wireless/ath/ath10k/mac.c | 5 +++--
>>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
>>>> index cd3016d..42cac32 100644
>>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>>> @@ -3432,8 +3432,9 @@ static int ath10k_mac_tx_submit(struct ath10k *ar,
>>>> }
>>>>
>>>> if (ret) {
>>>> - ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
>>>> - ret);
>>>> + if (net_ratelimit())
>>>> + ath10k_warn(ar, "failed to transmit packet, dropping: %d\n",
>>>> + ret);
>>>> ieee80211_free_txskb(ar->hw, skb);
>>>> }
>>>
>>> ath10k_warn() is already rate limited. If there's something wrong then
>>> that function should be fixed, not the callers.
>>>
>>> void ath10k_warn(struct ath10k *ar, const char *fmt, ...)
>>> {
>>> struct va_format vaf = {
>>> .fmt = fmt,
>>> };
>>> va_list args;
>>>
>>> va_start(args, fmt);
>>> vaf.va = &args;
>>> dev_warn_ratelimited(ar->dev, "%pV", &vaf);
>>> trace_ath10k_log_warn(ar, &vaf);
>>>
>>> va_end(args);
>>> }
>>
>> The problem with having the ratelimit here is that you may miss
>> rare warnings due to a flood of common warnings.
>>
>> That is why it is still useful to ratelimit potential floods
>> of warnings.
>
> I think this is a common problem in kernel, not specific to ath10k. For
> starters you could configure the limits dev_warn_ratelimited() has, not
> trying to workaround it in the driver.
I will try to explain this once more.
If you have the ratelimit in a centralized place, then all code that calls it
is rate-limitted with same counter and each call site gets the same priority.
One verbose caller can thus disable logs for the much more rare callers.
My patch pre-filters one of the verbose callers, which lets other more
rare and interesting callers be more likely to print logging messages
that are useful for debugging.
>> I would like to remove the ratelimit from ath10k_warn eventually.
>
> I think that's not a good idea, it might cause unnecessary host reboots
> in problem cases. Rate limitting the messages is much better option.
Ok, but even so, that would be a later patch and that is not a reason
to reject the one I posted.
For what it is worth, I and my users have been running such a patch for years
in various embedded and other systems and it works fine.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* wireless.wiki.kernel.org: lingering status of http://linuxwireless.org/en/users/Drivers/wl12xx/calibrator/
From: Andreas Mohr @ 2016-09-15 15:14 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
Dear Mr. Berg,
since we are working with TI WL12xx hardware,
I keep a reference on
http://linuxwireless.org/en/users/Drivers/wl12xx/calibrator/ ,
where it now says:
"NOTE: this page is for archival only, see the note at the end of the page."
"This is a static dump of the old wiki, taken after locking it in January 2015. The new wiki is at https://wireless.wiki.kernel.org/."
Trying to find related information
by searching for "calibrator" on https://wireless.wiki.kernel.org
will yield
https://wireless.wiki.kernel.org/en/developers/documentation/nl80211?s[]=calibrator
where "wl12xx calibrator" is a *dead link*.
The apparent underlying reason for this surfaces when
going through the en ... users ... Drivers hierarchy to
https://wireless.wiki.kernel.org/en/users/drivers/wl12xx
where it says
"
For relicensing, the content of this page was removed.
The old website for now has a copy of the old content:
http://linuxwireless.sipsolutions.net/en/users/Drivers/wl12xx/·
"
Somehow I am not quite feeling entirely well with this status quo
(I would expect that that content *will* get lost, and possibly rather sooner than later,
since someone is bound to eventually say "the old site copy is not needed any more").
So,
are there some ways to improve the content situation,
or will this job then eventually need to be done by
last-ditch efforts (web.archive.org etc.)?
BTW, I realized that
https://wireless.wiki.kernel.org does not seem to provide
contact information specific to Wiki maintenance aspects.
Perhaps this is because
the usual communication channels as listed e.g. on
https://wireless.wiki.kernel.org/en/users/support
are expected to be used,
but then there still is no explicit statement about Wiki-specific things
(the Best Practice solution would likely be to
add a one-liner saying e.g.
"When intending to provide input about Wiki-specific maintenance aspects,
please refer to the same general communication channels listed above.")
Ah, of course I should be checking out https://wiki.kernel.org/ -
but hmm that one does not list anything either...
Thank you,
Andreas Mohr
^ permalink raw reply
* Re: Using ath5k/ath9k radio for constant-tx noise source.
From: Zefir Kurtisi @ 2016-09-15 15:28 UTC (permalink / raw)
To: Ben Greear, linux-wireless@vger.kernel.org; +Cc: Christian Lamparter
In-Reply-To: <6d50965d-af35-dad9-23fe-162678a0f02f@candelatech.com>
Hi Ben,
On 09/15/2016 02:22 AM, Ben Greear wrote:
> On 08/20/2015 08:11 AM, Zefir Kurtisi wrote:
>> On 08/19/2015 09:07 PM, Ben Greear wrote:
>>> I have a commercial AP that is using a CM9 ath5k radio (evidently, I could be
>>> wrong)
>>> and it has the ability to do a constant transmit of raw noise (RF probe shows
>>> noise, but a monitor-port sniffer does not see any frames from the CM9).
>>>
>>> I don't know the low-level details of how it is doing this, but I suspect
>>> it is using something like madwifi for a driver.
>>>
>>> Does anyone know how this can be done with modern software and
>>> ath5k or ath9k NICs?
>>>
>>> Thanks,
>>> Ben
>>>
>>
>> Maybe slightly related: some years ago when DFS became a topic and it was hard to
>> get hands on radar pattern generators, Christian Lamparter wrote a variant of the
>> carl9170 fw [1] which can generate radar pulses to test ath9k and other DFS radar
>> detectors. Pulses are generated by enabling txout at defined sampling intervals.
>>
>> It should be doable to mimic what you are looking for by generating a _very_ long
>> pulse.
>
> Sorry to revive such an old thread..but I'm back poking at this.
>
Whew, that year went by so incredibly fast ;)
> I've used the modified carl9170 firmware to generate pulses, with
> the control being 'pulse-width' and 'pulse-interval'.
>
> This sort of works, and sometimes our ath10k in an isolation chamber reports
> a radar event.
>
> But, after some reading, I am thinking I need more control to better mimic
> a radar.
>
> If I understand things properly, I need something like this:
>
> A pulse event being: pulse width, pulse period: For instance 1us, 200us
> Then, I need to configure an amount of pulse events, maybe 10-30 consecutive pulse
> events.
> Then, I need a quiet period to mimic the radar sweeping full circle (15 seconds
> perhaps)
>
> From what I can tell, the carl9170 modified firmware is missing the features
> to do this, though it should not be too difficult to add.
>
Yes, that's essentially it - the last step is even not needed if your goal is to
estimate DFS detection probabilities, since in the certification lab they usually
just repeatedly fire the radar pattern and count detection events.
When I played with the modified carl9170 FW, I estimated that developing an solid
and reliable radar pattern pulse scheduler would take me 2-4 weeks, so being in a
hurry I ended up using an SDR (Ettus USRP N200, see [1]). I developed a pulse
scheduler to feed arbitrary patterns (covering those for DFS testing), which is
available in [2]. It has not been maintained ever since, but might help you as
starting point if you decide to go that route.
> If someone has an idea whether the control above is appropriate, I'd
> appreciate feedback before I start hacking...
>
> This document seemed useful, for instance:
>
> https://dl.cdn-anritsu.com/en-en/test-measurement/files/Product-Introductions/Product-Introduction/mx370073a-el1200.pdf
>
We use the R&S SMBV100A [3], which we know is also used in some certification
labs. Unfortunately it is not exactly cheap - if you are not going to prepare your
product for certification, the SDR approach is affordable and good enough.
>
> Thanks,
> Ben
>
Good luck,
Zefir
[1] https://www.ettus.com/product/details/UN200-KIT
[2] https://github.com/zefir-kurtisi/USRP-Radar-Relay
[3]
https://www.rohde-schwarz.com/us/product/smbv100a-productstartpage_63493-10220.html
^ permalink raw reply
* Re: Using ath5k/ath9k radio for constant-tx noise source.
From: Ben Greear @ 2016-09-15 15:59 UTC (permalink / raw)
To: Zefir Kurtisi, linux-wireless@vger.kernel.org; +Cc: Christian Lamparter
In-Reply-To: <27058308-3d36-b415-900f-3e3b65b11dab@neratec.com>
On 09/15/2016 08:28 AM, Zefir Kurtisi wrote:
> Hi Ben,
>
> On 09/15/2016 02:22 AM, Ben Greear wrote:
>> On 08/20/2015 08:11 AM, Zefir Kurtisi wrote:
>>> On 08/19/2015 09:07 PM, Ben Greear wrote:
>>>> I have a commercial AP that is using a CM9 ath5k radio (evidently, I could be
>>>> wrong)
>>>> and it has the ability to do a constant transmit of raw noise (RF probe shows
>>>> noise, but a monitor-port sniffer does not see any frames from the CM9).
>>>>
>>>> I don't know the low-level details of how it is doing this, but I suspect
>>>> it is using something like madwifi for a driver.
>>>>
>>>> Does anyone know how this can be done with modern software and
>>>> ath5k or ath9k NICs?
>>>>
>>>> Thanks,
>>>> Ben
>>>>
>>>
>>> Maybe slightly related: some years ago when DFS became a topic and it was hard to
>>> get hands on radar pattern generators, Christian Lamparter wrote a variant of the
>>> carl9170 fw [1] which can generate radar pulses to test ath9k and other DFS radar
>>> detectors. Pulses are generated by enabling txout at defined sampling intervals.
>>>
>>> It should be doable to mimic what you are looking for by generating a _very_ long
>>> pulse.
>>
>> Sorry to revive such an old thread..but I'm back poking at this.
>>
> Whew, that year went by so incredibly fast ;)
>
>> I've used the modified carl9170 firmware to generate pulses, with
>> the control being 'pulse-width' and 'pulse-interval'.
>>
>> This sort of works, and sometimes our ath10k in an isolation chamber reports
>> a radar event.
>>
>> But, after some reading, I am thinking I need more control to better mimic
>> a radar.
>>
>> If I understand things properly, I need something like this:
>>
>> A pulse event being: pulse width, pulse period: For instance 1us, 200us
>> Then, I need to configure an amount of pulse events, maybe 10-30 consecutive pulse
>> events.
>> Then, I need a quiet period to mimic the radar sweeping full circle (15 seconds
>> perhaps)
>>
>> From what I can tell, the carl9170 modified firmware is missing the features
>> to do this, though it should not be too difficult to add.
>>
> Yes, that's essentially it - the last step is even not needed if your goal is to
> estimate DFS detection probabilities, since in the certification lab they usually
> just repeatedly fire the radar pattern and count detection events.
>
> When I played with the modified carl9170 FW, I estimated that developing an solid
> and reliable radar pattern pulse scheduler would take me 2-4 weeks, so being in a
> hurry I ended up using an SDR (Ettus USRP N200, see [1]). I developed a pulse
> scheduler to feed arbitrary patterns (covering those for DFS testing), which is
> available in [2]. It has not been maintained ever since, but might help you as
> starting point if you decide to go that route.
Out of curiosity, about how much did that kit cost?
>
>> If someone has an idea whether the control above is appropriate, I'd
>> appreciate feedback before I start hacking...
>>
>> This document seemed useful, for instance:
>>
>> https://dl.cdn-anritsu.com/en-en/test-measurement/files/Product-Introductions/Product-Introduction/mx370073a-el1200.pdf
>>
> We use the R&S SMBV100A [3], which we know is also used in some certification
> labs. Unfortunately it is not exactly cheap - if you are not going to prepare your
> product for certification, the SDR approach is affordable and good enough.
Thanks for the info. We previously used the carl9170 to do some const-tx signal generation
to reproduce some interesting crashes in ath10k, and now a user wants a cheap radar emulator.
We could also use it for some basic testing in our own labs.
I'll work on allowing the specific number of pulses as well as a quiet period in
the carl9170. Hopefully just a day or two of work on top of what I already have.
Thanks much for the suggestions.
--Ben
>
>>
>> Thanks,
>> Ben
>>
>
> Good luck,
> Zefir
>
> [1] https://www.ettus.com/product/details/UN200-KIT
> [2] https://github.com/zefir-kurtisi/USRP-Radar-Relay
> [3]
> https://www.rohde-schwarz.com/us/product/smbv100a-productstartpage_63493-10220.html
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Using ath5k/ath9k radio for constant-tx noise source.
From: Ben Greear @ 2016-09-15 16:03 UTC (permalink / raw)
To: Bob Copeland
Cc: Zefir Kurtisi, linux-wireless@vger.kernel.org,
Christian Lamparter
In-Reply-To: <20160915132601.GC4475@localhost>
On 09/15/2016 06:26 AM, Bob Copeland wrote:
> On Wed, Sep 14, 2016 at 05:22:46PM -0700, Ben Greear wrote:
>> On 08/20/2015 08:11 AM, Zefir Kurtisi wrote:
>>> On 08/19/2015 09:07 PM, Ben Greear wrote:
>>>> I have a commercial AP that is using a CM9 ath5k radio (evidently, I could be wrong)
>>>> and it has the ability to do a constant transmit of raw noise (RF probe shows
>>>> noise, but a monitor-port sniffer does not see any frames from the CM9).
>>>>
>>>> I don't know the low-level details of how it is doing this, but I suspect
>>>> it is using something like madwifi for a driver.
>>>>
>>>> Does anyone know how this can be done with modern software and
>>>> ath5k or ath9k NICs?
>
> Hi Ben,
>
> I wrote some code to do this on ath5k -- I can post a patch if you're
> interested in using ath5k for this.
>
> Here's a snapshot of what it looks like when running on ch.1:
>
> https://bobcopeland.com/images/speccy-testmode.png
>
I would be interested in seeing those patches.
ath5k is probably cheaper and easier to find than carl9170 nics.
Personally, such patches for ath9k would be best, but ath5k is still interesting.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* pull-request: iwlwifi 2016-09-15
From: Luca Coelho @ 2016-09-15 16:10 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, linuxwifi
[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]
Hi Kalle,
Here is one more patch intended for 4.8. It's small and low risk, just
moving some lines of code around, to prevent a firmware crash in
certain situations.
Let me know if everything's fine (or not). :)
Luca.
The following changes since commit a904a08b5fee5317ff0f7b8212aa5d0776795a52:
iwlwifi: mvm: Advertise support for AP channel width change (2016-08-29 22:29:06 +0300)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git tags/iwlwifi-for-kalle-2016-09-15
for you to fetch changes up to 54c5ef2e93ea002dc5dd63349298b2778fe59edb:
iwlwifi: mvm: update TX queue before making a copy of the skb (2016-09-15 18:35:20 +0300)
----------------------------------------------------------------
* fix to prevent firmware crash when sending off-channel frames
----------------------------------------------------------------
Beni Lev (1):
iwlwifi: mvm: update TX queue before making a copy of the skb
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] iwlwifi: mvm: update TX queue before making a copy of the skb
From: Luca Coelho @ 2016-09-15 16:13 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless
In-Reply-To: <1473955833.5664.38.camel@coelho.fi>
From: Beni Lev <beni.lev@intel.com>
Off-channel action frames (such as ANQP frames) must be sent either on
the AUX queue or on the offchannel queue, otherwise the firmware will
cause a SYSASSERT.
In the current implementation, the queue to be used is correctly set in
the original skb, but this is done after it is copied. Thus the copy
remains with the original, incorrect queue.
Fix this by setting the queue in the original skb before copying it.
Fixes: commit 5c08b0f5026f ("iwlwifi: mvm: don't override the rate with the AMSDU len")
Cc: stable@vger.kernel.org # v4.6+
Signed-off-by: Beni Lev <beni.lev@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
index c6585ab..b3a87a3 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -513,6 +513,15 @@ int iwl_mvm_tx_skb_non_sta(struct iwl_mvm *mvm, struct sk_buff *skb)
int hdrlen = ieee80211_hdrlen(hdr->frame_control);
int queue;
+ /* IWL_MVM_OFFCHANNEL_QUEUE is used for ROC packets that can be used
+ * in 2 different types of vifs, P2P & STATION. P2P uses the offchannel
+ * queue. STATION (HS2.0) uses the auxiliary context of the FW,
+ * and hence needs to be sent on the aux queue
+ */
+ if (IEEE80211_SKB_CB(skb)->hw_queue == IWL_MVM_OFFCHANNEL_QUEUE &&
+ skb_info->control.vif->type == NL80211_IFTYPE_STATION)
+ IEEE80211_SKB_CB(skb)->hw_queue = mvm->aux_queue;
+
memcpy(&info, skb->cb, sizeof(info));
if (WARN_ON_ONCE(info.flags & IEEE80211_TX_CTL_AMPDU))
@@ -526,16 +535,6 @@ int iwl_mvm_tx_skb_non_sta(struct iwl_mvm *mvm, struct sk_buff *skb)
/* This holds the amsdu headers length */
skb_info->driver_data[0] = (void *)(uintptr_t)0;
- /*
- * IWL_MVM_OFFCHANNEL_QUEUE is used for ROC packets that can be used
- * in 2 different types of vifs, P2P & STATION. P2P uses the offchannel
- * queue. STATION (HS2.0) uses the auxiliary context of the FW,
- * and hence needs to be sent on the aux queue
- */
- if (IEEE80211_SKB_CB(skb)->hw_queue == IWL_MVM_OFFCHANNEL_QUEUE &&
- info.control.vif->type == NL80211_IFTYPE_STATION)
- IEEE80211_SKB_CB(skb)->hw_queue = mvm->aux_queue;
-
queue = info.hw_queue;
/*
--
2.9.3
^ permalink raw reply related
* [PATCH] mwifiex: fix memory leak on regd when chan is zero
From: Colin King @ 2016-09-15 16:21 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo, linux-wireless,
netdev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
When chan is zero mwifiex_create_custom_regdomain does not kfree
regd and we have a memory leak. Fix this by freeing regd before
the return.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
index 3344a26..15a91f3 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
@@ -1049,8 +1049,10 @@ mwifiex_create_custom_regdomain(struct mwifiex_private *priv,
enum nl80211_band band;
chan = *buf++;
- if (!chan)
+ if (!chan) {
+ kfree(regd);
return NULL;
+ }
chflags = *buf++;
band = (chan <= 14) ? NL80211_BAND_2GHZ : NL80211_BAND_5GHZ;
freq = ieee80211_channel_to_frequency(chan, band);
--
2.9.3
^ 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