kernel/include/net/nfc/digital.h, branch linux-3.17.y

NFC: digital: Add 'tg_listen_md' and 'tg_get_rf_tech' driver hooks

2014-07-22T23:17:31Z

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 Signed-off-by: Mark A. Greer Signed-off-by: Samuel Ortiz

NFC: digital: Remove extra blank line

2014-07-22T23:17:31Z

Remove extra blank line that was inadvertently added by a recent commit. CC: Thierry Escande Signed-off-by: Mark A. Greer Signed-off-by: Samuel Ortiz

NFC: digital: Add digital framing calls when in target mode

2014-07-20T22:45:21Z

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 Signed-off-by: Mark A. Greer Signed-off-by: Samuel Ortiz

NFC: digital: Add macros for the ISO/IEC 14443-B Protocol

2014-04-21T22:37:28Z

Add RF tech and framing macros for the ISO/IEC 14443-B Protocol. Cc: Thierry Escande Signed-off-by: Mark A. Greer Signed-off-by: Samuel Ortiz

NFC: digital: Rename Type V tags to Type 5 tags

2014-03-10T23:40:59Z

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 Signed-off-by: Samuel Ortiz

NFC: digital: Add poll support for type 4A tag platform

2014-02-16T22:49:54Z

This adds support for ATS request and response handling for type 4A tag activation. Signed-off-by: Thierry Escande Signed-off-by: Samuel Ortiz

NFC: Add ISO/IEC 15693 header definitions

2014-02-16T22:49:53Z

Add the header definitions required by upcoming patches that add support for ISO/IEC 15693. Signed-off-by: Mark A. Greer Signed-off-by: Samuel Ortiz

NFC: digital: Add a note about asynchronous functions

2014-01-04T02:35:34Z

This explains how and why the timeout parameter must be handled by the driver implementation. Signed-off-by: Samuel Ortiz

NFC Digital: Add NFC-A technology support

2013-09-25T00:02:23Z

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 Signed-off-by: Samuel Ortiz

NFC Digital: Implement driver commands mechanism

2013-09-25T00:02:07Z

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 Signed-off-by: Samuel Ortiz