summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-02-13Bluetooth: Track Secure Connections support of remote devicesMarcel Holtmann
It is important to know if Secure Connections support has been enabled for a given remote device. The information is provided in the remote host features page. So track this information and provide a simple helper function to extract the status. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-02-13Bluetooth: Fix mgmt error code for negative PIN responseJohan Hedberg
The NOT_PAIRED status is only really suitable for operations where being paired is a pre-requisite. Using it e.g. for the mgmt_pair_device command seems unintuitive. In the case that either the local or the remote user responds with a negative PIN Code response the "PIN or Key Missing" HCI status will be generated. This patch changes the mapping of this status from the NOT_PAIRED mgmt status to the more intuitive AUTH_FAILED mgmt status. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-13Bluetooth: Convert to use ATTRIBUTE_GROUPS macroWei Yongjun
Use ATTRIBUTE_GROUPS macro to reduce the number of lines of code. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-02-13Bluetooth: Add support for remote OOB input of P-256 dataMarcel Holtmann
The current management interface only allows to provide the remote OOB input of P-192 data. This extends the command to also accept P-256 data as well. To make this backwards compatible, the userspace can decide to only provide P-192 data or the combined P-192 and P-256 data. It is also allowed to leave the P-192 data empty if userspace only has the remote P-256 data. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-02-13Bluetooth: Add internal function for storing P-192 and P-256 dataMarcel Holtmann
Add function to allow adding P-192 and P-256 data to the internal storage. This also fixes a few coding style issues from the previous helper functions for the out-of-band credentials storage. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-02-13Bluetooth: Provide remote OOB data for Secure ConnectionsMarcel Holtmann
When Secure Connections has been enabled it is possible to provide P-192 and/or P-256 data during the pairing process. The internal out-of-band credentials storage has been extended to also hold P-256 data. Initially the P-256 data will be empty and with Secure Connections enabled no P-256 data will be provided. This is according to the specification since it might be possible that the remote side did not provide either of the out-of-band credentials. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-02-13Bluetooth: Add debugfs quirk for forcing Secure Connections supportMarcel Holtmann
The Bluetooth 4.1 specification with Secure Connections support has just been released and controllers with this feature are still in an early stage. A handful of controllers have already support for it, but they do not always identify this feature correctly. This debugfs entry allows to tell the kernel that the controller can be treated as it would fully support Secure Connections. Using debugfs to force Secure Connections support of course does not make this feature magically appear in all controllers. This is a debug functionality for early adopters. Once the majority of controllers matures this quirk will be removed. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-02-13Bluetooth: Add support for local OOB data with Secure ConnectionsMarcel Holtmann
For Secure Connections support and the usage of out-of-band pairing, it is needed to read the P-256 hash and randomizer or P-192 hash and randomizer. This change will read P-192 data when Secure Connections is disabled and P-192 and P-256 data when it is enabled. The difference is between using HCI Read Local OOB Data and using the new HCI Read Local OOB Extended Data command. The first one has been introduced with Bluetooth 2.1 and returns only the P-192 data. < HCI Command: Read Local OOB Data (0x03|0x0057) plen 0 > HCI Event: Command Complete (0x0e) plen 36 Read Local OOB Data (0x03|0x0057) ncmd 1 Status: Success (0x00) Hash C from P-192: 975a59baa1c4eee391477cb410b23e6d Randomizer R with P-192: 9ee63b7dec411d3b467c5ae446df7f7d The second command has been introduced with Bluetooth 4.1 and will return P-192 and P-256 data. < HCI Command: Read Local OOB Extended Data (0x03|0x007d) plen 0 > HCI Event: Command Complete (0x0e) plen 68 Read Local OOB Extended Data (0x03|0x007d) ncmd 1 Status: Success (0x00) Hash C from P-192: 6489731804b156fa6355efb8124a1389 Randomizer R with P-192: 4781d5352fb215b2958222b3937b6026 Hash C from P-256: 69ef8a928b9d07fc149e630e74ecb991 Randomizer R with P-256: 4781d5352fb215b2958222b3937b6026 The change for the management interface is transparent and no change is required for existing userspace. The Secure Connections feature needs to be manually enabled. When it is disabled, then userspace only gets the P-192 returned and with Secure Connections enabled, userspace gets P-192 and P-256 in an extended structure. It is also acceptable to just ignore the P-256 data since it is not required to support them. The pairing with out-of-band credentials will still succeed. However then of course no Secure Connection will b established. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-02-13Bluetooth: Limit acceptable link key types to only supported onesMarcel Holtmann
The link keys that are loaded by userspace during controller setup should be limited to actual valid and supported types. With the support for Secure Connections, it is limited to types 0x00 - 0x08 at the moment. Reject any other link key types. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-02-13Bluetooth: Enable Secure Connection during power on if configuredMarcel Holtmann
If support for Secure Connection has been configured, then make sure to send the appropiate HCI command to enable it when powering on the controller. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-02-13Bluetooth: Add management command for enabling Secure ConnectionsMarcel Holtmann
The support for Secure Connections need to be explicitly enabled by userspace. This is required since only userspace that can handle the new link key types should enable support for Secure Connections. This command handling is similar to how Secure Simple Pairing enabling is done. It also tracks the case when Secure Connections support is enabled via raw HCI commands. This makes sure that the host features page is updated as well. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-02-13Bluetooth: Add flags and setting for Secure Connections supportMarcel Holtmann
The MGMT_SETTING_SECURE_CONN setting is used to track the support and status for Secure Connections from the management interface. For HCI based tracking HCI_SC_ENABLED flag is used. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-02-13Bluetooth: Enable Authenticated Payload Timeout Expired eventMarcel Holtmann
With Secure Connections capable controllers, the authenticated payload timeout can trigger. Enable the event so the controller informs the host when this happens. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-02-13Bluetooth: Add support for handling P-256 derived link keysMarcel Holtmann
Before being able to enable Secure Connections support, the core needs to know on how to handle P-256 derived link keys. The difference between authenticated and unauthenticated P-256 derived link keys is the same as its P-192 counter parts. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-02-13Bluetooth: Add definitions for new link key typesMarcel Holtmann
With the introduction of Secure Connections, the list of link key types got extended by P-256 versions of authenticated and unauthenticated link keys. To avoid any confusion the previous authenticated and unauthenticated link key types got ammended with a P912 postfix. And the two new keys have a P256 postfix now. Existing code using the previous definitions has been adjusted. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-02-13Bluetooth: Add HCI command definition for extended OOB dataMarcel Holtmann
The Secure Connections feature introduces the support for P-256 strength pairings (compared to P-192 with Secure Simple Pairing). This however means that for out-of-band pairing the hash and randomizer needs to be differentiated. Two new commands are introduced to handle the possible combinations of P-192 and P-256. This add the HCI command definition for both. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-02-13Bluetooth: Add HCI command definition for Secure Connections enablingMarcel Holtmann
The Secure Connections feature is optional and host stacks have to manually enable it. This add the HCI command definiton for reading and writing this setting. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-02-13Bluetooth: Add LMP feature definitions for Secure Connections supportMarcel Holtmann
The support for Secure Connections introduces two new controller features and one new host feature. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2014-02-13Bluetooth: Fix outgoing authentication requirement checkJohan Hedberg
The check for HIGH security level dates back to pre-mgmt times when a raw L2CAP socket with HIGH security level was used to trigger dedicated bonding. For legacy pairing checking for the security level was the only way to catch the need to authenticate in all scenarios. With mgmt however, the pair_device command does not use HIGH security but MEDIUM security. Therefore, the existing code would never trigger authentication for a non-SSP connection without an MITM requirement (e.g. if user space provided a NoInputNoOutput IO capability). In such a scenario the mgmt_pair_device command would return success without actually triggering any kind of pairing. This patch updates the authentication requirement check to also consider MEDIUM security level, and thereby ensures that mgmt_pair_device will always trigger authentication. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2014-02-12mwifiex: add key material v2 supportAvinash Patil
This patch adds key material V2 support to mwifiex. Newer FW supports this feature and FW KEY API version is used to determine which command structure needs to be used. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: parse API version from FWAvinash Patil
This patch adds support to parse FW API version TLVs. Currently only API version for key_material is supported. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: disable all TDLS link during disconnectionAvinash Patil
During deauthenticate/link lost event, disable all TDLS links as TDLS would not work when infra connection is not active. Also this will avoid an issue where ping to peer station doesn't work after reassociation to AP where we had created TDLS link in earlier association. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: separate BA params for TDLS link if 11ac is supportedAvinash Patil
If TDLS link is 11ac enabled i.e. we as well as peer station supports VHT, configure seprate TX & RX window sizes during BA setup. So even if BSS does not support 11ac, we can use VHT capabilities and higher window sizes on direct link. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: add VHT support for TDLSAvinash Patil
During TDLS setup request/response, if HW is 11ac capable, we add VHT Capability IEs in outgoing data frame. Also while processing received setup request/response, we preserve peer's 11ac capability retrieved from IEs. Patch also gets VHT parameters from config_station handlers and sets it to FW using TDLS config command. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: pass ieee80211_vht_cap to mwifiex_fill_vht_cap_tlvAvinash Patil
This patch changes mwifiex_fill_vht_cap_tlv function to pass struct ieee80211_vht_cap instead of mwifiex_ie_types_vhtcap so that it can be used generically. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: AMPDU support for TDLS linkAvinash Patil
This patch adds AMPDU support for TDLS link. We have set 11n capabilities including AMPDU parameters during ENABLE_LINK. We set a variable in RA list to indicate this as TDLS link. This patch uses these capabilities to know if AMPDU is allowed on TDLS link and enables AMPDU aggregation for TX and RX reording support for RA list for this peer. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: tdls related handling for data packets addressed to TDLS peerAvinash Patil
1. If data packet is addressed to TDLS peer for which link is established, mark these packets with TDLS flag so that FW can send them on direct link instead of sending via AP. 2. If data packet is addressed to TDLS peer and TDLS setup is underway, move these packets to TDLS queue. 3. If this packet is TDLS setup packet, do not block it. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: provision for holding and restoring packets during TDLS setupAvinash Patil
While TDLS link is being setup, few packets from this station to peer station may be buffered at AP. It may happen that once TDLS link is setup, packets sent from station to peer on direct link get delivered before traffic from AP arrives at peer station. This results into packet reordering issue at peer station. To avoid this, we hold data packets destined to TDLS peer during TDLS setup. These packets are moved to temperory TDLS TX queue. Upon successful TDLS setup, they are moved to RA list created for this peer. Upon failure, packets are moved back to AP's RA list for that particular TID. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: add cfg80211 change_station handler supportAvinash Patil
This patch adds cfg80211 change_station handler support for mwifiex which is needed for TDLS link setup. Driver creates a command to modify peer link capabilities and issues command to FW. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: add cfg80211 add_station handler supportAvinash Patil
This patch adds cfg80211 add_station handler support for mwifiex which is needed for TDLS setup. Driver issues create TDLS link command to FW upon receiving add_station from cfg80211. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: add cfg80211 tdls_oper handler supportAvinash Patil
This patch adds cfg80211 handler tdls_oper handler support to mwifiex. Upon enable link, driver sets status as TDLS status as setup complete and also sets AMSDU size, AMPDU params for direct link. Upon disable link, driver issues command to FW to delete this link in FW. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: parse TDLS action frames during RXAvinash Patil
This patch adds support for parsing TDLS action frames during station receive handler. Peer station capabilities are stored into station node. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: add tdls_mgmt handler supportAvinash Patil
This patch adds support for TDLS management frames transmit handler. mwifiex driver supports TDLS with external support, i.e. expects user space application to form TDLS frames. Same is advertised to cfg80211 during registration. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: cleanup in mwifiex_fill_cap_info()Amitkumar Karwar
Pass 'struct ieee80211_ht_cap' pointer to mwifiex_fill_cap_info() instead of 'struct mwifiex_ie_types_htcap' pointer, because the routine internally uses the later one. This patch also adds WARN_ON_ONCE check for NULL band. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: move station list functions to common codeAvinash Patil
These functions are now needed by TDLS while managing station list. Move them from AP related file to utility file. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: make tos_to_tid_inv part of mwifiex_private structureAvinash Patil
tos_to_tid_inv values are needed even during TDLS restore operations. Currently tos_to_tid_inv is part of wmm.c and is declared static. Make it part of private structure so that it can be used in other files as well. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: handle AMPDU supported check for AP interfaceAvinash Patil
This patch fixes a bug where we were checking for AP's AMPDU param setting even when transmitting traffic to associated station. Patch adds provision to pass additional parameter ra_list pointer to function which checks if AMPDU is allowed. If current BSS type is AP, we check station's AMPDU params else we check AP's AMPDU params. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: advertise correct beamforming information for VHTAmitkumar Karwar
Currently MU/SU beamformer and MU beamformee features are not supported. Hence this patch modifies VHT capability information accordingly. Number of sounding dimensions should be zero in this case. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: update beamforming capability field for HTAmitkumar Karwar
This patch makes sure that beamforming capability field in ht capability info gets filled if hardware supports the feature. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: don't leak DMA command skbuffsAaron Durbin
The current mwifiex pcie driver assumed that it would get its cmdrsp_complete() callback called before another command was sent to unmap the command's skbuff. However, that is not true. The mwifiex_check_ps_cond() will send a sleep command to the card without having adapter->curr_cmd set. Within the workqueue's state machine the adapter's state would be set to allow commands (curr_cmd = NULL && cmd_sent = false) after having receieved the response from the sleep command. The card->cmd_buf would then be overridden with the new command but the first command's skbuff was not unmapped. This leaks mapped skbuffs when a bounce buffer is employed. To rectify this unmap the card->cmd_buf when the response is received from the card instead of waiting for the cmdrsp_complete() callback. Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Stewart <pstew@chromium.org> Reviewed-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: balance dma map/unmap sizesAaron Durbin
Depending on the underlying DMA implementation its not possible to partially unmap DMA buffers. Moreover its not possible to understand the intent of passing 0 as the size to dma unmap. The intent of this driver is unmap the entire skb buffer. The only way to ensure that the size matches on unmap is to store both the dma address and the size in the skb ca field. Introduce a mwifiex_dma_mapping structure which tracks the dma address and the size. Additionally, provide a mwifiex_unmap_pci_memory() that utilizes the new structure. This also provide symmetry within the internal API. Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Stewart <pstew@chromium.org> Reviewed-by: Avinash Patil <patila@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: implement extended scan featureAmitkumar Karwar
In extended scan, host gets scan results through one or multiple events instead of scan command response. Host will send next scan command when all the events are received. Legacy scan sometimes truncates scan results in a noisy environment due to buffer length limitation. This issue is addressed in extended scan. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: separate out next scan command queueing logicAmitkumar Karwar
This new function will be useful later for extended scan feature. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: separate out response buffer parsing codeAmitkumar Karwar
This new function will be useful later for extended scan feature. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: change beacon parameter structureAmitkumar Karwar
'mwifiex_bcn_param' structure contains five parameters which are present in beacon buffer in case of legacy scan. 'rssi' field won't be there in this buffer for extended scan. Hence 'bssid' and 'rssi' are removed from the structure and it is renamed as 'mwifiex_fixed_bcn_param' so that we can have common parsing logic later for both. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: remove unsupported code in 11acBing Zhao
bit12 in fw_cap_info is for testing only. Remove all related code. Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: improve readability in 11ac mcsmap to maxrate conversionBing Zhao
1) rename max_mcs to mcs; 2) initialize 'i' and 'nss' as 1 instead of 0 in nss lookup; 3) use GET_VHTNSSMCS(mcs_map, nss) macro; 4) use IEEE80211_VHT_MCS_* definitions instead of hard coding Reported-by: Paul Stewart <pstew@chromium.org> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: make 11ac mcs rate tables global and constBing Zhao
Remove these local array variables and define them as static const array in global space. The duplicated mcs_rate table is removed automatically with this change. Reported-by: Paul Stewart <pstew@chromium.org> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12mwifiex: make use of IEEE80211_VHT_MCS_NOT_SUPPORTEDBing Zhao
Remove driver's macro and use ieee80211's definition instead Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2014-02-12ath9k: Calculate IQ-CAL medianSujith Manoharan
This patch adds a routine to calculate the median IQ correction values for AR955x, which is used for outlier detection. The normal method which is used for all other chips is bypassed for AR955x. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-17 00:31:29 +0000