aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
...
| * NFC: NCI: Store the spi device pointer from the spi instanceEric Lapuyade2013-09-24
| | | | | | | | | | | | | | | | | | Storing the spi device was forgotten in the original implementation, which would pretty obviously cause some kind of serious crash when actually trying to send something through that device. Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC Digital: Add target NFC-DEP supportThierry Escande2013-09-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for NFC-DEP target mode for NFC-A and NFC-F technologies. If the driver provides it, the stack uses an automatic mode for technology detection and automatic anti-collision. Otherwise the stack tries to use non-automatic synchronization and listens for SENS_REQ and SENSF_REQ commands. The detection, activation, and data exchange procedures work exactly the same way as in initiator mode, as described in the previous commits, except that the digital stack waits for commands and sends responses back to the peer device. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC Digital: Add initiator NFC-DEP supportThierry Escande2013-09-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for NFC-DEP protocol in initiator mode for NFC-A and NFC-F technologies. When a target is detected, the process flow is as follow: For NFC-A technology: 1 - The digital stack receives a SEL_RES as the reply of the SEL_REQ command. 2 - If b7 of SEL_RES is set, the peer device is configure for NFC-DEP protocol. NFC core is notified through nfc_targets_found(). Execution continues at step 4. 3 - Otherwise, it's a tag and the NFC core is notified. Detection ends. 4 - The digital stacks sends an ATR_REQ command containing a randomly generated NFCID3 and the general bytes obtained from the LLCP layer of NFC core. For NFC-F technology: 1 - The digital stack receives a SENSF_RES as the reply of the SENSF_REQ command. 2 - If B1 and B2 of NFCID2 are 0x01 and 0xFE respectively, the peer device is configured for NFC-DEP protocol. NFC core is notified through nfc_targets_found(). Execution continues at step 4. 3 - Otherwise it's a type 3 tag. NFC core is notified. Detection ends. 4 - The digital stacks sends an ATR_REQ command containing the NFC-F NFCID2 as NFCID3 and the general bytes obtained from the LLCP layer of NFC core. For both technologies: 5 - The digital stacks receives the ATR_RES response containing the NFCID3 and the general bytes of the peer device. 6 - The digital stack notifies NFC core that the DEP link is up through nfc_dep_link_up(). 7 - The NFC core performs data exchange through tm_transceive(). 8 - The digital stack sends a DEP_REQ command containing an I PDU with the data from NFC core. 9 - The digital stack receives a DEP_RES command 10 - If the DEP_RES response contains a supervisor PDU with timeout extension request (RTOX) the digital stack sends a DEP_REQ command containing a supervisor PDU acknowledging the RTOX request. The execution continues at step 9. 11 - If the DEP_RES response contains an I PDU, the response data is passed back to NFC core through the response callback. The execution continues at step 8. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC Digital: Add NFC-F technology supportThierry Escande2013-09-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds polling support for NFC-F technology at 212 kbits/s and 424 kbits/s. A user space application like neard can send type 3 tag commands through the NFC core. Process flow for NFC-F detection is as follow: 1 - The digital stack sends the SENSF_REQ command to the NFC device. 2 - A peer device replies with a SENSF_RES response. 3 - The digital stack notifies the NFC core of the presence of a target in the operation field and passes the target NFCID2. This also adds support for CRC calculation of type CRC-F. The CRC calculation is handled by the digital stack if the NFC device doesn't support it. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC Digital: Add NFC-A technology supportThierry Escande2013-09-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for NFC-A technology at 106 kbits/s. The stack can detect tags of type 1 and 2. There is no support for collision detection. Tags can be read and written by using a user space application or a daemon like neard. The flow of polling operations for NFC-A detection is as follow: 1 - The digital stack sends the SENS_REQ command to the NFC device. 2 - The NFC device receives a SENS_RES response from a peer device and passes it to the digital stack. 3 - If the SENS_RES response identifies a type 1 tag, detection ends. NFC core is notified through nfc_targets_found(). 4 - Otherwise, the digital stack sets the cascade level of NFCID1 to CL1 and sends the SDD_REQ command. 5 - The digital stack selects SEL_CMD and SEL_PAR according to the cascade level and sends the SDD_REQ command. 4 - The digital stack receives a SDD_RES response for the cascade level passed in the SDD_REQ command. 5 - The digital stack analyses (part of) NFCID1 and verify BCC. 6 - The digital stack sends the SEL_REQ command with the NFCID1 received in the SDD_RES. 6 - The peer device replies with a SEL_RES response 7 - Detection ends if NFCID1 is complete. NFC core notified of new target by nfc_targets_found(). 8 - If NFCID1 is not complete, the cascade level is incremented (up to and including CL3) and the execution continues at step 5 to get the remaining bytes of NFCID1. Once target detection is done, type 1 and 2 tag commands must be handled by a user space application (i.e neard) through the NFC core. Responses for type 1 tag are returned directly to user space via NFC core. Responses of type 2 commands are handled differently. The digital stack doesn't analyse the type of commands sent through im_transceive() and must differentiate valid responses from error ones. The response process flow is as follow: 1 - If the response length is 16 bytes, it is a valid response of a READ command. the packet is returned to the NFC core through the callback passed to im_transceive(). Processing stops. 2 - If the response is 1 byte long and is a ACK byte (0x0A), it is a valid response of a WRITE command for example. First packet byte is set to 0 for no-error and passed back to the NFC core. Processing stops. 3 - Any other response is treated as an error and -EIO error code is returned to the NFC core through the response callback. Moreover, since the driver can't differentiate success response from a NACK response, the digital stack has to handle CRC calculation. Thus, this patch also adds support for CRC calculation. If the driver doesn't handle it, the digital stack will calculate CRC and will add it to sent frames. CRC will also be checked and removed from received frames. Pointers to the correct CRC calculation functions are stored in the digital stack device structure when a target is detected. This avoids the need to check the current target type for every call to im_transceive() and for every response received from a peer device. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC Digital: Implement driver commands mechanismThierry Escande2013-09-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements the mechanism used to send commands to the driver in initiator mode through in_send_cmd(). Commands are serialized and sent to the driver by using a work item on the system workqueue. Responses are handled asynchronously by another work item. Once the digital stack receives the response through the command_complete callback, the next command is sent to the driver. This also implements the polling mechanism. It's handled by a work item cycling on all supported protocols. The start poll command for a given protocol is sent to the driver using the mechanism described above. The process continues until a peer is discovered or stop_poll is called. This patch implements the poll function for NFC-A that sends a SENS_REQ command and waits for the SENS_RES response. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: Digital Protocol stack implementationThierry Escande2013-09-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the initial commit of the NFC Digital Protocol stack implementation. It offers an interface for devices that don't have an embedded NFC Digital protocol stack. The driver instantiates the digital stack by calling nfc_digital_allocate_device(). Within the nfc_digital_ops structure, the driver specifies a set of function pointers for driver operations. These functions must be implemented by the driver and are: in_configure_hw: Hardware configuration for RF technology and communication framing in initiator mode. This is a synchronous function. in_send_cmd: Initiator mode data exchange using RF technology and framing previously set with in_configure_hw. The peer response is returned through callback cb. If an io error occurs or the peer didn't reply within the specified timeout (ms), the error code is passed back through the resp pointer. This is an asynchronous function. tg_configure_hw: Hardware configuration for RF technology and communication framing in target mode. This is a synchronous function. tg_send_cmd: Target mode data exchange using RF technology and framing previously set with tg_configure_hw. The peer next command is returned through callback cb. If an io error occurs or the peer didn't reply within the specified timeout (ms), the error code is passed back through the resp pointer. This is an asynchronous function. tg_listen: Put the device in listen mode waiting for data from the peer device. This is an asynchronous function. tg_listen_mdaa: If supported, put the device in automatic listen mode with mode detection and automatic anti-collision. In this mode, the device automatically detects the RF technology and executes the anti-collision detection using the command responses specified in mdaa_params. The mdaa_params structure contains SENS_RES, NFCID1, and SEL_RES for 106A RF tech. NFCID2 and system code (sc) for 212F and 424F. The driver returns the NFC-DEP ATR_REQ command through cb. The digital stack deducts the RF tech by analyzing the SoD of the frame containing the ATR_REQ command. This is an asynchronous function. switch_rf: Turns device radio on or off. The stack does not call explicitly switch_rf to turn the radio on. A call to in|tg_configure_hw must turn the device radio on. abort_cmd: Discard the last sent command. Then the driver registers itself against the digital stack by using nfc_digital_register_device() which in turn registers the digital stack against the NFC core layer. The digital stack implements common NFC operations like dev_up(), dev_down(), start_poll(), stop_poll(), etc. This patch is only a skeleton and NFC operations are just stubs. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: pn533: Start listen timer from start_pollSamuel Ortiz2013-09-24
| | | | | | | | | | | | | | | | | | If we start the polling loop from a listening cycle, we need to start the corresponding timer as well. This bug showed up after commit dfccd0f5 as it was impossible to start from a listening cycle before it. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: pn533: Send ATR_REQ directly for active device detectionSamuel Ortiz2013-09-24
| | | | | | | | | | | | | | | | In order to improve active devices detection, we send an ATR_REQ between each passive detection cycle. Without this algorithm, Android 4.3 based devices running the Broadcom stack are hardly detected. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: Set active target upon DEP up event receptionSamuel Ortiz2013-09-24
| | | | | | | | | | | | | | | | | | | | As we can potentially get DEP up events without having sent a netlink command, we need to set the active target properly from dep_link_is_up. Spontaneous DEP up events can come from devices that detected an active p2p target. In that case there is no need to call the netlink DEP up command as the link is already up and running. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: NCI: Simplify NCI SPI to become a simple framing/checking layerEric Lapuyade2013-09-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NCI SPI layer should not manage the nci dev, this is the job of the nci chipset driver. This layer should be limited to frame/deframe nci packets, and optionnaly check integrity (crc) and manage the ack/nak protocol. The NCI SPI must not be mixed up with an NCI dev. spi_[dev|device] are therefore renamed to a simple spi for more clarity. The header and crc sizes are moved to nci.h so that drivers can use them to reserve space in outgoing skbs. nci_spi_send() is exported to be accessible by drivers. Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: Move struct nfc_phy_ops out of HCI up to nfc core levelEric Lapuyade2013-09-24
| | | | | | | | | | | | | | | | struct nfc_phy_ops is not an HCI structure only, it can also be used by NCI or direct NFC Core drivers. Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: NCI: Rename spi ndev -> nsdev and nci_dev -> ndev for consistencyEric Lapuyade2013-09-24
| | | | | | | | | | | | | | | | | | An hci dev is an hdev. An nci dev is an ndev. Calling an nci spi dev an ndev is misleading since it's not the same thing. The nci dev contained in the nci spi dev is also named inconsistently. Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: NCI: Fix wrong allocation size in nci_spi_allocate_device()Eric Lapuyade2013-09-24
| | | | | | | | | | Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: Standardize logging styleJoe Perches2013-09-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Use standardized styles to minimize coding defects. Always use nfc_<level> where feasible. Add \n to formats where appropriate. Typo "it it" correction. Add #define pr_fmt where appropriate. Remove function tracing logging messages. Remove OOM messages. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: Convert nfc_dev_info and nfc_dev_err to nfc_<level>Joe Perches2013-09-24
| | | | | | | | | | | | | | | | | | | | | | Use a more standard kernel style macro logging name. Standardize the spacing of the "NFC: " prefix. Add \n to uses, remove from macro. Fix the defective uses that already had a \n. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: Replace nfc_dev_dbg with dev_dbgJoe Perches2013-09-24
| | | | | | | | | | | | | | | | | | | | | | Use the generic kernel function instead of a home-grown one that does the same thing. Add \n to uses not at the macro. Don't add \n where the nfc_dev_dbg macro mistakenly had them already. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: pn544: Add SE enable/disable operationArron Wang2013-09-24
| | | | | | | | | | | | | | | | | | To enable the UICC secure element, we first enable the UICC gate list in order for the SE to be able to use all RF technologies. For the embedded SE, we just turn the eSE default mode to ON. Signed-off-by: Arron Wang <arron.wang@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: Export nfc_find_se()Arron Wang2013-09-24
| | | | | | | | | | | | | | This will be needed by all NFC driver implementing the SE ops. Signed-off-by: Arron Wang <arron.wang@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: pn544: Add SE discover operationArron Wang2013-09-24
| | | | | | | | | | | | | | | | | | | | For the SWP secure element, we send the proprietary SELF_TEST_SWP command and check the response. For the WI secure element, we simply try to switch to the default embedded SE mode. If that works, it means we have an embedded SE. Signed-off-by: Arron Wang <arron.wang@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* | Merge branch 'for-john' of ↵John W. Linville2013-10-18
|\ \ | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next
| * | iwlwifi: mvm: fix operator precedenceDavid Spinadel2013-10-18
| | | | | | | | | | | | | | | | | | | | | | | | Integers need to be multiplied before division. Signed-off-by: David Spinadel <david.spinadel@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | iwlwifi: mvm: fix fw_rx_stats debugfs entryLuciano Coelho2013-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The fw_rx_stats entry in debugfs was getting truncated because the internal buffer used to hold the string was too short. The calculation of the needed buffer size was rather bogus. Simplify the calculation by multiplying the number of entries in the entire structure by the size of each data line and adding the size of the header lines. Additionally, add the mac_id value, which was missing. Signed-off-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | iwlwifi: mvm: BT Coex - enable Tx power based on BT statusEmmanuel Grumbach2013-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The activity grading indication from the firmware should not be used in this case, but the bt_status in the firwmare notification. Fix that. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | iwlwifi: mvm: BT Coex - always set mandatory fieldsEmmanuel Grumbach2013-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The firmware always expects the Coex Mode to be set. Moreover, the firmware expects bit 0 is the valid bits to be set all the times. I misunderstood the API and didn't set these bits when commands are sent to update the paramters of the Coex. As a result, the firmware understood that the BT Coex was disabled (Coex mode = 0) and ignored all the updates (valid bit 0 clear). Fix that. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | iwlwifi: mvm: NVM - increase max section sizeIdan Kahlon2013-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Section size limitation to 6000 is incorrect. NVM file need to support bigger sections in order to support PAPD tables. Signed-off-by: Idan Kahlon <idanx.kahlon@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Maor Perez <maorx.perez@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | iwlwifi: support Signed firmware image and Dual CPUsEran Harary2013-10-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Support Signed firmware based on code signing system (CSS) protocol and dual CPUs download, the code recognize if there are more than one CPU and if we need to operate the signed protocol according to the ucode binary image Signed-off-by: Eran Harary <eran.harary@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | iwlwifi: mvm: add IBSS supportJohannes Berg2013-10-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the firmware level, IBSS support has similar programming requirements as AP/GO support, so use the same functions with just small differences. With IBSS only a single virtual interface can be used, so no changes in the advertised interface combinations are needed. For now, don't use hardware crypto for the GTKs in IBSS mode, the firmware should support it though. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | iwlwifi: Support 7265 devicesEran Harary2013-10-11
| | | | | | | | | | | | | | | | | | | | | | | | 7265 is a very similar device to 7260, so just add the definitions based on 7260 for it. Signed-off-by: Eran Harary <eran.harary@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | iwlwifi: mvm: BT Coex - update integration with rate controlEmmanuel Grumbach2013-10-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | Remove code that is not needed and always allow MIMO when in tight mode. In loose mode, we should avoid MIMO since BT can use the other antenna to Rx while we Tx. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | iwlwifi: mvm: BT Coex - remove duplicate code in rate controlEmmanuel Grumbach2013-10-11
| | | | | | | | | | | | | | | | | | | | | | | | The code limiting the AMPDU length due to BT traffic was duplicated. Remove the redundant code. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | iwlwifi: mvm: BT Coex - start AMPDU even when BT is activeEmmanuel Grumbach2013-10-11
| | | | | | | | | | | | | | | | | | | | | | | | Tests have shown that we should start AMPDU even when BT is active. So remove that constraint. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | iwlwifi: mvm: BT Coex - tune SMPS parametersEmmanuel Grumbach2013-10-11
| | | | | | | | | | | | | | | | | | | | | | | | Tests have shown that we should go SMSP_STATIC when BT traffic is high, and stay in dynamic if BT traffic is low. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | iwlwifi: mvm: BT Coex - track bandwidth changes in HTEmmanuel Grumbach2013-10-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BT Coex needs to be updated when the bandwidth is modified by the AP. While at it, remove the vif parameter from bt_coex_vif_change since it was unused. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | iwlwifi: mvm: keep connection to AP after WoWLANJohannes Berg2013-10-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, after WoWLAN, we weren't able to keep the connection to the AP because the firmware didn't give us the right information. Since the firmware API has been changed to include all the information we need, change the driver to work with the new API (if it is available) and program all the relevant information in mac80211 to keep the connection. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | Merge remote-tracking branch 'wireless-next/master' into HEADJohannes Berg2013-10-11
| |\ \
| * | | iwlwifi: mvm: add support for NICs which have only 16 Tx queues.Eytan Lifshitz2013-10-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some NICs embedded in platforms that have only 16 Tx queues, this affect the mapping of the Tx queues. Signed-off-by: Eytan Lifshitz <eytan.lifshitz@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | | iwlwifi: mvm: prevent the NIC to be powered at driver load time.Eytan Lifshitz2013-10-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some NICs aren't allowed to be powered up at driver load time. Fix it, and move the external NVM loading from driver load time to driver up time (parsing the external nvm file remains at driver load time). Signed-off-by: Eytan Lifshitz <eytan.lifshitz@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | | iwlwifi: mvm: Add device wide power commandAlexander Bondar2013-10-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FW starts using legacy power table command (0x77) for device wide power settings. Currently this command contains only option flags field. It can configure the following: CAM (Continuous Active Mode) and POWER_SAVE_ENABLE debug option. Send this command when firmware is loaded - D0 and D3. Note: Setting this command is important to avoid unwanted FW behavior. It particularly fixes a bug when a device does not drop to low power after disassociation from AP. Signed-off-by: Alexander Bondar <alexander.bondar@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | | iwlwifi: pcie: restart the driver when a command times outEmmanuel Grumbach2013-10-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This should really not happen. If it does, restarting is the only way to recover since the driver and the firmware might very well be out of sync. Moreover, iwl_op_mode_nic_error will print data that might help debugging. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | | iwlwifi: mvm: BT Coex - set the proper LUT for single ant devicesEmmanuel Grumbach2013-10-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Single shared antenna devices need a special LUT. Address this need. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | | iwlwifi: mvm: BT Coex - don't limit agg size in loose schemeEmmanuel Grumbach2013-10-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In loose BT Coex scheme, the aggregation size doesn't need to be limited. To avoid triggering it, remove a lockdep assertion - we need to compute the AMPDU size limit from rate control code which can't take mvm->mutex. This means that there is a race but in the worst case, we will have a wrong AMPDU size limit which is not a big issue. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | | wireless: iwlwifi: remove unnecessary pci_set_drvdata()Jingoo Han2013-10-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The driver core clears the driver data to NULL after device_release or on probe failure. Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | | iwlwifi: pcie: dump_stack upon timeout of SYNC cmdEmmanuel Grumbach2013-10-02
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | | iwlwifi: mvm: change the name of init_ucode_run flagEytan Lifshitz2013-10-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In RF KILL the init ucode is running, but don't complete all its tasks, so we need to run the init ucode again. Change the flag name to init_ucode_complete, to be more appropriate. Signed-off-by: Eytan Lifshitz <eytan.lifshitz@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | | iwlwifi: mvm: implement new IPv6 offload APIJohannes Berg2013-10-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The firmware API for IPv6 NDP/NS offload has changed again. Implement support for the new API; this requires calculating the solicited node address for each "target" address as it's no longer ignored by the firmware. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | | iwlwifi: mvm: BT Coex - Correctly enable and treat rssi eventsEmmanuel Grumbach2013-10-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rssi events were enabled on interfaces using 5.2GHz. Interfaces on 5.2GHz were taken into account while determining the ACK / CTS kill mask. Fix that. The last rssi notified to BT Coex was reset every BT Coex Notification. Since we get a lot of these notifications from the firmware, we reset the rssi all the time which means that the bt_rssi_event is called all the time. Fix that by puting the rssi we pull upon BT Coex notification into iwl_mvm_vif_bf_data.last_bt_coex_event Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | | iwlwifi: mvm: BT Coex - adapt debugfs to new APIEmmanuel Grumbach2013-10-02
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | | iwlwifi: mvm: don't use reduced Tx power when not applicableEmmanuel Grumbach2013-10-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we have only one antenna for BT and WiFi, reduced Tx power is irrelevant. Also, in loose scheme, we should not use reduced Tx power nor set the control mask to Tx power. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
| * | | iwlwifi: mvm: make debugfs write() operations write up to count bytesDjalal Harouni2013-10-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some debugfs write() operations of the MVM Firmware will ignore the count argument, and will copy more bytes than what was specified. Fix this by getting the right count of bytes. This will honor restrictions put on the number of bytes to write and avoid strcmp() calls on garbage data. Signed-off-by: Djalal Harouni <tixxdz@opendz.org> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit v1.2.2 (git 2.25.0) at 2025-08-06 12:09:02 -0400