linux_dsm_epyc7002/net/nfc/digital_technology.c

347 lines
7.3 KiB
C
Raw Normal View History

/*
* 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.
*
*/
#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 22:55:27 +07:00
#define DIGITAL_SEL_RES_NFCID1_COMPLETE(sel_res) (!((sel_res) & 0x04))
#define DIGITAL_SEL_RES_IS_T2T(sel_res) (!((sel_res) & 0x60))
#define DIGITAL_SENS_RES_IS_T1T(sens_res) (((sens_res) & 0x000C) == 0x000C)
#define DIGITAL_SENS_RES_IS_VALID(sens_res) \
((!((sens_res) & 0x1F00) && (((sens_res) & 0x000C) == 0x000C)) || \
(((sens_res) & 0x1F00) && ((sens_res) & 0x000C) != 0x000C))
#define DIGITAL_MIFARE_READ_RES_LEN 16
#define DIGITAL_MIFARE_ACK_RES 0x0A
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;
static int digital_in_send_sdd_req(struct nfc_digital_dev *ddev,
struct nfc_target *target);
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;
}
if (DIGITAL_SEL_RES_IS_T2T(sel_res)) {
nfc_proto = NFC_PROTO_MIFARE;
} else {
rc = -EOPNOTSUPP;
goto exit;
}
target->sel_res = sel_res;
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);
if (!skb) {
PR_ERR("alloc_skb failed");
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);
}
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 22:55:27 +07:00
struct nfc_target *target = NULL;
u16 sens_res;
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;
}
memcpy(&target->sens_res, resp->data, sizeof(u16));
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 22:55:27 +07:00
sens_res = be16_to_cpu(target->sens_res);
if (!DIGITAL_SENS_RES_IS_VALID(sens_res)) {
PROTOCOL_ERR("4.6.3.3");
rc = -EINVAL;
goto exit;
}
if (DIGITAL_SENS_RES_IS_T1T(sens_res))
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);
}
}
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 22:55:27 +07: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;
}