aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* brcmfmac: determine host controller related variables during probeArend van Spriel2013-10-18
| | | | | | | | | | | | Instead of determining the limits for scatter-gather MMC transfer request upon each transmit it is now determined during the probe of the SDIO function. Reviewed-by: Franky Lin <frankyl@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmfmac: rename variable max_seg_sz to max_seg_cnt for clarityArend van Spriel2013-10-18
| | | | | | | | | | | | The variable max_seg_sz in brcmf_sdio_buffrw() respresents the maximum number of buffers that can be sent in one MMC transfer request. Rename it to max_seg_cnt to avoid confusion. Reviewed-by: Franky Lin <frankyl@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmfmac: add tracepoint for capturing the SDPCM headerArend van Spriel2013-10-18
| | | | | | | | | | | Having the SDPCM header information in the traces is a valuable piece of information. Reviewed-by: Franky Lin <frankyl@broadcom.com> Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmfmac: store address in trace_brcmf_hexdump()Arend van Spriel2013-10-18
| | | | | | | | | | The trace function trace_brcmf_hexdump() stores the length, but having the address of the buffer being dumped helps putting it in context. Reviewed-by: Franky Lin <frankyl@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath9k: add TX99 supportLuis R. Rodriguez2013-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TX99 support enables Specific Absorption Rate (SAR) testing. SAR is the unit of measurement for the amount of radio frequency(RF) absorbed by the body when using a wireless device. The RF exposure limits used are expressed in the terms of SAR, which is a measure of the electric and magnetic field strength and power density for transmitters operating at frequencies from 300 kHz to 100 GHz. Regulatory bodies around the world require that wireless device be evaluated to meet the RF exposure limits set forth in the governmental SAR regulations. In the examples below, for more bit rate options see the iw TX bitrate setting documentation: http://wireless.kernel.org/en/users/Documentation/iw#Modifying_transmit_bitrates Example usage: iw phy phy0 interface add moni0 type monitor ip link set dev moni0 up iw dev moni0 set channel 36 HT40+ iw set bitrates mcs-5 4 echo 10 > /sys/kernel/debug/ieee80211/phy0/ath9k/tx99_power echo 1 > /sys/kernel/debug/ieee80211/phy0/ath9k/tx99 Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath9k: check for NULL rate when using ieee80211_get_rts_cts_rate()Luis R. Rodriguez2013-10-18
| | | | | | | | | ieee80211_get_rts_cts_rate() can return NULL, so don't rely on its members when it does return NULL. Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath: add support for proper dynamic regulatory hintsLuis R. Rodriguez2013-10-18
| | | | | | | | | | | This enables support for dynamic user regulatory hints. This is enabled only when CFG80211_CERTIFICATION_ONUS is selected. For US and JP this is explicitly disabled unless the systems are being used for strict controlled testing. Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath: split user and driver reguluatory hint parsingLuis R. Rodriguez2013-10-18
| | | | | | | | | On the regulatory notifier split up the parsing of the hints coming from drivers or user. We'll treat these separately. Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath: move common dynamic regulatory domain setting to a helperLuis R. Rodriguez2013-10-18
| | | | | | | | This moves the dynamic regulatory domain selection code into a helper. Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* cfg80211: export reg_initiator_name()Luis R. Rodriguez2013-10-18
| | | | | | | | Drivers can now use this to parse the regulatory request and be more verbose when needed. Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rt2x00: rt2800lib: autodetect 5GHz band supportGabor Juhos2013-10-18
| | | | | | | | | | | | | | If the RF chip supports more than 14 channels that indirectly means that it supports the 5GHz band. Use this fact to enable 5GHz band support instead of setting SUPPORT_BAND_5GHZ separately for each RF chip. Also move the setup code of the 2GHz band to the same place. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rt2x00: rt2800lib: use switch statement for RF specific setupGabor Juhos2013-10-18
| | | | | | | | It is much more readable than multiple if-else-if statements. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* rt2x00: rt2800lib: use {tx,rx}_chain_num to avoid superfluous EEPROM accessGabor Juhos2013-10-18
| | | | | | | | | | The {rx,tx}_chain_num fields of rt2x00dev->default_ant contains the number of RX and TX chains already when the rt2800_probe_hw_mode() function runs. Use those values instead of parsing the EEPROM configuration values again. Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath9k/ath: move dfs pattern detector to athJanusz Dziedzic2013-10-18
| | | | | | | | | | Move the DFS pattern detector code to the ath module so the other Atheros drivers can make us of it. This makes no functional changes. Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath9k: dfs use CFG80211_CERTIFICATION_ONUS flagJanusz Dziedzic2013-10-18
| | | | | | | | | | | Use CFG80211_CERTIFICATION_ONUS flag in the DFS detector code. This is required as a preparation for moving DFS detector code from ath9k to ath module. Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath9k: dfs move ath_dfs_pool_statsJanusz Dziedzic2013-10-18
| | | | | | | | | Move ath_dfs_pool_stats to dfs_pattern_detector code to be not specyfic only for ath9k. Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath9k: dfs kill ath9k specyfic codeJanusz Dziedzic2013-10-18
| | | | | | | | | Kill of using ath9k_hw_common() function in dfs detector code. Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Reviewed-by: Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* libertas: move firmware lifetime handling to firmware.cDan Williams2013-10-18
| | | | | | | | | | | | | Previously, each bus type was responsible for freeing the firmware structure, but some did that badly. Move responsibility for freeing firmware into firmware.c so that it's done once and correctly, instead of happening in multiple places in bus-specific code. This fixes a use-after-free bug found by Dr. H. Nikolaus Schaller where the SDIO code forgot to NULL priv->helper_fw after freeing it. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath9k: add HT40 spectral scan capabilityLorenzo Bianconi2013-10-18
| | | | | | | | | | Add spectral scan feature on HT40 channels for ath9k. This patch extends previous capability added by Simon Wunderlich Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> Reviewed-by: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de> Tested-by: Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath9k: add noise floor parameter to ath9k_hw_getchan_noiseLorenzo Bianconi2013-10-18
| | | | | | | | | | Add nf parameter to ath9k_hw_getchan_noise() in order to compute NF for EXT chains with the same scale of noise floor calculated on CTL chains. ath9k_hw_getchan_noise() will be used in ath_process_fft() for spectral scan on HT40 channels Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Merge tag 'nfc-next-3.13-1' of ↵John W. Linville2013-10-18
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next Samuel Ortiz <sameo@linux.intel.com> says: "This is the first NFC pull request for the 3.13 kernel. It's a fairly big one, with the following highlights: - NFC digital layer implementation: Most NFC chipsets implement the NFC digital layer in firmware, but others have more basic functionalities and expect the host to implement the digital layer. This layer sits below the NFC core. - Sony's port100 support: This is "soft" NFC USB dongle that expects the digital layer to be implemented on the host. This is the first user of our NFC digital stack implementation. - Secure element API: We now provide a netlink API for enabling, disabling and discovering NFC attached (embedded or UICC ones) secure elements. With some userspace help, this allows us to support NFC payments. Only the pn544 driver currently supports that API. - NCI SPI fixes and improvements: In order to support NCI devices over SPI, we fixed and improved our NCI/SPI implementation. The currently most deployed NFC NCI chipset, Broadcom's bcm2079x, supports that mode and we're planning to use our NCI/SPI framework to implement a driver for it. - pn533 fragmentation support in target mode: This was the only missing feature from our pn533 impementation. We now support fragmentation in both Tx and Rx modes, in target mode." Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * NFC: Fix SE API related sparse warningSamuel Ortiz2013-10-07
| | | | | | | | | | | | | | | | | | | | se_io_cb can be declared static. This fixes the following sparse warning: net/nfc/netlink.c:1287:6: warning: symbol 'se_io_cb' was not declared. Should it be static? Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: port100: Add target mode supportThierry Escande2013-10-07
| | | | | | | | | | | | | | | | | | | | | | | | | | This implements the target NFC digital operations tg_configure_hw(), tg_listen(), tg_listen_mdaa(), and tg_send_cmd(). The target mode supports NFC-A technology at 106kbits/s and NFC-F technologies at 212 and 424kbits/s. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Cc: Stephen Tiedemann <stephen.tiedemann@gmail.com> Tested-by: Cho, Yu-Chen <acho@suse.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: port100: Add initiator mode supportThierry Escande2013-10-07
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements the initiator NFC operations in_configure_hw() and in_send_cmd(). It also implements the switch_rf() operation. The initiator mode supports NFC-A technology at 106kbits/s and NFC-F technologies at 212 and 424kbits/s. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Cc: Stephen Tiedemann <stephen.tiedemann@gmail.com> Tested-by: Cho, Yu-Chen <acho@suse.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: port100: Commands mechanism implementationThierry Escande2013-10-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements the command handling mechanism. The digital stack serializes all commands sent to the driver. This means that the digital stack waits for the reply of the current command before sending a new one. So there is no command queue managed at driver level. All Port-100 commands are asynchronous. If the command has been sent successfully to the device, it replies with an ACK frame. Then the command response is received (or actually no-response in case of timeout or error) and a command complete work on the system workqueue is responsible for sending the response (or the error) back to the digital stack. The digital stack requires some commands to be synchronous, mainly hardware configuration ones. These commands use the asynchronous command path but are made synchronous by using a completion object. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Cc: Stephen Tiedemann <stephen.tiedemann@gmail.com> Tested-by: Cho, Yu-Chen <acho@suse.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: Sony Port-100 Series driverThierry Escande2013-10-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for the Sony NFC USB dongle RC-S380, based on the Port-100 chip. This dongle is an analog frontend and does not implement the digital layer. This driver uses the nfc_digital module which is an implementation of the NFC Digital Protocol stack. This patch is a skeleton. It only registers the dongle against the NFC digital protocol stack. All NFC digital operation functions are stubbed out. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Cc: Stephen Tiedemann <stephen.tiedemann@gmail.com> Tested-by: Cho, Yu-Chen <acho@suse.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: pn533: Target mode Tx fragmentation supportOlivier Guiter2013-09-25
| | | | | | | | | | | | | | | | | | | | | | In target mode, when we want to send frames larger than the max length (PN533_CMD_DATAEXCH_DATA_MAXLEN), we have to split the frame in smaller chunks and send them, using a specific working queue, with the TgSetMetaData command. TgSetMetaData sets his own MI bit in the PFB. The last chunk is sent using the TgSetData command. Signed-off-by: Olivier Guiter <olivier.guiter@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: pn533: Add support for incoming fragmented frame in target modeOlivier Guiter2013-09-25
| | | | | | | | | | | | | | | | | | | | This code processes, for Target Mode, incoming fragmented frames. If the MI bit is present, we start a working queue to grab and aggregate all the parts (using TmGetData between each parts). On the last one, as there's no more MI bit, we jump on the usual behavior. Signed-off-by: Olivier Guiter <olivier.guiter@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: pn533: Add MI/TG bits only when in Initiator modeOlivier Guiter2013-09-25
| | | | | | | | | | | | | | | | | | | | The fragmentation routine (used to split big frames) could be used in target or initiator mode (TgSetMetaData vs InDataExchange), but the MI/TG bytes are not needed in target mode (TgSetMetaData), so we add a check on the mode Signed-off-by: Olivier Guiter <olivier.guiter@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: NCI: Modify NCI SPI to implement CS/INT handshake per the specEric Lapuyade2013-09-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The NFC Forum NCI specification defines both a hardware and software protocol when using a SPI physical transport to connect an NFC NCI Chipset. The hardware requirement is that, after having raised the chip select line, the SPI driver must wait for an INT line from the NFC chipset to raise before it sends the data. The chip select must be raised first though, because this is the signal that the NFC chipset will detect to wake up and then raise its INT line. If the INT line doesn't raise in a timely fashion, the SPI driver should abort operation. When data is transferred from Device host (DH) to NFC Controller (NFCC), the signaling sequence is the following: Data Transfer from DH to NFCC • 1-Master asserts SPI_CSN • 2-Slave asserts SPI_INT • 3-Master sends NCI-over-SPI protocol header and payload data • 4-Slave deasserts SPI_INT • 5-Master deasserts SPI_CSN When data must be transferred from NFCC to DH, things are a little bit different. Data Transfer from NFCC to DH • 1-Slave asserts SPI_INT -> NFC chipset irq handler called -> process reading from SPI • 2-Master asserts SPI_CSN • 3-Master send 2-octet NCI-over-SPI protocol header • 4-Slave sends 2-octet NCI-over-SPI protocol payload length • 5-Slave sends NCI-over-SPI protocol payload • 6-Master deasserts SPI_CSN In this case, SPI driver should function normally as it does today. Note that the INT line can and will be lowered anytime between beginning of step 3 and end of step 5. A low INT is therefore valid after chip select has been raised. This would be easily implemented in a single driver. Unfortunately, we don't write the SPI driver and I had to imagine some workaround trick to get the SPI and NFC drivers to work in a synchronized fashion. The trick is the following: - send an empty spi message: this will raise the chip select line, and send nothing. We expect the /CS line will stay arisen because we asked for it in the spi_transfer cs_change field - wait for a completion, that will be completed by the NFC driver IRQ handler when it knows we are in the process of sending data (NFC spec says that we use SPI in a half duplex mode, so we are either sending or receiving). - when completed, proceed with the normal data send. This has been tested and verified to work very consistently on a Nexus 10 (spi-s3c64xx driver). It may not work the same with other spi drivers. The previously defined nci_spi_ops{} whose intended purpose were to address this problem are not used anymore and therefore totally removed. The nci_spi_send() takes a new optional write_handshake_completion completion pointer. If non NULL, the nci spi layer will run the above trick when sending data to the NFC Chip. If NULL, the data is sent normally all at once and it is then the NFC driver responsibility to know what it's doing. Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: NCI: nci_spi_recv_frame() now returns (not forward) the read frameEric Lapuyade2013-09-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, nci_spi_recv_frame() would directly transmit incoming frames to the NCI Core. However, it turns out that some NFC NCI Chips will add additional proprietary headers that must be handled/removed before NCI Core gets a chance to handle the frame. With this modification, the chip phy or driver are now responsible to transmit incoming frames to NCI Core after proper treatment, and NCI SPI becomes a driver helper instead of sitting between the NFC driver and NCI Core. As a general rule in NFC, *_recv_frame() APIs are used to deliver an incoming frame to an upper layer. To better suit the actual purpose of nci_spi_recv_frame(), and go along with its nci_spi_send() counterpart, the function is renamed to nci_spi_read() The skb is returned as the function result Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: NCI: zero struct spi_transfer variables before usageEric Lapuyade2013-09-25
| | | | | | | | | | | | | | | | | | | | Using ARM compiler, and without zero-ing spi_transfer, spi-s3c64xx driver would issue abnormal errors due to bpw field value being set to unexpected value. This structure MUST be set to all zeros except for those field specifically used. Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: netlink: SE API implementationSamuel Ortiz2013-09-24
| | | | | | | | | | | | | | | | Implementation of the NFC_CMD_SE_IO command for sending ISO7816 APDUs to NFC embedded secure elements. The reply is forwarded to user space through NFC_CMD_SE_IO as well. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: Define secure element IO API and commandsSamuel Ortiz2013-09-24
| | | | | | | | | | | | | | | | | | | | | | In order to send and receive ISO7816 APDUs to and from NFC embedded secure elements, we define a specific netlink command. On a typical SE use case, host applications will send very few APDUs (Less than 10) per transaction. This is why we decided to go for a simple netlink API. Defining another NFC socket protocol for such low traffic would have been overengineered. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: Document NFC targets sens_res fieldSamuel Ortiz2013-09-24
| | | | | | | | | | | | | | | | SENS_RES has no specific endiannes attached to it, the kernel ABI is the following one: Byte 2 (As described by the NFC Forum Digital spec) is the u16 most significant byte. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: Fix sens_res endiannes handlingThierry Escande2013-09-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was triggered by the following sparse warning: net/nfc/digital_technology.c:272:20: sparse: cast to restricted __be16 The SENS_RES response must be treated as __le16 with the first byte received as LSB and the second one as MSB. This is the way neard handles it in the sens_res field of the nfc_target structure which is treated as u16 in cpu endianness. So le16_to_cpu() is used on the received SENS_RES instead of memcpy'ing it. SENS_RES test macros have also been fixed accordingly. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: rawsock: Fix a memory leakThierry Escande2013-09-24
| | | | | | | | | | | | | | | | In the rawsock data exchange callback, the sk_buff is not freed on error. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: pn533: Staticize local symbolsSachin Kamat2013-09-24
| | | | | | | | | | | | | | Local symbols used only in this file are made static. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: nfcwilink: Remove redundant dev_set_drvdataSachin Kamat2013-09-24
| | | | | | | | | | | | | | | | Driver core sets driver data to NULL upon failure or remove. Cc: Ilan Elias <ilane@ti.com> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: digital_tg_send_sensf_res() can be staticFengguang Wu2013-09-24
| | | | | | | | | | | | | | | | | | | | | | Fixes sparse hint: net/nfc/digital_technology.c:640:5: sparse: symbol 'digital_tg_send_sensf_res' was not declared. Should it be static? Cc: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: Add newline to pr_* callsSamuel Ortiz2013-09-24
| | | | | | | | | | | | | | | | We do not add the newline to the pr_fmt macro, in order to give more flexibility to the caller and to keep the logging style consistent with the rest of the NFC and kernel code. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: Remove PR_ERR and PR_DBG macrosSamuel Ortiz2013-09-24
| | | | | | | | | | | | | | They can be replaced by the standard pr_err and pr_debug one after defining the right pr_fmt macro. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * 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>
generated by cgit v1.2.2 (git 2.25.0) at 2025-08-23 01:37:20 -0400