* 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
* Re: [PATCH] mwifiex: fix null pointer deference when adapter is null
From: kbuild test robot @ 2016-09-15 16:29 UTC (permalink / raw)
To: Colin King
Cc: kbuild-all, Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20160915134238.5167-1-colin.king@canonical.com>
[-- Attachment #1: Type: text/plain, Size: 9843 bytes --]
Hi Colin,
[auto build test WARNING on wireless-drivers-next/master]
[also build test WARNING on next-20160915]
[cannot apply to v4.8-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url: https://github.com/0day-ci/linux/commits/Colin-King/mwifiex-fix-null-pointer-deference-when-adapter-is-null/20160915-231625
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git master
config: x86_64-randconfig-x013-201637 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/net/wireless/marvell/mwifiex/main.c: In function 'mwifiex_shutdown_sw':
>> drivers/net/wireless/marvell/mwifiex/main.c:1433:1: warning: label 'exit_remove' defined but not used [-Wunused-label]
exit_remove:
^~~~~~~~~~~
Cyclomatic Complexity 5 include/linux/compiler.h:__read_once_size
Cyclomatic Complexity 5 include/linux/compiler.h:__write_once_size
Cyclomatic Complexity 2 arch/x86/include/asm/bitops.h:set_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:constant_test_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls64
Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u64
Cyclomatic Complexity 1 include/linux/list.h:INIT_LIST_HEAD
Cyclomatic Complexity 1 include/linux/list.h:list_empty
Cyclomatic Complexity 1 include/asm-generic/getorder.h:__get_order
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:atomic_read
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:atomic_inc
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:atomic_dec
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:atomic_add_return
Cyclomatic Complexity 1 include/linux/spinlock.h:spinlock_check
Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock_irqrestore
Cyclomatic Complexity 1 include/linux/kasan.h:kasan_kmalloc
Cyclomatic Complexity 28 include/linux/slab.h:kmalloc_index
Cyclomatic Complexity 1 include/linux/slab.h:kmem_cache_alloc_trace
Cyclomatic Complexity 1 include/linux/slab.h:kmalloc_order_trace
Cyclomatic Complexity 68 include/linux/slab.h:kmalloc_large
Cyclomatic Complexity 5 include/linux/slab.h:kmalloc
Cyclomatic Complexity 1 include/linux/slab.h:kzalloc
Cyclomatic Complexity 1 include/linux/skbuff.h:skb_end_pointer
Cyclomatic Complexity 1 include/linux/skbuff.h:skb_queue_empty
Cyclomatic Complexity 1 include/linux/skbuff.h:skb_shared
Cyclomatic Complexity 1 include/linux/skbuff.h:skb_headroom
Cyclomatic Complexity 1 include/linux/netdevice.h:netdev_get_tx_queue
Cyclomatic Complexity 1 include/linux/netdevice.h:netdev_priv
Cyclomatic Complexity 1 include/linux/netdevice.h:netif_tx_stop_queue
Cyclomatic Complexity 1 include/linux/netdevice.h:netif_tx_queue_stopped
Cyclomatic Complexity 1 include/linux/netdevice.h:netif_carrier_ok
Cyclomatic Complexity 1 include/linux/etherdevice.h:is_multicast_ether_addr
Cyclomatic Complexity 1 include/linux/etherdevice.h:ether_addr_copy
Cyclomatic Complexity 1 include/linux/etherdevice.h:ether_addr_equal
Cyclomatic Complexity 1 include/linux/etherdevice.h:ether_addr_equal_unaligned
Cyclomatic Complexity 1 drivers/net/wireless/marvell/mwifiex/util.h:MWIFIEX_SKB_TXCB
Cyclomatic Complexity 6 drivers/net/wireless/marvell/mwifiex/main.h:mwifiex_get_priv
Cyclomatic Complexity 1 drivers/net/wireless/marvell/mwifiex/main.h:mwifiex_netdev_get_priv
Cyclomatic Complexity 1 drivers/net/wireless/marvell/mwifiex/main.h:mwifiex_is_skb_mgmt_frame
Cyclomatic Complexity 1 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_get_stats
Cyclomatic Complexity 1 include/linux/workqueue.h:queue_work
Cyclomatic Complexity 2 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_queue_rx_work
Cyclomatic Complexity 4 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_set_multicast_list
Cyclomatic Complexity 1 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_netdev_select_wmm_queue
Cyclomatic Complexity 1 include/linux/err.h:IS_ERR
Cyclomatic Complexity 1 include/linux/timekeeping.h:ktime_get_real
Cyclomatic Complexity 1 include/linux/skbuff.h:__net_timestamp
Cyclomatic Complexity 1 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_open
Cyclomatic Complexity 2 drivers/net/wireless/marvell/mwifiex/util.h:MWIFIEX_SKB_RXCB
Cyclomatic Complexity 1 include/linux/netdevice.h:dev_kfree_skb_any
Cyclomatic Complexity 6 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_unregister
Cyclomatic Complexity 2 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_free_adapter
Cyclomatic Complexity 3 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_terminate_workqueue
Cyclomatic Complexity 1 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_init_module
Cyclomatic Complexity 1 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_cleanup_module
Cyclomatic Complexity 2 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_queue_main_work
Cyclomatic Complexity 9 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_process_rx
Cyclomatic Complexity 2 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_rx_work_queue
Cyclomatic Complexity 5 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_clone_skb_for_tx_status
Cyclomatic Complexity 2 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_init_priv_params
Cyclomatic Complexity 1 drivers/net/wireless/marvell/mwifiex/main.c:is_command_pending
Cyclomatic Complexity 81 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_main_process
Cyclomatic Complexity 2 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_main_work_queue
Cyclomatic Complexity 3 drivers/net/wireless/marvell/mwifiex/main.c:_mwifiex_dbg
Cyclomatic Complexity 6 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_bypass_tx_queue
Cyclomatic Complexity 4 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_queue_tx_pkt
Cyclomatic Complexity 4 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_multi_chan_resync
Cyclomatic Complexity 19 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_drv_info_dump
Cyclomatic Complexity 9 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_upload_device_dump
Cyclomatic Complexity 3 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_tx_timeout
Cyclomatic Complexity 2 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_set_mac_address
Cyclomatic Complexity 16 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_hard_start_xmit
Cyclomatic Complexity 3 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_close
Cyclomatic Complexity 34 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_fw_dpc
Cyclomatic Complexity 6 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_init_hw_fw
Cyclomatic Complexity 14 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_reinit_sw
Cyclomatic Complexity 20 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_shutdown_sw
Cyclomatic Complexity 2 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_do_flr
Cyclomatic Complexity 7 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_register
Cyclomatic Complexity 15 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_add_card
Cyclomatic Complexity 20 drivers/net/wireless/marvell/mwifiex/main.c:mwifiex_remove_card
vim +/exit_remove +1433 drivers/net/wireless/marvell/mwifiex/main.c
4c5dae59 Amitkumar Karwar 2016-07-26 1417 atomic_read(&adapter->rx_pending),
4c5dae59 Amitkumar Karwar 2016-07-26 1418 atomic_read(&adapter->tx_pending),
4c5dae59 Amitkumar Karwar 2016-07-26 1419 atomic_read(&adapter->cmd_pending));
4c5dae59 Amitkumar Karwar 2016-07-26 1420 }
4c5dae59 Amitkumar Karwar 2016-07-26 1421
4c5dae59 Amitkumar Karwar 2016-07-26 1422 for (i = 0; i < adapter->priv_num; i++) {
4c5dae59 Amitkumar Karwar 2016-07-26 1423 priv = adapter->priv[i];
4c5dae59 Amitkumar Karwar 2016-07-26 1424 if (!priv)
4c5dae59 Amitkumar Karwar 2016-07-26 1425 continue;
4c5dae59 Amitkumar Karwar 2016-07-26 1426 rtnl_lock();
4c5dae59 Amitkumar Karwar 2016-07-26 1427 if (priv->netdev &&
4c5dae59 Amitkumar Karwar 2016-07-26 1428 priv->wdev.iftype != NL80211_IFTYPE_UNSPECIFIED)
4c5dae59 Amitkumar Karwar 2016-07-26 1429 mwifiex_del_virtual_intf(adapter->wiphy, &priv->wdev);
4c5dae59 Amitkumar Karwar 2016-07-26 1430 rtnl_unlock();
4c5dae59 Amitkumar Karwar 2016-07-26 1431 }
4c5dae59 Amitkumar Karwar 2016-07-26 1432
4c5dae59 Amitkumar Karwar 2016-07-26 @1433 exit_remove:
4c5dae59 Amitkumar Karwar 2016-07-26 1434 up(sem);
4c5dae59 Amitkumar Karwar 2016-07-26 1435 exit_sem_err:
4c5dae59 Amitkumar Karwar 2016-07-26 1436 mwifiex_dbg(adapter, INFO, "%s, successful\n", __func__);
2d1cb5d4 Colin Ian King 2016-09-15 1437 exit_return:
4c5dae59 Amitkumar Karwar 2016-07-26 1438 return 0;
4c5dae59 Amitkumar Karwar 2016-07-26 1439 }
4c5dae59 Amitkumar Karwar 2016-07-26 1440
4c5dae59 Amitkumar Karwar 2016-07-26 1441 /* This function gets called during PCIe function level reset. Required
:::::: The code at line 1433 was first introduced by commit
:::::: 4c5dae59d2e9386c706a2f3c7c2746ae277bf568 mwifiex: add PCIe function level reset support
:::::: TO: Amitkumar Karwar <akarwar@marvell.com>
:::::: CC: Kalle Valo <kvalo@codeaurora.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 29215 bytes --]
^ permalink raw reply
* Re: [PATCH] mwifiex: fix memory leak on regd when chan is zero
From: Kalle Valo @ 2016-09-15 17:10 UTC (permalink / raw)
To: Colin King
Cc: Amitkumar Karwar, Nishant Sarmukadam, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20160915162117.1209-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> writes:
> 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;
> + }
Bob sent a similar fix and he also did more:
mwifiex: fix error handling in mwifiex_create_custom_regdomain
https://patchwork.kernel.org/patch/9331337/
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] mwifiex: fix memory leak on regd when chan is zero
From: Colin Ian King @ 2016-09-15 17:26 UTC (permalink / raw)
To: Kalle Valo
Cc: Amitkumar Karwar, Nishant Sarmukadam, linux-wireless, netdev,
linux-kernel
In-Reply-To: <87vaxx9jhk.fsf@kamboji.qca.qualcomm.com>
On 15/09/16 18:10, Kalle Valo wrote:
> Colin King <colin.king@canonical.com> writes:
>
>> 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;
>> + }
>
> Bob sent a similar fix and he also did more:
>
> mwifiex: fix error handling in mwifiex_create_custom_regdomain
>
> https://patchwork.kernel.org/patch/9331337/
>
Ah, sorry for the duplication noise.
Colin
^ permalink raw reply
* Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
From: Grumbach, Emmanuel @ 2016-09-15 17:34 UTC (permalink / raw)
To: greearb@candelatech.com, kvalo@qca.qualcomm.com
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <a26dfea0-9a18-69fc-e23c-cb223490822d@candelatech.com>
T24gVGh1LCAyMDE2LTA5LTE1IGF0IDA4OjE0IC0wNzAwLCBCZW4gR3JlZWFyIHdyb3RlOg0KPiBP
biAwOS8xNS8yMDE2IDA3OjA2IEFNLCBWYWxvLCBLYWxsZSB3cm90ZToNCj4gPiBCZW4gR3JlZWFy
IDxncmVlYXJiQGNhbmRlbGF0ZWNoLmNvbT4gd3JpdGVzOg0KPiA+IA0KPiA+ID4gT24gMDkvMTQv
MjAxNiAwNzoxOCBBTSwgVmFsbywgS2FsbGUgd3JvdGU6DQo+ID4gPiA+IGdyZWVhcmJAY2FuZGVs
YXRlY2guY29tIHdyaXRlczoNCj4gPiA+ID4gDQo+ID4gPiA+ID4gRnJvbTogQmVuIEdyZWVhciA8
Z3JlZWFyYkBjYW5kZWxhdGVjaC5jb20+DQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gVGhpcyBhbGxv
d3MgdXNlci1zcGFjZSB0b29scyB0byBkZWNvZGUgZGVidWctbG9nDQo+ID4gPiA+ID4gbWVzc2Fn
ZXMgYnkgcGFyc2luZyBkbWVzZyBvciAvdmFyL2xvZy9tZXNzYWdlcy4NCj4gPiA+ID4gPiANCj4g
PiA+ID4gPiBTaWduZWQtb2ZmLWJ5OiBCZW4gR3JlZWFyIDxncmVlYXJiQGNhbmRlbGF0ZWNoLmNv
bT4NCj4gPiA+ID4gDQo+ID4gPiA+IERvbid0IHRyYWNpbmcgcG9pbnRzIGFscmVhZHkgcHJvdmlk
ZSB0aGUgc2FtZSBpbmZvcm1hdGlvbj8NCj4gPiA+IA0KPiA+ID4gVHJhY2luZyB0b29scyBhcmUg
ZGlmZmljdWx0IHRvIHNldCB1cCBhbmQgbWF5IG5vdCBiZSBhdmFpbGFibGUgb24NCj4gPiA+IHJh
bmRvbSBlbWJlZGRlZCBkZXZpY2VzLiAgQW5kIGlmIHdlIGFyZSBkZWFsaW5nIHdpdGggYnVnIHJl
cG9ydHMNCj4gPiA+IGZyb20NCj4gPiA+IHRoZSBmaWVsZCwgbW9zdCB1c2VycyB3aWxsIG5vdCBi
ZSBhYmxlIHRvIHNldCBpdCB1cCByZWdhcmRsZXNzLg0KPiA+ID4gDQo+ID4gPiBUaGVyZSBhcmUg
c2ltaWxhciB3YXlzIHRvIHByaW50IG91dCBoZXgsIGJ1dCB0aGUgbG9naWMgYmVsb3cNCj4gPiA+
IGNyZWF0ZXMNCj4gPiA+IHNwZWNpZmljIGFuZCBwYXJzZWFibGUgbG9ncyBpbiB0aGUgJ2RtZXNn
JyBvdXRwdXQgYW5kIHNpbWlsYXIuDQo+ID4gPiANCj4gPiA+IEkgaGF2ZSB3cml0dGVuIGEgdG9v
bCB0aGF0IGNhbiBkZWNvZGUgdGhlc2UgbWVzc2FnZXMgaW50byB1c2VmdWwNCj4gPiA+IGh1bWFu
LXJlYWRhYmxlDQo+ID4gPiB0ZXh0IHNvIHRoYXQgSSBjYW4gZGVidWcgZmlybXdhcmUgaXNzdWVz
IGJvdGggbG9jYWxseSBhbmQgZnJvbQ0KPiA+ID4gZmllbGQgcmVwb3J0cy4NCj4gPiA+IA0KPiA+
ID4gU3RvY2sgZmlybXdhcmUgZ2VuZXJhdGVzIHNpbWlsYXIgbG9ncyBhbmQgUUNBIGNvdWxkIHdy
aXRlIHRoZWlyDQo+ID4gPiBvd24gZGVjb2RlIGxvZ2ljDQo+ID4gPiBmb3IgdGhlaXIgZmlybXdh
cmUgdmVyc2lvbnMuDQo+ID4gDQo+ID4gUmVpbnZlbnRpbmcgdGhlIHdoZWVsIGJ5IHVzaW5nIHBy
aW50ayBhcyB0aGUgZGVsaXZlcnkgbWVjaGFuaXNtDQo+ID4gZG9lc24ndA0KPiA+IHNvdW5kIGxp
a2UgYSBnb29kIGlkZWEuIElJUkMgRW1tYW51ZWwgdGFsa2VkIGFib3V0IHNvbWUga2luZCBvZg0K
PiA+IGZpcm13YXJlDQo+ID4gZGVidWdnaW5nIGZyYW1ld29yaywgaGUgbWlnaHQgaGF2ZSBzb21l
IGlkZWFzLg0KPiANCj4gV2FpdGluZyBmb3IgbWFnaWNhbCBmcmFtZXdvcmtzIHRvIGZpeCBwcm9i
bGVtcyBpcyBldmVuIHdvcnNlLg0KPiANCkl0IGhhcyBiZWVuIHllYXJzIHNpbmNlIGF0aDEwayBo
YXMgYmVlbiBpbiB0aGUga2VybmVsLiAgVGhlcmUgaXMNCj4gYmFzaWNhbGx5DQo+IHN0aWxsIG5v
IHdheSB0byBkZWJ1ZyB3aGF0IHRoZSBmaXJtd2FyZSBpcyBkb2luZy4NCj4gDQoNCkkga25vdyB0
aGUgZmVlbGluZyA6KSBJIHdhcyBpbiB0aGUgc2FtZSBzaXR1YXRpb24gYmVmb3JlIEkgYWRkZWQg
c3R1ZmYNCmZvciBpd2x3aWZpLg0KDQo+IE15IHBhdGNoIGdpdmVzIHlvdSBzb21ldGhpbmcgdGhh
dCBjYW4gd29yayByaWdodCBub3csIHdpdGggdGhlDQo+IHN0YW5kYXJkICdkbWVzZycNCj4gZnJh
bWV3b3JrIGZvdW5kIGluIHZpcnR1YWxseSBhbGwga2VybmVscyBuZXcgYW5kIG9sZCwgYW5kIGl0
IGhhcyBiZWVuDQo+IHByb3Zlbg0KPiB0byBiZSB1c2VmdWwgaW4gdGhlIGZpZWxkLiAgVGhlIG1l
c3NhZ2VzIGFyZSBhbHNvIG5pY2VseSBpbnRlcmxlYXZlZA0KPiB3aXRoIHRoZQ0KPiByZXN0IG9m
IHRoZSBtYWM4MDIxMSBzdGFjayBtZXNzYWdlcyBhbmQgYW55IG90aGVyIGRyaXZlciBtZXNzYWdl
cywgc28NCj4geW91IGhhdmUNCj4gY29udGV4dC4NCj4gDQo+IElmIHNvbWVvbmUgd2FudHMgdG8g
YWRkIHN1cHBvcnQgZm9yIGEgZnJhbWV3b3JrIGxhdGVyLCB0aGVuIGJ5IGFsbA0KPiBtZWFucywg
cG9zdA0KPiB0aGUgcGF0Y2hlcyB3aGVuIGl0IGlzIHJlYWR5Lg0KDQpGcm9tIG15IGV4cGVyaWVu
Y2UsIGEgc3Ryb25nIGFuZCBlYXN5LXRvLXVzZSBmaXJtd2FyZSBkZWJ1Zw0KaW5mcmFzdHJ1Y3R1
cmUgaXMgaW1wb3J0YW50IGJlY2F1c2UgdHlwaWNhbGx5LCB0aGUgZmlybXdhcmUgaXMgd3JpdHRl
bg0KYnkgb3RoZXIgcGVvcGxlIHdobyBoYXZlIGRpZmZlcmVudCBwcmlvcml0aWVzIChhbmQgYXJl
IG5vdCBhbHdheXMgTGludXgNCndpemFyZHMpIGV0Yy4uLiBCZWluZyBhYmxlIHRvIGdpdmUgdGhl
bSBnb29kIGRhdGEgaXMgdGhlIG9ubHkgd2F5IHRvDQpoYXZlIHRoZW0gZml4IHRoZWlyIGJ1Z3Mg
OikgRm9yIHVzLCBpdCB3YXMgcmVhbGx5IGEgZ2FtZSBjaGFuZ2VyLiBXaGVuDQp5b3Ugd29yayBm
b3IgYSBiaWcgY29ycG9yYXRlLCBoYXZpbmcgMiBncm91cHMgd29yayBiZXR0ZXIgdG9nZXRoZXIN
CmFsd2F5cyBoYXMgYSBiaWcgaW1wYWN0LiBUaGF0J3MgZm9yIHRoZSBwaGlsb3NvcGhpY2FsIHBh
cnQgOikNCg0KRldJVzogd2hhdCBJIGRpZCBoYXMgbm90aGluZyB0byBkbyB3aXRoIEZXICdsaXZl
IHRyYWNpbmcnLCBidXQgd2l0aA0KZmlybXdhcmUgZHVtcHMuIE9uZSBwYXJ0IG9mIG91ciBmaXJt
d2FyZSBkdW1wcyBpbmNsdWRlIHRyYWNpbmcuIFdlIGFsc28NCmhhdmUgImZpcm13YXJlIHByaW50
cyIsIGJ1dCB3ZSBkb24ndCBwcmludCB0aGVtIGluIHRoZSBrZXJuZWwgbG9nIGFuZA0KdGhleSBh
cmUgbm90IHBhcnQgb2YgdGhlIGZpcm13YXJlIGR1bXAgdGhpbmcuIFdlIHJhdGhlciByZWNvcmQg
dGhlbSBpbg0KdHJhY2Vwb2ludHMganVzdCBsaWtlIHJlYWxseSAqYW55dGhpbmcqIHRoYXQgY29t
ZXMgZnJvbSB0aGUgZmlybXdhcmUuDQpCYXNpY2FsbHksIHdlIGhhdmUgMiBsYXllcnMsIHRoZSB0
cmFuc3BvcnQgbGF5ZXIgKFBDSWUpIGFuZCB0aGUNCm9wZXJhdGlvbl9tb2RlIGxheWVyLiBUaGUg
Zmlyc3QganVzdCBicmluZ3MgdGhlIGRhdGEgZnJvbSB0aGUgZmlybXdhcmUNCmFuZCBpbiB0aGF0
IGxheWVyIHdlICpibGluZGx5KiByZWNvcmQgZXZlcnl0aGluZyBpbiB0cmFjZXBvaW50cy4gSW4g
dGhlDQpvcGVyYXRpb25fbW9kZSBsYXllciwgd2UgbG9vayBhdCB0aGUgZGF0YSBpdHNlbGYuIElu
IGNhc2Ugb2YgZGVidWcNCnByaW50cyBmcm9tIHRoZSBmaXJtd2FyZSwgd2Ugc2ltcGx5IGRpc2Nh
cmQgdGhlbSwgYmVjYXVzZSB3ZSBkb24ndA0KcmVhbGx5IGNhcmUgb2YgdGhlIG1lYW5pbmcuIEFs
bCB3ZSB3YW50IGlzIHRvIGhhdmUgdGhlbSBnbyB0aHJvdWdoIHRoZQ0KUENJZSBsYXllciBzbyB0
aGF0IHRoZXkgYXJlIHJlY29yZGVkIGluIHRoZSB0cmFjZXBvaW50cy4NCldoZW4gd2UgZmluaXNo
IHJlY29yZGluZyB0aGUgc2VxdWVuY2Ugd2Ugd2FudGVkIHdpdGggdHJhY2luZyAodHJhY2UNCi1j
bWQpLCB3ZSBwYXJzZSB0aGUgb3V0cHV0IGFuZCB0aGVuLCB3ZSBwYXJzZSB0aGUgZmlybXdhcmUg
cHJpbnRzLg0KSU1ITywgdGhpcyBpcyBtb3JlIHJlbGlhYmxlIHRoYW4ga2VybmVsIGxvZ3MgYW5k
IHlvdSBkb24ndCBsb3NlIHRoZQ0KYWxpZ25tZW50IHdpdGggdGhlIGRyaXZlciB0cmFjZXMgYXMg
bG9uZyBhcyB5b3UgaGF2ZSBkcml2ZXIgZGF0YSBpbg0KdHJhY2Vwb2ludHMgYXMgd2VsbC4NCg0K
PiANCj4gVGhhbmtzLA0KPiBCZW4NCj4gDQo+IA==
^ permalink raw reply
* Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
From: Ben Greear @ 2016-09-15 17:59 UTC (permalink / raw)
To: Grumbach, Emmanuel, kvalo@qca.qualcomm.com
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <1473960869.31073.15.camel@intel.com>
On 09/15/2016 10:34 AM, Grumbach, Emmanuel wrote:
> On Thu, 2016-09-15 at 08:14 -0700, Ben Greear wrote:
>> 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.
>>
>
> I know the feeling :) I was in the same situation before I added stuff
> for iwlwifi.
>
>> 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.
>
> From my experience, a strong and easy-to-use firmware debug
> infrastructure is important because typically, the firmware is written
> by other people who have different priorities (and are not always Linux
> wizards) etc... Being able to give them good data is the only way to
> have them fix their bugs :) For us, it was really a game changer. When
> you work for a big corporate, having 2 groups work better together
> always has a big impact. That's for the philosophical part :)
>
> FWIW: what I did has nothing to do with FW 'live tracing', but with
> firmware dumps. One part of our firmware dumps include tracing. We also
> have "firmware prints", but we don't print them in the kernel log and
> they are not part of the firmware dump thing. We rather record them in
> tracepoints just like really *anything* that comes from the firmware.
> Basically, we have 2 layers, the transport layer (PCIe) and the
> operation_mode layer. The first just brings the data from the firmware
> and in that layer we *blindly* record everything in tracepoints. In the
> operation_mode layer, we look at the data itself. In case of debug
> prints from the firmware, we simply discard them, because we don't
> really care of the meaning. All we want is to have them go through the
> PCIe layer so that they are recorded in the tracepoints.
> When we finish recording the sequence we wanted with tracing (trace
> -cmd), we parse the output and then, we parse the firmware prints.
> IMHO, this is more reliable than kernel logs and you don't lose the
> alignment with the driver traces as long as you have driver data in
> tracepoints as well.
I have other patches that remember the last 100 or so firmware log messages from
the kernel and provide that in a binary dump image when firmware crashes.
This is indeed very useful.
But, when debugging non-crash occasions, it is still useful to see what
the firmware is doing.
For instance, maybe it is reporting lots of tx-hangs and/or low-level
resets. This gives you a clue as to why a user might report 'my wifi sucks'.
Since I am both FW and driver team for my firmware variant,
and my approach has been working for me, then I feel it is certainly better than
the current state. And just maybe the official upstream FW team could start
using something similar as well. Currently, I don't see how they can ever make
much progress on firmware crashes reported in stock kernels.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* pull-request: iwlwifi-next 2016-09-15
From: Luca Coelho @ 2016-09-15 18:00 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, linuxwifi
[-- Attachment #1: Type: text/plain, Size: 4999 bytes --]
Hi Kalle,
One more pull request intended for 4.9. There are changes all over,
mostly new hardware support, DQA, multiqueue MSIx work, and a bunch of
cleanups and improvements. More details in the tag description.
Let me know if everything's fine (or not). :)
Luca.
The following changes since commit 76f8c0e17edc6eba43f84952e5a87c7f50f69370:
iwlwifi: pcie: remove dead code (2016-08-30 14:16:43 +0300)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2016-09-15
for you to fetch changes up to ace403cf409d68c61ae75e71fd8a681263d73e20:
iwlwifi: mvm: tighten BAID range check (2016-09-15 20:43:47 +0300)
----------------------------------------------------------------
* work for new hardware support continues
* dynamic queue allocation stabilization
* improvements in the MSIx code
* multiqueue support work continues
* new firmware version support
* general cleanups and improvements
----------------------------------------------------------------
Emmanuel Grumbach (1):
iwlwifi: mvm: bump max API to 26
Haim Dreyfuss (3):
iwlwifi: pcie: Configure shared interrupt vector in MSIX mode
iwlwifi: pcie: Set affinity mask for rx interrupt vectors per cpu
iwlwifi: pcie: replace possible_cpus() with online_cpus() in MSIX mode
Johannes Berg (3):
iwlwifi: mvm: make RSS RX more robust
iwlwifi: mvm: remove pointless _bh from spinlock in timer
iwlwifi: mvm: tighten BAID range check
Liad Kaufman (3):
iwlwifi: mvm: don't free queue after delba in dqa
iwlwifi: mvm: fix pending frames tracking on tx resp
iwlwifi: mvm: free reserved queue on STA removal
Oren Givon (2):
iwlwifi: add the new 9560 series
iwlwifi: add the new 8275 series
Sara Sharon (10):
iwlwifi: mvm: call a different txq_enable function
iwlwifi: pcie: introduce new tfd and tb formats
iwlwifi: mvm: remove dump of locked registers
iwlwifi: mvm: support new shared memory config API
iwlwifi: introduce trans API to get byte count table
iwlwifi: pcie: assign and access a000 TFD & TBs
iwlwifi: change byte count table for a000 devices
iwlwifi: pcie: merge iwl_queue and iwl_txq
iwlwifi: mvm: support new BA notification response
iwlwifi: pcie: change indentation of iwl_pcie_set_interrupt_capa()
Sharon Dvir (1):
iwlwifi: unify iwl_get_ucode_image() implementations
Wei Yongjun (1):
iwlwifi: mvm: use setup_timer instead of init_timer and data fields
kbuild test robot (1):
iwlwifi: fix semicolon.cocci warnings
drivers/net/wireless/intel/iwlwifi/dvm/ucode.c | 11 +--
drivers/net/wireless/intel/iwlwifi/iwl-7000.c | 4 +-
drivers/net/wireless/intel/iwlwifi/iwl-8000.c | 15 ++-
drivers/net/wireless/intel/iwlwifi/iwl-9000.c | 13 ++-
drivers/net/wireless/intel/iwlwifi/iwl-a000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 2 +
drivers/net/wireless/intel/iwlwifi/iwl-csr.h | 2 +
drivers/net/wireless/intel/iwlwifi/iwl-fh.h | 57 +++++++++---
drivers/net/wireless/intel/iwlwifi/iwl-fw.h | 9 ++
drivers/net/wireless/intel/iwlwifi/iwl-io.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-trans.c | 1 +
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 14 ++-
drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h | 79 ++++++++++++++++
drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h | 22 ++++-
drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c | 4 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 109 ++++++++++++----------
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 9 +-
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 2 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 8 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 36 ++++++--
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 175 +++++++++++++++++++++++------------
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 5 +
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 127 +++++++++++++++----------
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 16 +++-
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 247 +++++++++++++++++++++++++++++++++----------------
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 384 +++++++++++++++++++++++++++++++++++++++++++++-------------------------------
26 files changed, 896 insertions(+), 459 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 09/21] ath10k: print fw debug messages in hex.
From: Ben Greear @ 2016-09-15 18:08 UTC (permalink / raw)
To: Grumbach, Emmanuel, kvalo@qca.qualcomm.com
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <50a08de4-1959-3dc9-cfc7-89d5b2914cc5@candelatech.com>
On 09/15/2016 10:59 AM, Ben Greear wrote:
> On 09/15/2016 10:34 AM, Grumbach, Emmanuel wrote:
> I have other patches that remember the last 100 or so firmware log messages from
> the kernel and provide that in a binary dump image when firmware crashes.
>
> This is indeed very useful.
>
> But, when debugging non-crash occasions, it is still useful to see what
> the firmware is doing.
>
> For instance, maybe it is reporting lots of tx-hangs and/or low-level
> resets. This gives you a clue as to why a user might report 'my wifi sucks'.
>
> Since I am both FW and driver team for my firmware variant,
> and my approach has been working for me, then I feel it is certainly better than
> the current state. And just maybe the official upstream FW team could start
> using something similar as well. Currently, I don't see how they can ever make
> much progress on firmware crashes reported in stock kernels.
I forgot the other good reason about console logging this:
Sometimes ath10k firmware crash causes the entire kernel to crash, so there is no time to
grab the binary dump from a file system...but a serial console can help you
make progress...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH 02/25] iwlwifi: mvm: don't free queue after delba in dqa
From: Luca Coelho @ 2016-09-15 18:11 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Liad Kaufman, Luca Coelho
In-Reply-To: <1473962425.5664.41.camel@coelho.fi>
From: Liad Kaufman <liad.kaufman@intel.com>
In DQA mode, a delBA might free the queue although it
shouldn't. Fix that.
Fixes: cf941e174ee2 ("iwlwifi: mvm: support dqa-mode agg on non-shared queue")
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
index 8b91544..6271470 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
@@ -1100,9 +1100,13 @@ static void iwl_mvm_check_ratid_empty(struct iwl_mvm *mvm,
IWL_DEBUG_TX_QUEUES(mvm,
"Can continue DELBA flow ssn = next_recl = %d\n",
tid_data->next_reclaimed);
- iwl_mvm_disable_txq(mvm, tid_data->txq_id,
- vif->hw_queue[tid_to_mac80211_ac[tid]], tid,
- CMD_ASYNC);
+ if (!iwl_mvm_is_dqa_supported(mvm)) {
+ u8 mac80211_ac = tid_to_mac80211_ac[tid];
+
+ iwl_mvm_disable_txq(mvm, tid_data->txq_id,
+ vif->hw_queue[mac80211_ac], tid,
+ CMD_ASYNC);
+ }
tid_data->state = IWL_AGG_OFF;
ieee80211_stop_tx_ba_cb_irqsafe(vif, sta->addr, tid);
break;
--
2.9.3
^ permalink raw reply related
* [PATCH 01/25] iwlwifi: mvm: call a different txq_enable function
From: Luca Coelho @ 2016-09-15 18:11 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Sara Sharon, Luca Coelho
In-Reply-To: <1473962425.5664.41.camel@coelho.fi>
From: Sara Sharon <sara.sharon@intel.com>
Since the SCD_QUEUE_CFG command was introduced the driver
calls iwl_trans_txq_enable_cfg() with a NULL for scd_cfg
parameter.
This makes the transport avoid writing to the SCD pointers,
since it can cause races with firmware, which is also accessing
the registers.
The transport only updates the write pointer in that case.
Fix a wrong call to iwl_trans_txq_enable() which caused a
scd_cfg parameter to be sent to transport, resulting with an
access to SCD registers.
Fixes: 58f2cc57dc6a ("iwlwifi: mvm: support dqa-mode scd queue redirection")
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
index 30fc3af..a92e12e 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -588,9 +588,7 @@ int iwl_mvm_scd_queue_redirect(struct iwl_mvm *mvm, int queue, int tid,
ret);
/* Make sure the SCD wrptr is correctly set before reconfiguring */
- iwl_trans_txq_enable(mvm->trans, queue, iwl_mvm_ac_to_tx_fifo[ac],
- cmd.sta_id, tid, LINK_QUAL_AGG_FRAME_LIMIT_DEF,
- ssn, wdg_timeout);
+ iwl_trans_txq_enable_cfg(mvm->trans, queue, ssn, NULL, wdg_timeout);
/* Update the TID "owner" of the queue */
spin_lock_bh(&mvm->queue_info_lock);
--
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