summaryrefslogtreecommitdiffstats
path: root/include/net/nfc (follow)
Commit message (Collapse)AuthorAgeFilesLines
* NFC: nci: Add support for proprietary RF ProtocolsChristophe Ricard2014-09-241-4/+5
| | | | | | | | | | | | | | | | | In NFC Forum NCI specification, some RF Protocol values are reserved for proprietary use (from 0x80 to 0xfe). Some CLF vendor may need to use one value within this range for specific technology. Furthermore, some CLF may not becompliant with NFC Froum NCI specification 2.0 and therefore will not support RF Protocol value 0x06 for PROTOCOL_T5T as mention in a draft specification and in a recent push. Adding get_rf_protocol handle to the nci_ops structure will help to set the correct technology to target. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: NCI: Add support of ISO15693Vincent Cuissard2014-09-011-3/+13
| | | | | | | | | Update nci.h to respect latest NCI specification proposal (stop using proprietary opcodes). Handle ISO15693 parameters in NCI_RF_ACTIVATED_NTF handler. Signed-off-by: Vincent Cuissard <cuissard@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Add 'tg_listen_md' and 'tg_get_rf_tech' driver hooksMark A. Greer2014-07-231-0/+12
| | | | | | | | | | | | | | | | | | The digital layer of the NFC subsystem currently supports a 'tg_listen_mdaa' driver hook that supports devices that can do mode detection and automatic anticollision. However, there are some devices that can do mode detection but not automatic anitcollision so add the 'tg_listen_md' hook to support those devices. In order for the digital layer to get the RF technology detected by the device from the driver, add the 'tg_get_rf_tech' hook. It is only valid to call this hook immediately after a successful call to 'tg_listen_md'. CC: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Remove extra blank lineMark A. Greer2014-07-231-1/+0
| | | | | | | | | Remove extra blank line that was inadvertently added by a recent commit. CC: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: hci: Add stop_poll HCI operand.Christophe Ricard2014-07-231-0/+1
| | | | | | | | stop_poll allows to stop CLF reader polling. Some other operations might be necessary for some CLF to stop polling. For example in card mode. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Add digital framing calls when in target modeMark A. Greer2014-07-211-0/+2
| | | | | | | | | | | | | | Add new "NFC_DIGITAL_FRAMING_*" calls to the digital layer so the driver can make the necessary adjustments when performing anticollision while in target mode. The driver must ensure that the effect of these calls happens after the following response has been sent but before reception of the next request begins. Acked-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: Add RAW socket type support for SOCKPROTO_RAWHiren Tandel2014-05-201-0/+3
| | | | | | | | | | This allows for a more generic NFC sniffing by using SOCKPROTO_RAW SOCK_RAW to read RAW NFC frames. This is for sniffing anything but LLCP (HCI, NCI, etc...). Signed-off-by: Hiren Tandel <hirent@marvell.com> Signed-off-by: Rahul Tank <rahult@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Add macros for the ISO/IEC 14443-B ProtocolMark A. Greer2014-04-221-0/+4
| | | | | | | | Add RF tech and framing macros for the ISO/IEC 14443-B Protocol. Cc: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: hci: Add load_session HCI operandChristophe Ricard2014-04-221-0/+1
| | | | | | | | | | load_session allows a CLF to restore the gate <-> pipe table from some proprietary location. The main advantage to add this function is to reduce the memory wear by running pipe creation (and storing) only once. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Rename Type V tags to Type 5 tagsMark A. Greer2014-03-111-1/+1
| | | | | | | | | | | According to the latest draft specification from the NFC-V committee, ISO/IEC 15693 tags will be referred to as "Type 5" tags and not "Type V" tags anymore. Make the code reflect the new terminology. Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Add poll support for type 4A tag platformThierry Escande2014-02-161-0/+3
| | | | | | | | This adds support for ATS request and response handling for type 4A tag activation. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: Add ISO/IEC 15693 header definitionsMark A. Greer2014-02-162-0/+7
| | | | | | | | Add the header definitions required by upcoming patches that add support for ISO/IEC 15693. Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* Merge branch 'master' of ↵John W. Linville2014-01-172-0/+12
|\ | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem
| * NFC: NCI: Add set_config APIAmitkumar Karwar2014-01-071-0/+1
| | | | | | | | | | | | | | | | | | This API can be used by drivers to send their custom configuration using SET_CONFIG NCI command to the device. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: NCI: Add setup handlerAmitkumar Karwar2014-01-071-0/+1
| | | | | | | | | | | | | | | | | | Some drivers require special configuration while initializing. This patch adds setup handler for this custom configuration. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: Add a note about asynchronous functionsThierry Escande2014-01-041-0/+10
| | | | | | | | | | | | | | This explains how and why the timeout parameter must be handled by the driver implementation. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* | include/net/: Fix FSF address in file headersJeff Kirsher2013-12-065-13/+5
|/ | | | | | | | | | Several files refer to an old address for the Free Software Foundation in the file header comment. Resolve by replacing the address with the URL <http://www.gnu.org/licenses/> so that we do not have to keep updating the header comments anytime the address changes. Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* NFC: NCI: Modify NCI SPI to implement CS/INT handshake per the specEric Lapuyade2013-09-251-10/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-251-1/+1
| | | | | | | | | | | | | | | | | | | | 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: Define secure element IO API and commandsSamuel Ortiz2013-09-251-0/+5
| | | | | | | | | | | 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-251-0/+8
| | | | | | | | 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: Add NFC-A technology supportThierry Escande2013-09-251-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-251-0/+25
| | | | | | | | | | | | | | | | | | | | 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-251-0/+199
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: NCI: Simplify NCI SPI to become a simple framing/checking layerEric Lapuyade2013-09-252-30/+15
| | | | | | | | | | | | | | | | 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-252-6/+6
| | | | | | | | 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-251-13/+13
| | | | | | | | | 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: Convert nfc_dev_info and nfc_dev_err to nfc_<level>Joe Perches2013-09-251-2/+2
| | | | | | | | | | | 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-251-1/+0
| | | | | | | | | | | 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: Export nfc_find_se()Arron Wang2013-09-251-0/+1
| | | | | | | 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: netlink: Add result of firmware operation to completion eventEric Lapuyade2013-08-141-1/+2
| | | | | | | | | | Result is added as an NFC_ATTR_FIRMWARE_DOWNLOAD_STATUS attribute containing the standard errno positive value of the completion result. This event will be sent when the firmare download operation is done and will contain the operation result. Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: Move nfc_fw_download_done() definition from private to publicEric Lapuyade2013-08-141-0/+2
| | | | | | | | This API must be called by NFC drivers, and its prototype was incorrectly placed. Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: netlink: Rename CMD_FW_UPLOAD to CMD_FW_DOWNLOADSamuel Ortiz2013-07-312-3/+3
| | | | | | | | | Loading a firmware into a target is typically called firmware download, not firmware upload. So we rename the netlink API to NFC_CMD_FW_DOWNLOAD in order to avoid any terminology confusion from userspace. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: Add secure elements addition and removal APISamuel Ortiz2013-06-141-1/+21
| | | | | | | | This API will allow NFC drivers to add and remove the secure elements they know about or detect. Typically this should be called (asynchronously or not) from the driver or the host interface stack detect_se hook. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: Extend and fix the internal secure element APISamuel Ortiz2013-06-142-4/+8
| | | | | | | | | | Secure elements need to be discovered after enabling the NFC controller. This is typically done by the NCI core and the HCI drivers (HCI does not specify how to discover SEs, it is left to the specific drivers). Also, the SE enable/disable API explicitely takes a SE index as its argument. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: Remove the static supported_se fieldSamuel Ortiz2013-06-143-4/+0
| | | | | | | | | | | | Supported secure elements are typically found during a discovery process initiated when the NFC controller is up and running. For a given NFC chipset there can be many configurations (embedded SE or not, with or without a SIM card wired to the NFC controller SWP interface, etc...) and thus driver code will never know before hand which SEs are available. So we remove this field, it will be replaced by a real SE discovery mechanism. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: pn533: Copy NFCID2 through ATR_REQSamuel Ortiz2013-06-141-0/+2
| | | | | | | | When using NFC-F we should copy the NFCID2 buffer that we got from SENSF_RES through the ATR_REQ NFCID3 buffer. Not doing so violates NFC Forum digital requirement #189. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: Add NCI over SPI receiveFrederic Danis2013-06-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Before any operation, driver interruption is de-asserted to prevent race condition between TX and RX. Transaction starts by emitting "Direct read" and acknowledged mode bytes. Then packet length is read allowing to allocate correct NCI socket buffer. After that payload is retrieved. A delay after the transaction can be added. This delay is determined by the driver during nci_spi_allocate_device() call and can be 0. If acknowledged mode is set: - CRC of header and payload is checked - if frame reception fails (CRC error): NACK is sent - if received frame has ACK or NACK flag: unblock nci_spi_send() Payload is passed to NCI module. At the end, driver interruption is re asserted. Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: Add NCI over SPI sendFrederic Danis2013-06-141-0/+3
| | | | | | | | | | | | | | | | | | | | | Before any operation, driver interruption is de-asserted to prevent race condition between TX and RX. The NCI over SPI header is added in front of NCI packet. If acknowledged mode is set, CRC-16-CCITT is added to the packet. Then the packet is forwarded to SPI module to be sent. A delay after the transaction is added. This delay is determined by the driver during nci_spi_allocate_device() call and can be 0. After data has been sent, driver interruption is re-asserted. If acknowledged mode is set, nci_spi_send will block until acknowledgment is received. Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: Add basic NCI over SPIFrederic Danis2013-06-141-0/+49
| | | | | | | | | | | | | | | | | | The NFC Forum defines a transport interface based on Serial Peripheral Interface (SPI) for the NFC Controller Interface (NCI). This module implements the SPI transport of NCI, calling SPI module directly to read/write data to NFC controller (NFCC). NFCC driver should provide functions performing device open and close. It should also provide functions asserting/de-asserting interruption to prevent TX/RX race conditions. NFCC driver can also fix a delay between transactions if needed by the hardware. Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: HCI: Implement fw_upload opsEric Lapuyade2013-06-141-0/+1
| | | | | | | | | This is a simple forward to the HCI driver. When driver is done with the operation, it shall directly notify NFC Core by calling nfc_fw_upload_done(). Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: Add firmware upload netlink commandEric Lapuyade2013-06-141-0/+2
| | | | | | | | | | | | | | | | | | As several NFC chipsets can have their firmwares upgraded and reflashed, this patchset adds a new netlink command to trigger that the driver loads or flashes a new firmware. This will allows userspace triggered firmware upgrade through netlink. The firmware name or hint is passed as a parameter, and the driver will eventually fetch the firmware binary through the request_firmware API. The cmd can only be executed when the nfc dev is not in use. Actual firmware loading/flashing is an asynchronous operation. Result of the operation shall send a new event up to user space through the nfc dev multicast socket. During operation, the nfc dev is not openable and thus not usable. Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: NCI: Fix skb->dev usageFrederic Danis2013-06-141-2/+2
| | | | | | | | | | | | | skb->dev is used for carrying a net_device pointer and not an nci_dev pointer. Remove usage of skb-dev to carry nci_dev and replace it by parameter in nci_recv_frame(), nci_send_frame() and driver send() functions. NfcWilink driver is also updated to use those functions. Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: RFKILL supportSamuel Ortiz2013-04-121-0/+2
| | | | | | | | | | All NFC devices will now get proper RFKILL support as long as they provide some dev_up and dev_down hooks. Rfkilling an NFC device will bring it down while it is left to userspace to bring it back up when being rfkill unblocked. This is very similar to what Bluetooth does. Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: Initial Secure Element APISamuel Ortiz2013-01-103-0/+10
| | | | | | | | | | Each NFC adapter can have several links to different secure elements and that property needs to be exported by the drivers. A secure element link can be enabled and disabled, and card emulation will be handled by the currently active one. Otherwise card emulation will be host implemented. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: Add HCI quirks to support driver (non)standard implementationsEric Lapuyade2013-01-101-0/+13
| | | | | | | | | Some chips diverge from the HCI spec in their implementation of standard features. This adds a new quirks parameter to nfc_hci_allocate_device() to let the driver indicate its divergence. Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: Added error handling in event_received hci opsEric Lapuyade2013-01-101-2/+2
| | | | | | There is no use to return an error if the caller doesn't get it. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: Fixed nfc core and hci unregistration and cleanupEric Lapuyade2013-01-102-0/+4
| | | | | | | | | | When an adapter is removed, it will unregister itself from hci and/or nfc core. In order to do that safely, work tasks must first be canceled and prevented to be scheduled again, before the hci or nfc device can be destroyed. Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: Export nfc_hci_sak_to_protocol()Eric Lapuyade2012-11-191-0/+1
| | | | | | | Some HCI drivers will need it. Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: Export nfc_hci_result_to_errno as it can be needed by HCI driversEric Lapuyade2012-11-191-0/+2
| | | | | Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-28 06:07:30 +0100