This implements the target NFC digital operations tg_configure_hw(),
tg_listen(), tg_listen_mdaa(), and tg_send_cmd().

The target mode supports NFC-A technology at 106kbits/s and NFC-F
technologies at 212 and 424kbits/s.
Signed-off-by: NThierry Escande <thierry.escande@linux.intel.com>
Cc: Stephen Tiedemann <stephen.tiedemann@gmail.com>
Tested-by: NCho, Yu-Chen <acho@suse.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

This patch implements the initiator NFC operations in_configure_hw()
and in_send_cmd(). It also implements the switch_rf() operation.

The initiator mode supports NFC-A technology at 106kbits/s and NFC-F
technologies at 212 and 424kbits/s.
Signed-off-by: NThierry Escande <thierry.escande@linux.intel.com>
Cc: Stephen Tiedemann <stephen.tiedemann@gmail.com>
Tested-by: NCho, Yu-Chen <acho@suse.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

This patch implements the command handling mechanism. The digital stack
serializes all commands sent to the driver. This means that the digital
stack waits for the reply of the current command before sending a new
one. So there is no command queue managed at driver level.

All Port-100 commands are asynchronous. If the command has been sent
successfully to the device, it replies with an ACK frame. Then the
command response is received (or actually no-response in case of
timeout or error) and a command complete work on the system workqueue
is responsible for sending the response (or the error) back to the
digital stack.

The digital stack requires some commands to be synchronous, mainly
hardware configuration ones. These commands use the asynchronous
command path but are made synchronous by using a completion object.
Signed-off-by: NThierry Escande <thierry.escande@linux.intel.com>
Cc: Stephen Tiedemann <stephen.tiedemann@gmail.com>
Tested-by: NCho, Yu-Chen <acho@suse.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

This adds support for the Sony NFC USB dongle RC-S380, based on the
Port-100 chip. This dongle is an analog frontend and does not implement
the digital layer. This driver uses the nfc_digital module which is an
implementation of the NFC Digital Protocol stack.

This patch is a skeleton. It only registers the dongle against the NFC
digital protocol stack. All NFC digital operation functions are stubbed
out.
Signed-off-by: NThierry Escande <thierry.escande@linux.intel.com>
Cc: Stephen Tiedemann <stephen.tiedemann@gmail.com>
Tested-by: NCho, Yu-Chen <acho@suse.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

In target mode, when we want to send frames larger than the max length
(PN533_CMD_DATAEXCH_DATA_MAXLEN), we have to split the frame in smaller
chunks and send them, using a specific working queue, with the TgSetMetaData
command. TgSetMetaData sets his own MI bit in the PFB.
The last chunk is sent using the TgSetData command.
Signed-off-by: NOlivier Guiter <olivier.guiter@linux.intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

This code processes, for Target Mode, incoming fragmented frames.
If the MI bit is present, we start a working queue to grab and aggregate
all the parts (using TmGetData between each parts). On the last one, as
there's no more MI bit, we jump on the usual behavior.
Signed-off-by: NOlivier Guiter <olivier.guiter@linux.intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

The fragmentation routine (used to split big frames) could be used in
target or initiator mode (TgSetMetaData vs InDataExchange), but the
MI/TG bytes are not needed in target mode (TgSetMetaData), so we
add a check on the mode
Signed-off-by: NOlivier Guiter <olivier.guiter@linux.intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

The NFC Forum NCI specification defines both a hardware and software
protocol when using a SPI physical transport to connect an NFC NCI
Chipset. The hardware requirement is that, after having raised the chip
select line, the SPI driver must wait for an INT line from the NFC
chipset to raise before it sends the data. The chip select must be
raised first though, because this is the signal that the NFC chipset
will detect to wake up and then raise its INT line. If the INT line
doesn't raise in a timely fashion, the SPI driver should abort
operation.

When data is transferred from Device host (DH) to NFC Controller (NFCC),
the signaling sequence is the following:

Data Transfer from DH to NFCC
• 1-Master asserts SPI_CSN
• 2-Slave asserts SPI_INT
• 3-Master sends NCI-over-SPI protocol header and payload data
• 4-Slave deasserts SPI_INT
• 5-Master deasserts SPI_CSN

When data must be transferred from NFCC to DH, things are a little bit
different.

Data Transfer from NFCC to DH
• 1-Slave asserts SPI_INT -> NFC chipset irq handler called -> process
reading from SPI
• 2-Master asserts SPI_CSN
• 3-Master send 2-octet NCI-over-SPI protocol header
• 4-Slave sends 2-octet NCI-over-SPI protocol payload length
• 5-Slave sends NCI-over-SPI protocol payload
• 6-Master deasserts SPI_CSN

In this case, SPI driver should function normally as it does today. Note
that the INT line can and will be lowered anytime between beginning of
step 3 and end of step 5. A low INT is therefore valid after chip select
has been raised.

This would be easily implemented in a single driver. Unfortunately, we
don't write the SPI driver and I had to imagine some workaround trick to
get the SPI and NFC drivers to work in a synchronized fashion. The trick
is the following:

- send an empty spi message: this will raise the chip select line, and
send nothing. We expect the /CS line will stay arisen because we asked
for it in the spi_transfer cs_change field
- wait for a completion, that will be completed by the NFC driver IRQ
handler when it knows we are in the process of sending data (NFC spec
says that we use SPI in a half duplex mode, so we are either sending or
receiving).
- when completed, proceed with the normal data send.

This has been tested and verified to work very consistently on a Nexus
10 (spi-s3c64xx driver). It may not work the same with other spi
drivers.

The previously defined nci_spi_ops{} whose intended purpose were to
address this problem are not used anymore and therefore totally removed.

The nci_spi_send() takes a new optional write_handshake_completion
completion pointer. If non NULL, the nci spi layer will run the above
trick when sending data to the NFC Chip. If NULL, the data is sent
normally all at once and it is then the NFC driver responsibility to
know what it's doing.
Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Previously, nci_spi_recv_frame() would directly transmit incoming frames
to the NCI Core. However, it turns out that some NFC NCI Chips will add
additional proprietary headers that must be handled/removed before NCI
Core gets a chance to handle the frame. With this modification, the chip
phy or driver are now responsible to transmit incoming frames to NCI
Core after proper treatment, and NCI SPI becomes a driver helper instead
of sitting between the NFC driver and NCI Core.

As a general rule in NFC, *_recv_frame() APIs are used to deliver an
incoming frame to an upper layer. To better suit the actual purpose of
nci_spi_recv_frame(), and go along with its nci_spi_send()
counterpart, the function is renamed to nci_spi_read()

The skb is returned as the function result
Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Using ARM compiler, and without zero-ing spi_transfer, spi-s3c64xx
driver would issue abnormal errors due to bpw field value being set to
unexpected value. This structure MUST be set to all zeros except for
those field specifically used.
Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Implementation of the NFC_CMD_SE_IO command for sending ISO7816 APDUs to
NFC embedded secure elements. The reply is forwarded to user space
through NFC_CMD_SE_IO as well.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

In order to send and receive ISO7816 APDUs to and from NFC embedded
secure elements, we define a specific netlink command.
On a typical SE use case, host applications will send very few APDUs
(Less than 10) per transaction. This is why we decided to go for a
simple netlink API. Defining another NFC socket protocol for such low
traffic would have been overengineered.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

SENS_RES has no specific endiannes attached to it, the kernel ABI is the
following one: Byte 2 (As described by the NFC Forum Digital spec) is
the u16 most significant byte.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

This was triggered by the following sparse warning:

net/nfc/digital_technology.c:272:20: sparse: cast to restricted __be16

The SENS_RES response must be treated as __le16 with the first byte
received as LSB and the second one as MSB. This is the way neard
handles it in the sens_res field of the nfc_target structure which is
treated as u16 in cpu endianness. So le16_to_cpu() is used on the
received SENS_RES instead of memcpy'ing it.

SENS_RES test macros have also been fixed accordingly.
Signed-off-by: NThierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

In the rawsock data exchange callback, the sk_buff is not freed
on error.
Signed-off-by: NThierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Local symbols used only in this file are made static.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Driver core sets driver data to NULL upon failure or remove.

Cc: Ilan Elias <ilane@ti.com>
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Fixes sparse hint:

net/nfc/digital_technology.c:640:5: sparse: symbol 'digital_tg_send_sensf_res'
was not declared. Should it be static?

Cc: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

We do not add the newline to the pr_fmt macro, in order to give more
flexibility to the caller and to keep the logging style consistent with
the rest of the NFC and kernel code.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

They can be replaced by the standard pr_err and pr_debug one after
defining the right pr_fmt macro.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Storing the spi device was forgotten in the original implementation,
which would pretty obviously cause some kind of serious crash when
actually trying to send something through that device.
Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

This adds support for NFC-DEP target mode for NFC-A and NFC-F
technologies.

If the driver provides it, the stack uses an automatic mode for
technology detection and automatic anti-collision. Otherwise the stack
tries to use non-automatic synchronization and listens for SENS_REQ and
SENSF_REQ commands.

The detection, activation, and data exchange procedures work exactly
the same way as in initiator mode, as described in the previous
commits, except that the digital stack waits for commands and sends
responses back to the peer device.
Signed-off-by: NThierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

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>

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

If we start the polling loop from a listening cycle, we need to start
the corresponding timer as well.
This bug showed up after commit dfccd0f5 as it was impossible to start
from a listening cycle before it.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

In order to improve active devices detection, we send an ATR_REQ between
each passive detection cycle. Without this algorithm, Android 4.3 based
devices running the Broadcom stack are hardly detected.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

As we can potentially get DEP up events without having sent a netlink
command, we need to set the active target properly from dep_link_is_up.
Spontaneous DEP up events can come from devices that detected an active
p2p target. In that case there is no need to call the netlink DEP up
command as the link is already up and running.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

NCI SPI layer should not manage the nci dev, this is the job of the nci
chipset driver. This layer should be limited to frame/deframe nci
packets, and optionnaly check integrity (crc) and manage the ack/nak
protocol.

The NCI SPI must not be mixed up with an NCI dev. spi_[dev|device] are
therefore renamed to a simple spi for more clarity.
The header and crc sizes are moved to nci.h so that drivers can use
them to reserve space in outgoing skbs.
nci_spi_send() is exported to be accessible by drivers.
Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

struct nfc_phy_ops is not an HCI structure only, it can also be used by
NCI or direct NFC Core drivers.
Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

An hci dev is an hdev. An nci dev is an ndev. Calling an nci spi dev an
ndev is misleading since it's not the same thing. The nci dev contained
in the nci spi dev is also named inconsistently.
Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Use standardized styles to minimize coding defects.

Always use nfc_<level> where feasible.
Add \n to formats where appropriate.
Typo "it it" correction.
Add #define pr_fmt where appropriate.
Remove function tracing logging messages.
Remove OOM messages.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Use a more standard kernel style macro logging name.

Standardize the spacing of the "NFC: " prefix.
Add \n to uses, remove from macro.
Fix the defective uses that already had a \n.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Use the generic kernel function instead of a home-grown
one that does the same thing.

Add \n to uses not at the macro.  Don't add \n where
the nfc_dev_dbg macro mistakenly had them already.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

To enable the UICC secure element, we first enable the UICC gate list in
order for the SE to be able to use all RF technologies.
For the embedded SE, we just turn the eSE default mode to ON.
Signed-off-by: NArron Wang <arron.wang@intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

This will be needed by all NFC driver implementing the SE ops.
Signed-off-by: NArron Wang <arron.wang@intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

For the SWP secure element, we send the proprietary SELF_TEST_SWP
command and check the response.
For the WI secure element, we simply try to switch to the default
embedded SE mode. If that works, it means we have an embedded SE.
Signed-off-by: NArron Wang <arron.wang@intel.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>