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: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Samuel 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: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Samuel 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: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Since the NFC subsystem gained RFKILL support, it needs to be able
to build properly with whatever option for RFKILL has been selected.
on i386:
net/built-in.o: In function `nfc_unregister_device':
(.text+0x6a36d): undefined reference to `rfkill_unregister'
net/built-in.o: In function `nfc_unregister_device':
(.text+0x6a378): undefined reference to `rfkill_destroy'
net/built-in.o: In function `nfc_register_device':
(.text+0x6a493): undefined reference to `rfkill_alloc'
net/built-in.o: In function `nfc_register_device':
(.text+0x6a4a4): undefined reference to `rfkill_register'
net/built-in.o: In function `nfc_register_device':
(.text+0x6a4b3): undefined reference to `rfkill_destroy'
net/built-in.o: In function `nfc_dev_up':
(.text+0x6a8e8): undefined reference to `rfkill_blocked'
when CONFIG_RFKILL=m but NFC is builtin.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
And stop making it optional. LLCP is a fundamental part of the NFC
specifications and making it optional does not make much sense.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This config item has not carried much meaning for a while now and is
almost always enabled by default. As agreed during the Linux kernel
summit, remove it.
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This is an implementation of ETSI TS 102 622 specification.
Many NFC chipsets use HCI as the host <-> target protocol on top of a
serial link like i2c.
Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch is an initial implementation for the NFC Logical Link Control
protocol. It's also known as NFC peer to peer mode.
This is a basic implementation as it lacks SDP (services Discovery
Protocol), frames aggregation support, and frame rejecion parsing.
Follow up patches will implement those missing features.
This code has been tested against a Nexus S phone implementing LLCP 1.0.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The NFC Controller Interface (NCI) is a standard
communication protocol between an NFC Controller (NFCC)
and a Device Host (DH), defined by the NFC Forum.
Signed-off-by: Ilan Elias <ilane@ti.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The NFC subsystem core is responsible for providing the device driver
interface. It is also responsible for providing an interface to the control
operations and data exchange.
Signed-off-by: Lauro Ramos Venancio <lauro.venancio@openbossa.org>
Signed-off-by: Aloisio Almeida Jr <aloisio.almeida@openbossa.org>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Thierry Escande