renegade-project/linux-next
2
0
Fork 0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-28 15:13:55 +08:00
Code
b2eb0ee6d0
linux-next/net/nfc/digital_technology.c

1316 lines
27 KiB
C
Raw Normal View History

NFC Digital: Implement driver commands mechanism 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>
2013-09-19 23:55:26 +08:00
/*
* NFC Digital Protocol stack
* Copyright (c) 2013, Intel Corporation.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
* version 2, as published by the Free Software Foundation.
*
* This program is distributed in the hope it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
* more details.
*
*/
NFC: digital: Remove PR_ERR and PR_DBG macros 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>
2013-09-20 15:05:48 +08:00
#define pr_fmt(fmt) "digital: %s: " fmt, __func__
NFC Digital: Implement driver commands mechanism 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>
2013-09-19 23:55:26 +08:00
#include "digital.h"
#define DIGITAL_CMD_SENS_REQ 0x26
#define DIGITAL_CMD_ALL_REQ 0x52
#define DIGITAL_CMD_SEL_REQ_CL1 0x93
#define DIGITAL_CMD_SEL_REQ_CL2 0x95
#define DIGITAL_CMD_SEL_REQ_CL3 0x97
#define DIGITAL_SDD_REQ_SEL_PAR 0x20
#define DIGITAL_SDD_RES_CT 0x88
#define DIGITAL_SDD_RES_LEN 5
NFC Digital: Add NFC-A technology support 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>
2013-09-19 23:55:27 +08:00
#define DIGITAL_SEL_RES_NFCID1_COMPLETE(sel_res) (!((sel_res) & 0x04))
#define DIGITAL_SEL_RES_IS_T2T(sel_res) (!((sel_res) & 0x60))
NFC: digital: Add poll support for type 4A tag platform 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>
2014-01-27 07:31:31 +08:00
#define DIGITAL_SEL_RES_IS_T4T(sel_res) ((sel_res) & 0x20)
NFC Digital: Add initiator NFC-DEP support 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>
2013-09-19 23:55:29 +08:00
#define DIGITAL_SEL_RES_IS_NFC_DEP(sel_res) ((sel_res) & 0x40)
NFC Digital: Add NFC-A technology support 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>
2013-09-19 23:55:27 +08:00
NFC: digital: Fix sens_res endiannes handling 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>
2013-09-24 17:47:34 +08:00
#define DIGITAL_SENS_RES_IS_T1T(sens_res) (((sens_res) & 0x0C00) == 0x0C00)
NFC Digital: Add NFC-A technology support 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>
2013-09-19 23:55:27 +08:00
#define DIGITAL_SENS_RES_IS_VALID(sens_res) \
NFC: digital: Fix sens_res endiannes handling 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>
2013-09-24 17:47:34 +08:00
((!((sens_res) & 0x001F) && (((sens_res) & 0x0C00) == 0x0C00)) || \
(((sens_res) & 0x001F) && ((sens_res) & 0x0C00) != 0x0C00))
NFC Digital: Add NFC-A technology support 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>
2013-09-19 23:55:27 +08:00
#define DIGITAL_MIFARE_READ_RES_LEN 16
#define DIGITAL_MIFARE_ACK_RES 0x0A
NFC: digital: Add support for ISO/IEC 14443-B Protocol Add support for the ISO/IEC 14443-B protocol and Type 4B tags. It is expected that there will be only one tag within range so the full anticollision scheme is not implemented. Only the SENSB_REQ/SENSB_RES and ATTRIB_REQ/ATTRIB_RES are implemented. 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>
2014-04-01 08:36:38 +08:00
#define DIGITAL_CMD_SENSB_REQ 0x05
#define DIGITAL_SENSB_ADVANCED BIT(5)
#define DIGITAL_SENSB_EXTENDED BIT(4)
#define DIGITAL_SENSB_ALLB_REQ BIT(3)
#define DIGITAL_SENSB_N(n) ((n) & 0x7)
#define DIGITAL_CMD_SENSB_RES 0x50
#define DIGITAL_CMD_ATTRIB_REQ 0x1D
#define DIGITAL_ATTRIB_P1_TR0_DEFAULT (0x0 << 6)
#define DIGITAL_ATTRIB_P1_TR1_DEFAULT (0x0 << 4)
#define DIGITAL_ATTRIB_P1_SUPRESS_EOS BIT(3)
#define DIGITAL_ATTRIB_P1_SUPRESS_SOS BIT(2)
#define DIGITAL_ATTRIB_P2_LISTEN_POLL_1 (0x0 << 6)
#define DIGITAL_ATTRIB_P2_POLL_LISTEN_1 (0x0 << 4)
#define DIGITAL_ATTRIB_P2_MAX_FRAME_256 0x8
#define DIGITAL_ATTRIB_P4_DID(n) ((n) & 0xf)
NFC Digital: Add NFC-F technology support 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>
2013-09-19 23:55:28 +08:00
#define DIGITAL_CMD_SENSF_REQ 0x00
#define DIGITAL_CMD_SENSF_RES 0x01
#define DIGITAL_SENSF_RES_MIN_LENGTH 17
#define DIGITAL_SENSF_RES_RD_AP_B1 0x00
#define DIGITAL_SENSF_RES_RD_AP_B2 0x8F
#define DIGITAL_SENSF_REQ_RC_NONE 0
#define DIGITAL_SENSF_REQ_RC_SC 1
#define DIGITAL_SENSF_REQ_RC_AP 2
NFC: digital: Add Digital Layer support for ISO/IEC 15693 Add support for ISO/IEC 15693 to the digital layer. The code currently uses single-slot anticollision only since the digital layer infrastructure only supports one tag per adapter (making it pointless to do 16-slot anticollision). The code uses two new framing types: 'NFC_DIGITAL_FRAMING_ISO15693_INVENTORY' and 'NFC_DIGITAL_FRAMING_ISO15693_TVT'. The former is used to tell the driver to prepare for an Inventory command and the ensuing anticollision sequence. The latter is used to tell the driver that the anticollision sequence is over and to prepare for non-inventory commands. Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-01-22 07:23:59 +08:00
#define DIGITAL_CMD_ISO15693_INVENTORY_REQ 0x01
#define DIGITAL_ISO15693_REQ_FLAG_DATA_RATE BIT(1)
#define DIGITAL_ISO15693_REQ_FLAG_INVENTORY BIT(2)
#define DIGITAL_ISO15693_REQ_FLAG_NB_SLOTS BIT(5)
#define DIGITAL_ISO15693_RES_FLAG_ERROR BIT(0)
#define DIGITAL_ISO15693_RES_IS_VALID(flags) \
(!((flags) & DIGITAL_ISO15693_RES_FLAG_ERROR))
NFC: digital: Add ISO-DEP support for data exchange When a type 4A target is activated, this change adds the ISO-DEP SoD when sending frames and removes it when receiving responses. Chaining is not supported so sent frames are rejected if they exceed remote FSC bytes. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-01-27 07:31:32 +08:00
#define DIGITAL_ISO_DEP_I_PCB 0x02
#define DIGITAL_ISO_DEP_PNI(pni) ((pni) & 0x01)
#define DIGITAL_ISO_DEP_PCB_TYPE(pcb) ((pcb) & 0xC0)
#define DIGITAL_ISO_DEP_I_BLOCK 0x00
#define DIGITAL_ISO_DEP_BLOCK_HAS_DID(pcb) ((pcb) & 0x08)
NFC: digital: Add poll support for type 4A tag platform 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>
2014-01-27 07:31:31 +08:00
static const u8 digital_ats_fsc[] = {
16, 24, 32, 40, 48, 64, 96, 128,
};
#define DIGITAL_ATS_FSCI(t0) ((t0) & 0x0F)
NFC: digital: Add support for ISO/IEC 14443-B Protocol Add support for the ISO/IEC 14443-B protocol and Type 4B tags. It is expected that there will be only one tag within range so the full anticollision scheme is not implemented. Only the SENSB_REQ/SENSB_RES and ATTRIB_REQ/ATTRIB_RES are implemented. 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>
2014-04-01 08:36:38 +08:00
#define DIGITAL_SENSB_FSCI(pi2) (((pi2) & 0xF0) >> 4)
NFC: digital: Add poll support for type 4A tag platform 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>
2014-01-27 07:31:31 +08:00
#define DIGITAL_ATS_MAX_FSC 256
#define DIGITAL_RATS_BYTE1 0xE0
#define DIGITAL_RATS_PARAM 0x80
NFC Digital: Add NFC-A technology support 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>
2013-09-19 23:55:27 +08:00
struct digital_sdd_res {
u8 nfcid1[4];
u8 bcc;
} __packed;
struct digital_sel_req {
u8 sel_cmd;
u8 b2;
u8 nfcid1[4];
u8 bcc;
} __packed;
NFC: digital: Add support for ISO/IEC 14443-B Protocol Add support for the ISO/IEC 14443-B protocol and Type 4B tags. It is expected that there will be only one tag within range so the full anticollision scheme is not implemented. Only the SENSB_REQ/SENSB_RES and ATTRIB_REQ/ATTRIB_RES are implemented. 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>
2014-04-01 08:36:38 +08:00
struct digital_sensb_req {
u8 cmd;
u8 afi;
u8 param;
} __packed;
struct digital_sensb_res {
u8 cmd;
u8 nfcid0[4];
u8 app_data[4];
u8 proto_info[3];
} __packed;
struct digital_attrib_req {
u8 cmd;
u8 nfcid0[4];
u8 param1;
u8 param2;
u8 param3;
u8 param4;
} __packed;
struct digital_attrib_res {
u8 mbli_did;
} __packed;
NFC Digital: Add NFC-F technology support 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>
2013-09-19 23:55:28 +08:00
struct digital_sensf_req {
u8 cmd;
u8 sc1;
u8 sc2;
u8 rc;
u8 tsn;
} __packed;
struct digital_sensf_res {
u8 cmd;
u8 nfcid2[8];
u8 pad0[2];
u8 pad1[3];
u8 mrti_check;
u8 mrti_update;
u8 pad2;
u8 rd[2];
} __packed;
NFC: digital: Add Digital Layer support for ISO/IEC 15693 Add support for ISO/IEC 15693 to the digital layer. The code currently uses single-slot anticollision only since the digital layer infrastructure only supports one tag per adapter (making it pointless to do 16-slot anticollision). The code uses two new framing types: 'NFC_DIGITAL_FRAMING_ISO15693_INVENTORY' and 'NFC_DIGITAL_FRAMING_ISO15693_TVT'. The former is used to tell the driver to prepare for an Inventory command and the ensuing anticollision sequence. The latter is used to tell the driver that the anticollision sequence is over and to prepare for non-inventory commands. Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-01-22 07:23:59 +08:00
struct digital_iso15693_inv_req {
u8 flags;
u8 cmd;
u8 mask_len;
u64 mask;
} __packed;
struct digital_iso15693_inv_res {
u8 flags;
u8 dsfid;
u64 uid;
} __packed;
NFC Digital: Add NFC-A technology support 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>
2013-09-19 23:55:27 +08:00
static int digital_in_send_sdd_req(struct nfc_digital_dev *ddev,
struct nfc_target *target);
NFC: digital: Add ISO-DEP support for data exchange When a type 4A target is activated, this change adds the ISO-DEP SoD when sending frames and removes it when receiving responses. Chaining is not supported so sent frames are rejected if they exceed remote FSC bytes. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-01-27 07:31:32 +08:00
int digital_in_iso_dep_pull_sod(struct nfc_digital_dev *ddev,
struct sk_buff *skb)
{
u8 pcb;
u8 block_type;
if (skb->len < 1)
return -EIO;
pcb = *skb->data;
block_type = DIGITAL_ISO_DEP_PCB_TYPE(pcb);
/* No support fo R-block nor S-block */
if (block_type != DIGITAL_ISO_DEP_I_BLOCK) {
pr_err("ISO_DEP R-block and S-block not supported\n");
return -EIO;
}
if (DIGITAL_ISO_DEP_BLOCK_HAS_DID(pcb)) {
pr_err("DID field in ISO_DEP PCB not supported\n");
return -EIO;
}
skb_pull(skb, 1);
return 0;
}
int digital_in_iso_dep_push_sod(struct nfc_digital_dev *ddev,
struct sk_buff *skb)
{
/*
* Chaining not supported so skb->len + 1 PCB byte + 2 CRC bytes must
* not be greater than remote FSC
*/
if (skb->len + 3 > ddev->target_fsc)
return -EIO;
skb_push(skb, 1);
*skb->data = DIGITAL_ISO_DEP_I_PCB | ddev->curr_nfc_dep_pni;
ddev->curr_nfc_dep_pni =
DIGITAL_ISO_DEP_PNI(ddev->curr_nfc_dep_pni + 1);
return 0;
}
NFC: digital: Add poll support for type 4A tag platform 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>
2014-01-27 07:31:31 +08:00
static void digital_in_recv_ats(struct nfc_digital_dev *ddev, void *arg,
struct sk_buff *resp)
{
struct nfc_target *target = arg;
u8 fsdi;
int rc;
if (IS_ERR(resp)) {
rc = PTR_ERR(resp);
resp = NULL;
goto exit;
}
if (resp->len < 2) {
rc = -EIO;
goto exit;
}
fsdi = DIGITAL_ATS_FSCI(resp->data[1]);
if (fsdi >= 8)
ddev->target_fsc = DIGITAL_ATS_MAX_FSC;
else
ddev->target_fsc = digital_ats_fsc[fsdi];
ddev->curr_nfc_dep_pni = 0;
rc = digital_target_found(ddev, target, NFC_PROTO_ISO14443);
exit:
dev_kfree_skb(resp);
kfree(target);
if (rc)
digital_poll_next_tech(ddev);
}
static int digital_in_send_rats(struct nfc_digital_dev *ddev,
struct nfc_target *target)
{
int rc;
struct sk_buff *skb;
skb = digital_skb_alloc(ddev, 2);
if (!skb)
return -ENOMEM;
*skb_put(skb, 1) = DIGITAL_RATS_BYTE1;
*skb_put(skb, 1) = DIGITAL_RATS_PARAM;
rc = digital_in_send_cmd(ddev, skb, 30, digital_in_recv_ats,
target);
if (rc)
kfree_skb(skb);
return rc;
}
NFC Digital: Add NFC-A technology support 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>
2013-09-19 23:55:27 +08:00
static void digital_in_recv_sel_res(struct nfc_digital_dev *ddev, void *arg,
struct sk_buff *resp)
{
struct nfc_target *target = arg;
int rc;
u8 sel_res;
u8 nfc_proto;
if (IS_ERR(resp)) {
rc = PTR_ERR(resp);
resp = NULL;
goto exit;
}
if (!DIGITAL_DRV_CAPS_IN_CRC(ddev)) {
rc = digital_skb_check_crc_a(resp);
if (rc) {
PROTOCOL_ERR("4.4.1.3");
goto exit;
}
}
if (!resp->len) {
rc = -EIO;
goto exit;
}
sel_res = resp->data[0];
if (!DIGITAL_SEL_RES_NFCID1_COMPLETE(sel_res)) {
rc = digital_in_send_sdd_req(ddev, target);
if (rc)
goto exit;
goto exit_free_skb;
}
NFC: digital: Add poll support for type 4A tag platform 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>
2014-01-27 07:31:31 +08:00
target->sel_res = sel_res;
NFC Digital: Add NFC-A technology support 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>
2013-09-19 23:55:27 +08:00
if (DIGITAL_SEL_RES_IS_T2T(sel_res)) {
nfc_proto = NFC_PROTO_MIFARE;
NFC: digital: Check for NFC-DEP before checking for Type 4 tag In digital_in_recv_sel_res(), the code that determines the tag type will interpret bits 7:6 (lsb being b1 as per the Digital Specification) of a SEL RES set to 11b as a Type 4 tag. This is okay except that the neard will interpret the same value as an NFC-DEP device (in src/tag.c:set_tag_type() in the neard source). Make the digital layer's interpretation match neard's interpretation by changing the order of the checks in digital_in_recv_sel_res() so that a value of 11b in bits 7:6 is interpreted as an NFC-DEP device instead of a Type 4 tag. 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>
2014-07-03 00:01:56 +08:00
} else if (DIGITAL_SEL_RES_IS_NFC_DEP(sel_res)) {
nfc_proto = NFC_PROTO_NFC_DEP;
NFC: digital: Add poll support for type 4A tag platform 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>
2014-01-27 07:31:31 +08:00
} else if (DIGITAL_SEL_RES_IS_T4T(sel_res)) {
rc = digital_in_send_rats(ddev, target);
if (rc)
goto exit;
/*
* Skip target_found and don't free it for now. This will be
* done when receiving the ATS
*/
goto exit_free_skb;
NFC Digital: Add NFC-A technology support 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>
2013-09-19 23:55:27 +08:00
} else {
rc = -EOPNOTSUPP;
goto exit;
}
rc = digital_target_found(ddev, target, nfc_proto);
exit:
kfree(target);
exit_free_skb:
dev_kfree_skb(resp);
if (rc)
digital_poll_next_tech(ddev);
}
static int digital_in_send_sel_req(struct nfc_digital_dev *ddev,
struct nfc_target *target,
struct digital_sdd_res *sdd_res)
{
struct sk_buff *skb;
struct digital_sel_req *sel_req;
u8 sel_cmd;
int rc;
skb = digital_skb_alloc(ddev, sizeof(struct digital_sel_req));
if (!skb)
return -ENOMEM;
skb_put(skb, sizeof(struct digital_sel_req));
sel_req = (struct digital_sel_req *)skb->data;
if (target->nfcid1_len <= 4)
sel_cmd = DIGITAL_CMD_SEL_REQ_CL1;
else if (target->nfcid1_len < 10)
sel_cmd = DIGITAL_CMD_SEL_REQ_CL2;
else
sel_cmd = DIGITAL_CMD_SEL_REQ_CL3;
sel_req->sel_cmd = sel_cmd;
sel_req->b2 = 0x70;
memcpy(sel_req->nfcid1, sdd_res->nfcid1, 4);
sel_req->bcc = sdd_res->bcc;
if (DIGITAL_DRV_CAPS_IN_CRC(ddev)) {
rc = digital_in_configure_hw(ddev, NFC_DIGITAL_CONFIG_FRAMING,
NFC_DIGITAL_FRAMING_NFCA_STANDARD_WITH_CRC_A);
if (rc)
goto exit;
} else {
digital_skb_add_crc_a(skb);
}
rc = digital_in_send_cmd(ddev, skb, 30, digital_in_recv_sel_res,
target);
exit:
if (rc)
kfree_skb(skb);
return rc;
}
static void digital_in_recv_sdd_res(struct nfc_digital_dev *ddev, void *arg,
struct sk_buff *resp)
{
struct nfc_target *target = arg;
struct digital_sdd_res *sdd_res;
int rc;
u8 offset, size;
u8 i, bcc;
if (IS_ERR(resp)) {
rc = PTR_ERR(resp);
resp = NULL;
goto exit;
}
if (resp->len < DIGITAL_SDD_RES_LEN) {
PROTOCOL_ERR("4.7.2.8");
rc = -EINVAL;
goto exit;
}
sdd_res = (struct digital_sdd_res *)resp->data;
for (i = 0, bcc = 0; i < 4; i++)
bcc ^= sdd_res->nfcid1[i];
if (bcc != sdd_res->bcc) {
PROTOCOL_ERR("4.7.2.6");
rc = -EINVAL;
goto exit;
}
if (sdd_res->nfcid1[0] == DIGITAL_SDD_RES_CT) {
offset = 1;
size = 3;
} else {
offset = 0;
size = 4;
}
memcpy(target->nfcid1 + target->nfcid1_len, sdd_res->nfcid1 + offset,
size);
target->nfcid1_len += size;
rc = digital_in_send_sel_req(ddev, target, sdd_res);
exit:
dev_kfree_skb(resp);
if (rc) {
kfree(target);
digital_poll_next_tech(ddev);
}
}
static int digital_in_send_sdd_req(struct nfc_digital_dev *ddev,
struct nfc_target *target)
{
int rc;
struct sk_buff *skb;
u8 sel_cmd;
rc = digital_in_configure_hw(ddev, NFC_DIGITAL_CONFIG_FRAMING,
NFC_DIGITAL_FRAMING_NFCA_STANDARD);
if (rc)
return rc;
skb = digital_skb_alloc(ddev, 2);
NFC: digital: Add newline to pr_* calls 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>
2013-09-20 22:56:40 +08:00
if (!skb)
NFC Digital: Add NFC-A technology support 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>
2013-09-19 23:55:27 +08:00
return -ENOMEM;
if (target->nfcid1_len == 0)
sel_cmd = DIGITAL_CMD_SEL_REQ_CL1;
else if (target->nfcid1_len == 3)
sel_cmd = DIGITAL_CMD_SEL_REQ_CL2;
else
sel_cmd = DIGITAL_CMD_SEL_REQ_CL3;
*skb_put(skb, sizeof(u8)) = sel_cmd;
*skb_put(skb, sizeof(u8)) = DIGITAL_SDD_REQ_SEL_PAR;
return digital_in_send_cmd(ddev, skb, 30, digital_in_recv_sdd_res,
target);
}
NFC Digital: Implement driver commands mechanism 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>
2013-09-19 23:55:26 +08:00
static void digital_in_recv_sens_res(struct nfc_digital_dev *ddev, void *arg,
struct sk_buff *resp)
{
NFC Digital: Add NFC-A technology support 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>
2013-09-19 23:55:27 +08:00
struct nfc_target *target = NULL;
int rc;
if (IS_ERR(resp)) {
rc = PTR_ERR(resp);
resp = NULL;
goto exit;
}
if (resp->len < sizeof(u16)) {
rc = -EIO;
goto exit;
}
target = kzalloc(sizeof(struct nfc_target), GFP_KERNEL);
if (!target) {
rc = -ENOMEM;
goto exit;
}
NFC: digital: Fix sens_res endiannes handling 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>
2013-09-24 17:47:34 +08:00
target->sens_res = __le16_to_cpu(*(__le16 *)resp->data);
NFC Digital: Implement driver commands mechanism 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>
2013-09-19 23:55:26 +08:00
NFC: digital: Fix sens_res endiannes handling 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>
2013-09-24 17:47:34 +08:00
if (!DIGITAL_SENS_RES_IS_VALID(target->sens_res)) {
NFC Digital: Add NFC-A technology support 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>
2013-09-19 23:55:27 +08:00
PROTOCOL_ERR("4.6.3.3");
rc = -EINVAL;
goto exit;
}
NFC: digital: Fix sens_res endiannes handling 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>
2013-09-24 17:47:34 +08:00
if (DIGITAL_SENS_RES_IS_T1T(target->sens_res))
NFC Digital: Add NFC-A technology support 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>
2013-09-19 23:55:27 +08:00
rc = digital_target_found(ddev, target, NFC_PROTO_JEWEL);
else
rc = digital_in_send_sdd_req(ddev, target);
exit:
dev_kfree_skb(resp);
if (rc) {
kfree(target);
digital_poll_next_tech(ddev);
}
NFC Digital: Implement driver commands mechanism 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>
2013-09-19 23:55:26 +08:00
}
int digital_in_send_sens_req(struct nfc_digital_dev *ddev, u8 rf_tech)
{
struct sk_buff *skb;
int rc;
rc = digital_in_configure_hw(ddev, NFC_DIGITAL_CONFIG_RF_TECH,
NFC_DIGITAL_RF_TECH_106A);
if (rc)
return rc;
rc = digital_in_configure_hw(ddev, NFC_DIGITAL_CONFIG_FRAMING,
NFC_DIGITAL_FRAMING_NFCA_SHORT);
if (rc)
return rc;
skb = digital_skb_alloc(ddev, 1);
if (!skb)
return -ENOMEM;
*skb_put(skb, sizeof(u8)) = DIGITAL_CMD_SENS_REQ;
rc = digital_in_send_cmd(ddev, skb, 30, digital_in_recv_sens_res, NULL);
if (rc)
kfree_skb(skb);
return rc;
}
NFC Digital: Add NFC-A technology support 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>
2013-09-19 23:55:27 +08:00
int digital_in_recv_mifare_res(struct sk_buff *resp)
{
/* Successful READ command response is 16 data bytes + 2 CRC bytes long.
* Since the driver can't differentiate a ACK/NACK response from a valid
* READ response, the CRC calculation must be handled at digital level
* even if the driver supports it for this technology.
*/
if (resp->len == DIGITAL_MIFARE_READ_RES_LEN + DIGITAL_CRC_LEN) {
if (digital_skb_check_crc_a(resp)) {
PROTOCOL_ERR("9.4.1.2");
return -EIO;
}
return 0;
}
/* ACK response (i.e. successful WRITE). */
if (resp->len == 1 && resp->data[0] == DIGITAL_MIFARE_ACK_RES) {
resp->data[0] = 0;
return 0;
}
/* NACK and any other responses are treated as error. */
return -EIO;
}
NFC Digital: Add NFC-F technology support 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>
2013-09-19 23:55:28 +08:00
NFC: digital: Add support for ISO/IEC 14443-B Protocol Add support for the ISO/IEC 14443-B protocol and Type 4B tags. It is expected that there will be only one tag within range so the full anticollision scheme is not implemented. Only the SENSB_REQ/SENSB_RES and ATTRIB_REQ/ATTRIB_RES are implemented. 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>
2014-04-01 08:36:38 +08:00
static void digital_in_recv_attrib_res(struct nfc_digital_dev *ddev, void *arg,
struct sk_buff *resp)
{
struct nfc_target *target = arg;
struct digital_attrib_res *attrib_res;
int rc;
if (IS_ERR(resp)) {
rc = PTR_ERR(resp);
resp = NULL;
goto exit;
}
if (resp->len < sizeof(*attrib_res)) {
PROTOCOL_ERR("12.6.2");
rc = -EIO;
goto exit;
}
attrib_res = (struct digital_attrib_res *)resp->data;
if (attrib_res->mbli_did & 0x0f) {
PROTOCOL_ERR("12.6.2.1");
rc = -EIO;
goto exit;
}
rc = digital_target_found(ddev, target, NFC_PROTO_ISO14443_B);
exit:
dev_kfree_skb(resp);
kfree(target);
if (rc)
digital_poll_next_tech(ddev);
}
NFC: digital: digital_in_send_attrib_req() can be static CC: "Mark A. Greer" <mgreer@animalcreek.com> CC: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-05-26 06:52:15 +08:00
static int digital_in_send_attrib_req(struct nfc_digital_dev *ddev,
NFC: digital: Add support for ISO/IEC 14443-B Protocol Add support for the ISO/IEC 14443-B protocol and Type 4B tags. It is expected that there will be only one tag within range so the full anticollision scheme is not implemented. Only the SENSB_REQ/SENSB_RES and ATTRIB_REQ/ATTRIB_RES are implemented. 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>
2014-04-01 08:36:38 +08:00
struct nfc_target *target,
struct digital_sensb_res *sensb_res)
{
struct digital_attrib_req *attrib_req;
struct sk_buff *skb;
int rc;
skb = digital_skb_alloc(ddev, sizeof(*attrib_req));
if (!skb)
return -ENOMEM;
attrib_req = (struct digital_attrib_req *)skb_put(skb,
sizeof(*attrib_req));
attrib_req->cmd = DIGITAL_CMD_ATTRIB_REQ;
memcpy(attrib_req->nfcid0, sensb_res->nfcid0,
sizeof(attrib_req->nfcid0));
attrib_req->param1 = DIGITAL_ATTRIB_P1_TR0_DEFAULT |
DIGITAL_ATTRIB_P1_TR1_DEFAULT;
attrib_req->param2 = DIGITAL_ATTRIB_P2_LISTEN_POLL_1 |
DIGITAL_ATTRIB_P2_POLL_LISTEN_1 |
DIGITAL_ATTRIB_P2_MAX_FRAME_256;
attrib_req->param3 = sensb_res->proto_info[1] & 0x07;
attrib_req->param4 = DIGITAL_ATTRIB_P4_DID(0);
rc = digital_in_send_cmd(ddev, skb, 30, digital_in_recv_attrib_res,
target);
if (rc)
kfree_skb(skb);
return rc;
}
static void digital_in_recv_sensb_res(struct nfc_digital_dev *ddev, void *arg,
struct sk_buff *resp)
{
struct nfc_target *target = NULL;
struct digital_sensb_res *sensb_res;
u8 fsci;
int rc;
if (IS_ERR(resp)) {
rc = PTR_ERR(resp);
resp = NULL;
goto exit;
}
if (resp->len != sizeof(*sensb_res)) {
PROTOCOL_ERR("5.6.2.1");
rc = -EIO;
goto exit;
}
sensb_res = (struct digital_sensb_res *)resp->data;
if (sensb_res->cmd != DIGITAL_CMD_SENSB_RES) {
PROTOCOL_ERR("5.6.2");
rc = -EIO;
goto exit;
}
if (!(sensb_res->proto_info[1] & BIT(0))) {
PROTOCOL_ERR("5.6.2.12");
rc = -EIO;
goto exit;
}
if (sensb_res->proto_info[1] & BIT(3)) {
PROTOCOL_ERR("5.6.2.16");
rc = -EIO;
goto exit;
}
fsci = DIGITAL_SENSB_FSCI(sensb_res->proto_info[1]);
if (fsci >= 8)
ddev->target_fsc = DIGITAL_ATS_MAX_FSC;
else
ddev->target_fsc = digital_ats_fsc[fsci];
target = kzalloc(sizeof(struct nfc_target), GFP_KERNEL);
if (!target) {
rc = -ENOMEM;
goto exit;
}
rc = digital_in_send_attrib_req(ddev, target, sensb_res);
exit:
dev_kfree_skb(resp);
if (rc) {
kfree(target);
digital_poll_next_tech(ddev);
}
}
int digital_in_send_sensb_req(struct nfc_digital_dev *ddev, u8 rf_tech)
{
struct digital_sensb_req *sensb_req;
struct sk_buff *skb;
int rc;
rc = digital_in_configure_hw(ddev, NFC_DIGITAL_CONFIG_RF_TECH,
NFC_DIGITAL_RF_TECH_106B);
if (rc)
return rc;
rc = digital_in_configure_hw(ddev, NFC_DIGITAL_CONFIG_FRAMING,
NFC_DIGITAL_FRAMING_NFCB);
if (rc)
return rc;
skb = digital_skb_alloc(ddev, sizeof(*sensb_req));
if (!skb)
return -ENOMEM;
sensb_req = (struct digital_sensb_req *)skb_put(skb,
sizeof(*sensb_req));
sensb_req->cmd = DIGITAL_CMD_SENSB_REQ;
sensb_req->afi = 0x00; /* All families and sub-families */
sensb_req->param = DIGITAL_SENSB_N(0);
rc = digital_in_send_cmd(ddev, skb, 30, digital_in_recv_sensb_res,
NULL);
if (rc)
kfree_skb(skb);
return rc;
}
NFC Digital: Add NFC-F technology support 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>
2013-09-19 23:55:28 +08:00
static void digital_in_recv_sensf_res(struct nfc_digital_dev *ddev, void *arg,
struct sk_buff *resp)
{
int rc;
NFC Digital: Add initiator NFC-DEP support 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>
2013-09-19 23:55:29 +08:00
u8 proto;
NFC Digital: Add NFC-F technology support 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>
2013-09-19 23:55:28 +08:00
struct nfc_target target;
struct digital_sensf_res *sensf_res;
if (IS_ERR(resp)) {
rc = PTR_ERR(resp);
resp = NULL;
goto exit;
}
if (resp->len < DIGITAL_SENSF_RES_MIN_LENGTH) {
rc = -EIO;
goto exit;
}
if (!DIGITAL_DRV_CAPS_IN_CRC(ddev)) {
rc = digital_skb_check_crc_f(resp);
if (rc) {
PROTOCOL_ERR("6.4.1.8");
goto exit;
}
}
skb_pull(resp, 1);
memset(&target, 0, sizeof(struct nfc_target));
sensf_res = (struct digital_sensf_res *)resp->data;
memcpy(target.sensf_res, sensf_res, resp->len);
target.sensf_res_len = resp->len;
memcpy(target.nfcid2, sensf_res->nfcid2, NFC_NFCID2_MAXSIZE);
target.nfcid2_len = NFC_NFCID2_MAXSIZE;
NFC Digital: Add initiator NFC-DEP support 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>
2013-09-19 23:55:29 +08:00
if (target.nfcid2[0] == DIGITAL_SENSF_NFCID2_NFC_DEP_B1 &&
target.nfcid2[1] == DIGITAL_SENSF_NFCID2_NFC_DEP_B2)
proto = NFC_PROTO_NFC_DEP;
else
proto = NFC_PROTO_FELICA;
rc = digital_target_found(ddev, &target, proto);
NFC Digital: Add NFC-F technology support 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>
2013-09-19 23:55:28 +08:00
exit:
dev_kfree_skb(resp);
if (rc)
digital_poll_next_tech(ddev);
}
int digital_in_send_sensf_req(struct nfc_digital_dev *ddev, u8 rf_tech)
{
struct digital_sensf_req *sensf_req;
struct sk_buff *skb;
int rc;
u8 size;
rc = digital_in_configure_hw(ddev, NFC_DIGITAL_CONFIG_RF_TECH, rf_tech);
if (rc)
return rc;
rc = digital_in_configure_hw(ddev, NFC_DIGITAL_CONFIG_FRAMING,
NFC_DIGITAL_FRAMING_NFCF);
if (rc)
return rc;
size = sizeof(struct digital_sensf_req);
skb = digital_skb_alloc(ddev, size);
if (!skb)
return -ENOMEM;
skb_put(skb, size);
sensf_req = (struct digital_sensf_req *)skb->data;
sensf_req->cmd = DIGITAL_CMD_SENSF_REQ;
sensf_req->sc1 = 0xFF;
sensf_req->sc2 = 0xFF;
sensf_req->rc = 0;
sensf_req->tsn = 0;
*skb_push(skb, 1) = size + 1;
if (!DIGITAL_DRV_CAPS_IN_CRC(ddev))
digital_skb_add_crc_f(skb);
rc = digital_in_send_cmd(ddev, skb, 30, digital_in_recv_sensf_res,
NULL);
if (rc)
kfree_skb(skb);
return rc;
}
NFC Digital: Add target NFC-DEP support 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>
2013-09-19 23:55:30 +08:00
NFC: digital: Add Digital Layer support for ISO/IEC 15693 Add support for ISO/IEC 15693 to the digital layer. The code currently uses single-slot anticollision only since the digital layer infrastructure only supports one tag per adapter (making it pointless to do 16-slot anticollision). The code uses two new framing types: 'NFC_DIGITAL_FRAMING_ISO15693_INVENTORY' and 'NFC_DIGITAL_FRAMING_ISO15693_TVT'. The former is used to tell the driver to prepare for an Inventory command and the ensuing anticollision sequence. The latter is used to tell the driver that the anticollision sequence is over and to prepare for non-inventory commands. Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-01-22 07:23:59 +08:00
static void digital_in_recv_iso15693_inv_res(struct nfc_digital_dev *ddev,
void *arg, struct sk_buff *resp)
{
struct digital_iso15693_inv_res *res;
struct nfc_target *target = NULL;
int rc;
if (IS_ERR(resp)) {
rc = PTR_ERR(resp);
resp = NULL;
goto out_free_skb;
}
if (resp->len != sizeof(*res)) {
rc = -EIO;
goto out_free_skb;
}
res = (struct digital_iso15693_inv_res *)resp->data;
if (!DIGITAL_ISO15693_RES_IS_VALID(res->flags)) {
PROTOCOL_ERR("ISO15693 - 10.3.1");
rc = -EINVAL;
goto out_free_skb;
}
target = kzalloc(sizeof(*target), GFP_KERNEL);
if (!target) {
rc = -ENOMEM;
goto out_free_skb;
}
target->is_iso15693 = 1;
target->iso15693_dsfid = res->dsfid;
memcpy(target->iso15693_uid, &res->uid, sizeof(target->iso15693_uid));
rc = digital_target_found(ddev, target, NFC_PROTO_ISO15693);
kfree(target);
out_free_skb:
dev_kfree_skb(resp);
if (rc)
digital_poll_next_tech(ddev);
}
int digital_in_send_iso15693_inv_req(struct nfc_digital_dev *ddev, u8 rf_tech)
{
struct digital_iso15693_inv_req *req;
struct sk_buff *skb;
int rc;
rc = digital_in_configure_hw(ddev, NFC_DIGITAL_CONFIG_RF_TECH,
NFC_DIGITAL_RF_TECH_ISO15693);
if (rc)
return rc;
rc = digital_in_configure_hw(ddev, NFC_DIGITAL_CONFIG_FRAMING,
NFC_DIGITAL_FRAMING_ISO15693_INVENTORY);
if (rc)
return rc;
skb = digital_skb_alloc(ddev, sizeof(*req));
if (!skb)
return -ENOMEM;
skb_put(skb, sizeof(*req) - sizeof(req->mask)); /* No mask */
req = (struct digital_iso15693_inv_req *)skb->data;
/* Single sub-carrier, high data rate, no AFI, single slot
* Inventory command
*/
req->flags = DIGITAL_ISO15693_REQ_FLAG_DATA_RATE |
DIGITAL_ISO15693_REQ_FLAG_INVENTORY |
DIGITAL_ISO15693_REQ_FLAG_NB_SLOTS;
req->cmd = DIGITAL_CMD_ISO15693_INVENTORY_REQ;
req->mask_len = 0;
rc = digital_in_send_cmd(ddev, skb, 30,
digital_in_recv_iso15693_inv_res, NULL);
if (rc)
kfree_skb(skb);
return rc;
}
NFC Digital: Add target NFC-DEP support 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>
2013-09-19 23:55:30 +08:00
static int digital_tg_send_sel_res(struct nfc_digital_dev *ddev)
{
struct sk_buff *skb;
int rc;
skb = digital_skb_alloc(ddev, 1);
if (!skb)
return -ENOMEM;
*skb_put(skb, 1) = DIGITAL_SEL_RES_NFC_DEP;
if (!DIGITAL_DRV_CAPS_TG_CRC(ddev))
digital_skb_add_crc_a(skb);
NFC: digital: Add digital framing calls when in target mode 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>
2014-07-03 01:16:15 +08:00
rc = digital_tg_configure_hw(ddev, NFC_DIGITAL_CONFIG_FRAMING,
NFC_DIGITAL_FRAMING_NFCA_ANTICOL_COMPLETE);
if (rc) {
kfree_skb(skb);
return rc;
}
NFC Digital: Add target NFC-DEP support 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>
2013-09-19 23:55:30 +08:00
rc = digital_tg_send_cmd(ddev, skb, 300, digital_tg_recv_atr_req,
NULL);
if (rc)
kfree_skb(skb);
return rc;
}
static void digital_tg_recv_sel_req(struct nfc_digital_dev *ddev, void *arg,
struct sk_buff *resp)
{
int rc;
if (IS_ERR(resp)) {
rc = PTR_ERR(resp);
resp = NULL;
goto exit;
}
if (!DIGITAL_DRV_CAPS_TG_CRC(ddev)) {
rc = digital_skb_check_crc_a(resp);
if (rc) {
PROTOCOL_ERR("4.4.1.3");
goto exit;
}
}
/* Silently ignore SEL_REQ content and send a SEL_RES for NFC-DEP */
rc = digital_tg_send_sel_res(ddev);
exit:
if (rc)
digital_poll_next_tech(ddev);
dev_kfree_skb(resp);
}
static int digital_tg_send_sdd_res(struct nfc_digital_dev *ddev)
{
struct sk_buff *skb;
struct digital_sdd_res *sdd_res;
int rc, i;
skb = digital_skb_alloc(ddev, sizeof(struct digital_sdd_res));
if (!skb)
return -ENOMEM;
skb_put(skb, sizeof(struct digital_sdd_res));
sdd_res = (struct digital_sdd_res *)skb->data;
sdd_res->nfcid1[0] = 0x08;
get_random_bytes(sdd_res->nfcid1 + 1, 3);
sdd_res->bcc = 0;
for (i = 0; i < 4; i++)
sdd_res->bcc ^= sdd_res->nfcid1[i];
NFC: digital: Add digital framing calls when in target mode 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>
2014-07-03 01:16:15 +08:00
rc = digital_tg_configure_hw(ddev, NFC_DIGITAL_CONFIG_FRAMING,
NFC_DIGITAL_FRAMING_NFCA_STANDARD_WITH_CRC_A);
if (rc) {
kfree_skb(skb);
return rc;
}
NFC Digital: Add target NFC-DEP support 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>
2013-09-19 23:55:30 +08:00
rc = digital_tg_send_cmd(ddev, skb, 300, digital_tg_recv_sel_req,
NULL);
if (rc)
kfree_skb(skb);
return rc;
}
static void digital_tg_recv_sdd_req(struct nfc_digital_dev *ddev, void *arg,
struct sk_buff *resp)
{
u8 *sdd_req;
int rc;
if (IS_ERR(resp)) {
rc = PTR_ERR(resp);
resp = NULL;
goto exit;
}
sdd_req = resp->data;
if (resp->len < 2 || sdd_req[0] != DIGITAL_CMD_SEL_REQ_CL1 ||
sdd_req[1] != DIGITAL_SDD_REQ_SEL_PAR) {
rc = -EINVAL;
goto exit;
}
rc = digital_tg_send_sdd_res(ddev);
exit:
if (rc)
digital_poll_next_tech(ddev);
dev_kfree_skb(resp);
}
static int digital_tg_send_sens_res(struct nfc_digital_dev *ddev)
{
struct sk_buff *skb;
u8 *sens_res;
int rc;
skb = digital_skb_alloc(ddev, 2);
if (!skb)
return -ENOMEM;
sens_res = skb_put(skb, 2);
sens_res[0] = (DIGITAL_SENS_RES_NFC_DEP >> 8) & 0xFF;
sens_res[1] = DIGITAL_SENS_RES_NFC_DEP & 0xFF;
NFC: digital: Add digital framing calls when in target mode 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>
2014-07-03 01:16:15 +08:00
rc = digital_tg_configure_hw(ddev, NFC_DIGITAL_CONFIG_FRAMING,
NFC_DIGITAL_FRAMING_NFCA_STANDARD);
if (rc) {
kfree_skb(skb);
return rc;
}
NFC Digital: Add target NFC-DEP support 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>
2013-09-19 23:55:30 +08:00
rc = digital_tg_send_cmd(ddev, skb, 300, digital_tg_recv_sdd_req,
NULL);
if (rc)
kfree_skb(skb);
return rc;
}
void digital_tg_recv_sens_req(struct nfc_digital_dev *ddev, void *arg,
struct sk_buff *resp)
{
u8 sens_req;
int rc;
if (IS_ERR(resp)) {
rc = PTR_ERR(resp);
resp = NULL;
goto exit;
}
sens_req = resp->data[0];
if (!resp->len || (sens_req != DIGITAL_CMD_SENS_REQ &&
sens_req != DIGITAL_CMD_ALL_REQ)) {
rc = -EINVAL;
goto exit;
}
rc = digital_tg_send_sens_res(ddev);
exit:
if (rc)
digital_poll_next_tech(ddev);
dev_kfree_skb(resp);
}
NFC: digital: Handle multiple SENSF_REQ frames According to section 5.15.1.3 of the NFC Activity Specification, multiple SENSF_REQ commands can be received by a target before it receives an ATR_REQ command. To handle this, add a routine that checks whether a SENSF_REQ or ATR_REQ has been recieved. If its a SENSF_REQ, respond appropriately and continue waiting for a ATR_REQ. If its an ATR_REQ, handle it as before. 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>
2014-04-24 02:00:56 +08:00
static void digital_tg_recv_atr_or_sensf_req(struct nfc_digital_dev *ddev,
void *arg, struct sk_buff *resp)
{
if (!IS_ERR(resp) && (resp->len >= 2) &&
(resp->data[1] == DIGITAL_CMD_SENSF_REQ))
digital_tg_recv_sensf_req(ddev, arg, resp);
else
digital_tg_recv_atr_req(ddev, arg, resp);
return;
}
NFC: digital: digital_tg_send_sensf_res() can be static 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>
2013-09-20 23:08:08 +08:00
static int digital_tg_send_sensf_res(struct nfc_digital_dev *ddev,
NFC Digital: Add target NFC-DEP support 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>
2013-09-19 23:55:30 +08:00
struct digital_sensf_req *sensf_req)
{
struct sk_buff *skb;
u8 size;
int rc;
struct digital_sensf_res *sensf_res;
size = sizeof(struct digital_sensf_res);
NFC: digital: SENSF_RES excludes RD when SENSF_REQ RC is zero The check in digital_tg_send_sensf_res() that excludes the 'RD' field from the SENSF_RES is inverted. The 'RD' field should be excluded when the SENSF_REQ 'RC' field is equal to DIGITAL_SENSF_REQ_RC_NONE instead of when its not equal. This is described in section 6.6.2.11 of the NFC Digital Specification. 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>
2014-04-24 02:00:55 +08:00
if (sensf_req->rc == DIGITAL_SENSF_REQ_RC_NONE)
NFC Digital: Add target NFC-DEP support 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>
2013-09-19 23:55:30 +08:00
size -= sizeof(sensf_res->rd);
skb = digital_skb_alloc(ddev, size);
if (!skb)
return -ENOMEM;
skb_put(skb, size);
sensf_res = (struct digital_sensf_res *)skb->data;
memset(sensf_res, 0, size);
sensf_res->cmd = DIGITAL_CMD_SENSF_RES;
sensf_res->nfcid2[0] = DIGITAL_SENSF_NFCID2_NFC_DEP_B1;
sensf_res->nfcid2[1] = DIGITAL_SENSF_NFCID2_NFC_DEP_B2;
get_random_bytes(&sensf_res->nfcid2[2], 6);
switch (sensf_req->rc) {
case DIGITAL_SENSF_REQ_RC_SC:
sensf_res->rd[0] = sensf_req->sc1;
sensf_res->rd[1] = sensf_req->sc2;
break;
case DIGITAL_SENSF_REQ_RC_AP:
sensf_res->rd[0] = DIGITAL_SENSF_RES_RD_AP_B1;
sensf_res->rd[1] = DIGITAL_SENSF_RES_RD_AP_B2;
break;
}
*skb_push(skb, sizeof(u8)) = size + 1;
if (!DIGITAL_DRV_CAPS_TG_CRC(ddev))
digital_skb_add_crc_f(skb);
rc = digital_tg_send_cmd(ddev, skb, 300,
NFC: digital: Handle multiple SENSF_REQ frames According to section 5.15.1.3 of the NFC Activity Specification, multiple SENSF_REQ commands can be received by a target before it receives an ATR_REQ command. To handle this, add a routine that checks whether a SENSF_REQ or ATR_REQ has been recieved. If its a SENSF_REQ, respond appropriately and continue waiting for a ATR_REQ. If its an ATR_REQ, handle it as before. 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>
2014-04-24 02:00:56 +08:00
digital_tg_recv_atr_or_sensf_req, NULL);
NFC Digital: Add target NFC-DEP support 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>
2013-09-19 23:55:30 +08:00
if (rc)
kfree_skb(skb);
return rc;
}
void digital_tg_recv_sensf_req(struct nfc_digital_dev *ddev, void *arg,
struct sk_buff *resp)
{
struct digital_sensf_req *sensf_req;
int rc;
if (IS_ERR(resp)) {
rc = PTR_ERR(resp);
resp = NULL;
goto exit;
}
if (!DIGITAL_DRV_CAPS_TG_CRC(ddev)) {
rc = digital_skb_check_crc_f(resp);
if (rc) {
PROTOCOL_ERR("6.4.1.8");
goto exit;
}
}
if (resp->len != sizeof(struct digital_sensf_req) + 1) {
rc = -EINVAL;
goto exit;
}
skb_pull(resp, 1);
sensf_req = (struct digital_sensf_req *)resp->data;
if (sensf_req->cmd != DIGITAL_CMD_SENSF_REQ) {
rc = -EINVAL;
goto exit;
}
rc = digital_tg_send_sensf_res(ddev, sensf_req);
exit:
if (rc)
digital_poll_next_tech(ddev);
dev_kfree_skb(resp);
}
NFC: digital: Add 'tg_listen_md' and 'tg_get_rf_tech' driver hooks 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>
2014-07-22 12:24:39 +08:00
static int digital_tg_config_nfca(struct nfc_digital_dev *ddev)
NFC Digital: Add target NFC-DEP support 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>
2013-09-19 23:55:30 +08:00
{
int rc;
NFC: digital: Add 'tg_listen_md' and 'tg_get_rf_tech' driver hooks 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>
2014-07-22 12:24:39 +08:00
rc = digital_tg_configure_hw(ddev, NFC_DIGITAL_CONFIG_RF_TECH,
NFC_DIGITAL_RF_TECH_106A);
NFC Digital: Add target NFC-DEP support 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>
2013-09-19 23:55:30 +08:00
if (rc)
return rc;
NFC: digital: Add 'tg_listen_md' and 'tg_get_rf_tech' driver hooks 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>
2014-07-22 12:24:39 +08:00
return digital_tg_configure_hw(ddev, NFC_DIGITAL_CONFIG_FRAMING,
NFC_DIGITAL_FRAMING_NFCA_NFC_DEP);
}
int digital_tg_listen_nfca(struct nfc_digital_dev *ddev, u8 rf_tech)
{
int rc;
rc = digital_tg_config_nfca(ddev);
NFC Digital: Add target NFC-DEP support 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>
2013-09-19 23:55:30 +08:00
if (rc)
return rc;
return digital_tg_listen(ddev, 300, digital_tg_recv_sens_req, NULL);
}
NFC: digital: Add 'tg_listen_md' and 'tg_get_rf_tech' driver hooks 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>
2014-07-22 12:24:39 +08:00
static int digital_tg_config_nfcf(struct nfc_digital_dev *ddev, u8 rf_tech)
NFC Digital: Add target NFC-DEP support 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>
2013-09-19 23:55:30 +08:00
{
int rc;
rc = digital_tg_configure_hw(ddev, NFC_DIGITAL_CONFIG_RF_TECH, rf_tech);
if (rc)
return rc;
NFC: digital: Add 'tg_listen_md' and 'tg_get_rf_tech' driver hooks 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>
2014-07-22 12:24:39 +08:00
return digital_tg_configure_hw(ddev, NFC_DIGITAL_CONFIG_FRAMING,
NFC_DIGITAL_FRAMING_NFCF_NFC_DEP);
}
int digital_tg_listen_nfcf(struct nfc_digital_dev *ddev, u8 rf_tech)
{
int rc;
u8 *nfcid2;
rc = digital_tg_config_nfcf(ddev, rf_tech);
NFC Digital: Add target NFC-DEP support 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>
2013-09-19 23:55:30 +08:00
if (rc)
return rc;
nfcid2 = kzalloc(NFC_NFCID2_MAXSIZE, GFP_KERNEL);
if (!nfcid2)
return -ENOMEM;
nfcid2[0] = DIGITAL_SENSF_NFCID2_NFC_DEP_B1;
nfcid2[1] = DIGITAL_SENSF_NFCID2_NFC_DEP_B2;
get_random_bytes(nfcid2 + 2, NFC_NFCID2_MAXSIZE - 2);
return digital_tg_listen(ddev, 300, digital_tg_recv_sensf_req, nfcid2);
}
NFC: digital: Add 'tg_listen_md' and 'tg_get_rf_tech' driver hooks 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>
2014-07-22 12:24:39 +08:00
void digital_tg_recv_md_req(struct nfc_digital_dev *ddev, void *arg,
struct sk_buff *resp)
{
u8 rf_tech;
int rc;
if (IS_ERR(resp)) {
resp = NULL;
goto exit_free_skb;
}
rc = ddev->ops->tg_get_rf_tech(ddev, &rf_tech);
if (rc)
goto exit_free_skb;
switch (rf_tech) {
case NFC_DIGITAL_RF_TECH_106A:
rc = digital_tg_config_nfca(ddev);
if (rc)
goto exit_free_skb;
digital_tg_recv_sens_req(ddev, arg, resp);
break;
case NFC_DIGITAL_RF_TECH_212F:
case NFC_DIGITAL_RF_TECH_424F:
rc = digital_tg_config_nfcf(ddev, rf_tech);
if (rc)
goto exit_free_skb;
digital_tg_recv_sensf_req(ddev, arg, resp);
break;
default:
goto exit_free_skb;
}
return;
exit_free_skb:
digital_poll_next_tech(ddev);
dev_kfree_skb(resp);
}
Copy Permalink