- 14 Jun, 2018 11 commits
-
-
Brian Norris authored
Sort these alphabetically, with local includes in a separate section. Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org>
-
Brian Norris authored
We started using a common CE_ATTR_FLAGS definition, so drop this one. Signed-off-by:
-
Brian Norris authored
It's easier to violate abstractions and introduce bugs when snoc.h is including pci.h. Let's not do that. I'm not extremely familiar with this driver yet, but several of the shared PCI/SNOC bits seem to be related to the Copy Engine, so move them to ce.h. Signed-off-by:
-
Brian Norris authored
We're 'ath10k_snoc', not 'ath10k_pci'. This probably means we're accessing junk data in ath10k_snoc_rx_replenish_retry(), unless 'ath10k_snoc' and 'ath10k_pci' happen to have very similar struct layouts. Noticed by inspection. Fixes: d9151052 ("ath10k: add hif rx methods for wcn3990") Signed-off-by:
-
Brian Norris authored
ath10k_snoc_init()/ath10k_snoc_exit() don't add much value; module_platform_driver() can remove the boilerplate. Signed-off-by:
-
Brian Norris authored
The comments are telling you what the enum could tell you instead. Signed-off-by:
-
YueHaibing authored
Use dma_zalloc_coherent instead of dma_alloc_coherent followed by memset 0. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
YueHaibing authored
sizeof(struct ce_desc) should be a copy-paste mistake just use sizeof(struct ce_desc_64) to avoid mem leak Fixes: b7ba83f7 ("ath10k: add support for shadow register for WNC3990") Signed-off-by:
-
Wei Yongjun authored
Fixes the following sparse warnings: drivers/net/wireless/ath/ath10k/snoc.c:823:5: warning: symbol 'ath10k_snoc_get_ce_id_from_irq' was not declared. Should it be static? drivers/net/wireless/ath/ath10k/snoc.c:871:6: warning: symbol 'ath10k_snoc_init_napi' was not declared. Should it be static? Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
Karthikeyan Periyasamy authored
The spectral scan has been always broken on QCA9984 and QCA9888. Introduce a hardware parameter 'spectral_bin_offset' to resolve this issue for QCA9984 and QCA9888 chipsets. For other chipsets, the hardware parameter 'spectral_bin_offset' is zero so that existing behaviour is retained as it is. In QCA9984 and QCA9888 chipsets, hardware param value 'spectral_bin_discard' is 12 bytes. This 12 bytes is derived as the sum of segment index (4 bytes), extra bins before the actual data (4 bytes) and extra bins after the actual data (4 bytes). Always discarding (12 bytes) happens at end of the samples and incorrect samples got dumped, so that user can find incorrect arrangement samples in spectral scan dump. To fix this issue, we have to discard first 8 bytes and last 4 bytes in every samples, so totally 12 bytes are discarded. In every sample we need to consider the offset while taking the actual spectral data. For QCA9984, QCA9888 the offset is 8 bytes (segment index + extra bins before actual data). Hardware tested: QCA9984 and QCA9888 Firmware tested: 10.4-3.5.3-00053 Signed-off-by:
Karthikeyan Periyasamy <periyasa@codeaurora.org> Signed-off-by:
-
Ben Greear authored
The India regulatory domain allows CH 173, so add that to the available channel list. I verified basic connectivity between a 9880 and 9984 NIC. Signed-off-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
-
- 13 Jun, 2018 6 commits
-
-
Colin Ian King authored
Currently tpc_stats is allocated and is leaked on the return path if num_tx_chain is greater than WMI_TPC_TX_N_CHAIN. Avoid this leak by performing the check on num_tx_chain before the allocation of tpc_stats. Detected by CoverityScan, CID#1469422 ("Resource Leak") Fixes: 4b190675 ("ath10k: fix kernel panic while reading tpc_stats") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Gustavo A. R. Silva authored
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> Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by:
Steve deRosier <derosier@cal-sierra.com> Signed-off-by:
-
Guy Chronister authored
This is a Qualcomm Atheros AR6004X with an sdio ID of 0x19 and hardware ID of 0271:0419. Tested on a Dell Venue 11 Pro 7130 with a self compiled kernel. Signed-off-by:
Guy Chronister <guylovesbritt@gmail.com> [kvalo@codeaurora.org: cleanup commit log] Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that in this particular case, I replaced "pass through" with a proper "fall through" comment, which is what GCC is expecting to find. Signed-off-by:
-
- 25 May, 2018 23 commits
-
-
Eyal Ilsar authored
Introduce infrastructure for supporting Factory Test Mode (FTM) of the wireless LAN subsystem. In order for the user space to access the firmware in test mode the relevant netlink channel needs to be exposed from the kernel driver. The above is achieved as follows: 1) Register wcn36xx driver to testmode callback from netlink 2) Add testmode callback implementation to handle incoming FTM commands 3) Add FTM command packet structure 4) Add handling for GET_BUILD_RELEASE_NUMBER (msgid=0x32A2) 5) Add generic handling for all PTT_MSG packets Signed-off-by:
Eyal Ilsar <eilsar@codeaurora.org> Signed-off-by:
Ramon Fried <ramon.fried@linaro.org> Signed-off-by:
-
Sriram R authored
In the 10.4-3.6 firmware branch there's a new DFS Host confirmation feature which is advertised using WMI_SERVICE_HOST_DFS_CHECK_SUPPORT flag. This new features enables the ath10k host to send information to the firmware on the specifications of detected radar type. This allows the firmware to validate if the host's radar pattern detector unit is operational and check if the radar information shared by host matches the radar pulses sent as phy error events from firmware. If the check fails the firmware won't allow use of DFS channels on AP mode when using FCC regulatory region. Hence this patch is mandatory when using a firmware from 10.4-3.6 branch. Else, DFS channels on FCC regions cannot be used. Supported Chipsets : QCA9984/QCA9888/QCA4019 Firmware Version : 10.4-3.6-00104 Signed-off-by:
Sriram R <srirrama@codeaurora.org> Signed-off-by:
-
Sriram R authored
This enables ath10k/ath9k drivers to collect the specifications of the radar type once it is detected by the dfs pattern detector unit. Usage of the collected info is specific to driver implementation. For example, collected radar info could be used by the host driver to send to co-processors for additional processing/validation. Note: 'radar_detector_specs' data containing the specifications of different radar types which was private within dfs_pattern_detector/ dfs_pri_detector is now shared with drivers as well for making use of this information. Signed-off-by:
-
Daniel Mack authored
Add a missing newline in wcn36xx_smd_send_and_wait() and also log the command request and response type that was processed. Signed-off-by:
Daniel Mack <daniel@zonque.org> Signed-off-by:
-
Daniel Mack authored
Drop the extra warning about failed allocations, both the core and the only caller of this function will warn loud enough in such cases. Signed-off-by:
-
Daniel Mack authored
When the interface is shut down, wcn36xx_smd_close() potentially races against the queue worker. Make sure to cancel the work, and then free all the remnants in hal_ind_queue manually. This is again just a theoretical issue, not something that was triggered in the wild. Signed-off-by:
-
Daniel Mack authored
When a BSSID is joined, set the link status to 'preassoc', and set it to 'idle' when the BSS is deleted. This is what the downstream driver is doing, and it seems to improve the reliability during connect/disconnect stress tests. Signed-off-by:
-
Daniel Mack authored
In reap_tx_dxes(), when we iterate over the linked descriptors, only consider such valid that have WCN36xx_DXE_CTRL_EOP set. This is what the prima downstream driver is doing as well. Signed-off-by:
-
Daniel Mack authored
On RX and TX interrupts, check for the WCN36XX_CH_STAT_INT_ED_MASK or WCN36XX_CH_STAT_INT_DONE_MASK in the interrupt reason register, and only handle packets when it is set. This way, reap_tx_dxes() is only invoked when needed. This brings the dequeing logic in line with what the prima downstream driver is doing. While at it, also log the interrupt reason. Signed-off-by:
-
Daniel Mack authored
Like on the TX side, check for the interrupt reason when the RX interrupt is latched and clear the ERR, DONE and ED masks. This seems to help with connection timeouts and network stream starvatations. And FWIW, the downstream driver does the same thing. Note that in analogy to the TX side, WCN36XX_DXE_0_INT_CLR should be set to WCN36XX_INT_MASK_CHAN_RX_{L,H} rather than WCN36XX_DXE_INT_CH{1,3}_MASK. It did the right thing however, as the defines happen to have identical values. Also, instead of determining register addresses and values inside wcn36xx_rx_handle_packets(), pass them as arguments. Signed-off-by: -
Daniel Mack authored
There's no need to disable the IRQ from inside its handler. Instead just grab the spinlock of the channel that is being processed. Signed-off-by:
-
Daniel Mack authored
The device takes 32-bit addresses only, so inform the DMA API about it. This is the default on msm8016, so that doesn't change anything, but it's best practice to be explicit. Signed-off-by:
-
Daniel Mack authored
When wcn36xx_dxe_tx_frame() is entered while the device is still processing the queue asyncronously, we are racing against the firmware code with updates to the buffer descriptors. Presumably, the firmware scans the ring buffer that holds the descriptors and scans for a valid control descriptor, and then assumes that the next descriptor contains the payload. If, however, the control descriptor is marked valid, but the payload descriptor isn't, the packet is not sent out. Another issue with the current code is that is lacks memory barriers before descriptors are marked valid. This is important because the CPU may reorder writes to memory, even if it is allocated as coherent DMA area, and hence the device may see incompletely written data. To fix this, the code in wcn36xx_dxe_tx_frame() was restructured a bit so that the payload descriptor is made valid before the control descriptor. Memory barriers are added to ensure coherency of shared memory areas. Signed-off-by:
-
YueHaibing authored
clk_disable_unprepare() already checks that the clock pointer is valid. No need to test it before calling it. Signed-off-by:
-
Sven Eckelmann authored
The regdomain code is used to select the correct the correct conformance test limits (CTL) for a country. If the regdomain code isn't correctly mapped to the actual CTL entries in EEPROM then it could happen that the device violates the regulations. But it can also happen that the device is then not able to be used with its full txpower on all rates. The CTL mappings for this regdomain code were now changed to: * 2.4GHz: ETSI * 5GHz: NO_CTL -> ETSI Signed-off-by:
Sven Eckelmann <sven.eckelmann@openmesh.com> Signed-off-by:
-
Sven Eckelmann authored
The regdomain code is used to select the correct the correct conformance test limits (CTL) for a country. If the regdomain code isn't correctly mapped to the actual CTL entries in EEPROM then it could happen that the device violates the regulations. But it can also happen that the device is then not able to be used with its full txpower on all rates. The CTL mappings for this regdomain code were now changed to: * 2.4GHz: ETSI * 5GHz: NO_CTL -> ETSI Signed-off-by:
-
Sven Eckelmann authored
The regdomain code is used to select the correct the correct conformance test limits (CTL) for a country. If the regdomain code isn't correctly mapped to the actual CTL entries in EEPROM then it could happen that the device violates the regulations. But it can also happen that the device is then not able to be used with its full txpower on all rates. The CTL mappings for this regdomain code were now changed to: * 2.4GHz: ETSI * 5GHz: ETSI -> FCC Signed-off-by:
-
Sven Eckelmann authored
The regdomain code is used to select the correct the correct conformance test limits (CTL) for a country. If the regdomain code isn't correctly mapped to the actual CTL entries in EEPROM then it could happen that the device violates the regulations. But it can also happen that the device is then not able to be used with its full txpower on all rates. The CTL mappings for this regdomain code were now changed to: * 2.4GHz: ETSI * 5GHz: NO_CTL -> ETSI Signed-off-by:
-
Sven Eckelmann authored
The regdomain code is used to select the correct the correct conformance test limits (CTL) for a country. If the regdomain code isn't correctly mapped to the actual CTL entries in EEPROM then it could happen that the device violates the regulations. But it can also happen that the device is then not able to be used with its full txpower on all rates. The CTL mappings for this regdomain code were now changed to: * 2.4GHz: ETSI * 5GHz: NO_CTL -> ETSI Signed-off-by:
-
Sven Eckelmann authored
The regdomain code is used to select the correct the correct conformance test limits (CTL) for a country. If the regdomain code isn't correctly mapped to the actual CTL entries in EEPROM then it could happen that the device violates the regulations. But it can also happen that the device is then not able to be used with its full txpower on all rates. This change itself doesn't change the selected CTL of this country and is only required to stay in sync with the QCA mappings. Signed-off-by:
-
Sven Eckelmann authored
The regdomain code is used to select the correct the correct conformance test limits (CTL) for a country. If the regdomain code isn't correctly mapped to the actual CTL entries in EEPROM then it could happen that the device violates the regulations. But it can also happen that the device is then not able to be used with its full txpower on all rates. This change itself doesn't change the selected CTL of this country and is only required to stay in sync with the QCA mappings. Signed-off-by:
-
Sven Eckelmann authored
The regdomain code is used to select the correct the correct conformance test limits (CTL) for a country. If the regdomain code isn't correctly mapped to the actual CTL entries in EEPROM then it could happen that the device violates the regulations. But it can also happen that the device is then not able to be used with its full txpower on all rates. This change itself doesn't change the selected CTL of this country and is only required to stay in sync with the QCA mappings. Signed-off-by:
-
Sven Eckelmann authored
The regdomain code is used to select the correct the correct conformance test limits (CTL) for a country. If the regdomain code isn't correctly mapped to the actual CTL entries in EEPROM then it could happen that the device violates the regulations. But it can also happen that the device is then not able to be used with its full txpower on all rates. The CTL mappings for this regdomain code were now changed to: * 2.4GHz: ETSI * 5GHz: ETSI -> FCC Signed-off-by:
-
