WSL2-Linux-Kernel/net/nfc/digital.h

181 строка
5.6 KiB
C
Исходник Обычный вид История

NFC: Digital Protocol stack implementation This is the initial commit of the NFC Digital Protocol stack implementation. It offers an interface for devices that don't have an embedded NFC Digital protocol stack. The driver instantiates the digital stack by calling nfc_digital_allocate_device(). Within the nfc_digital_ops structure, the driver specifies a set of function pointers for driver operations. These functions must be implemented by the driver and are: in_configure_hw: Hardware configuration for RF technology and communication framing in initiator mode. This is a synchronous function. in_send_cmd: Initiator mode data exchange using RF technology and framing previously set with in_configure_hw. The peer response is returned through callback cb. If an io error occurs or the peer didn't reply within the specified timeout (ms), the error code is passed back through the resp pointer. This is an asynchronous function. tg_configure_hw: Hardware configuration for RF technology and communication framing in target mode. This is a synchronous function. tg_send_cmd: Target mode data exchange using RF technology and framing previously set with tg_configure_hw. The peer next command is returned through callback cb. If an io error occurs or the peer didn't reply within the specified timeout (ms), the error code is passed back through the resp pointer. This is an asynchronous function. tg_listen: Put the device in listen mode waiting for data from the peer device. This is an asynchronous function. tg_listen_mdaa: If supported, put the device in automatic listen mode with mode detection and automatic anti-collision. In this mode, the device automatically detects the RF technology and executes the anti-collision detection using the command responses specified in mdaa_params. The mdaa_params structure contains SENS_RES, NFCID1, and SEL_RES for 106A RF tech. NFCID2 and system code (sc) for 212F and 424F. The driver returns the NFC-DEP ATR_REQ command through cb. The digital stack deducts the RF tech by analyzing the SoD of the frame containing the ATR_REQ command. This is an asynchronous function. switch_rf: Turns device radio on or off. The stack does not call explicitly switch_rf to turn the radio on. A call to in|tg_configure_hw must turn the device radio on. abort_cmd: Discard the last sent command. Then the driver registers itself against the digital stack by using nfc_digital_register_device() which in turn registers the digital stack against the NFC core layer. The digital stack implements common NFC operations like dev_up(), dev_down(), start_poll(), stop_poll(), etc. This patch is only a skeleton and NFC operations are just stubs. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-09-19 19:55:25 +04: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.
*
*/
#ifndef __DIGITAL_H
#define __DIGITAL_H
#include <net/nfc/nfc.h>
#include <net/nfc/digital.h>
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 19:55:27 +04:00
#include <linux/crc-ccitt.h>
#include <linux/crc-itu-t.h>
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 19:55:27 +04:00
#define PROTOCOL_ERR(req) pr_err("%d: NFC Digital Protocol error: %s\n", \
__LINE__, req)
NFC: Digital Protocol stack implementation This is the initial commit of the NFC Digital Protocol stack implementation. It offers an interface for devices that don't have an embedded NFC Digital protocol stack. The driver instantiates the digital stack by calling nfc_digital_allocate_device(). Within the nfc_digital_ops structure, the driver specifies a set of function pointers for driver operations. These functions must be implemented by the driver and are: in_configure_hw: Hardware configuration for RF technology and communication framing in initiator mode. This is a synchronous function. in_send_cmd: Initiator mode data exchange using RF technology and framing previously set with in_configure_hw. The peer response is returned through callback cb. If an io error occurs or the peer didn't reply within the specified timeout (ms), the error code is passed back through the resp pointer. This is an asynchronous function. tg_configure_hw: Hardware configuration for RF technology and communication framing in target mode. This is a synchronous function. tg_send_cmd: Target mode data exchange using RF technology and framing previously set with tg_configure_hw. The peer next command is returned through callback cb. If an io error occurs or the peer didn't reply within the specified timeout (ms), the error code is passed back through the resp pointer. This is an asynchronous function. tg_listen: Put the device in listen mode waiting for data from the peer device. This is an asynchronous function. tg_listen_mdaa: If supported, put the device in automatic listen mode with mode detection and automatic anti-collision. In this mode, the device automatically detects the RF technology and executes the anti-collision detection using the command responses specified in mdaa_params. The mdaa_params structure contains SENS_RES, NFCID1, and SEL_RES for 106A RF tech. NFCID2 and system code (sc) for 212F and 424F. The driver returns the NFC-DEP ATR_REQ command through cb. The digital stack deducts the RF tech by analyzing the SoD of the frame containing the ATR_REQ command. This is an asynchronous function. switch_rf: Turns device radio on or off. The stack does not call explicitly switch_rf to turn the radio on. A call to in|tg_configure_hw must turn the device radio on. abort_cmd: Discard the last sent command. Then the driver registers itself against the digital stack by using nfc_digital_register_device() which in turn registers the digital stack against the NFC core layer. The digital stack implements common NFC operations like dev_up(), dev_down(), start_poll(), stop_poll(), etc. This patch is only a skeleton and NFC operations are just stubs. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-09-19 19:55:25 +04:00
#define DIGITAL_CMD_IN_SEND 0
#define DIGITAL_CMD_TG_SEND 1
#define DIGITAL_CMD_TG_LISTEN 2
#define DIGITAL_CMD_TG_LISTEN_MDAA 3
#define DIGITAL_CMD_TG_LISTEN_MD 4
#define DIGITAL_MAX_HEADER_LEN 7
#define DIGITAL_CRC_LEN 2
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 19:55:29 +04:00
#define DIGITAL_SENSF_NFCID2_NFC_DEP_B1 0x01
#define DIGITAL_SENSF_NFCID2_NFC_DEP_B2 0xFE
#define DIGITAL_SENS_RES_NFC_DEP 0x0100
#define DIGITAL_SEL_RES_NFC_DEP 0x40
#define DIGITAL_SENSF_FELICA_SC 0xFFFF
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 19:55:27 +04:00
#define DIGITAL_DRV_CAPS_IN_CRC(ddev) \
((ddev)->driver_capabilities & NFC_DIGITAL_DRV_CAPS_IN_CRC)
#define DIGITAL_DRV_CAPS_TG_CRC(ddev) \
((ddev)->driver_capabilities & NFC_DIGITAL_DRV_CAPS_TG_CRC)
struct digital_data_exch {
data_exchange_cb_t cb;
void *cb_context;
};
struct sk_buff *digital_skb_alloc(struct nfc_digital_dev *ddev,
unsigned int len);
int digital_send_cmd(struct nfc_digital_dev *ddev, u8 cmd_type,
struct sk_buff *skb, struct digital_tg_mdaa_params *params,
u16 timeout, nfc_digital_cmd_complete_t cmd_cb,
void *cb_context);
int digital_in_configure_hw(struct nfc_digital_dev *ddev, int type, int param);
static inline int digital_in_send_cmd(struct nfc_digital_dev *ddev,
struct sk_buff *skb, u16 timeout,
nfc_digital_cmd_complete_t cmd_cb,
void *cb_context)
{
return digital_send_cmd(ddev, DIGITAL_CMD_IN_SEND, skb, NULL, timeout,
cmd_cb, cb_context);
}
void digital_poll_next_tech(struct nfc_digital_dev *ddev);
int digital_in_send_sens_req(struct nfc_digital_dev *ddev, u8 rf_tech);
int digital_in_send_sensb_req(struct nfc_digital_dev *ddev, u8 rf_tech);
int digital_in_send_sensf_req(struct nfc_digital_dev *ddev, u8 rf_tech);
int digital_in_send_iso15693_inv_req(struct nfc_digital_dev *ddev, u8 rf_tech);
int digital_in_iso_dep_pull_sod(struct nfc_digital_dev *ddev,
struct sk_buff *skb);
int digital_in_iso_dep_push_sod(struct nfc_digital_dev *ddev,
struct sk_buff *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 19:55:27 +04:00
int digital_target_found(struct nfc_digital_dev *ddev,
struct nfc_target *target, u8 protocol);
int digital_in_recv_mifare_res(struct sk_buff *resp);
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 19:55:29 +04:00
int digital_in_send_atr_req(struct nfc_digital_dev *ddev,
struct nfc_target *target, __u8 comm_mode, __u8 *gb,
size_t gb_len);
int digital_in_send_dep_req(struct nfc_digital_dev *ddev,
struct nfc_target *target, struct sk_buff *skb,
struct digital_data_exch *data_exch);
int digital_tg_configure_hw(struct nfc_digital_dev *ddev, int type, int param);
static inline int digital_tg_send_cmd(struct nfc_digital_dev *ddev,
struct sk_buff *skb, u16 timeout,
nfc_digital_cmd_complete_t cmd_cb, void *cb_context)
{
return digital_send_cmd(ddev, DIGITAL_CMD_TG_SEND, skb, NULL, timeout,
cmd_cb, cb_context);
}
void digital_tg_recv_sens_req(struct nfc_digital_dev *ddev, void *arg,
struct sk_buff *resp);
void digital_tg_recv_sensf_req(struct nfc_digital_dev *ddev, void *arg,
struct sk_buff *resp);
static inline int digital_tg_listen(struct nfc_digital_dev *ddev, u16 timeout,
nfc_digital_cmd_complete_t cb, void *arg)
{
return digital_send_cmd(ddev, DIGITAL_CMD_TG_LISTEN, NULL, NULL,
timeout, cb, arg);
}
void digital_tg_recv_atr_req(struct nfc_digital_dev *ddev, void *arg,
struct sk_buff *resp);
int digital_tg_send_dep_res(struct nfc_digital_dev *ddev, struct sk_buff *skb);
int digital_tg_listen_nfca(struct nfc_digital_dev *ddev, u8 rf_tech);
int digital_tg_listen_nfcf(struct nfc_digital_dev *ddev, u8 rf_tech);
void digital_tg_recv_md_req(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 19:55:27 +04:00
typedef u16 (*crc_func_t)(u16, const u8 *, size_t);
#define CRC_A_INIT 0x6363
#define CRC_B_INIT 0xFFFF
#define CRC_F_INIT 0x0000
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 19:55:27 +04:00
void digital_skb_add_crc(struct sk_buff *skb, crc_func_t crc_func, u16 init,
u8 bitwise_inv, u8 msb_first);
static inline void digital_skb_add_crc_a(struct sk_buff *skb)
{
digital_skb_add_crc(skb, crc_ccitt, CRC_A_INIT, 0, 0);
}
static inline void digital_skb_add_crc_b(struct sk_buff *skb)
{
digital_skb_add_crc(skb, crc_ccitt, CRC_B_INIT, 1, 0);
}
static inline void digital_skb_add_crc_f(struct sk_buff *skb)
{
digital_skb_add_crc(skb, crc_itu_t, CRC_F_INIT, 0, 1);
}
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 19:55:27 +04:00
static inline void digital_skb_add_crc_none(struct sk_buff *skb)
{
return;
}
int digital_skb_check_crc(struct sk_buff *skb, crc_func_t crc_func,
u16 crc_init, u8 bitwise_inv, u8 msb_first);
static inline int digital_skb_check_crc_a(struct sk_buff *skb)
{
return digital_skb_check_crc(skb, crc_ccitt, CRC_A_INIT, 0, 0);
}
static inline int digital_skb_check_crc_b(struct sk_buff *skb)
{
return digital_skb_check_crc(skb, crc_ccitt, CRC_B_INIT, 1, 0);
}
static inline int digital_skb_check_crc_f(struct sk_buff *skb)
{
return digital_skb_check_crc(skb, crc_itu_t, CRC_F_INIT, 0, 1);
}
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 19:55:27 +04:00
static inline int digital_skb_check_crc_none(struct sk_buff *skb)
{
return 0;
}
NFC: Digital Protocol stack implementation This is the initial commit of the NFC Digital Protocol stack implementation. It offers an interface for devices that don't have an embedded NFC Digital protocol stack. The driver instantiates the digital stack by calling nfc_digital_allocate_device(). Within the nfc_digital_ops structure, the driver specifies a set of function pointers for driver operations. These functions must be implemented by the driver and are: in_configure_hw: Hardware configuration for RF technology and communication framing in initiator mode. This is a synchronous function. in_send_cmd: Initiator mode data exchange using RF technology and framing previously set with in_configure_hw. The peer response is returned through callback cb. If an io error occurs or the peer didn't reply within the specified timeout (ms), the error code is passed back through the resp pointer. This is an asynchronous function. tg_configure_hw: Hardware configuration for RF technology and communication framing in target mode. This is a synchronous function. tg_send_cmd: Target mode data exchange using RF technology and framing previously set with tg_configure_hw. The peer next command is returned through callback cb. If an io error occurs or the peer didn't reply within the specified timeout (ms), the error code is passed back through the resp pointer. This is an asynchronous function. tg_listen: Put the device in listen mode waiting for data from the peer device. This is an asynchronous function. tg_listen_mdaa: If supported, put the device in automatic listen mode with mode detection and automatic anti-collision. In this mode, the device automatically detects the RF technology and executes the anti-collision detection using the command responses specified in mdaa_params. The mdaa_params structure contains SENS_RES, NFCID1, and SEL_RES for 106A RF tech. NFCID2 and system code (sc) for 212F and 424F. The driver returns the NFC-DEP ATR_REQ command through cb. The digital stack deducts the RF tech by analyzing the SoD of the frame containing the ATR_REQ command. This is an asynchronous function. switch_rf: Turns device radio on or off. The stack does not call explicitly switch_rf to turn the radio on. A call to in|tg_configure_hw must turn the device radio on. abort_cmd: Discard the last sent command. Then the driver registers itself against the digital stack by using nfc_digital_register_device() which in turn registers the digital stack against the NFC core layer. The digital stack implements common NFC operations like dev_up(), dev_down(), start_poll(), stop_poll(), etc. This patch is only a skeleton and NFC operations are just stubs. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-09-19 19:55:25 +04:00
#endif /* __DIGITAL_H */