The secure element state was not updated from the enable/disable ops,
leaving the SE state to disabled for ever.
Signed-off-by: Arron Wang <arron.wang@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Another typo from the initial commit where we check for the secure
element type field instead of its state when enabling or disabling it.
Signed-off-by: Arron Wang <arron.wang@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
There is a cut and paste bug so we enable a second time instead of
disabling.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Result is added as an NFC_ATTR_FIRMWARE_DOWNLOAD_STATUS attribute
containing the standard errno positive value of the completion result.
This event will be sent when the firmare download operation is done and
will contain the operation result.
Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This API must be called by NFC drivers, and its prototype was
incorrectly placed.
Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
In order to fetch the discovered secure elements from an NFC controller,
we need to send a netlink command that will dump the list of available
SEs from NFC.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This is a typo coming from the initial implementation. se_discover fails
when it returns something different than zero and we should only display
a warning in that case.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Loading a firmware into a target is typically called firmware
download, not firmware upload. So we rename the netlink API to
NFC_CMD_FW_DOWNLOAD in order to avoid any terminology confusion from
userspace.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
kbuild test robot found following error:
net/built-in.o: In function `nci_spi_send':
>> spi.c:(.text+0x19a76f): undefined reference to `crc_ccitt'
Add CRC_CCITT module to Kconfig to fix it
Reported-by: kbuild test robot.
Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The WKS (Well Known Services) bitmask should be transmitted in big endian
order. Picky implementations will refuse to establish an LLCP link when the
WKS bit 0 is not set to 1. The vast majority of implementations out there
are not that picky though...
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
In order to advertise our LLCP support properly and to follow the LLCP
specs requirements, we need to initialize the WKS (Well-Known Services)
bitfield to 1 as SAP 0 is the only mandatory supported service.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When we receive a RNR, the remote is busy processing the last received
frame. We set a local flag for that, and we should send a SYMM when it
is set instead of sending any pending frame.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Without the new LLCP_CONNECTING state, non blocking sockets will be
woken up with a POLLHUP right after calling connect() because their
state is stuck at LLCP_CLOSED.
That prevents userspace from implementing any proper non blocking
socket based NFC p2p client.
Cc: stable@vger.kernel.org
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
In nfc_llcp_tx_work() the sk_buff is not freed when the llcp_sock
is null and the PDU is an I one.
Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This patch keeps the socket alive and therefore does not remove
it from the sockets list in the local until the DISC PDU has been
actually sent. Otherwise we would reply with DM PDUs before sending
the DISC one.
Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
nfc_llcp_send_disconnect() already exists but is not used.
nfc_llcp_disconnect() naming is not consistent with other PDU
sending functions.
This patch removes nfc_llcp_send_disconnect() and renames
nfc_llcp_disconnect()
Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Enabling or disabling an NFC accessible secure element through netlink
requires giving both an NFC controller and a secure element indexes.
Once enabled the secure element will handle card emulation once polling
starts.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Called via netlink, this API will enable or disable a specific secure
element. When a secure element is enabled, it will handle card emulation
and more generically ISO-DEP target mode, i.e. all target mode cases
except for p2p target mode.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When an NFC driver or host controller stack discovers a secure element,
it will call nfc_add_se(). In order for userspace applications to use
these secure elements, a netlink event will then be sent with the SE
index and its type. With that information userspace applications can
decide wether or not to enable SEs, through their indexes.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This API will allow NFC drivers to add and remove the secure elements
they know about or detect. Typically this should be called (asynchronously
or not) from the driver or the host interface stack detect_se hook.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Secure elements need to be discovered after enabling the NFC controller.
This is typically done by the NCI core and the HCI drivers (HCI does not
specify how to discover SEs, it is left to the specific drivers).
Also, the SE enable/disable API explicitely takes a SE index as its
argument.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Supported secure elements are typically found during a discovery process
initiated when the NFC controller is up and running. For a given NFC
chipset there can be many configurations (embedded SE or not, with or
without a SIM card wired to the NFC controller SWP interface, etc...) and
thus driver code will never know before hand which SEs are available.
So we remove this field, it will be replaced by a real SE discovery
mechanism.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Before any operation, driver interruption is de-asserted to prevent
race condition between TX and RX.
Transaction starts by emitting "Direct read" and acknowledged mode
bytes. Then packet length is read allowing to allocate correct NCI
socket buffer. After that payload is retrieved.
A delay after the transaction can be added.
This delay is determined by the driver during nci_spi_allocate_device()
call and can be 0.
If acknowledged mode is set:
- CRC of header and payload is checked
- if frame reception fails (CRC error): NACK is sent
- if received frame has ACK or NACK flag: unblock nci_spi_send()
Payload is passed to NCI module.
At the end, driver interruption is re asserted.
Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Before any operation, driver interruption is de-asserted to prevent
race condition between TX and RX.
The NCI over SPI header is added in front of NCI packet.
If acknowledged mode is set, CRC-16-CCITT is added to the packet.
Then the packet is forwarded to SPI module to be sent.
A delay after the transaction is added.
This delay is determined by the driver during nci_spi_allocate_device()
call and can be 0.
After data has been sent, driver interruption is re-asserted.
If acknowledged mode is set, nci_spi_send will block until
acknowledgment is received.
Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Arron Wang
Dan Carpenter
Eric Lapuyade
Samuel Ortiz
Frederic Danis
Thierry Escande