2019-05-29 22:18:02 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
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 23:55:25 +08:00
|
|
|
/*
|
|
|
|
|
* NFC Digital Protocol stack
|
|
|
|
|
* Copyright (c) 2013, Intel Corporation.
|
|
|
|
|
*/
|
|
|
|
|
|
2013-09-20 15:05:48 +08:00
|
|
|
#define pr_fmt(fmt) "digital: %s: " fmt, __func__
|
|
|
|
|
|
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 23:55:25 +08:00
|
|
|
#include <linux/module.h>
|
|
|
|
|
|
|
|
|
|
#include "digital.h"
|
|
|
|
|
|
2013-09-19 23:55:26 +08:00
|
|
|
#define DIGITAL_PROTO_NFCA_RF_TECH \
|
2015-11-20 19:40:19 +08:00
|
|
|
(NFC_PROTO_JEWEL_MASK | NFC_PROTO_MIFARE_MASK | \
|
|
|
|
|
NFC_PROTO_NFC_DEP_MASK | NFC_PROTO_ISO14443_MASK)
|
2013-09-19 23:55:26 +08:00
|
|
|
|
2014-04-01 08:36:38 +08:00
|
|
|
#define DIGITAL_PROTO_NFCB_RF_TECH NFC_PROTO_ISO14443_B_MASK
|
|
|
|
|
|
2013-09-19 23:55:29 +08:00
|
|
|
#define DIGITAL_PROTO_NFCF_RF_TECH \
|
|
|
|
|
(NFC_PROTO_FELICA_MASK | NFC_PROTO_NFC_DEP_MASK)
|
2013-09-19 23:55:28 +08:00
|
|
|
|
2014-01-22 07:23:59 +08:00
|
|
|
#define DIGITAL_PROTO_ISO15693_RF_TECH NFC_PROTO_ISO15693_MASK
|
|
|
|
|
|
2016-06-07 22:21:52 +08:00
|
|
|
/* Delay between each poll frame (ms) */
|
|
|
|
|
#define DIGITAL_POLL_INTERVAL 10
|
|
|
|
|
|
2013-09-19 23:55:26 +08:00
|
|
|
struct digital_cmd {
|
|
|
|
|
struct list_head queue;
|
|
|
|
|
|
|
|
|
|
u8 type;
|
|
|
|
|
u8 pending;
|
|
|
|
|
|
|
|
|
|
u16 timeout;
|
|
|
|
|
struct sk_buff *req;
|
|
|
|
|
struct sk_buff *resp;
|
2013-09-19 23:55:30 +08:00
|
|
|
struct digital_tg_mdaa_params *mdaa_params;
|
2013-09-19 23:55:26 +08:00
|
|
|
|
|
|
|
|
nfc_digital_cmd_complete_t cmd_cb;
|
|
|
|
|
void *cb_context;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct sk_buff *digital_skb_alloc(struct nfc_digital_dev *ddev,
|
|
|
|
|
unsigned int len)
|
|
|
|
|
{
|
|
|
|
|
struct sk_buff *skb;
|
|
|
|
|
|
|
|
|
|
skb = alloc_skb(len + ddev->tx_headroom + ddev->tx_tailroom,
|
|
|
|
|
GFP_KERNEL);
|
|
|
|
|
if (skb)
|
|
|
|
|
skb_reserve(skb, ddev->tx_headroom);
|
|
|
|
|
|
|
|
|
|
return 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
|
|
|
void digital_skb_add_crc(struct sk_buff *skb, crc_func_t crc_func, u16 init,
|
|
|
|
|
u8 bitwise_inv, u8 msb_first)
|
|
|
|
|
{
|
|
|
|
|
u16 crc;
|
|
|
|
|
|
|
|
|
|
crc = crc_func(init, skb->data, skb->len);
|
|
|
|
|
|
|
|
|
|
if (bitwise_inv)
|
|
|
|
|
crc = ~crc;
|
|
|
|
|
|
|
|
|
|
if (msb_first)
|
|
|
|
|
crc = __fswab16(crc);
|
|
|
|
|
|
networking: add and use skb_put_u8()
Joe and Bjørn suggested that it'd be nicer to not have the
cast in the fairly common case of doing
*(u8 *)skb_put(skb, 1) = c;
Add skb_put_u8() for this case, and use it across the code,
using the following spatch:
@@
expression SKB, C, S;
typedef u8;
identifier fn = {skb_put};
fresh identifier fn2 = fn ## "_u8";
@@
- *(u8 *)fn(SKB, S) = C;
+ fn2(SKB, C);
Note that due to the "S", the spatch isn't perfect, it should
have checked that S is 1, but there's also places that use a
sizeof expression like sizeof(var) or sizeof(u8) etc. Turns
out that nobody ever did something like
*(u8 *)skb_put(skb, 2) = c;
which would be wrong anyway since the second byte wouldn't be
initialized.
Suggested-by: Joe Perches <joe@perches.com>
Suggested-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 20:29:24 +08:00
|
|
|
skb_put_u8(skb, crc & 0xFF);
|
|
|
|
|
skb_put_u8(skb, (crc >> 8) & 0xFF);
|
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_skb_check_crc(struct sk_buff *skb, crc_func_t crc_func,
|
|
|
|
|
u16 crc_init, u8 bitwise_inv, u8 msb_first)
|
|
|
|
|
{
|
|
|
|
|
int rc;
|
|
|
|
|
u16 crc;
|
|
|
|
|
|
|
|
|
|
if (skb->len <= 2)
|
|
|
|
|
return -EIO;
|
|
|
|
|
|
|
|
|
|
crc = crc_func(crc_init, skb->data, skb->len - 2);
|
|
|
|
|
|
|
|
|
|
if (bitwise_inv)
|
|
|
|
|
crc = ~crc;
|
|
|
|
|
|
|
|
|
|
if (msb_first)
|
|
|
|
|
crc = __swab16(crc);
|
|
|
|
|
|
|
|
|
|
rc = (skb->data[skb->len - 2] - (crc & 0xFF)) +
|
|
|
|
|
(skb->data[skb->len - 1] - ((crc >> 8) & 0xFF));
|
|
|
|
|
|
|
|
|
|
if (rc)
|
|
|
|
|
return -EIO;
|
|
|
|
|
|
|
|
|
|
skb_trim(skb, skb->len - 2);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2013-09-19 23:55:26 +08:00
|
|
|
static inline void digital_switch_rf(struct nfc_digital_dev *ddev, bool on)
|
|
|
|
|
{
|
|
|
|
|
ddev->ops->switch_rf(ddev, on);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void digital_abort_cmd(struct nfc_digital_dev *ddev)
|
|
|
|
|
{
|
|
|
|
|
ddev->ops->abort_cmd(ddev);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void digital_wq_cmd_complete(struct work_struct *work)
|
|
|
|
|
{
|
|
|
|
|
struct digital_cmd *cmd;
|
|
|
|
|
struct nfc_digital_dev *ddev = container_of(work,
|
|
|
|
|
struct nfc_digital_dev,
|
|
|
|
|
cmd_complete_work);
|
|
|
|
|
|
|
|
|
|
mutex_lock(&ddev->cmd_lock);
|
|
|
|
|
|
|
|
|
|
cmd = list_first_entry_or_null(&ddev->cmd_queue, struct digital_cmd,
|
|
|
|
|
queue);
|
|
|
|
|
if (!cmd) {
|
|
|
|
|
mutex_unlock(&ddev->cmd_lock);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
list_del(&cmd->queue);
|
|
|
|
|
|
|
|
|
|
mutex_unlock(&ddev->cmd_lock);
|
|
|
|
|
|
|
|
|
|
if (!IS_ERR(cmd->resp))
|
|
|
|
|
print_hex_dump_debug("DIGITAL RX: ", DUMP_PREFIX_NONE, 16, 1,
|
|
|
|
|
cmd->resp->data, cmd->resp->len, false);
|
|
|
|
|
|
|
|
|
|
cmd->cmd_cb(ddev, cmd->cb_context, cmd->resp);
|
|
|
|
|
|
2013-09-19 23:55:30 +08:00
|
|
|
kfree(cmd->mdaa_params);
|
2013-09-19 23:55:26 +08:00
|
|
|
kfree(cmd);
|
|
|
|
|
|
|
|
|
|
schedule_work(&ddev->cmd_work);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void digital_send_cmd_complete(struct nfc_digital_dev *ddev,
|
|
|
|
|
void *arg, struct sk_buff *resp)
|
|
|
|
|
{
|
|
|
|
|
struct digital_cmd *cmd = arg;
|
|
|
|
|
|
|
|
|
|
cmd->resp = resp;
|
|
|
|
|
|
|
|
|
|
schedule_work(&ddev->cmd_complete_work);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void digital_wq_cmd(struct work_struct *work)
|
|
|
|
|
{
|
|
|
|
|
int rc;
|
|
|
|
|
struct digital_cmd *cmd;
|
2013-09-19 23:55:30 +08:00
|
|
|
struct digital_tg_mdaa_params *params;
|
2013-09-19 23:55:26 +08:00
|
|
|
struct nfc_digital_dev *ddev = container_of(work,
|
|
|
|
|
struct nfc_digital_dev,
|
|
|
|
|
cmd_work);
|
|
|
|
|
|
|
|
|
|
mutex_lock(&ddev->cmd_lock);
|
|
|
|
|
|
|
|
|
|
cmd = list_first_entry_or_null(&ddev->cmd_queue, struct digital_cmd,
|
|
|
|
|
queue);
|
|
|
|
|
if (!cmd || cmd->pending) {
|
|
|
|
|
mutex_unlock(&ddev->cmd_lock);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2016-06-17 02:24:44 +08:00
|
|
|
cmd->pending = 1;
|
|
|
|
|
|
2013-09-19 23:55:26 +08:00
|
|
|
mutex_unlock(&ddev->cmd_lock);
|
|
|
|
|
|
|
|
|
|
if (cmd->req)
|
|
|
|
|
print_hex_dump_debug("DIGITAL TX: ", DUMP_PREFIX_NONE, 16, 1,
|
|
|
|
|
cmd->req->data, cmd->req->len, false);
|
|
|
|
|
|
|
|
|
|
switch (cmd->type) {
|
|
|
|
|
case DIGITAL_CMD_IN_SEND:
|
|
|
|
|
rc = ddev->ops->in_send_cmd(ddev, cmd->req, cmd->timeout,
|
|
|
|
|
digital_send_cmd_complete, cmd);
|
|
|
|
|
break;
|
2013-09-19 23:55:30 +08:00
|
|
|
|
|
|
|
|
case DIGITAL_CMD_TG_SEND:
|
|
|
|
|
rc = ddev->ops->tg_send_cmd(ddev, cmd->req, cmd->timeout,
|
|
|
|
|
digital_send_cmd_complete, cmd);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DIGITAL_CMD_TG_LISTEN:
|
|
|
|
|
rc = ddev->ops->tg_listen(ddev, cmd->timeout,
|
|
|
|
|
digital_send_cmd_complete, cmd);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case DIGITAL_CMD_TG_LISTEN_MDAA:
|
|
|
|
|
params = cmd->mdaa_params;
|
|
|
|
|
|
|
|
|
|
rc = ddev->ops->tg_listen_mdaa(ddev, params, cmd->timeout,
|
|
|
|
|
digital_send_cmd_complete, cmd);
|
|
|
|
|
break;
|
|
|
|
|
|
2014-07-22 12:24:39 +08:00
|
|
|
case DIGITAL_CMD_TG_LISTEN_MD:
|
|
|
|
|
rc = ddev->ops->tg_listen_md(ddev, cmd->timeout,
|
|
|
|
|
digital_send_cmd_complete, cmd);
|
|
|
|
|
break;
|
|
|
|
|
|
2013-09-19 23:55:26 +08:00
|
|
|
default:
|
2013-09-20 22:56:40 +08:00
|
|
|
pr_err("Unknown cmd type %d\n", cmd->type);
|
2013-09-19 23:55:26 +08:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!rc)
|
|
|
|
|
return;
|
|
|
|
|
|
2013-09-20 22:56:40 +08:00
|
|
|
pr_err("in_send_command returned err %d\n", rc);
|
2013-09-19 23:55:26 +08:00
|
|
|
|
|
|
|
|
mutex_lock(&ddev->cmd_lock);
|
|
|
|
|
list_del(&cmd->queue);
|
|
|
|
|
mutex_unlock(&ddev->cmd_lock);
|
|
|
|
|
|
|
|
|
|
kfree_skb(cmd->req);
|
2013-09-19 23:55:30 +08:00
|
|
|
kfree(cmd->mdaa_params);
|
2013-09-19 23:55:26 +08:00
|
|
|
kfree(cmd);
|
|
|
|
|
|
|
|
|
|
schedule_work(&ddev->cmd_work);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int digital_send_cmd(struct nfc_digital_dev *ddev, u8 cmd_type,
|
2013-09-19 23:55:30 +08:00
|
|
|
struct sk_buff *skb, struct digital_tg_mdaa_params *params,
|
|
|
|
|
u16 timeout, nfc_digital_cmd_complete_t cmd_cb,
|
|
|
|
|
void *cb_context)
|
2013-09-19 23:55:26 +08:00
|
|
|
{
|
|
|
|
|
struct digital_cmd *cmd;
|
|
|
|
|
|
2017-05-22 20:11:01 +08:00
|
|
|
cmd = kzalloc(sizeof(*cmd), GFP_KERNEL);
|
2013-09-19 23:55:26 +08:00
|
|
|
if (!cmd)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
|
|
cmd->type = cmd_type;
|
|
|
|
|
cmd->timeout = timeout;
|
|
|
|
|
cmd->req = skb;
|
2013-09-19 23:55:30 +08:00
|
|
|
cmd->mdaa_params = params;
|
2013-09-19 23:55:26 +08:00
|
|
|
cmd->cmd_cb = cmd_cb;
|
|
|
|
|
cmd->cb_context = cb_context;
|
|
|
|
|
INIT_LIST_HEAD(&cmd->queue);
|
|
|
|
|
|
|
|
|
|
mutex_lock(&ddev->cmd_lock);
|
|
|
|
|
list_add_tail(&cmd->queue, &ddev->cmd_queue);
|
|
|
|
|
mutex_unlock(&ddev->cmd_lock);
|
|
|
|
|
|
|
|
|
|
schedule_work(&ddev->cmd_work);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int digital_in_configure_hw(struct nfc_digital_dev *ddev, int type, int param)
|
|
|
|
|
{
|
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
|
|
rc = ddev->ops->in_configure_hw(ddev, type, param);
|
|
|
|
|
if (rc)
|
2013-09-20 22:56:40 +08:00
|
|
|
pr_err("in_configure_hw failed: %d\n", rc);
|
2013-09-19 23:55:26 +08:00
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
2013-09-19 23:55:30 +08:00
|
|
|
int digital_tg_configure_hw(struct nfc_digital_dev *ddev, int type, int param)
|
|
|
|
|
{
|
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
|
|
rc = ddev->ops->tg_configure_hw(ddev, type, param);
|
|
|
|
|
if (rc)
|
2013-09-20 22:56:40 +08:00
|
|
|
pr_err("tg_configure_hw failed: %d\n", rc);
|
2013-09-19 23:55:30 +08:00
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int digital_tg_listen_mdaa(struct nfc_digital_dev *ddev, u8 rf_tech)
|
|
|
|
|
{
|
|
|
|
|
struct digital_tg_mdaa_params *params;
|
|
|
|
|
|
2017-05-22 20:11:01 +08:00
|
|
|
params = kzalloc(sizeof(*params), GFP_KERNEL);
|
2013-09-19 23:55:30 +08:00
|
|
|
if (!params)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
|
|
params->sens_res = DIGITAL_SENS_RES_NFC_DEP;
|
|
|
|
|
get_random_bytes(params->nfcid1, sizeof(params->nfcid1));
|
|
|
|
|
params->sel_res = DIGITAL_SEL_RES_NFC_DEP;
|
|
|
|
|
|
|
|
|
|
params->nfcid2[0] = DIGITAL_SENSF_NFCID2_NFC_DEP_B1;
|
|
|
|
|
params->nfcid2[1] = DIGITAL_SENSF_NFCID2_NFC_DEP_B2;
|
|
|
|
|
get_random_bytes(params->nfcid2 + 2, NFC_NFCID2_MAXSIZE - 2);
|
|
|
|
|
params->sc = DIGITAL_SENSF_FELICA_SC;
|
|
|
|
|
|
|
|
|
|
return digital_send_cmd(ddev, DIGITAL_CMD_TG_LISTEN_MDAA, NULL, params,
|
|
|
|
|
500, digital_tg_recv_atr_req, NULL);
|
|
|
|
|
}
|
|
|
|
|
|
2014-07-22 12:24:39 +08:00
|
|
|
static int digital_tg_listen_md(struct nfc_digital_dev *ddev, u8 rf_tech)
|
|
|
|
|
{
|
|
|
|
|
return digital_send_cmd(ddev, DIGITAL_CMD_TG_LISTEN_MD, NULL, NULL, 500,
|
|
|
|
|
digital_tg_recv_md_req, NULL);
|
|
|
|
|
}
|
|
|
|
|
|
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_target_found(struct nfc_digital_dev *ddev,
|
|
|
|
|
struct nfc_target *target, u8 protocol)
|
|
|
|
|
{
|
|
|
|
|
int rc;
|
|
|
|
|
u8 framing;
|
|
|
|
|
u8 rf_tech;
|
2014-07-03 00:03:49 +08:00
|
|
|
u8 poll_tech_count;
|
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 (*check_crc)(struct sk_buff *skb);
|
|
|
|
|
void (*add_crc)(struct sk_buff *skb);
|
|
|
|
|
|
|
|
|
|
rf_tech = ddev->poll_techs[ddev->poll_tech_index].rf_tech;
|
|
|
|
|
|
|
|
|
|
switch (protocol) {
|
|
|
|
|
case NFC_PROTO_JEWEL:
|
|
|
|
|
framing = NFC_DIGITAL_FRAMING_NFCA_T1T;
|
|
|
|
|
check_crc = digital_skb_check_crc_b;
|
|
|
|
|
add_crc = digital_skb_add_crc_b;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case NFC_PROTO_MIFARE:
|
|
|
|
|
framing = NFC_DIGITAL_FRAMING_NFCA_T2T;
|
|
|
|
|
check_crc = digital_skb_check_crc_a;
|
|
|
|
|
add_crc = digital_skb_add_crc_a;
|
|
|
|
|
break;
|
|
|
|
|
|
2013-09-19 23:55:28 +08:00
|
|
|
case NFC_PROTO_FELICA:
|
|
|
|
|
framing = NFC_DIGITAL_FRAMING_NFCF_T3T;
|
|
|
|
|
check_crc = digital_skb_check_crc_f;
|
|
|
|
|
add_crc = digital_skb_add_crc_f;
|
|
|
|
|
break;
|
|
|
|
|
|
2013-09-19 23:55:29 +08:00
|
|
|
case NFC_PROTO_NFC_DEP:
|
|
|
|
|
if (rf_tech == NFC_DIGITAL_RF_TECH_106A) {
|
|
|
|
|
framing = NFC_DIGITAL_FRAMING_NFCA_NFC_DEP;
|
|
|
|
|
check_crc = digital_skb_check_crc_a;
|
|
|
|
|
add_crc = digital_skb_add_crc_a;
|
|
|
|
|
} else {
|
|
|
|
|
framing = NFC_DIGITAL_FRAMING_NFCF_NFC_DEP;
|
|
|
|
|
check_crc = digital_skb_check_crc_f;
|
|
|
|
|
add_crc = digital_skb_add_crc_f;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
|
2014-01-22 07:23:59 +08:00
|
|
|
case NFC_PROTO_ISO15693:
|
2014-03-06 22:39:19 +08:00
|
|
|
framing = NFC_DIGITAL_FRAMING_ISO15693_T5T;
|
2014-01-22 07:23:59 +08:00
|
|
|
check_crc = digital_skb_check_crc_b;
|
|
|
|
|
add_crc = digital_skb_add_crc_b;
|
2014-02-12 19:13:23 +08:00
|
|
|
break;
|
2014-01-27 07:31:31 +08:00
|
|
|
|
|
|
|
|
case NFC_PROTO_ISO14443:
|
|
|
|
|
framing = NFC_DIGITAL_FRAMING_NFCA_T4T;
|
|
|
|
|
check_crc = digital_skb_check_crc_a;
|
|
|
|
|
add_crc = digital_skb_add_crc_a;
|
2014-01-22 07:23:59 +08:00
|
|
|
break;
|
|
|
|
|
|
2014-04-01 08:36:38 +08:00
|
|
|
case NFC_PROTO_ISO14443_B:
|
|
|
|
|
framing = NFC_DIGITAL_FRAMING_NFCB_T4T;
|
|
|
|
|
check_crc = digital_skb_check_crc_b;
|
|
|
|
|
add_crc = digital_skb_add_crc_b;
|
|
|
|
|
break;
|
|
|
|
|
|
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
|
|
|
default:
|
2013-09-20 22:56:40 +08:00
|
|
|
pr_err("Invalid protocol %d\n", protocol);
|
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 -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
2013-09-20 22:56:40 +08:00
|
|
|
pr_debug("rf_tech=%d, protocol=%d\n", rf_tech, protocol);
|
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
|
|
|
|
|
|
|
|
ddev->curr_rf_tech = rf_tech;
|
|
|
|
|
|
|
|
|
|
if (DIGITAL_DRV_CAPS_IN_CRC(ddev)) {
|
|
|
|
|
ddev->skb_add_crc = digital_skb_add_crc_none;
|
|
|
|
|
ddev->skb_check_crc = digital_skb_check_crc_none;
|
|
|
|
|
} else {
|
|
|
|
|
ddev->skb_add_crc = add_crc;
|
|
|
|
|
ddev->skb_check_crc = check_crc;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
rc = digital_in_configure_hw(ddev, NFC_DIGITAL_CONFIG_FRAMING, framing);
|
|
|
|
|
if (rc)
|
|
|
|
|
return rc;
|
|
|
|
|
|
|
|
|
|
target->supported_protocols = (1 << protocol);
|
|
|
|
|
|
2014-07-03 00:03:49 +08:00
|
|
|
poll_tech_count = ddev->poll_tech_count;
|
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
|
|
|
ddev->poll_tech_count = 0;
|
|
|
|
|
|
2014-07-03 00:03:49 +08:00
|
|
|
rc = nfc_targets_found(ddev->nfc_dev, target, 1);
|
|
|
|
|
if (rc) {
|
|
|
|
|
ddev->poll_tech_count = poll_tech_count;
|
|
|
|
|
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
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2013-09-19 23:55:26 +08:00
|
|
|
void digital_poll_next_tech(struct nfc_digital_dev *ddev)
|
|
|
|
|
{
|
2014-05-10 19:06:02 +08:00
|
|
|
u8 rand_mod;
|
|
|
|
|
|
2013-09-19 23:55:26 +08:00
|
|
|
digital_switch_rf(ddev, 0);
|
|
|
|
|
|
|
|
|
|
mutex_lock(&ddev->poll_lock);
|
|
|
|
|
|
|
|
|
|
if (!ddev->poll_tech_count) {
|
|
|
|
|
mutex_unlock(&ddev->poll_lock);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2014-05-10 19:06:02 +08:00
|
|
|
get_random_bytes(&rand_mod, sizeof(rand_mod));
|
|
|
|
|
ddev->poll_tech_index = rand_mod % ddev->poll_tech_count;
|
2013-09-19 23:55:26 +08:00
|
|
|
|
|
|
|
|
mutex_unlock(&ddev->poll_lock);
|
|
|
|
|
|
2016-06-07 22:21:52 +08:00
|
|
|
schedule_delayed_work(&ddev->poll_work,
|
|
|
|
|
msecs_to_jiffies(DIGITAL_POLL_INTERVAL));
|
2013-09-19 23:55:26 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void digital_wq_poll(struct work_struct *work)
|
|
|
|
|
{
|
|
|
|
|
int rc;
|
|
|
|
|
struct digital_poll_tech *poll_tech;
|
|
|
|
|
struct nfc_digital_dev *ddev = container_of(work,
|
|
|
|
|
struct nfc_digital_dev,
|
2016-06-07 22:21:52 +08:00
|
|
|
poll_work.work);
|
2013-09-19 23:55:26 +08:00
|
|
|
mutex_lock(&ddev->poll_lock);
|
|
|
|
|
|
|
|
|
|
if (!ddev->poll_tech_count) {
|
|
|
|
|
mutex_unlock(&ddev->poll_lock);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
poll_tech = &ddev->poll_techs[ddev->poll_tech_index];
|
|
|
|
|
|
|
|
|
|
mutex_unlock(&ddev->poll_lock);
|
|
|
|
|
|
|
|
|
|
rc = poll_tech->poll_func(ddev, poll_tech->rf_tech);
|
|
|
|
|
if (rc)
|
|
|
|
|
digital_poll_next_tech(ddev);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void digital_add_poll_tech(struct nfc_digital_dev *ddev, u8 rf_tech,
|
|
|
|
|
digital_poll_t poll_func)
|
|
|
|
|
{
|
|
|
|
|
struct digital_poll_tech *poll_tech;
|
|
|
|
|
|
|
|
|
|
if (ddev->poll_tech_count >= NFC_DIGITAL_POLL_MODE_COUNT_MAX)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
poll_tech = &ddev->poll_techs[ddev->poll_tech_count++];
|
|
|
|
|
|
|
|
|
|
poll_tech->rf_tech = rf_tech;
|
|
|
|
|
poll_tech->poll_func = poll_func;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2021-03-27 16:15:56 +08:00
|
|
|
* digital_start_poll - start_poll operation
|
2020-10-28 08:56:53 +08:00
|
|
|
* @nfc_dev: device to be polled
|
|
|
|
|
* @im_protocols: bitset of nfc initiator protocols to be used for polling
|
|
|
|
|
* @tm_protocols: bitset of nfc transport protocols to be used for polling
|
2013-09-19 23:55:26 +08:00
|
|
|
*
|
|
|
|
|
* For every supported protocol, the corresponding polling function is added
|
|
|
|
|
* to the table of polling technologies (ddev->poll_techs[]) using
|
|
|
|
|
* digital_add_poll_tech().
|
|
|
|
|
* When a polling function fails (by timeout or protocol error) the next one is
|
|
|
|
|
* schedule by digital_poll_next_tech() on the poll workqueue (ddev->poll_work).
|
|
|
|
|
*/
|
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 23:55:25 +08:00
|
|
|
static int digital_start_poll(struct nfc_dev *nfc_dev, __u32 im_protocols,
|
|
|
|
|
__u32 tm_protocols)
|
|
|
|
|
{
|
2013-09-19 23:55:26 +08:00
|
|
|
struct nfc_digital_dev *ddev = nfc_get_drvdata(nfc_dev);
|
|
|
|
|
u32 matching_im_protocols, matching_tm_protocols;
|
|
|
|
|
|
2013-09-20 22:56:40 +08:00
|
|
|
pr_debug("protocols: im 0x%x, tm 0x%x, supported 0x%x\n", im_protocols,
|
2013-09-20 15:05:48 +08:00
|
|
|
tm_protocols, ddev->protocols);
|
2013-09-19 23:55:26 +08:00
|
|
|
|
|
|
|
|
matching_im_protocols = ddev->protocols & im_protocols;
|
|
|
|
|
matching_tm_protocols = ddev->protocols & tm_protocols;
|
|
|
|
|
|
|
|
|
|
if (!matching_im_protocols && !matching_tm_protocols) {
|
2013-09-20 22:56:40 +08:00
|
|
|
pr_err("Unknown protocol\n");
|
2013-09-19 23:55:26 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (ddev->poll_tech_count) {
|
2013-09-20 22:56:40 +08:00
|
|
|
pr_err("Already polling\n");
|
2013-09-19 23:55:26 +08:00
|
|
|
return -EBUSY;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (ddev->curr_protocol) {
|
2013-09-20 22:56:40 +08:00
|
|
|
pr_err("A target is already active\n");
|
2013-09-19 23:55:26 +08:00
|
|
|
return -EBUSY;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ddev->poll_tech_count = 0;
|
|
|
|
|
ddev->poll_tech_index = 0;
|
|
|
|
|
|
|
|
|
|
if (matching_im_protocols & DIGITAL_PROTO_NFCA_RF_TECH)
|
|
|
|
|
digital_add_poll_tech(ddev, NFC_DIGITAL_RF_TECH_106A,
|
|
|
|
|
digital_in_send_sens_req);
|
|
|
|
|
|
2014-04-01 08:36:38 +08:00
|
|
|
if (matching_im_protocols & DIGITAL_PROTO_NFCB_RF_TECH)
|
|
|
|
|
digital_add_poll_tech(ddev, NFC_DIGITAL_RF_TECH_106B,
|
|
|
|
|
digital_in_send_sensb_req);
|
|
|
|
|
|
2014-02-22 10:16:11 +08:00
|
|
|
if (matching_im_protocols & DIGITAL_PROTO_NFCF_RF_TECH) {
|
2013-09-19 23:55:28 +08:00
|
|
|
digital_add_poll_tech(ddev, NFC_DIGITAL_RF_TECH_212F,
|
|
|
|
|
digital_in_send_sensf_req);
|
|
|
|
|
|
|
|
|
|
digital_add_poll_tech(ddev, NFC_DIGITAL_RF_TECH_424F,
|
|
|
|
|
digital_in_send_sensf_req);
|
|
|
|
|
}
|
|
|
|
|
|
2014-01-22 07:23:59 +08:00
|
|
|
if (matching_im_protocols & DIGITAL_PROTO_ISO15693_RF_TECH)
|
|
|
|
|
digital_add_poll_tech(ddev, NFC_DIGITAL_RF_TECH_ISO15693,
|
|
|
|
|
digital_in_send_iso15693_inv_req);
|
|
|
|
|
|
2014-02-22 10:16:11 +08:00
|
|
|
if (matching_tm_protocols & NFC_PROTO_NFC_DEP_MASK) {
|
2013-09-19 23:55:30 +08:00
|
|
|
if (ddev->ops->tg_listen_mdaa) {
|
|
|
|
|
digital_add_poll_tech(ddev, 0,
|
|
|
|
|
digital_tg_listen_mdaa);
|
2014-07-22 12:24:39 +08:00
|
|
|
} else if (ddev->ops->tg_listen_md) {
|
|
|
|
|
digital_add_poll_tech(ddev, 0,
|
|
|
|
|
digital_tg_listen_md);
|
2013-09-19 23:55:30 +08:00
|
|
|
} else {
|
|
|
|
|
digital_add_poll_tech(ddev, NFC_DIGITAL_RF_TECH_106A,
|
|
|
|
|
digital_tg_listen_nfca);
|
|
|
|
|
|
|
|
|
|
digital_add_poll_tech(ddev, NFC_DIGITAL_RF_TECH_212F,
|
|
|
|
|
digital_tg_listen_nfcf);
|
|
|
|
|
|
|
|
|
|
digital_add_poll_tech(ddev, NFC_DIGITAL_RF_TECH_424F,
|
|
|
|
|
digital_tg_listen_nfcf);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-09-19 23:55:26 +08:00
|
|
|
if (!ddev->poll_tech_count) {
|
2013-09-20 22:56:40 +08:00
|
|
|
pr_err("Unsupported protocols: im=0x%x, tm=0x%x\n",
|
2013-09-19 23:55:26 +08:00
|
|
|
matching_im_protocols, matching_tm_protocols);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
2016-06-07 22:21:52 +08:00
|
|
|
schedule_delayed_work(&ddev->poll_work, 0);
|
2013-09-19 23:55:26 +08:00
|
|
|
|
|
|
|
|
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 23:55:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void digital_stop_poll(struct nfc_dev *nfc_dev)
|
|
|
|
|
{
|
2013-09-19 23:55:26 +08:00
|
|
|
struct nfc_digital_dev *ddev = nfc_get_drvdata(nfc_dev);
|
|
|
|
|
|
|
|
|
|
mutex_lock(&ddev->poll_lock);
|
|
|
|
|
|
|
|
|
|
if (!ddev->poll_tech_count) {
|
2013-09-20 22:56:40 +08:00
|
|
|
pr_err("Polling operation was not running\n");
|
2013-09-19 23:55:26 +08:00
|
|
|
mutex_unlock(&ddev->poll_lock);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ddev->poll_tech_count = 0;
|
|
|
|
|
|
|
|
|
|
mutex_unlock(&ddev->poll_lock);
|
|
|
|
|
|
2016-06-07 22:21:52 +08:00
|
|
|
cancel_delayed_work_sync(&ddev->poll_work);
|
2013-09-19 23:55:26 +08:00
|
|
|
|
|
|
|
|
digital_abort_cmd(ddev);
|
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 23:55:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int digital_dev_up(struct nfc_dev *nfc_dev)
|
|
|
|
|
{
|
2013-09-19 23:55:26 +08:00
|
|
|
struct nfc_digital_dev *ddev = nfc_get_drvdata(nfc_dev);
|
|
|
|
|
|
|
|
|
|
digital_switch_rf(ddev, 1);
|
|
|
|
|
|
|
|
|
|
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 23:55:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int digital_dev_down(struct nfc_dev *nfc_dev)
|
|
|
|
|
{
|
2013-09-19 23:55:26 +08:00
|
|
|
struct nfc_digital_dev *ddev = nfc_get_drvdata(nfc_dev);
|
|
|
|
|
|
|
|
|
|
digital_switch_rf(ddev, 0);
|
|
|
|
|
|
|
|
|
|
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 23:55:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int digital_dep_link_up(struct nfc_dev *nfc_dev,
|
|
|
|
|
struct nfc_target *target,
|
|
|
|
|
__u8 comm_mode, __u8 *gb, size_t gb_len)
|
|
|
|
|
{
|
2013-09-19 23:55:29 +08:00
|
|
|
struct nfc_digital_dev *ddev = nfc_get_drvdata(nfc_dev);
|
2014-01-07 06:34:37 +08:00
|
|
|
int rc;
|
|
|
|
|
|
|
|
|
|
rc = digital_in_send_atr_req(ddev, target, comm_mode, gb, gb_len);
|
2013-09-19 23:55:29 +08:00
|
|
|
|
2014-01-07 06:34:37 +08:00
|
|
|
if (!rc)
|
|
|
|
|
ddev->curr_protocol = NFC_PROTO_NFC_DEP;
|
|
|
|
|
|
|
|
|
|
return rc;
|
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 23:55:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int digital_dep_link_down(struct nfc_dev *nfc_dev)
|
|
|
|
|
{
|
2013-09-19 23:55:29 +08:00
|
|
|
struct nfc_digital_dev *ddev = nfc_get_drvdata(nfc_dev);
|
|
|
|
|
|
2016-06-17 02:24:45 +08:00
|
|
|
digital_abort_cmd(ddev);
|
|
|
|
|
|
2013-09-19 23:55:29 +08:00
|
|
|
ddev->curr_protocol = 0;
|
|
|
|
|
|
|
|
|
|
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 23:55:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int digital_activate_target(struct nfc_dev *nfc_dev,
|
|
|
|
|
struct nfc_target *target, __u32 protocol)
|
|
|
|
|
{
|
2014-01-07 06:34:37 +08:00
|
|
|
struct nfc_digital_dev *ddev = nfc_get_drvdata(nfc_dev);
|
|
|
|
|
|
|
|
|
|
if (ddev->poll_tech_count) {
|
|
|
|
|
pr_err("Can't activate a target while polling\n");
|
|
|
|
|
return -EBUSY;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (ddev->curr_protocol) {
|
|
|
|
|
pr_err("A target is already active\n");
|
|
|
|
|
return -EBUSY;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ddev->curr_protocol = protocol;
|
|
|
|
|
|
2013-09-19 23:55:26 +08:00
|
|
|
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 23:55:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void digital_deactivate_target(struct nfc_dev *nfc_dev,
|
2015-10-26 05:54:43 +08:00
|
|
|
struct nfc_target *target,
|
|
|
|
|
u8 mode)
|
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 23:55:25 +08:00
|
|
|
{
|
2013-09-19 23:55:26 +08:00
|
|
|
struct nfc_digital_dev *ddev = nfc_get_drvdata(nfc_dev);
|
|
|
|
|
|
2014-01-07 06:34:37 +08:00
|
|
|
if (!ddev->curr_protocol) {
|
|
|
|
|
pr_err("No active target\n");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-16 11:34:21 +08:00
|
|
|
digital_abort_cmd(ddev);
|
2013-09-19 23:55:26 +08:00
|
|
|
ddev->curr_protocol = 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 23:55:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int digital_tg_send(struct nfc_dev *dev, struct sk_buff *skb)
|
|
|
|
|
{
|
2013-09-19 23:55:30 +08:00
|
|
|
struct nfc_digital_dev *ddev = nfc_get_drvdata(dev);
|
|
|
|
|
|
|
|
|
|
return digital_tg_send_dep_res(ddev, skb);
|
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 23:55:25 +08:00
|
|
|
}
|
|
|
|
|
|
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_send_complete(struct nfc_digital_dev *ddev, void *arg,
|
|
|
|
|
struct sk_buff *resp)
|
|
|
|
|
{
|
|
|
|
|
struct digital_data_exch *data_exch = arg;
|
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
|
|
if (IS_ERR(resp)) {
|
|
|
|
|
rc = PTR_ERR(resp);
|
2014-01-27 07:31:32 +08:00
|
|
|
resp = NULL;
|
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
|
|
|
goto done;
|
|
|
|
|
}
|
|
|
|
|
|
2014-01-27 07:31:32 +08:00
|
|
|
if (ddev->curr_protocol == NFC_PROTO_MIFARE) {
|
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_in_recv_mifare_res(resp);
|
2014-01-27 07:31:32 +08:00
|
|
|
/* crc check is done in digital_in_recv_mifare_res() */
|
|
|
|
|
goto done;
|
|
|
|
|
}
|
|
|
|
|
|
2014-04-01 08:36:38 +08:00
|
|
|
if ((ddev->curr_protocol == NFC_PROTO_ISO14443) ||
|
|
|
|
|
(ddev->curr_protocol == NFC_PROTO_ISO14443_B)) {
|
2014-01-27 07:31:32 +08:00
|
|
|
rc = digital_in_iso_dep_pull_sod(ddev, resp);
|
|
|
|
|
if (rc)
|
|
|
|
|
goto done;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
rc = ddev->skb_check_crc(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
|
|
|
|
2014-01-27 07:31:32 +08:00
|
|
|
done:
|
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 (rc) {
|
|
|
|
|
kfree_skb(resp);
|
|
|
|
|
resp = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
data_exch->cb(data_exch->cb_context, resp, rc);
|
|
|
|
|
|
|
|
|
|
kfree(data_exch);
|
|
|
|
|
}
|
|
|
|
|
|
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 23:55:25 +08:00
|
|
|
static int digital_in_send(struct nfc_dev *nfc_dev, struct nfc_target *target,
|
|
|
|
|
struct sk_buff *skb, data_exchange_cb_t cb,
|
|
|
|
|
void *cb_context)
|
|
|
|
|
{
|
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_digital_dev *ddev = nfc_get_drvdata(nfc_dev);
|
|
|
|
|
struct digital_data_exch *data_exch;
|
2014-01-27 07:31:32 +08:00
|
|
|
int 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
|
|
|
|
2017-05-22 20:11:01 +08:00
|
|
|
data_exch = kzalloc(sizeof(*data_exch), GFP_KERNEL);
|
2017-05-22 20:24:24 +08:00
|
|
|
if (!data_exch)
|
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;
|
|
|
|
|
|
|
|
|
|
data_exch->cb = cb;
|
|
|
|
|
data_exch->cb_context = cb_context;
|
|
|
|
|
|
2014-02-12 21:27:51 +08:00
|
|
|
if (ddev->curr_protocol == NFC_PROTO_NFC_DEP) {
|
|
|
|
|
rc = digital_in_send_dep_req(ddev, target, skb, data_exch);
|
|
|
|
|
goto exit;
|
|
|
|
|
}
|
2013-09-19 23:55:29 +08:00
|
|
|
|
2014-04-01 08:36:38 +08:00
|
|
|
if ((ddev->curr_protocol == NFC_PROTO_ISO14443) ||
|
|
|
|
|
(ddev->curr_protocol == NFC_PROTO_ISO14443_B)) {
|
2014-01-27 07:31:32 +08:00
|
|
|
rc = digital_in_iso_dep_push_sod(ddev, skb);
|
|
|
|
|
if (rc)
|
2014-02-12 21:27:51 +08:00
|
|
|
goto exit;
|
2014-01-27 07:31:32 +08:00
|
|
|
}
|
|
|
|
|
|
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
|
|
|
ddev->skb_add_crc(skb);
|
|
|
|
|
|
2014-02-12 21:27:51 +08:00
|
|
|
rc = digital_in_send_cmd(ddev, skb, 500, digital_in_send_complete,
|
|
|
|
|
data_exch);
|
|
|
|
|
|
|
|
|
|
exit:
|
|
|
|
|
if (rc)
|
|
|
|
|
kfree(data_exch);
|
|
|
|
|
|
|
|
|
|
return rc;
|
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 23:55:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct nfc_ops digital_nfc_ops = {
|
|
|
|
|
.dev_up = digital_dev_up,
|
|
|
|
|
.dev_down = digital_dev_down,
|
|
|
|
|
.start_poll = digital_start_poll,
|
|
|
|
|
.stop_poll = digital_stop_poll,
|
|
|
|
|
.dep_link_up = digital_dep_link_up,
|
|
|
|
|
.dep_link_down = digital_dep_link_down,
|
|
|
|
|
.activate_target = digital_activate_target,
|
|
|
|
|
.deactivate_target = digital_deactivate_target,
|
|
|
|
|
.tm_send = digital_tg_send,
|
|
|
|
|
.im_transceive = digital_in_send,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct nfc_digital_dev *nfc_digital_allocate_device(struct nfc_digital_ops *ops,
|
|
|
|
|
__u32 supported_protocols,
|
|
|
|
|
__u32 driver_capabilities,
|
|
|
|
|
int tx_headroom, int tx_tailroom)
|
|
|
|
|
{
|
|
|
|
|
struct nfc_digital_dev *ddev;
|
|
|
|
|
|
|
|
|
|
if (!ops->in_configure_hw || !ops->in_send_cmd || !ops->tg_listen ||
|
|
|
|
|
!ops->tg_configure_hw || !ops->tg_send_cmd || !ops->abort_cmd ||
|
2014-07-22 12:24:39 +08:00
|
|
|
!ops->switch_rf || (ops->tg_listen_md && !ops->tg_get_rf_tech))
|
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 23:55:25 +08:00
|
|
|
return NULL;
|
|
|
|
|
|
2017-05-22 20:11:01 +08:00
|
|
|
ddev = kzalloc(sizeof(*ddev), GFP_KERNEL);
|
2013-09-20 22:56:40 +08:00
|
|
|
if (!ddev)
|
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 23:55:25 +08:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
ddev->driver_capabilities = driver_capabilities;
|
|
|
|
|
ddev->ops = ops;
|
|
|
|
|
|
2013-09-19 23:55:26 +08:00
|
|
|
mutex_init(&ddev->cmd_lock);
|
|
|
|
|
INIT_LIST_HEAD(&ddev->cmd_queue);
|
|
|
|
|
|
|
|
|
|
INIT_WORK(&ddev->cmd_work, digital_wq_cmd);
|
|
|
|
|
INIT_WORK(&ddev->cmd_complete_work, digital_wq_cmd_complete);
|
|
|
|
|
|
|
|
|
|
mutex_init(&ddev->poll_lock);
|
2016-06-07 22:21:52 +08:00
|
|
|
INIT_DELAYED_WORK(&ddev->poll_work, digital_wq_poll);
|
2013-09-19 23:55:26 +08:00
|
|
|
|
|
|
|
|
if (supported_protocols & NFC_PROTO_JEWEL_MASK)
|
|
|
|
|
ddev->protocols |= NFC_PROTO_JEWEL_MASK;
|
|
|
|
|
if (supported_protocols & NFC_PROTO_MIFARE_MASK)
|
|
|
|
|
ddev->protocols |= NFC_PROTO_MIFARE_MASK;
|
2013-09-19 23:55:28 +08:00
|
|
|
if (supported_protocols & NFC_PROTO_FELICA_MASK)
|
|
|
|
|
ddev->protocols |= NFC_PROTO_FELICA_MASK;
|
2013-09-19 23:55:29 +08:00
|
|
|
if (supported_protocols & NFC_PROTO_NFC_DEP_MASK)
|
|
|
|
|
ddev->protocols |= NFC_PROTO_NFC_DEP_MASK;
|
2014-01-22 07:23:59 +08:00
|
|
|
if (supported_protocols & NFC_PROTO_ISO15693_MASK)
|
|
|
|
|
ddev->protocols |= NFC_PROTO_ISO15693_MASK;
|
2014-01-27 07:31:31 +08:00
|
|
|
if (supported_protocols & NFC_PROTO_ISO14443_MASK)
|
|
|
|
|
ddev->protocols |= NFC_PROTO_ISO14443_MASK;
|
2014-04-01 08:36:38 +08:00
|
|
|
if (supported_protocols & NFC_PROTO_ISO14443_B_MASK)
|
|
|
|
|
ddev->protocols |= NFC_PROTO_ISO14443_B_MASK;
|
2013-09-19 23:55:26 +08:00
|
|
|
|
|
|
|
|
ddev->tx_headroom = tx_headroom + DIGITAL_MAX_HEADER_LEN;
|
|
|
|
|
ddev->tx_tailroom = tx_tailroom + DIGITAL_CRC_LEN;
|
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 23:55:25 +08:00
|
|
|
|
|
|
|
|
ddev->nfc_dev = nfc_allocate_device(&digital_nfc_ops, ddev->protocols,
|
|
|
|
|
ddev->tx_headroom,
|
|
|
|
|
ddev->tx_tailroom);
|
|
|
|
|
if (!ddev->nfc_dev) {
|
2013-09-20 22:56:40 +08:00
|
|
|
pr_err("nfc_allocate_device failed\n");
|
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 23:55:25 +08:00
|
|
|
goto free_dev;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
nfc_set_drvdata(ddev->nfc_dev, ddev);
|
|
|
|
|
|
|
|
|
|
return ddev;
|
|
|
|
|
|
|
|
|
|
free_dev:
|
|
|
|
|
kfree(ddev);
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(nfc_digital_allocate_device);
|
|
|
|
|
|
|
|
|
|
void nfc_digital_free_device(struct nfc_digital_dev *ddev)
|
|
|
|
|
{
|
|
|
|
|
nfc_free_device(ddev->nfc_dev);
|
|
|
|
|
kfree(ddev);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(nfc_digital_free_device);
|
|
|
|
|
|
|
|
|
|
int nfc_digital_register_device(struct nfc_digital_dev *ddev)
|
|
|
|
|
{
|
|
|
|
|
return nfc_register_device(ddev->nfc_dev);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(nfc_digital_register_device);
|
|
|
|
|
|
|
|
|
|
void nfc_digital_unregister_device(struct nfc_digital_dev *ddev)
|
|
|
|
|
{
|
2013-09-19 23:55:26 +08:00
|
|
|
struct digital_cmd *cmd, *n;
|
|
|
|
|
|
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 23:55:25 +08:00
|
|
|
nfc_unregister_device(ddev->nfc_dev);
|
2013-09-19 23:55:26 +08:00
|
|
|
|
|
|
|
|
mutex_lock(&ddev->poll_lock);
|
|
|
|
|
ddev->poll_tech_count = 0;
|
|
|
|
|
mutex_unlock(&ddev->poll_lock);
|
|
|
|
|
|
2016-06-07 22:21:52 +08:00
|
|
|
cancel_delayed_work_sync(&ddev->poll_work);
|
2013-09-19 23:55:26 +08:00
|
|
|
cancel_work_sync(&ddev->cmd_work);
|
|
|
|
|
cancel_work_sync(&ddev->cmd_complete_work);
|
|
|
|
|
|
|
|
|
|
list_for_each_entry_safe(cmd, n, &ddev->cmd_queue, queue) {
|
|
|
|
|
list_del(&cmd->queue);
|
2016-06-17 02:24:43 +08:00
|
|
|
|
|
|
|
|
/* Call the command callback if any and pass it a ENODEV error.
|
|
|
|
|
* This gives a chance to the command issuer to free any
|
|
|
|
|
* allocated buffer.
|
|
|
|
|
*/
|
|
|
|
|
if (cmd->cmd_cb)
|
|
|
|
|
cmd->cmd_cb(ddev, cmd->cb_context, ERR_PTR(-ENODEV));
|
|
|
|
|
|
2013-09-19 23:55:30 +08:00
|
|
|
kfree(cmd->mdaa_params);
|
2013-09-19 23:55:26 +08:00
|
|
|
kfree(cmd);
|
|
|
|
|
}
|
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 23:55:25 +08:00
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(nfc_digital_unregister_device);
|
|
|
|
|
|
|
|
|
|
MODULE_LICENSE("GPL");
|