If the device is polling, this will trigger a netlink event to notify
userspace about the polling error.
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>
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>
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>
This is a simple forward to the HCI driver. When driver is done with the
operation, it shall directly notify NFC Core by calling
nfc_fw_upload_done().
Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Each NFC adapter can have several links to different secure elements and
that property needs to be exported by the drivers.
A secure element link can be enabled and disabled, and card emulation will
be handled by the currently active one. Otherwise card emulation will be
host implemented.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Some chips diverge from the HCI spec in their implementation of standard
features. This adds a new quirks parameter to
nfc_hci_allocate_device() to let the driver indicate its divergence.
Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Some chips use a standard HCI event code, destined to a proprietary
gate, with a different meaning. Therefore, the HCI driver must always
have a chance to intercept the event before standard processing is
attempted.
The new semantic specifies that the result value "1" means that the
driver doesn't especially handle the event. result <= 0 means it was
handled.
Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When an adapter is removed, it will unregister itself from hci and/or
nfc core. In order to do that safely, work tasks must first be canceled
and prevented to be scheduled again, before the hci or nfc device can be
destroyed.
Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
A chip with pre-opened gates may send events on a gate that nobody
has opened in the handset host. Discard those events.
Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
NFC_HCI_ID_MGMT_VERSION_SW and NFC_HCI_ID_MGMT_VERSION_HW are optional
registers for gate NFC_HCI_ID_MGMT_GATE in standard HCI. When chip
doesn't implement, just leave all the information as zeros.
Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
In some cases, pre-opened pipes don't stay open when a clear all pipes
command is sent. They stay created however. Therefore, one can never
assume that such a pipe is already open. As re-opening a pipe seems not
to be a problem, we do that now.
Signed-off-by: Eric Lapuyade <eric.lapuyade@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Return code from nfc_hci_execute_cmd was not propagated to caller.
Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>