- 16 2月, 2018 2 次提交
-
-
由 Sara Sharon 提交于
In IBSS, the mac80211 sets the cab_queue to be invalid. However, the multicast station uses it, so we need to override it. A previous patch did it, but it was nested inside the if's and was applied only for legacy FWs that don't support the new station type API, instead of being applied for all paths. In addition, add a missing NL80211_IFTYPE_ADHOC to the initialization of the queues in iwl_mvm_mac_ctxt_init() Fixes: ee48b722 ("iwlwifi: mvm: support ibss in dqa mode") Signed-off-by: NSara Sharon <sara.sharon@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
由 Sara Sharon 提交于
A previous patch allowed the same PN for packets originating from the same AMSDU by copying PN only for the last packet in the series. This however is bogus since we cannot assume the last frame will be received on the same queue, and if it is received on a different ueue we will end up not incrementing the PN and possibly let the next packet to have the same PN and pass through. Change the logic instead to driver explicitly indicate for the second sub frame and on to be allowed to have the same PN as the first subframe. Indicate it to mac80211 as well for the fallback queue. Fixes: f1ae02b1 ("iwlwifi: mvm: allow same PN for de-aggregated AMSDU") Signed-off-by: NSara Sharon <sara.sharon@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
-
- 12 2月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
This is the mindless scripted replacement of kernel use of POLL* variables as described by Al, done by this script: for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'` for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done done with de-mangling cleanups yet to come. NOTE! On almost all architectures, the EPOLL* constants have the same values as the POLL* constants do. But they keyword here is "almost". For various bad reasons they aren't the same, and epoll() doesn't actually work quite correctly in some cases due to this on Sparc et al. The next patch from Al will sort out the final differences, and we should be all done. Scripted-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 08 2月, 2018 1 次提交
-
-
由 Ryan Hsu 提交于
This reverts commit 9ed4f916. The commit introduced a regression that over read the ie with the padding. - the expected IE information ath10k_pci 0000:03:00.0: found firmware features ie (1 B) ath10k_pci 0000:03:00.0: Enabling feature bit: 6 ath10k_pci 0000:03:00.0: Enabling feature bit: 7 ath10k_pci 0000:03:00.0: features ath10k_pci 0000:03:00.0: 00000000: c0 00 00 00 00 00 00 00 - the wrong IE with padding is read (0x77) ath10k_pci 0000:03:00.0: found firmware features ie (4 B) ath10k_pci 0000:03:00.0: Enabling feature bit: 6 ath10k_pci 0000:03:00.0: Enabling feature bit: 7 ath10k_pci 0000:03:00.0: Enabling feature bit: 8 ath10k_pci 0000:03:00.0: Enabling feature bit: 9 ath10k_pci 0000:03:00.0: Enabling feature bit: 10 ath10k_pci 0000:03:00.0: Enabling feature bit: 12 ath10k_pci 0000:03:00.0: Enabling feature bit: 13 ath10k_pci 0000:03:00.0: Enabling feature bit: 14 ath10k_pci 0000:03:00.0: Enabling feature bit: 16 ath10k_pci 0000:03:00.0: Enabling feature bit: 17 ath10k_pci 0000:03:00.0: Enabling feature bit: 18 ath10k_pci 0000:03:00.0: features ath10k_pci 0000:03:00.0: 00000000: c0 77 07 00 00 00 00 00 Tested-by: NMike Lothian <mike@fireburn.co.uk> Signed-off-by: NRyan Hsu <ryanhsu@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 07 2月, 2018 6 次提交
-
-
由 Oleksij Rempel 提交于
as reported in: https://github.com/qca/open-ath9k-htc-firmware/pull/71#issuecomment-361100070Signed-off-by: NOleksij Rempel <linux@rempel-privat.de> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Yu Wang 提交于
If device gone during chip reset, ar->normal_mode_fw.board is not initialized, but ath10k_debug_print_hwfw_info() will try to access its member, which will cause 'kernel NULL pointer' issue. This was found using a faulty device (pci link went down sometimes) in a random insmod/rmmod/other-op test. To fix it, check ar->normal_mode_fw.board before accessing the member. pci 0000:02:00.0: BAR 0: assigned [mem 0xf7400000-0xf75fffff 64bit] ath10k_pci 0000:02:00.0: enabling device (0000 -> 0002) ath10k_pci 0000:02:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0 ath10k_pci 0000:02:00.0: failed to read device register, device is gone ath10k_pci 0000:02:00.0: failed to wait for target init: -5 ath10k_pci 0000:02:00.0: failed to warm reset: -5 ath10k_pci 0000:02:00.0: firmware crashed during chip reset ath10k_pci 0000:02:00.0: firmware crashed! (uuid 5d018951-b8e1-404a-8fde-923078b4423a) ath10k_pci 0000:02:00.0: (null) target 0x00000000 chip_id 0x00340aff sub 0000:0000 ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 1 ath10k_pci 0000:02:00.0: firmware ver api 0 features crc32 00000000 ... BUG: unable to handle kernel NULL pointer dereference at 00000004 ... Call Trace: [<fb4e7882>] ath10k_print_driver_info+0x12/0x20 [ath10k_core] [<fb62b7dd>] ath10k_pci_fw_crashed_dump+0x6d/0x4d0 [ath10k_pci] [<fb629f07>] ? ath10k_pci_sleep.part.19+0x57/0xc0 [ath10k_pci] [<fb62c8ee>] ath10k_pci_hif_power_up+0x14e/0x1b0 [ath10k_pci] [<c10477fb>] ? do_page_fault+0xb/0x10 [<fb4eb934>] ath10k_core_register_work+0x24/0x840 [ath10k_core] [<c18a00d8>] ? netlbl_unlhsh_remove+0x178/0x410 [<c10477f0>] ? __do_page_fault+0x480/0x480 [<c1068e44>] process_one_work+0x114/0x3e0 [<c1069d07>] worker_thread+0x37/0x4a0 [<c106e294>] kthread+0xa4/0xc0 [<c1069cd0>] ? create_worker+0x180/0x180 [<c106e1f0>] ? kthread_park+0x50/0x50 [<c18ab4f7>] ret_from_fork+0x1b/0x28 Code: 78 80 b8 50 09 00 00 00 75 5d 8d 75 94 c7 44 24 08 aa d7 52 fb c7 44 24 04 64 00 00 00 89 34 24 e8 82 52 e2 c5 8b 83 dc 08 00 00 <8b> 50 04 8b 08 31 c0 e8 20 57 e3 c5 89 44 24 10 8b 83 58 09 00 EIP: [<fb4e7754>]- ath10k_debug_print_board_info+0x34/0xb0 [ath10k_core] SS:ESP 0068:f4921d90 CR2: 0000000000000004 Signed-off-by: NYu Wang <yyuwang@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Wojciech Dubowik 提交于
Commit 8da58553 ("ath9k: Use calibrated noise floor value when available") introduced regression in ath9k_hw_getchan_noise where per chain nominal noise floor has been taken instead default for channel. Revert to original default channel noise floor. Fixes: 8da58553 ("ath9k: Use calibrated noise floor value when available") Reported-by: NSebastian Gottschall <s.gottschall@dd-wrt.com> Signed-off-by: NWojciech Dubowik <Wojciech.Dubowik@neratec.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Tobias Schramm 提交于
Some modern Ubiquiti devices contain a rebranded QCA988X rev2 with a custom Ubiquiti vendor and device id. This patch adds support for those devices, treating them as a QCA988X v2. Signed-off-by: NTobias Schramm <tobleminer@gmail.com> [kvalo@codeaurora.org: rebase, add missing fields in hw_params, fix a long line in pci.c:61] Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Yu Wang 提交于
The length of DRAM dump for QCA6174 hw3.0/hw3.2 and QCA9377 hw1.1 are less than the actual value, some coredump contents are missed. To fix it, change the length from 0x90000 to 0xa8000. Fixes: 703f261d ("ath10k: add memory dump support for QCA6174/QCA9377") Signed-off-by: NYu Wang <yyuwang@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Larry Finger 提交于
There has been a coding error in rtl8821ae since it was first introduced, namely that an 8-bit register was read using a 16-bit read in _rtl8821ae_dbi_read(). This error was fixed with commit 40b368af ("rtlwifi: Fix alignment issues"); however, this change led to instability in the connection. To restore stability, this change was reverted in commit b8b8b163 ("rtlwifi: rtl8821ae: Fix connection lost problem"). Unfortunately, the unaligned access causes machine checks in ARM architecture, and we were finally forced to find the actual cause of the problem on x86 platforms. Following a suggestion from Pkshih <pkshih@realtek.com>, it was found that increasing the ASPM L1 latency from 0 to 7 fixed the instability. This parameter was varied to see if a smaller value would work; however, it appears that 7 is the safest value. A new symbol is defined for this quantity, thus it can be easily changed if necessary. Fixes: b8b8b163 ("rtlwifi: rtl8821ae: Fix connection lost problem") Cc: Stable <stable@vger.kernel.org> # 4.14+ Fix-suggested-by: NPkshih <pkshih@realtek.com> Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Tested-by: James Cameron <quozl@laptop.org> # x86_64 OLPC NL3 Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 01 2月, 2018 4 次提交
-
-
由 Felix Fietkau 提交于
Avoids data connection stalls when the client toggles powersave mode Fixes: aee5b8cf ("mt76: implement A-MPDU rx reordering in the driver code") Signed-off-by: NFelix Fietkau <nbd@nbd.name> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Felix Fietkau 提交于
Fixes: aee5b8cf ("mt76: implement A-MPDU rx reordering in the driver code") Signed-off-by: NFelix Fietkau <nbd@nbd.name> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Felix Fietkau 提交于
Avoids timeouts on reordered A-MPDU rx frames Fixes: aee5b8cf ("mt76: implement A-MPDU rx reordering in the driver code") Signed-off-by: NFelix Fietkau <nbd@nbd.name> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Felix Fietkau 提交于
With software A-MPDU reordering in place, frames that notify mac80211 of powersave changes are reordered as well, which can cause connection stalls. Fix this by implementing powersave state processing in the driver. Fixes: aee5b8cf ("mt76: implement A-MPDU rx reordering in the driver code") Signed-off-by: NFelix Fietkau <nbd@nbd.name> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 26 1月, 2018 9 次提交
-
-
由 Felix Fietkau 提交于
Apparently hardware does not perform CCMP PN validation in hardware, so we need to take care of this in the driver. This is important for protecting against replay attacks. Since validation of fragmented frames is more complex, the CCMP header for those is preserved. To keep the counter in sync, the first fragment is verified by both mt76 and mac80211, and all other fragments only by mac80211. Signed-off-by: NFelix Fietkau <nbd@nbd.name> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Felix Fietkau 提交于
Preparation for adding software rx CCMP PN validation Signed-off-by: NFelix Fietkau <nbd@nbd.name> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Felix Fietkau 提交于
Add a separate function for processing frames after A-MPDU reordering, reduce code duplication Signed-off-by: NFelix Fietkau <nbd@nbd.name> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Felix Fietkau 提交于
This is required for performing CCMP PN validation in software Signed-off-by: NFelix Fietkau <nbd@nbd.name> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Felix Fietkau 提交于
Avoids the rhashtable lookup based on the MAC address inside mac80211 Signed-off-by: NFelix Fietkau <nbd@nbd.name> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Felix Fietkau 提交于
Preparation for passing in more internal rx data via skb->cb Signed-off-by: NFelix Fietkau <nbd@nbd.name> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Felix Fietkau 提交于
Like beacons, probe responses need a hardware-generated TSF value. Set the flag that causes the hw to generate it Signed-off-by: NFelix Fietkau <nbd@nbd.name> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Felix Fietkau 提交于
Sending frames to mac80211 needs time, which could allow for more rx packets to end up in the DMA ring. Retry polling until there are no more frames left. Improves rx latency under load. Signed-off-by: NFelix Fietkau <nbd@nbd.name> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Ping-Ke Shih 提交于
Add 'static' or declaration to resolve the warnings, and remove two unused functions halbtc_set_macreg() and halbtc_get_macreg() exposed when they were made static. Signed-off-by: NPing-Ke Shih <pkshih@realtek.com> Acked-by: NLarry Finger <Larry.Finger@lwfinger.net> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 25 1月, 2018 17 次提交
-
-
由 Ramon Fried 提交于
wcn36xx_dxe_init() doesn't check for the return value of wcn36xx_dxe_init_descs(), release the resources in case an error ocurred. Signed-off-by: NRamon Fried <rfried@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Wojciech Dubowik 提交于
Display per frequency calibration data in dump_modal debugfs entry including reference power, voltage, tx temperature and noise floor. Example of chain 0 of OEM card (dump from modal_eeprom): Chain 0 Freq ref volt temp nf_Cal nf_Pow rx_temp 5180 -30 0 137 0 0 0 5320 -24 0 137 0 0 0 5500 -15 0 137 0 0 0 5620 -10 0 137 0 0 0 5700 -15 0 137 0 0 0 5745 -16 0 135 0 0 0 5785 -19 0 136 0 0 0 5825 -22 0 136 0 0 0 Example of a card with calibrated noise floor. Chain 0 Freq ref volt temp nf_Cal nf_Pow rx_temp 4890 -49 0 128 -107 -97 124 5100 -23 0 128 -101 -96 124 5180 -18 0 128 -101 -96 124 5300 -12 0 128 -102 -97 124 5500 -9 0 128 -101 -97 125 5640 -17 0 128 -101 -98 124 5785 -25 0 128 -101 -98 124 5940 -33 0 128 -106 -99 124 Signed-off-by: NWojciech Dubowik <Wojciech.Dubowik@neratec.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Wojciech Dubowik 提交于
AR9003 series allows to calibrate noise floor for different frequency bins. Once it's done it's possible to get more accurate rssi/signal values over whole frequency band at a given temperature. The RSSI/signal accuracy reported by calibrated RF cards improves from 6 to up to 2dB. This could be interesting for application which require good signal accuracy like roaming or mesh protocols. Signed-off-by: NWojciech Dubowik <Wojciech.Dubowik@neratec.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Wojciech Dubowik 提交于
AR9003 devices can have calibrated noise floor values which can be used instead of hard coded one. Read them from eeprom and save interpolated value in nf limits for the current channel. Signed-off-by: NWojciech Dubowik <Wojciech.Dubowik@neratec.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Wojciech Dubowik 提交于
AR9003 factory calibration allows to use bigger EEPROM than standard 1k without changing the default layout. Allow probing of EEPROM at alternative address if initial check for default fails. The original ar9003 eeprom ops are still be used. Signed-off-by: NWojciech Dubowik <Wojciech.Dubowik@neratec.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Maya Erez 提交于
In order to allow using the same brd file across different 11ad chips, the address for loading the brd file should be part of the FW file, instead of the brd file. The brd file is expected to include only one section. To allow backward compatibility the driver reads the address from the brd file in case it is not included in the FW file. Signed-off-by: NMaya Erez <merez@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Lior David 提交于
Sparrow D0 chips have slightly larger mac_rgf_ext section in order to support extra features such as multiple virtual interfaces. Signed-off-by: NLior David <liord@codeaurora.org> Signed-off-by: NMaya Erez <merez@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Lior David 提交于
Currently when we want to bring the interface up, we first reset the device which causes the boot loader to run. Then we halt the device CPU, load FW image and resume the device CPU. There are some boot loader versions which perform redundant memory accesses even when idle. Halting the device CPU while boot loader access memory can cause the device memory controller to get stuck, the FW will fail to load and the network interface will not come up. For such boot loaders implement a workaround where we freeze the boot loader before halting the device CPU, so it will not perform any memory accesses. Signed-off-by: NLior David <liord@codeaurora.org> Signed-off-by: NMaya Erez <merez@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Maya Erez 提交于
OTP HW vectors values are different for 40MHz and 330MHz AHB clocks. In SW reset flow, the host driver sets the clock frequency to 40MHz. In order to allow reading from the OTP, the host driver should configure the OTP HW vectors with the values that fits this clock frequency. Signed-off-by: NMaya Erez <merez@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Dedy Lansky 提交于
Talyn device supports boot without flash. Driver detects flashless device and in this case waits for ready indication from HW machine (instead of bootloader ready indication). Also in this case, MAC address is retrieved from OTP. Signed-off-by: NDedy Lansky <dlansky@codeaurora.org> Signed-off-by: NMaya Erez <merez@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Maya Erez 提交于
Talyn memory has changed, areas were increased and shifted to new locations. Use the appropriate address map according to the device JTAG ID. Signed-off-by: NDedy Lansky <dlansky@codeaurora.org> Signed-off-by: NMaya Erez <merez@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Maya Erez 提交于
Add Talyn JTAG ID to the list of valid IDs and identify this device as Talyn. Signed-off-by: NMaya Erez <merez@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Maya Erez 提交于
PCIe device ID has changed in Talyn. Add this ID to wil6210_pcie_ids list to allow recognition of Talyn device. Signed-off-by: NMaya Erez <merez@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Felix Fietkau 提交于
Sometimes the hardware will push small packets that trigger a WARN_ON in mac80211. Discard them early to avoid this issue. Reported-by: NStijn Tintel <stijn@linux-ipv6.be> Signed-off-by: NFelix Fietkau <nbd@nbd.name> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Arend Van Spriel 提交于
When using the firmware api it can fail simply because firmware does not like the request or it fails due to issues in the host interface. Currently, there is only a single error code which is confusing. So adding a parameter to pass the firmware error separately and in case of a firmware error always return -EBADE to user-space. Reviewed-by: NHante Meuleman <hante.meuleman@broadcom.com> Reviewed-by: NPieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by: NFranky Lin <franky.lin@broadcom.com> Signed-off-by: NArend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Arend Van Spriel 提交于
The protocol layer api defines callbacks for dongle commands. Although not really well documented these should only return an error code in case of an error, or 0 upon success. In the bcdc protocol it can return value above 0 and we carry a fix in the caller of the protocol layer api. This patch makes it adhere to the intent of the api as described above. Reviewed-by: NHante Meuleman <hante.meuleman@broadcom.com> Reviewed-by: NPieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by: NFranky Lin <franky.lin@broadcom.com> Signed-off-by: NArend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Sergey Matyukevich 提交于
Signed-off-by: NSergey Matyukevich <sergey.matyukevich.os@quantenna.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-