Lorenzo Bianconi [Sat, 27 Oct 2018 19:06:25 +0000 (21:06 +0200)]
mt76x0: phy: use mt76_poll_msec in mt76x0_phy_temp_sensor
Use mt76_poll_msec utility routine for CORE_R34 register polling
instead of mt76_poll in order to allow the hw to complete requested
calibration since on slow devices (e.g. mt7620 based boards) calibration
takes longer than 2ms
Fixes: 66a34c66e0cb ("mt76x0: phy: add phy/vco temperature compensation") Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
mt76x0: do not overwrite other MT_BBP(AGC, 8) fields
MT_BBP(AGC, 8) register has values depend on band in
mt76x0_bbp_switch_tab, so we should not overwrite other fields
than MT_BBP_AGC_GAIN when setting gain.
This can fix performance issues when connecting to 2.4GHz AP.
Fixes: 4636a2544c3b ("mt76x0: phy: align channel gain logic to mt76x2 one") Acked-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Felix Fietkau [Thu, 25 Oct 2018 14:11:34 +0000 (16:11 +0200)]
mt76: add support for reporting tx status with skb
MT76x2/MT76x0 has somewhat unreliable tx status reporting, and for that
reason the driver currently does not report per-skb tx ack status at all.
This breaks things like client idle polling, which relies on the tx ack
status of a transmitted nullfunc frame.
This patch adds code to report skb-attached tx status if requested by
mac80211 or the rate control module. Since tx status is polled from a
simple FIFO register, the code needs to account for the possibility of
tx status events getting lost.
The code keeps a list of skbs for which tx status is required and passes
them to mac80211 once tx status has been filled in and the DMA queue is
done with it.
If a tx status event is not received after one second, the status rates
are cleared, and a succesful ACK is indicated to avoid spurious disassoc
during assoc or client polling.
Felix Fietkau [Thu, 25 Oct 2018 15:40:06 +0000 (17:40 +0200)]
mt76: mt76x02: only override control->sta on sw-encrypted tx
control->sta is set to NULL early when encryption is turned on for the
station and info->control.hw_key is not set.
This code is missing a check for the 802.11 header protected flag, otherwise
it resets the station for other frames, e.g. client probing frames.
Lorenzo Bianconi [Sat, 20 Oct 2018 10:40:54 +0000 (12:40 +0200)]
mt76: move tx protection routines in mt76x02-lib module
Move mt76x02_set_rts_threshold and mt76x02_mac_set_tx_protection
routines in mt76x02-lib module and remove duplicated code in mt76x0
and mt76x2 drivers. Remove pci_mac.c and mt76x0/mac.c since now are
empty files
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Sat, 20 Oct 2018 10:40:52 +0000 (12:40 +0200)]
mt76: move mt76x02_set_tx_ackto in mt76x02-lib module
Move mt76x02_set_tx_ackto and mt76x02_set_coverage_class routines
in mt76x02-lib module in order to be reused by mt76x0 driver.
This is a preliminary patch to unify drv_bss_info_changed mac80211
callback between mt76x0 and mt76x2 drivers
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Sat, 20 Oct 2018 10:13:32 +0000 (12:13 +0200)]
mt76x0: pci: enable AP support
Add missing mac80211 callbacks to mt76x0e_ops data structure
and add mt76x02_beacon utility routines in mt76x0_bss_info_changed
in order to enable/disable beacon transmission
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Add mt76x02_init_beacon_config utility routine in mt76x02-lib
module in order to be reused by mt76x0 driver configuring
BSSID registers and remove duplicated code
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Sat, 20 Oct 2018 10:13:28 +0000 (12:13 +0200)]
mt76: move mt76x02_sw_scan and mt76x02_sw_scan_complete in mt76x02-lib module
Move mt76x02_sw_scan and mt76x02_sw_scan_complete utility routines
in mt76x02_util.c in order to be reused by mt76x0 and mt76x2u drivers
and remove duplicated code
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Sat, 20 Oct 2018 10:13:24 +0000 (12:13 +0200)]
mt76: move mt76x02_init_device in mt76x02-lib module
Move mt76x02_init_device routine in mt76x02_util.c in order to be
reused by mt76x0 driver and remove duplicated code. Move interface
combo definition supported by the driver in mt76x02_init_device routine
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Update mt76x0_phy_ant_select() to conform vendor driver, most notably
add dual antenna mode support, read configuration from EEPROM and
move ant select out of channel config to init phase. Plus small MT7630E
quirk for MT_CMB_CTRL register which vendor driver dedicated to this
chip do.
This make MT7630E workable with mt76x0e driver and do not cause any
problems on MT7610U for me.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Wed, 17 Oct 2018 22:35:32 +0000 (00:35 +0200)]
mt76: usb: fix static tracepoints
Add submit_urb and rx_urb static tracepoints in mt76-usb module.
Move trace_mac_txstat_fetch in mt76x02_mac_load_tx_status routine
in order to be available to usb drivers. Moreover remove
no longer used mt76x0/trace.{c,h}
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Felix Fietkau [Thu, 18 Oct 2018 14:09:07 +0000 (16:09 +0200)]
mt76: mt76x0: handle chip specific initval differences
Some RF registers need different values for various chips.
For at least mt76x0_rf_central_tab registers, overwriting them later does
not work, as the wrong values can cause the entire system to hang on some
devices with MT7610E
Driver works better for MT7630 without MCU calibration, which
looks like it can hangs the firmware. Vendor driver do not
perform it for MT7630 as well.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Mon, 15 Oct 2018 09:33:15 +0000 (11:33 +0200)]
mt76x0: use mt76x02_mac_work as stats handler
Use mt76x02_mac_work utility routine as stats workqueue handler
and remove duplicated code. Moreover run mac stuck check in
mt76x02_mac_work for client interfaces.
Remove no longer used avg_ampdu_len and mt76x02_mac_stats data
structure in mt76x02_dev
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Sun, 14 Oct 2018 16:55:19 +0000 (18:55 +0200)]
mt76x0: phy: simplify rf configuration routines
Simplify mt76x0_phy_vco_cal and mt76x0_phy_set_chan_rf_params
routines using mt76x0_rf_wr, mt76x0_rf_set and mt76x0_rf_clear
helper routines. Moreover over get rid of magic numbers
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lyude Paul [Sat, 24 Nov 2018 22:57:05 +0000 (17:57 -0500)]
brcmfmac: Fix out of bounds memory access during fw load
I ended up tracking down some rather nasty issues with f2fs (and other
filesystem modules) constantly crashing on my kernel down to a
combination of out of bounds memory accesses, one of which was coming
from brcmfmac during module load:
[ 30.891382] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
[ 30.894437] ==================================================================
[ 30.901581] BUG: KASAN: global-out-of-bounds in brcmf_fw_alloc_request+0x42c/0x480 [brcmfmac]
[ 30.909935] Read of size 1 at addr ffff2000024865df by task kworker/6:2/387
[ 30.916805]
[ 30.918261] CPU: 6 PID: 387 Comm: kworker/6:2 Tainted: G O 4.20.0-rc3Lyude-Test+ #19
[ 30.927251] Hardware name: amlogic khadas-vim2/khadas-vim2, BIOS 2018.07-rc2-armbian 09/11/2018
[ 30.935964] Workqueue: events brcmf_driver_register [brcmfmac]
[ 30.941641] Call trace:
[ 30.944058] dump_backtrace+0x0/0x3e8
[ 30.947676] show_stack+0x14/0x20
[ 30.950968] dump_stack+0x130/0x1c4
[ 30.954406] print_address_description+0x60/0x25c
[ 30.959066] kasan_report+0x1b4/0x368
[ 30.962683] __asan_report_load1_noabort+0x18/0x20
[ 30.967547] brcmf_fw_alloc_request+0x42c/0x480 [brcmfmac]
[ 30.967639] brcmf_sdio_probe+0x163c/0x2050 [brcmfmac]
[ 30.978035] brcmf_ops_sdio_probe+0x598/0xa08 [brcmfmac]
[ 30.983254] sdio_bus_probe+0x190/0x398
[ 30.983270] really_probe+0x2a0/0xa70
[ 30.983296] driver_probe_device+0x1b4/0x2d8
[ 30.994901] __driver_attach+0x200/0x280
[ 30.994914] bus_for_each_dev+0x10c/0x1a8
[ 30.994925] driver_attach+0x38/0x50
[ 30.994935] bus_add_driver+0x330/0x608
[ 30.994953] driver_register+0x140/0x388
[ 31.013965] sdio_register_driver+0x74/0xa0
[ 31.014076] brcmf_sdio_register+0x14/0x60 [brcmfmac]
[ 31.023177] brcmf_driver_register+0xc/0x18 [brcmfmac]
[ 31.023209] process_one_work+0x654/0x1080
[ 31.032266] worker_thread+0x4f0/0x1308
[ 31.032286] kthread+0x2a8/0x320
[ 31.039254] ret_from_fork+0x10/0x1c
[ 31.039269]
[ 31.044226] The buggy address belongs to the variable:
[ 31.044351] brcmf_firmware_path+0x11f/0xfffffffffffd3b40 [brcmfmac]
[ 31.055601]
[ 31.057031] Memory state around the buggy address:
[ 31.061800] ffff200002486480: 04 fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
[ 31.068983] ffff200002486500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 31.068993] >ffff200002486580: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00
[ 31.068999] ^
[ 31.069017] ffff200002486600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 31.096521] ffff200002486680: 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa
[ 31.096528] ==================================================================
[ 31.096533] Disabling lock debugging due to kernel taint
It appears that when trying to determine the length of the string in the
alternate firmware path, we make the mistake of not handling the case
where the firmware path is empty correctly. Since strlen(mp_path) can
return 0, we'll end up accessing mp_path[-1] when the firmware_path
isn't provided through the module arguments.
So, fix this by just setting the end char to '\0' by default, and only
changing it if we have a non-zero length. Additionally, use strnlen()
with BRCMF_FW_ALTPATH_LEN instead of strlen() just to be extra safe.
Fixes: 2baa3aaee27f ("brcmfmac: introduce brcmf_fw_alloc_request() function") Cc: Hante Meuleman <hante.meuleman@broadcom.com> Cc: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Cc: Franky Lin <franky.lin@broadcom.com> Cc: Arend van Spriel <arend.vanspriel@broadcom.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: Arend Van Spriel <arend.vanspriel@broadcom.com> Cc: Himanshu Jha <himanshujha199640@gmail.com> Cc: Dan Haab <dhaab@luxul.com> Cc: Jia-Shyr Chuang <saint.chuang@cypress.com> Cc: Ian Molton <ian@mnementh.co.uk> Cc: <stable@vger.kernel.org> # v4.17+ Signed-off-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Hans de Goede [Fri, 23 Nov 2018 09:11:48 +0000 (10:11 +0100)]
brcmfmac: Call brcmf_dmi_probe before brcmf_of_probe
ARM systems with UEFI may have both devicetree (of) and DMI data in this
case we end up setting brcmf_mp_device.board_type twice.
In this case we should prefer the devicetree data, because:
1) The devicerree data is more reliable
2) Some ARM systems (e.g. the Raspberry Pi 3 models) support both UEFI and
classic uboot booting, the devicetree data is always there, so using it
makes sure we ask for the same nvram file independent of how we booted.
This commit moves the brcmf_dmi_probe call to before the brcmf_of_probe
call, so that the latter can override the value of the first if both are
set.
Fixes: bd1e82bb420a ("brcmfmac: Set board_type from DMI on x86 based ...") Cc: Peter Robinson <pbrobinson@gmail.com> Tested-and-reported-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Dan Haab [Fri, 9 Nov 2018 16:38:55 +0000 (09:38 -0700)]
brcmfmac: support STA info struct v7
The newest firmwares provide STA info using v7 of the struct. As v7
isn't backward compatible, a union is needed.
Even though brcmfmac does not use any of the new info it's important to
provide the proper struct buffer. Without this change new firmwares will
fallback to the very limited v3 instead of something in between such as
v4.
Signed-off-by: Dan Haab <dan.haab@luxul.com> Reviewed-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Larry Finger [Mon, 19 Nov 2018 18:01:24 +0000 (20:01 +0200)]
b43: Fix error in cordic routine
The cordic routine for calculating sines and cosines that was added in
commit 6f98e62a9f1b ("b43: update cordic code to match current specs")
contains an error whereby a quantity declared u32 can in fact go negative.
This problem was detected by Priit Laes who is switching b43 to use the
routine in the library functions of the kernel.
Fixes: 986504540306 ("b43: make cordic common (LP-PHY and N-PHY need it)") Reported-by: Priit Laes <plaes@plaes.org> Cc: Rafał Miłecki <zajec5@gmail.com> Cc: Stable <stable@vger.kernel.org> # 2.6.34 Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Priit Laes <plaes@plaes.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Priit Laes [Mon, 19 Nov 2018 18:01:22 +0000 (20:01 +0200)]
lib: cordic: Move cordic macros and defines to header file
Now that these macros are in header file, we can eventually
clean up the duplicate macros present in the drivers that
utilize the same cordic algorithm implementation.
Also add CORDIC_ prefix to nonprefixed macros.
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Priit Laes <plaes@plaes.org> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Kalle Valo [Thu, 29 Nov 2018 09:00:00 +0000 (11:00 +0200)]
Merge tag 'iwlwifi-next-for-kalle-2018-11-23' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
second batch of iwlwifi patches intended for v4.21
* New FW debugging infrastructure;
* Some more work on 802.11ax;
* Improve support for multiple RF modules with 22000 devices;
* Remove an unused FW parameter;
* Other debugging improvements;
Lior Cohen [Thu, 3 May 2018 07:17:05 +0000 (10:17 +0300)]
iwlwifi: add debugfs file to read fw debug data recording
FW debug data will oneshot read all data available in DRAM
and fill the supplied user buffer. In case the read request
is greater than the new data in DRAM, the driver will write
all data it has and return the buffer immediately.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: Lior Cohen <lior2.cohen@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Sara Sharon [Wed, 13 Jun 2018 12:19:47 +0000 (15:19 +0300)]
iwlwifi: dbg: add apply point logic
Add a function to be called when apply point occurs.
For each of the TLVs, the function will perform the
apply point logic:
- For HCMD - send the stored host command
- For buffer allocation - allocate the memory and send the
buffer allocation command
- For trigger and region - update the stored configuration
Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Sara Sharon [Thu, 17 May 2018 07:14:30 +0000 (10:14 +0300)]
iwlwifi: trans: parse and store debug ini TLVs
The new debug ini TLVs can be either packed into firmware
binary or written in external file. Support loading them
from both. Store the data per apply point. Apply point is
a point during driver runtime, where the TLV becomes active.
For example, a trigger of hardware error may be configured
to collect a subset of data pre-alive, as a opposed to HW
error that occurs after alive.
Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
We need to check the TWT support of the peer and to
propagte the capability to the firmware.
The current implementation will enable TWT only if the TWT
support is advertised in the HE CAP IE and in the Extended
Capability IE.
Luca Coelho [Sat, 4 Aug 2018 11:45:42 +0000 (14:45 +0300)]
iwlwifi: fix cfg structs for 22000 with different RF modules
We have to choose different configuration and different firmwares
depending on the external RF module that is installed. Since the
external module is not represented in the PCI IDs, we need to change
the configuration at runtime, after checking the RF ID of the module
installed. We have a bit of a mess in the code that does this,
because it applies cfg's according to the RF ID only, ignoring the
integrated module that is in use.
Fix that for some devices by adding correct configurations for them
and not ignoring the integrated module's type when making the
decision.
Sara Sharon [Mon, 30 Jul 2018 08:59:16 +0000 (11:59 +0300)]
iwlwifi: dbg: don't limit dump decisions to all or monitor
Currently opmode is limited to asking transport to either
dump all the dumps configured at startup, or monitor only.
Instead, pass to transport a bitmask, to allow flexibility.
Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Kalle Valo [Thu, 15 Nov 2018 14:59:01 +0000 (16:59 +0200)]
Merge tag 'iwlwifi-next-for-kalle-2018-11-11' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
First set of iwlwifi patches for 4.21
* PCI IDs for some new 9000-series cards;
* Improve antenna usage on connection problems;
* Some improvements in the debugging code;
* Other clean-ups and small fixes;
iwlwifi: mvm: Send non offchannel traffic via AP sta
TDLS discovery response frame is a unicast direct frame to the peer.
Since we don't have a STA for this peer, this frame goes through
iwl_tx_skb_non_sta(). As the result aux_sta and some completely
arbitrary queue would be selected for this frame, resulting in a queue
hang. Fix that by sending such frames through AP sta instead.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
iwlwifi: mvm: add description to a few generic assert numbers
FW asserts 0x70, 0x71, and 0x73 all just mean that the real error
happened in another MAC, and to look there for the problem. Add their
descriptions to the assert number lookup table so users get a nicer
error message in the logs.
Also, since the 4 most-significant bits of the assert number are
dynamic, and depend on which MAC the assert occurred on, ignore those
bits when looking up the assert name.
Sara Sharon [Thu, 19 Jul 2018 06:15:11 +0000 (09:15 +0300)]
iwlwifi: pcie: don't reset TXQ write pointer
Currently code sets the write pointer when getting the TX queue
allocate response. This causes a redundant interrupt with any actual
change in the pointer. Remove this write altogether.
Fixes: 310181ec34e2 ("iwlwifi: move to TVQM mode") Signed-off-by: Sara Sharon <sara.sharon@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
iwlwifi: mvm: toggle tx antenna if tx fails during connection establishment
If tx fails during connection establishment, try another antenna for
the next tx. This will increase the chance to establish connection if
one of the antennas is blocked. Note that the antenna is toggled even
when failing to tx data frames since connection establishment may use
EAPOLs for 802.1X authentication/ 4 way handshake.
iwlwifi: fw: do not set sgi bits for HE connection
If the association supports HE, HT/VHT rates will never be used for Tx
and therefore there's no need to set the sgi-per-channel-width-support
bits, so don't set them in this case.
Fixes: 110b32f065f3 ("iwlwifi: mvm: rs: add basic implementation of the new RS API handlers") Signed-off-by: Naftali Goldstein <naftali.goldstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Enable low latency for softAP in all modes (standalone, SCM
and DCM).
This is in order to minimize the time the softAP leaves the channel for
other operations
iwlwifi: trans: Clear persistence bit when starting the FW
In D3 suspend flow in 9260 gen2 HW, the NIC receives two PERST signals.
The first PERST is expected and indicates the device on coming resume flow.
The second PERST causes FW restart FW restart.
In order to avoid this issue, the FW set the persistence bit on.
Once this bit is set, the FW ignores reset attempts.
The problem is when the FW gets assert during D3 and then the persistence
bit is set and causes the FW to ignore reset.
To handle this issue, the FW opens the preg bit which allows access
to the persistence bit, so that the driver clear the persistence bit
and reset the NIC.
The flow is as follows:
the driver checks if the persistence bit is set.
If the bit is set, the driver checks if he can clear the bit.
If the driver can not clear the bit then there is no point to continue
configuring the NIC since it will fail.
The fix was added is in start HW flow instead of the resume flow since in
general, if the persistence bit is set, the driver can not start the FW.
So it is good to check it when we start configuring the NIC.
The driver does not need to close the preg bit since the FW close it
during the start flow.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Johannes Berg [Wed, 4 Jul 2018 21:19:13 +0000 (23:19 +0200)]
iwlwifi: mvm: remove queue_info_lock
All the queue management code runs under mvm->mutex, so there are
only very few cases of accessing the data structures without it:
* TX path, which doesn't take any locks anyway
* iwl_mvm_wake_sw_queue() and iwl_mvm_stop_sw_queue() where we
just (atomically) read a bitmap, so the lock isn't needed.
Therefore, we can remove the spinlock. This enables some cleanup
in the ugly locking in iwl_mvm_inactivity_check().
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Johannes Berg [Wed, 4 Jul 2018 21:12:33 +0000 (23:12 +0200)]
iwlwifi: mvm: synchronize TID queue removal
When we mark a TID as no longer having a queue, there's no
guarantee the TX path isn't using this txq_id right now,
having accessed it just before we reset the value. To fix
this, add synchronize_net() when we change the TIDs from
having a queue to not having one, so that we can then be
sure that the TX path is no longer accessing that queue.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
YueHaibing [Fri, 5 Oct 2018 10:47:01 +0000 (10:47 +0000)]
iwlwifi: mvm: remove set but not used variable 'he_phy_data'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c: In function 'iwl_mvm_rx_mpdu_mq':
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c:1386:7: warning:
variable 'he_phy_data' set but not used [-Wunused-but-set-variable]
u64 he_phy_data;
'he_phy_data' never used since be introduce in
commit 18ead597daa1 ("iwlwifi: support new rx_mpdu_desc api")
Shaokun Zhang [Mon, 5 Nov 2018 11:25:30 +0000 (19:25 +0800)]
rtlwifi: rtl8192de: Fix misleading REG_MCUFWDL information
RT_TRACE shows REG_MCUFWDL value as a decimal value with a '0x'
prefix, which is somewhat misleading.
Fix it to print hexadecimal, as was intended.
Cc: Ping-Ke Shih <pkshih@realtek.com> Cc: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Rafał Miłecki [Fri, 26 Oct 2018 11:22:32 +0000 (13:22 +0200)]
brcmutil: print invalid chanspec when WARN-ing
On one of my devices I got WARNINGs when brcmfmac tried to decode
chanspec. I couldn't tell if it was some unsupported format or just a
malformed value passed by a firmware.
Print chanspec value so it's possible to debug a possible problem.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Dan Carpenter [Wed, 24 Oct 2018 08:33:34 +0000 (11:33 +0300)]
wireless: airo: potential buffer overflow in sprintf()
It looks like we wanted to print a maximum of BSSList_rid.ssidLen bytes
of the ssid, but we accidentally use "%*s" (width) instead of "%.*s"
(precision) so if the ssid doesn't have a NUL terminator this could lead
to an overflow.
Static analysis. Not tested.
Fixes: e174961ca1a0 ("net: convert print_mac to %pM") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
zhong jiang [Wed, 24 Oct 2018 05:52:09 +0000 (13:52 +0800)]
rtlwifi: rtl8723ae: Remove set but not used variables and #defines
radiob_array_table' and 'radiob_arraylen' are not used after setting its value.
It is safe to remove the unused variable. Meanwhile, radio B array should be
removed as well. because it will no longer be referenced.
Signed-off-by: zhong jiang <zhongjiang@huawei.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
brcmsmac: never log "tid x is not agg'able" by default
This message greatly spams the log under heavy Tx of frames with BK access
class which is especially true when operating as AP. It is also not informative
as the "agg'ablity" of TIDs are set once and never change.
Fix this by logging only in debug mode.
Signed-off-by: Ali MJ Al-Nasrawy <alimjalnasrawy@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
rtlwifi: rtl8821ae: phy: Mark expected switch fall-through
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 114948 ("Missing break in switch")
Addresses-Coverity-ID: 114949 ("Missing break in switch") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
rt2x00: rt2800lib: mark expected switch fall-throughs
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 145198 ("Missing break in switch") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
projects / kernel.git / log