diff options
author | Thierry Escande <thierry.escande@linux.intel.com> | 2013-09-19 17:55:27 +0200 |
---|---|---|
committer | Samuel Ortiz <sameo@linux.intel.com> | 2013-09-25 02:02:23 +0200 |
commit | 2c66daecc4092e6049673c281b2e6f0d5e59a94c (patch) | |
tree | 6aef21e592f00dc55ef5ad582aaaded57f4676c2 /net/nfc/digital.h | |
parent | 59ee2361c9248f07846f7a6e585768dcce18fb16 (diff) |
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>
Diffstat (limited to 'net/nfc/digital.h')
-rw-r--r-- | net/nfc/digital.h | 58 |
1 files changed, 58 insertions, 0 deletions
diff --git a/net/nfc/digital.h b/net/nfc/digital.h index 0a2767098daa..fb5324b792de 100644 --- a/net/nfc/digital.h +++ b/net/nfc/digital.h @@ -19,6 +19,8 @@ #include <net/nfc/nfc.h> #include <net/nfc/digital.h> +#include <linux/crc-ccitt.h> + #define PR_DBG(fmt, ...) pr_debug("%s: " fmt "\n", __func__, ##__VA_ARGS__) #define PR_ERR(fmt, ...) pr_err("%s: " fmt "\n", __func__, ##__VA_ARGS__) #define PROTOCOL_ERR(req) pr_err("%s:%d: NFC Digital Protocol error: %s\n", \ @@ -32,6 +34,16 @@ #define DIGITAL_MAX_HEADER_LEN 7 #define DIGITAL_CRC_LEN 2 +#define DIGITAL_DRV_CAPS_IN_CRC(ddev) \ + ((ddev)->driver_capabilities & NFC_DIGITAL_DRV_CAPS_IN_CRC) +#define DIGITAL_DRV_CAPS_TG_CRC(ddev) \ + ((ddev)->driver_capabilities & NFC_DIGITAL_DRV_CAPS_TG_CRC) + +struct digital_data_exch { + data_exchange_cb_t cb; + void *cb_context; +}; + struct sk_buff *digital_skb_alloc(struct nfc_digital_dev *ddev, unsigned int len); @@ -53,4 +65,50 @@ void digital_poll_next_tech(struct nfc_digital_dev *ddev); int digital_in_send_sens_req(struct nfc_digital_dev *ddev, u8 rf_tech); +int digital_target_found(struct nfc_digital_dev *ddev, + struct nfc_target *target, u8 protocol); + +int digital_in_recv_mifare_res(struct sk_buff *resp); + +typedef u16 (*crc_func_t)(u16, const u8 *, size_t); + +#define CRC_A_INIT 0x6363 +#define CRC_B_INIT 0xFFFF + +void digital_skb_add_crc(struct sk_buff *skb, crc_func_t crc_func, u16 init, + u8 bitwise_inv, u8 msb_first); + +static inline void digital_skb_add_crc_a(struct sk_buff *skb) +{ + digital_skb_add_crc(skb, crc_ccitt, CRC_A_INIT, 0, 0); +} + +static inline void digital_skb_add_crc_b(struct sk_buff *skb) +{ + digital_skb_add_crc(skb, crc_ccitt, CRC_B_INIT, 1, 0); +} + +static inline void digital_skb_add_crc_none(struct sk_buff *skb) +{ + return; +} + +int digital_skb_check_crc(struct sk_buff *skb, crc_func_t crc_func, + u16 crc_init, u8 bitwise_inv, u8 msb_first); + +static inline int digital_skb_check_crc_a(struct sk_buff *skb) +{ + return digital_skb_check_crc(skb, crc_ccitt, CRC_A_INIT, 0, 0); +} + +static inline int digital_skb_check_crc_b(struct sk_buff *skb) +{ + return digital_skb_check_crc(skb, crc_ccitt, CRC_B_INIT, 1, 0); +} + +static inline int digital_skb_check_crc_none(struct sk_buff *skb) +{ + return 0; +} + #endif /* __DIGITAL_H */ |