This adds support for NFC-DEP protocol in initiator mode for NFC-A and
NFC-F technologies.

When a target is detected, the process flow is as follow:

For NFC-A technology:
1 - The digital stack receives a SEL_RES as the reply of the SEL_REQ
    command.
2   - If b7 of SEL_RES is set, the peer device is configure for NFC-DEP
      protocol. NFC core is notified through nfc_targets_found().
      Execution continues at step 4.
3   - Otherwise, it's a tag and the NFC core is notified. Detection
      ends.
4 - The digital stacks sends an ATR_REQ command containing a randomly
    generated NFCID3 and the general bytes obtained from the LLCP layer
    of NFC core.

For NFC-F technology:
1 - The digital stack receives a SENSF_RES as the reply of the
    SENSF_REQ command.
2   - If B1 and B2 of NFCID2 are 0x01 and 0xFE respectively, the peer
      device is configured for NFC-DEP protocol. NFC core is notified
      through nfc_targets_found(). Execution continues at step 4.
3   - Otherwise it's a type 3 tag. NFC core is notified. Detection
      ends.
4 - The digital stacks sends an ATR_REQ command containing the NFC-F
    NFCID2 as NFCID3 and the general bytes obtained from the LLCP layer
    of NFC core.

For both technologies:
5 - The digital stacks receives the ATR_RES response containing the
    NFCID3 and the general bytes of the peer device.
6 - The digital stack notifies NFC core that the DEP link is up through
    nfc_dep_link_up().
7 - The NFC core performs data exchange through tm_transceive().
8 - The digital stack sends a DEP_REQ command containing an I PDU with
    the data from NFC core.
9 - The digital stack receives a DEP_RES command
10  - If the DEP_RES response contains a supervisor PDU with timeout
      extension request (RTOX) the digital stack sends a DEP_REQ
      command containing a supervisor PDU acknowledging the RTOX
      request. The execution continues at step 9.
11  - If the DEP_RES response contains an I PDU, the response data is
      passed back to NFC core through the response callback. The
      execution continues at step 8.
Signed-off-by: NThierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

This adds polling support for NFC-F technology at 212 kbits/s and 424
kbits/s. A user space application like neard can send type 3 tag
commands through the NFC core.

Process flow for NFC-F detection is as follow:

1 - The digital stack sends the SENSF_REQ command to the NFC device.
2 - A peer device replies with a SENSF_RES response.
3   - The digital stack notifies the NFC core of the presence of a
      target in the operation field and passes the target NFCID2.

This also adds support for CRC calculation of type CRC-F. The CRC
calculation is handled by the digital stack if the NFC device doesn't
support it.
Signed-off-by: NThierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

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: NThierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

This implements the mechanism used to send commands to the driver in
initiator mode through in_send_cmd().

Commands are serialized and sent to the driver by using a work item
on the system workqueue. Responses are handled asynchronously by
another work item. Once the digital stack receives the response through
the command_complete callback, the next command is sent to the driver.

This also implements the polling mechanism. It's handled by a work item
cycling on all supported protocols. The start poll command for a given
protocol is sent to the driver using the mechanism described above.
The process continues until a peer is discovered or stop_poll is
called. This patch implements the poll function for NFC-A that sends a
SENS_REQ command and waits for the SENS_RES response.
Signed-off-by: NThierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>