summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Bluetooth: Handle security level 4 for RFCOMM connectionsMarcel Holtmann2014-02-133-2/+15
| | | | | | | | | With the introduction of security level 4, the RFCOMM sockets need to be made aware of this new level. This change ensures that the pairing requirements are set correctly for these connections. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Handle security level 4 for L2CAP connectionsMarcel Holtmann2014-02-133-3/+19
| | | | | | | | | With the introduction of security level 4, the L2CAP sockets need to be made aware of this new level. This change ensures that the pairing requirements are set correctly for these connections. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Introduce requirements for security level 4Marcel Holtmann2014-02-133-5/+15
| | | | | | | | | | | | | | | | | | | | | | The security level 4 is a new strong security requirement that is based around 128-bit equivalent strength for link and encryption keys required using FIPS approved algorithms. Which means that E0, SAFER+ and P-192 are not allowed. Only connections created with P-256 resulting from using Secure Connections support are allowed. This security level needs to be enforced when Secure Connection Only mode is enabled for a controller or a service requires FIPS compliant strong security. Currently it is not possible to enable either of these two cases. This patch just puts in the foundation for being able to handle security level 4 in the future. It should be noted that devices or services with security level 4 requirement can only communicate using Bluetooth 4.1 controllers with support for Secure Connections. There is no backward compatibilty if used with older hardware. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Track Secure Connections support of remote devicesMarcel Holtmann2014-02-132-0/+11
| | | | | | | | | | 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>
* Bluetooth: Fix mgmt error code for negative PIN responseJohan Hedberg2014-02-131-1/+1
| | | | | | | | | | | | | 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>
* Bluetooth: Convert to use ATTRIBUTE_GROUPS macroWei Yongjun2014-02-131-16/+2Star
| | | | | | | 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>
* Bluetooth: Add support for remote OOB input of P-256 dataMarcel Holtmann2014-02-132-11/+42
| | | | | | | | | | | | 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>
* Bluetooth: Add internal function for storing P-192 and P-256 dataMarcel Holtmann2014-02-132-7/+39
| | | | | | | | | 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>
* Bluetooth: Provide remote OOB data for Secure ConnectionsMarcel Holtmann2014-02-133-13/+31
| | | | | | | | | | | | | | 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>
* Bluetooth: Add debugfs quirk for forcing Secure Connections supportMarcel Holtmann2014-02-133-3/+55
| | | | | | | | | | | | | | | | | | | 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>
* Bluetooth: Add support for local OOB data with Secure ConnectionsMarcel Holtmann2014-02-134-15/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Bluetooth: Limit acceptable link key types to only supported onesMarcel Holtmann2014-02-131-1/+1
| | | | | | | | | | 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>
* Bluetooth: Enable Secure Connection during power on if configuredMarcel Holtmann2014-02-131-0/+8
| | | | | | | | | 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>
* Bluetooth: Add management command for enabling Secure ConnectionsMarcel Holtmann2014-02-134-0/+141
| | | | | | | | | | | | | | 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>
* Bluetooth: Add flags and setting for Secure Connections supportMarcel Holtmann2014-02-133-0/+9
| | | | | | | | | 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>
* Bluetooth: Enable Authenticated Payload Timeout Expired eventMarcel Holtmann2014-02-131-0/+4
| | | | | | | | | 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>
* Bluetooth: Add support for handling P-256 derived link keysMarcel Holtmann2014-02-132-3/+6
| | | | | | | | | | 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>
* Bluetooth: Add definitions for new link key typesMarcel Holtmann2014-02-133-5/+7
| | | | | | | | | | | | | | 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>
* Bluetooth: Add HCI command definition for extended OOB dataMarcel Holtmann2014-02-131-0/+18
| | | | | | | | | | | | 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>
* Bluetooth: Add HCI command definition for Secure Connections enablingMarcel Holtmann2014-02-131-0/+11
| | | | | | | | | 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>
* Bluetooth: Add LMP feature definitions for Secure Connections supportMarcel Holtmann2014-02-132-0/+7
| | | | | | | | 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>
* Bluetooth: Fix outgoing authentication requirement checkJohan Hedberg2014-02-131-2/+5
| | | | | | | | | | | | | | | | | | | | 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>
* mwifiex: add key material v2 supportAvinash Patil2014-02-126-12/+388
| | | | | | | | | | 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>
* mwifiex: parse API version from FWAvinash Patil2014-02-124-1/+60
| | | | | | | | | 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>
* mwifiex: disable all TDLS link during disconnectionAvinash Patil2014-02-123-0/+40
| | | | | | | | | | | | 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>
* mwifiex: separate BA params for TDLS link if 11ac is supportedAvinash Patil2014-02-122-5/+38
| | | | | | | | | | | 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>
* mwifiex: add VHT support for TDLSAvinash Patil2014-02-126-7/+346
| | | | | | | | | | | | | | | 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>
* mwifiex: pass ieee80211_vht_cap to mwifiex_fill_vht_cap_tlvAvinash Patil2014-02-121-11/+12
| | | | | | | | | | 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>
* mwifiex: AMPDU support for TDLS linkAvinash Patil2014-02-125-4/+31
| | | | | | | | | | | | | 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>
* mwifiex: tdls related handling for data packets addressed to TDLS peerAvinash Patil2014-02-123-6/+48
| | | | | | | | | | | | | 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>
* mwifiex: provision for holding and restoring packets during TDLS setupAvinash Patil2014-02-124-0/+100
| | | | | | | | | | | | | | | | | | 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>
* mwifiex: add cfg80211 change_station handler supportAvinash Patil2014-02-126-1/+137
| | | | | | | | | | 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>
* mwifiex: add cfg80211 add_station handler supportAvinash Patil2014-02-124-0/+64
| | | | | | | | | | 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>
* mwifiex: add cfg80211 tdls_oper handler supportAvinash Patil2014-02-128-0/+246
| | | | | | | | | | | | 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>
* mwifiex: parse TDLS action frames during RXAvinash Patil2014-02-126-7/+160
| | | | | | | | | | 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>
* mwifiex: add tdls_mgmt handler supportAvinash Patil2014-02-128-0/+533
| | | | | | | | | | | | 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>
* mwifiex: cleanup in mwifiex_fill_cap_info()Amitkumar Karwar2014-02-124-16/+21
| | | | | | | | | | | | 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>
* mwifiex: move station list functions to common codeAvinash Patil2014-02-123-118/+124
| | | | | | | | | 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>
* mwifiex: make tos_to_tid_inv part of mwifiex_private structureAvinash Patil2014-02-124-23/+28
| | | | | | | | | | | | 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>
* mwifiex: handle AMPDU supported check for AP interfaceAvinash Patil2014-02-122-7/+21
| | | | | | | | | | | | 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>
* mwifiex: advertise correct beamforming information for VHTAmitkumar Karwar2014-02-122-2/+13
| | | | | | | | | | | | 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>
* mwifiex: update beamforming capability field for HTAmitkumar Karwar2014-02-122-0/+7
| | | | | | | | | 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>
* mwifiex: don't leak DMA command skbuffsAaron Durbin2014-02-121-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* mwifiex: balance dma map/unmap sizesAaron Durbin2014-02-122-74/+72Star
| | | | | | | | | | | | | | | | | | | | | | 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>
* mwifiex: implement extended scan featureAmitkumar Karwar2014-02-128-8/+255
| | | | | | | | | | | | | | 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>
* mwifiex: separate out next scan command queueing logicAmitkumar Karwar2014-02-121-62/+71
| | | | | | | | | 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>
* mwifiex: separate out response buffer parsing codeAmitkumar Karwar2014-02-121-146/+163
| | | | | | | | | 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>
* mwifiex: change beacon parameter structureAmitkumar Karwar2014-02-122-13/+16
| | | | | | | | | | | | | | '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>
* mwifiex: remove unsupported code in 11acBing Zhao2014-02-126-28/+17Star
| | | | | | | | 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>
* mwifiex: improve readability in 11ac mcsmap to maxrate conversionBing Zhao2014-02-121-13/+13
| | | | | | | | | | | 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>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-13 02:45:09 +0200