korg/linux
0
0
Fork 0
mirror of https://mirrors.bfsu.edu.cn/git/linux.git synced 2024-11-28 22:54:05 +08:00
Code Issues Packages Projects Releases Wiki Activity
e5629d2947
linux/include/net/nfc/nci_core.h

459 lines
13 KiB
C
Raw Normal View History

NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
/*
* The NFC Controller Interface is the communication protocol between an
* NFC Controller (NFCC) and a Device Host (DH).
*
* Copyright (C) 2011 Texas Instruments, Inc.
NFC: Add basic NCI over SPI The NFC Forum defines a transport interface based on Serial Peripheral Interface (SPI) for the NFC Controller Interface (NCI). This module implements the SPI transport of NCI, calling SPI module directly to read/write data to NFC controller (NFCC). NFCC driver should provide functions performing device open and close. It should also provide functions asserting/de-asserting interruption to prevent TX/RX race conditions. NFCC driver can also fix a delay between transactions if needed by the hardware. Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-05-29 21:35:02 +08:00
* Copyright (C) 2013 Intel Corporation. All rights reserved.
NFC: NCI: Handle Target mode activation Changes: * Extract the Listen mode activation parameters from RF_INTF_ACTIVATED_NTF. * Store the General Bytes of ATR_REQ. * Signal that Target mode is activated in case of an activation in NFC-DEP. * Update the NCI state accordingly. * Use the various constants defined in nfc.h. * Fix the ATR_REQ and ATR_RES maximum size. As per NCI 1.0 and NCI 1.1, the Activation Parameters for both Poll and Listen mode contain all the bytes of ATR_REQ/ATR_RES starting and including Byte 3 as defined in [DIGITAL]. In [DIGITAL], the maximum size of ATR_REQ/ATR_RES is 64 bytes and they are numbered starting from Byte 1. Signed-off-by: Julien Lefrique <lefrique@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-10-21 22:52:46 +08:00
* Copyright (C) 2014 Marvell International Ltd.
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
*
* Written by Ilan Elias <ilane@ti.com>
*
* Acknowledgements:
* This file is based on hci_core.h, which was written
* by Maxim Krasnyansky.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2
* as published by the Free Software Foundation
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
include/net/: Fix FSF address in file headers Several files refer to an old address for the Free Software Foundation in the file header comment. Resolve by replacing the address with the URL <http://www.gnu.org/licenses/> so that we do not have to keep updating the header comments anytime the address changes. Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-12-07 01:13:40 +08:00
* along with this program; if not, see <http://www.gnu.org/licenses/>.
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
*
*/
#ifndef __NCI_CORE_H
#define __NCI_CORE_H
#include <linux/interrupt.h>
#include <linux/skbuff.h>
NFC: nci: add generic uart support Some NFC controller supports UART as host interface. As with SPI, a lot of code can be shared between vendor drivers. This patch add the generic support of UART and provides some extension API for vendor specific needs. This code is strongly inspired by the Bluetooth HCI ldisc implementation. NCI UART vendor drivers will have to register themselves to this layer via nci_uart_register. Underlying tty will have to be configured from user land thanks to an ioctl. Signed-off-by: Vincent Cuissard <cuissard@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-06-11 17:25:47 +08:00
#include <linux/tty.h>
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
#include <net/nfc/nfc.h>
#include <net/nfc/nci.h>
NFC: Clearly separate NCI states from flags Make a clear separation between NCI states and flags. This is required in order to support more NCI states (e.g. for multiple targets support). Signed-off-by: Ilan Elias <ilane@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-01-18 19:16:12 +08:00
/* NCI device flags */
enum nci_flag {
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
NCI_INIT,
NCI_UP,
NFC: protect nci_data_exchange transactions Protect 'cb' and 'cb_context' arguments in nci_data_exchange. In fact, this implements a queue with max length of 1 data exchange transactions in parallel. Signed-off-by: Ilan Elias <ilane@ti.com> Acked-by: Lauro Ramos Venancio <lauro.venancio@openbossa.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-09-22 16:36:19 +08:00
NCI_DATA_EXCHANGE,
NFC: Add NCI data exchange timer Add NCI data exchange timer to catch timeouts, and call the data exchange callback with an error. Signed-off-by: Ilan Elias <ilane@ti.com> Acked-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-01-17 18:03:50 +08:00
NCI_DATA_EXCHANGE_TO,
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
};
NFC: Clearly separate NCI states from flags Make a clear separation between NCI states and flags. This is required in order to support more NCI states (e.g. for multiple targets support). Signed-off-by: Ilan Elias <ilane@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-01-18 19:16:12 +08:00
/* NCI device states */
enum nci_state {
NCI_IDLE,
NCI_DISCOVERY,
NFC: Add NCI multiple targets support Add the ability to select between multiple targets in NCI. If only one target is found, it will be auto-activated. If more than one target is found, then DISCOVER_NTF will be generated for each target, and the host should select one by calling DISCOVER_SELECT_CMD. Then, the target will be activated. If the activation fails, GENERIC_ERROR_NTF is generated. Signed-off-by: Ilan Elias <ilane@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-01-18 19:16:14 +08:00
NCI_W4_ALL_DISCOVERIES,
NCI_W4_HOST_SELECT,
NFC: Clearly separate NCI states from flags Make a clear separation between NCI states and flags. This is required in order to support more NCI states (e.g. for multiple targets support). Signed-off-by: Ilan Elias <ilane@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-01-18 19:16:12 +08:00
NCI_POLL_ACTIVE,
NFC: NCI: Handle Target mode activation Changes: * Extract the Listen mode activation parameters from RF_INTF_ACTIVATED_NTF. * Store the General Bytes of ATR_REQ. * Signal that Target mode is activated in case of an activation in NFC-DEP. * Update the NCI state accordingly. * Use the various constants defined in nfc.h. * Fix the ATR_REQ and ATR_RES maximum size. As per NCI 1.0 and NCI 1.1, the Activation Parameters for both Poll and Listen mode contain all the bytes of ATR_REQ/ATR_RES starting and including Byte 3 as defined in [DIGITAL]. In [DIGITAL], the maximum size of ATR_REQ/ATR_RES is 64 bytes and they are numbered starting from Byte 1. Signed-off-by: Julien Lefrique <lefrique@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-10-21 22:52:46 +08:00
NCI_LISTEN_ACTIVE,
NCI_LISTEN_SLEEP,
NFC: Clearly separate NCI states from flags Make a clear separation between NCI states and flags. This is required in order to support more NCI states (e.g. for multiple targets support). Signed-off-by: Ilan Elias <ilane@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-01-18 19:16:12 +08:00
};
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
/* NCI timeouts */
#define NCI_RESET_TIMEOUT 5000
#define NCI_INIT_TIMEOUT 5000
NFC: Set local general bytes in nci_start_poll If initiator protocol is NFC-DEP, set the local general bytes in nci_start_poll. Signed-off-by: Ilan Elias <ilane@ti.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2012-08-15 16:46:22 +08:00
#define NCI_SET_CONFIG_TIMEOUT 5000
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
#define NCI_RF_DISC_TIMEOUT 5000
NFC: Add NCI multiple targets support Add the ability to select between multiple targets in NCI. If only one target is found, it will be auto-activated. If more than one target is found, then DISCOVER_NTF will be generated for each target, and the host should select one by calling DISCOVER_SELECT_CMD. Then, the target will be activated. If the activation fails, GENERIC_ERROR_NTF is generated. Signed-off-by: Ilan Elias <ilane@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-01-18 19:16:14 +08:00
#define NCI_RF_DISC_SELECT_TIMEOUT 5000
NFC: Increase NCI deactivate timeout Increase NCI deactivate timeout from 5 sec to 30 sec. NCI deactivate procedure might take a long time, depending on the local and remote parameters. Signed-off-by: Ilan Elias <ilane@ti.com> Acked-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-01-08 19:43:02 +08:00
#define NCI_RF_DEACTIVATE_TIMEOUT 30000
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
#define NCI_CMD_TIMEOUT 5000
NFC: Add NCI data exchange timer Add NCI data exchange timer to catch timeouts, and call the data exchange callback with an error. Signed-off-by: Ilan Elias <ilane@ti.com> Acked-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-01-17 18:03:50 +08:00
#define NCI_DATA_TIMEOUT 700
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
struct nci_dev;
NFC: nci: rename nci_prop_ops to nci_driver_ops Initially it was used to create hooks in the driver for proprietary operations. Currently it is being used for hooks for both proprietary and generic operations. Signed-off-by: Robert Dolca <robert.dolca@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-10-22 17:11:39 +08:00
struct nci_driver_ops {
NFC: nci: Handle proprietary response and notifications Allow for drivers to explicitly define handlers for each proprietary notifications and responses they expect to support. Reviewed-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-06-06 19:16:37 +08:00
__u16 opcode;
int (*rsp)(struct nci_dev *dev, struct sk_buff *skb);
int (*ntf)(struct nci_dev *dev, struct sk_buff *skb);
};
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
struct nci_ops {
NFC: nci: Add nci init ops for early device initialization Some device may need to execute some proprietary commands in order to "wake-up"; Before the nci state initialization. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-06-06 19:16:40 +08:00
int (*init)(struct nci_dev *ndev);
NFC: nci: Add support for proprietary RF Protocols In NFC Forum NCI specification, some RF Protocol values are reserved for proprietary use (from 0x80 to 0xfe). Some CLF vendor may need to use one value within this range for specific technology. Furthermore, some CLF may not becompliant with NFC Froum NCI specification 2.0 and therefore will not support RF Protocol value 0x06 for PROTOCOL_T5T as mention in a draft specification and in a recent push. Adding get_rf_protocol handle to the nci_ops structure will help to set the correct technology to target. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-09-13 16:28:49 +08:00
int (*open)(struct nci_dev *ndev);
int (*close)(struct nci_dev *ndev);
int (*send)(struct nci_dev *ndev, struct sk_buff *skb);
int (*setup)(struct nci_dev *ndev);
NFC: nci: Add post_setup handler Some drivers require non-standard configuration after NCI_CORE_INIT request, because they need to know ndev->manufact_specific_info or ndev->manufact_id. This patch adds post_setup handler allowing to do such custom configuration. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-08-20 23:26:00 +08:00
int (*post_setup)(struct nci_dev *ndev);
NFC: nci: Add firmware download support A simple forward for firmware download (i.e. sending a new firmware to the NFC adapter) from the NFC subsystem to the drivers. This feature is required to update the firmware of NXP-NCI NFC controllers but can be used by any NCI driver. This feature has been present in the HCI subsystem since 9a695d. Signed-off-by: Clément Perrochaud <clement.perrochaud@effinnov.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-03-09 18:12:03 +08:00
int (*fw_download)(struct nci_dev *ndev, const char *firmware_name);
NFC: nci: Add support for proprietary RF Protocols In NFC Forum NCI specification, some RF Protocol values are reserved for proprietary use (from 0x80 to 0xfe). Some CLF vendor may need to use one value within this range for specific technology. Furthermore, some CLF may not becompliant with NFC Froum NCI specification 2.0 and therefore will not support RF Protocol value 0x06 for PROTOCOL_T5T as mention in a draft specification and in a recent push. Adding get_rf_protocol handle to the nci_ops structure will help to set the correct technology to target. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-09-13 16:28:49 +08:00
__u32 (*get_rfprotocol)(struct nci_dev *ndev, __u8 rf_protocol);
NFC: nci: Update nci_discover_se to run proprietary commands to discover all available secure element Some NFC controller using NCI protocols may need a proprietary commands flow to discover all available secure element Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-13 07:30:35 +08:00
int (*discover_se)(struct nci_dev *ndev);
NFC: nci: Update nci_disable_se to run proprietary commands to disable a secure element Some NFC controller using NCI protocols may need a proprietary commands flow to disable a secure element Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-13 07:30:37 +08:00
int (*disable_se)(struct nci_dev *ndev, u32 se_idx);
NFC: nci: Update nci_enable_se to run proprietary commands to enable a secure element Some NFC controller using NCI protocols may need a proprietary commands flow to enable a secure element Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-13 07:30:36 +08:00
int (*enable_se)(struct nci_dev *ndev, u32 se_idx);
NFC: nci: Add se_io NCI operand se_io allows to send apdu over the CLF to the embedded Secure Element. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-11-13 07:30:38 +08:00
int (*se_io)(struct nci_dev *ndev, u32 se_idx,
u8 *apdu, size_t apdu_length,
se_io_cb_t cb, void *cb_context);
NFC: nci: Add HCI over NCI protocol support According to the NCI specification, one can use HCI over NCI to talk with specific NFCEE. The HCI network is viewed as one logical NFCEE. This is needed to support secure element running HCI only firmwares embedded on an NCI capable chipset, like e.g. the st21nfcb. There is some duplication between this piece of code and the HCI core code, but the latter would need to be abstracted even more to be able to use NCI as a logical transport for HCP packets. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-02 05:26:14 +08:00
int (*hci_load_session)(struct nci_dev *ndev);
void (*hci_event_received)(struct nci_dev *ndev, u8 pipe, u8 event,
struct sk_buff *skb);
void (*hci_cmd_received)(struct nci_dev *ndev, u8 pipe, u8 cmd,
struct sk_buff *skb);
NFC: nci: Handle proprietary response and notifications Allow for drivers to explicitly define handlers for each proprietary notifications and responses they expect to support. Reviewed-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-06-06 19:16:37 +08:00
NFC: nci: rename nci_prop_ops to nci_driver_ops Initially it was used to create hooks in the driver for proprietary operations. Currently it is being used for hooks for both proprietary and generic operations. Signed-off-by: Robert Dolca <robert.dolca@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-10-22 17:11:39 +08:00
struct nci_driver_ops *prop_ops;
NFC: nci: Handle proprietary response and notifications Allow for drivers to explicitly define handlers for each proprietary notifications and responses they expect to support. Reviewed-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-06-06 19:16:37 +08:00
size_t n_prop_ops;
NFC: nci: Allow the driver to set handler for core nci ops The driver may be required to act when some responses or notifications arrive. For example the NCI core does not have a handler for NCI_OP_CORE_GET_CONFIG_RSP. The NFCC can send a config response that has to be read by the driver and the packet may contain vendor specific data. The Fields Peak driver needs to take certain actions when a reset notification arrives (packet also not handled by the nfc core). The driver handlers do not interfere with the core and they are called after the core processes the packet. Signed-off-by: Robert Dolca <robert.dolca@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-10-22 17:11:38 +08:00
NFC: nci: rename nci_prop_ops to nci_driver_ops Initially it was used to create hooks in the driver for proprietary operations. Currently it is being used for hooks for both proprietary and generic operations. Signed-off-by: Robert Dolca <robert.dolca@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-10-22 17:11:39 +08:00
struct nci_driver_ops *core_ops;
NFC: nci: Allow the driver to set handler for core nci ops The driver may be required to act when some responses or notifications arrive. For example the NCI core does not have a handler for NCI_OP_CORE_GET_CONFIG_RSP. The NFCC can send a config response that has to be read by the driver and the packet may contain vendor specific data. The Fields Peak driver needs to take certain actions when a reset notification arrives (packet also not handled by the nfc core). The driver handlers do not interfere with the core and they are called after the core processes the packet. Signed-off-by: Robert Dolca <robert.dolca@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-10-22 17:11:38 +08:00
size_t n_core_ops;
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
};
#define NCI_MAX_SUPPORTED_RF_INTERFACES 4
NFC: Add NCI multiple targets support Add the ability to select between multiple targets in NCI. If only one target is found, it will be auto-activated. If more than one target is found, then DISCOVER_NTF will be generated for each target, and the host should select one by calling DISCOVER_SELECT_CMD. Then, the target will be activated. If the activation fails, GENERIC_ERROR_NTF is generated. Signed-off-by: Ilan Elias <ilane@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-01-18 19:16:14 +08:00
#define NCI_MAX_DISCOVERED_TARGETS 10
NFC: nci: Add dynamic logical connections support The current NCI core only support the RF static connection. For other NFC features such as Secure Element communication, we may need to create logical connections to the NFCEE (Execution Environment. In order to track each logical connection ID dynamically, we add a linked list of connection info pointers to the nci_dev structure. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-02 05:26:08 +08:00
#define NCI_MAX_NUM_NFCEE 255
#define NCI_MAX_CONN_ID 7
NFC: nci: Handle proprietary response and notifications Allow for drivers to explicitly define handlers for each proprietary notifications and responses they expect to support. Reviewed-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-06-06 19:16:37 +08:00
#define NCI_MAX_PROPRIETARY_CMD 64
NFC: nci: Add dynamic logical connections support The current NCI core only support the RF static connection. For other NFC features such as Secure Element communication, we may need to create logical connections to the NFCEE (Execution Environment. In order to track each logical connection ID dynamically, we add a linked list of connection info pointers to the nci_dev structure. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-02 05:26:08 +08:00
struct nci_conn_info {
struct list_head list;
__u8 id; /* can be an RF Discovery ID or an NFCEE ID */
__u8 conn_id;
__u8 max_pkt_payload_len;
atomic_t credits_cnt;
__u8 initial_num_credits;
data_exchange_cb_t data_exchange_cb;
void *data_exchange_cb_context;
struct sk_buff *rx_skb;
};
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
NFC: nci: Add NFCEE discover support NFCEEs (NFC Execution Environment) have to be explicitly discovered by sending the NCI_OP_NFCEE_DISCOVER_CMD command. The NFCC will respond to this command by telling us how many NFCEEs are connected to it. Then the NFCC sends a notification command for each and every NFCEE connected. Here we implement support for sending NCI_OP_NFCEE_DISCOVER_CMD command, receiving the response and the potential notifications. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-02 05:26:10 +08:00
#define NCI_INVALID_CONN_ID 0x80
NFC: nci: Add HCI over NCI protocol support According to the NCI specification, one can use HCI over NCI to talk with specific NFCEE. The HCI network is viewed as one logical NFCEE. This is needed to support secure element running HCI only firmwares embedded on an NCI capable chipset, like e.g. the st21nfcb. There is some duplication between this piece of code and the HCI core code, but the latter would need to be abstracted even more to be able to use NCI as a logical transport for HCP packets. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-02 05:26:14 +08:00
#define NCI_HCI_ANY_OPEN_PIPE 0x03
/* Gates */
#define NCI_HCI_ADMIN_GATE 0x00
NFC: st-nci: Add support for proprietary commands Add support for proprietary commands useful mainly for factory testings. Here is a list: - FACTORY_MODE: Allow to set the driver into a mode where no secure element are activated. It does not consider any NFC_ATTR_VENDOR_DATA. - HCI_CLEAR_ALL_PIPES: Allow to execute a HCI clear all pipes command. It does not consider any NFC_ATTR_VENDOR_DATA. - HCI_DM_PUT_DATA: Allow to configure specific CLF registry like for example RF trimmings or low level drivers configurations (I2C, SPI, SWP). - HCI_DM_UPDATE_AID: Allow to configure an AID routing into the CLF routing table following RF technology, CLF mode or protocol. - HCI_DM_GET_INFO: Allow to retrieve CLF information. - HCI_DM_GET_DATA: Allow to retrieve CLF configurable data such as low level drivers configurations or RF trimmings. - HCI_DM_DIRECT_LOAD: Allow to load a firmware into the CLF. A complete packet can be more than 8KB. - HCI_DM_RESET: Allow to run a CLF reset in order to "commit" CLF configuration changes without CLF power off. - HCI_GET_PARAM: Allow to retrieve an HCI CLF parameter (for example the white list). - HCI_DM_FIELD_GENERATOR: Allow to generate different kind of RF technology. When using this command to anti-collision is done. - HCI_LOOPBACK: Allow to echo a command and test the Dh to CLF connectivity. - HCI_DM_VDC_MEASUREMENT_VALUE: Allow to measure the field applied on the CLF antenna. A value between 0 and 0x0f is returned. 0 is maximum. - HCI_DM_FWUPD_START: Allow to put CLF into firmware update mode. It is a specific CLF command as there is no GPIO for this. - HCI_DM_FWUPD_END: Allow to complete firmware update. - HCI_DM_VDC_VALUE_COMPARISON: Allow to compare the field applied on the CLF antenna to a reference value. - MANUFACTURER_SPECIFIC: Allow to retrieve manufacturer specific data received during a NCI_CORE_INIT_CMD. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-10-26 05:54:36 +08:00
#define NCI_HCI_LOOPBACK_GATE 0x04
NFC: st-nci: Add support for NCI_HCI_IDENTITY_MGMT_GATE NCI_HCI_IDENTITY_MGMT_GATE might be useful to get information about hardware or firmware version. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-10-26 05:54:33 +08:00
#define NCI_HCI_IDENTITY_MGMT_GATE 0x05
NFC: nci: Add HCI over NCI protocol support According to the NCI specification, one can use HCI over NCI to talk with specific NFCEE. The HCI network is viewed as one logical NFCEE. This is needed to support secure element running HCI only firmwares embedded on an NCI capable chipset, like e.g. the st21nfcb. There is some duplication between this piece of code and the HCI core code, but the latter would need to be abstracted even more to be able to use NCI as a logical transport for HCP packets. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-02 05:26:14 +08:00
#define NCI_HCI_LINK_MGMT_GATE 0x06
/* Pipes */
#define NCI_HCI_LINK_MGMT_PIPE 0x00
#define NCI_HCI_ADMIN_PIPE 0x01
/* Generic responses */
#define NCI_HCI_ANY_OK 0x00
#define NCI_HCI_ANY_E_NOT_CONNECTED 0x01
#define NCI_HCI_ANY_E_CMD_PAR_UNKNOWN 0x02
#define NCI_HCI_ANY_E_NOK 0x03
#define NCI_HCI_ANY_E_PIPES_FULL 0x04
#define NCI_HCI_ANY_E_REG_PAR_UNKNOWN 0x05
#define NCI_HCI_ANY_E_PIPE_NOT_OPENED 0x06
#define NCI_HCI_ANY_E_CMD_NOT_SUPPORTED 0x07
#define NCI_HCI_ANY_E_INHIBITED 0x08
#define NCI_HCI_ANY_E_TIMEOUT 0x09
#define NCI_HCI_ANY_E_REG_ACCESS_DENIED 0x0a
#define NCI_HCI_ANY_E_PIPE_ACCESS_DENIED 0x0b
#define NCI_HCI_DO_NOT_OPEN_PIPE 0x81
#define NCI_HCI_INVALID_PIPE 0x80
#define NCI_HCI_INVALID_GATE 0xFF
#define NCI_HCI_INVALID_HOST 0x80
#define NCI_HCI_MAX_CUSTOM_GATES 50
nfc: nci: Add comment to explain NCI_HCI_MAX_PIPES According to specification etsi 102 622 chapter 4.4 pipes identifier is 7 bits long giving a 127 possible pipes value. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-03-31 14:02:21 +08:00
/*
* According to specification 102 622 chapter 4.4 Pipes,
* the pipe identifier is 7 bits long.
*/
NFC: nci: Add HCI over NCI protocol support According to the NCI specification, one can use HCI over NCI to talk with specific NFCEE. The HCI network is viewed as one logical NFCEE. This is needed to support secure element running HCI only firmwares embedded on an NCI capable chipset, like e.g. the st21nfcb. There is some duplication between this piece of code and the HCI core code, but the latter would need to be abstracted even more to be able to use NCI as a logical transport for HCP packets. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-02 05:26:14 +08:00
#define NCI_HCI_MAX_PIPES 127
struct nci_hci_gate {
u8 gate;
u8 pipe;
u8 dest_host;
} __packed;
struct nci_hci_pipe {
u8 gate;
u8 host;
} __packed;
struct nci_hci_init_data {
u8 gate_count;
struct nci_hci_gate gates[NCI_HCI_MAX_CUSTOM_GATES];
char session_id[9];
};
#define NCI_HCI_MAX_GATES 256
struct nci_hci_dev {
NFC: nci: Move logical connection structure allocation conn_info is currently allocated only after nfcee_discovery_ntf which is not generic enough for logical connection other than NFCEE. The corresponding conn_info is now created in nci_core_conn_create_rsp(). Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-04 02:48:07 +08:00
u8 nfcee_id;
NFC: nci: Add HCI over NCI protocol support According to the NCI specification, one can use HCI over NCI to talk with specific NFCEE. The HCI network is viewed as one logical NFCEE. This is needed to support secure element running HCI only firmwares embedded on an NCI capable chipset, like e.g. the st21nfcb. There is some duplication between this piece of code and the HCI core code, but the latter would need to be abstracted even more to be able to use NCI as a logical transport for HCP packets. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-02 05:26:14 +08:00
struct nci_dev *ndev;
struct nci_conn_info *conn_info;
struct nci_hci_init_data init_data;
struct nci_hci_pipe pipes[NCI_HCI_MAX_PIPES];
u8 gate2pipe[NCI_HCI_MAX_GATES];
int expected_pipes;
int count_pipes;
struct sk_buff_head rx_hcp_frags;
struct work_struct msg_rx_work;
struct sk_buff_head msg_rx_queue;
};
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
/* NCI Core structures */
struct nci_dev {
struct nfc_dev *nfc_dev;
struct nci_ops *ops;
NFC: nci: Add HCI over NCI protocol support According to the NCI specification, one can use HCI over NCI to talk with specific NFCEE. The HCI network is viewed as one logical NFCEE. This is needed to support secure element running HCI only firmwares embedded on an NCI capable chipset, like e.g. the st21nfcb. There is some duplication between this piece of code and the HCI core code, but the latter would need to be abstracted even more to be able to use NCI as a logical transport for HCP packets. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-02 05:26:14 +08:00
struct nci_hci_dev *hci_dev;
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
int tx_headroom;
int tx_tailroom;
NFC: Clearly separate NCI states from flags Make a clear separation between NCI states and flags. This is required in order to support more NCI states (e.g. for multiple targets support). Signed-off-by: Ilan Elias <ilane@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-01-18 19:16:12 +08:00
atomic_t state;
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
unsigned long flags;
atomic_t cmd_cnt;
NFC: nci: Add dynamic logical connections support The current NCI core only support the RF static connection. For other NFC features such as Secure Element communication, we may need to create logical connections to the NFCEE (Execution Environment. In order to track each logical connection ID dynamically, we add a linked list of connection info pointers to the nci_dev structure. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-02 05:26:08 +08:00
__u8 cur_conn_id;
struct list_head conn_info_list;
NFC: nci: Add reference to the RF logical connection The NCI_STATIC_RF_CONN_ID logical connection is the most used connection. Keeping it directly accessible in the nci_dev structure will simplify and optimize the access. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-04 02:48:04 +08:00
struct nci_conn_info *rf_conn_info;
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
struct timer_list cmd_timer;
NFC: Add NCI data exchange timer Add NCI data exchange timer to catch timeouts, and call the data exchange callback with an error. Signed-off-by: Ilan Elias <ilane@ti.com> Acked-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-01-17 18:03:50 +08:00
struct timer_list data_timer;
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
struct workqueue_struct *cmd_wq;
struct work_struct cmd_work;
struct workqueue_struct *rx_wq;
struct work_struct rx_work;
struct workqueue_struct *tx_wq;
struct work_struct tx_work;
struct sk_buff_head cmd_q;
struct sk_buff_head rx_q;
struct sk_buff_head tx_q;
struct mutex req_lock;
struct completion req_completion;
__u32 req_status;
__u32 req_result;
void *driver_data;
__u32 poll_prots;
__u32 target_active_prot;
NFC: Add NCI multiple targets support Add the ability to select between multiple targets in NCI. If only one target is found, it will be auto-activated. If more than one target is found, then DISCOVER_NTF will be generated for each target, and the host should select one by calling DISCOVER_SELECT_CMD. Then, the target will be activated. If the activation fails, GENERIC_ERROR_NTF is generated. Signed-off-by: Ilan Elias <ilane@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-01-18 19:16:14 +08:00
struct nfc_target targets[NCI_MAX_DISCOVERED_TARGETS];
int n_targets;
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
/* received during NCI_OP_CORE_RESET_RSP */
__u8 nci_ver;
/* received during NCI_OP_CORE_INIT_RSP */
__u32 nfcc_features;
__u8 num_supported_rf_interfaces;
__u8 supported_rf_interfaces
[NCI_MAX_SUPPORTED_RF_INTERFACES];
__u8 max_logical_connections;
__u16 max_routing_table_size;
NFC: Update names and structs to NCI spec 1.0 d18 Addition, deletion and modification of NCI constants. Changes in NCI commands, responses and notifications structures. Signed-off-by: Ilan Elias <ilane@ti.com> Acked-by: Lauro Ramos Venancio <lauro.venancio@openbossa.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-11-09 18:09:14 +08:00
__u8 max_ctrl_pkt_payload_len;
__u16 max_size_for_large_params;
__u8 manufact_id;
__u32 manufact_specific_info;
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
NFC: nci: Add dynamic logical connections support The current NCI core only support the RF static connection. For other NFC features such as Secure Element communication, we may need to create logical connections to the NFCEE (Execution Environment. In order to track each logical connection ID dynamically, we add a linked list of connection info pointers to the nci_dev structure. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-02 05:26:08 +08:00
/* Save RF Discovery ID or NFCEE ID under conn_create */
__u8 cur_id;
NFC: Update names and structs to NCI spec 1.0 d22 Addition, deletion, and modification of NCI constants. Changes in NCI commands, responses, and notifications structures. Signed-off-by: Ilan Elias <ilane@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-12-20 22:57:40 +08:00
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
/* stored during nci_data_exchange */
struct sk_buff *rx_data_reassembly;
NFC: Implement NCI dep_link_up and dep_link_down During NFC-DEP target activation, store the remote general bytes to be used later in dep_link_up. When dep_link_up is called, activate the NFC-DEP target, and forward the remote general bytes. When dep_link_down is called, deactivate the target. Signed-off-by: Ilan Elias <ilane@ti.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2012-08-15 16:46:24 +08:00
/* stored during intf_activated_ntf */
__u8 remote_gb[NFC_MAX_GT_LEN];
__u8 remote_gb_len;
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
};
/* ----- NCI Devices ----- */
struct nci_dev *nci_allocate_device(struct nci_ops *ops,
NFC: NCI code identation fixes Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-03-05 08:03:54 +08:00
__u32 supported_protocols,
int tx_headroom,
int tx_tailroom);
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
void nci_free_device(struct nci_dev *ndev);
int nci_register_device(struct nci_dev *ndev);
void nci_unregister_device(struct nci_dev *ndev);
NFC: nci: Add HCI over NCI protocol support According to the NCI specification, one can use HCI over NCI to talk with specific NFCEE. The HCI network is viewed as one logical NFCEE. This is needed to support secure element running HCI only firmwares embedded on an NCI capable chipset, like e.g. the st21nfcb. There is some duplication between this piece of code and the HCI core code, but the latter would need to be abstracted even more to be able to use NCI as a logical transport for HCP packets. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-02 05:26:14 +08:00
int nci_request(struct nci_dev *ndev,
void (*req)(struct nci_dev *ndev,
unsigned long opt),
unsigned long opt, __u32 timeout);
NFC: nci: Add nci_prop_cmd allowing to send proprietary nci cmd Handle allowing to send proprietary nci commands anywhere in the nci state machine. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-06-06 19:16:41 +08:00
int nci_prop_cmd(struct nci_dev *ndev, __u8 oid, size_t len, __u8 *payload);
NFC: nci: Introduce nci_core_cmd This allows sending core commands from the driver. The driver should be able to send NCI core commands like CORE_GET_CONFIG_CMD. Signed-off-by: Robert Dolca <robert.dolca@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-10-22 17:11:37 +08:00
int nci_core_cmd(struct nci_dev *ndev, __u16 opcode, size_t len, __u8 *payload);
NFC: nci: export nci_core_reset and nci_core_init Some drivers needs to have ability to reinit NCI core, for example after updating firmware in setup() of post_setup() callback. This patch makes nci_core_reset() and nci_core_init() functions public, to make it possible. Signed-off-by: Robert Baldyga <r.baldyga@samsung.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-08-20 23:26:01 +08:00
int nci_core_reset(struct nci_dev *ndev);
int nci_core_init(struct nci_dev *ndev);
NFC: nci: Add nci_prop_cmd allowing to send proprietary nci cmd Handle allowing to send proprietary nci commands anywhere in the nci state machine. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-06-06 19:16:41 +08:00
NFC: NCI: Fix skb->dev usage skb->dev is used for carrying a net_device pointer and not an nci_dev pointer. Remove usage of skb-dev to carry nci_dev and replace it by parameter in nci_recv_frame(), nci_send_frame() and driver send() functions. NfcWilink driver is also updated to use those functions. Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-05-22 17:36:17 +08:00
int nci_recv_frame(struct nci_dev *ndev, struct sk_buff *skb);
NFC: NCI: export nci_send_frame and nci_send_cmd function Export nci_send_frame and nci_send_cmd symbols to allow drivers to use it. This is needed for example if NCI is used during firmware download phase. Signed-off-by: Vincent Cuissard <cuissard@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-10-26 17:27:38 +08:00
int nci_send_frame(struct nci_dev *ndev, struct sk_buff *skb);
NFC: NCI: Add set_config API This API can be used by drivers to send their custom configuration using SET_CONFIG NCI command to the device. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-01-07 04:58:18 +08:00
int nci_set_config(struct nci_dev *ndev, __u8 id, size_t len, __u8 *val);
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
NFC: nci: Add NFCEE discover support NFCEEs (NFC Execution Environment) have to be explicitly discovered by sending the NCI_OP_NFCEE_DISCOVER_CMD command. The NFCC will respond to this command by telling us how many NFCEEs are connected to it. Then the NFCC sends a notification command for each and every NFCEE connected. Here we implement support for sending NCI_OP_NFCEE_DISCOVER_CMD command, receiving the response and the potential notifications. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-02 05:26:10 +08:00
int nci_nfcee_discover(struct nci_dev *ndev, u8 action);
NFC: nci: Add NFCEE enabling and disabling support NFCEEs can be enabled or disabled by sending the NCI_OP_NFCEE_MODE_SET_CMD command to the NFCC. This patch provides an API for drivers to enable and disable e.g. their NCI discoveredd secure elements. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-02 05:26:11 +08:00
int nci_nfcee_mode_set(struct nci_dev *ndev, u8 nfcee_id, u8 nfcee_mode);
NFC: nci: Support all destinations type when creating a connection The current implementation limits nci_core_conn_create_req() to only manage NCI_DESTINATION_NFCEE. Add new parameters to nci_core_conn_create() to support all destination types described in the NCI specification. Because there are some parameters with variable size dynamic buffer allocation is needed. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-04 02:48:05 +08:00
int nci_core_conn_create(struct nci_dev *ndev, u8 destination_type,
u8 number_destination_params,
size_t params_len,
NFC: nci: Support logical connections management In order to communicate with an NFCEE, we need to open a logical connection to it, by sending the NCI_OP_CORE_CONN_CREATE_CMD command to the NFCC. It's left up to the drivers to decide when to close an already opened logical connection. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-02 05:26:12 +08:00
struct core_conn_create_dest_spec_params *params);
int nci_core_conn_close(struct nci_dev *ndev, u8 conn_id);
NFC: nci: Add NFCEE discover support NFCEEs (NFC Execution Environment) have to be explicitly discovered by sending the NCI_OP_NFCEE_DISCOVER_CMD command. The NFCC will respond to this command by telling us how many NFCEEs are connected to it. Then the NFCC sends a notification command for each and every NFCEE connected. Here we implement support for sending NCI_OP_NFCEE_DISCOVER_CMD command, receiving the response and the potential notifications. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-02 05:26:10 +08:00
NFC: nci: Add HCI over NCI protocol support According to the NCI specification, one can use HCI over NCI to talk with specific NFCEE. The HCI network is viewed as one logical NFCEE. This is needed to support secure element running HCI only firmwares embedded on an NCI capable chipset, like e.g. the st21nfcb. There is some duplication between this piece of code and the HCI core code, but the latter would need to be abstracted even more to be able to use NCI as a logical transport for HCP packets. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-02 05:26:14 +08:00
struct nci_hci_dev *nci_hci_allocate(struct nci_dev *ndev);
int nci_hci_send_event(struct nci_dev *ndev, u8 gate, u8 event,
const u8 *param, size_t param_len);
int nci_hci_send_cmd(struct nci_dev *ndev, u8 gate,
u8 cmd, const u8 *param, size_t param_len,
struct sk_buff **skb);
int nci_hci_open_pipe(struct nci_dev *ndev, u8 pipe);
int nci_hci_connect_gate(struct nci_dev *ndev, u8 dest_host,
u8 dest_gate, u8 pipe);
int nci_hci_set_param(struct nci_dev *ndev, u8 gate, u8 idx,
const u8 *param, size_t param_len);
int nci_hci_get_param(struct nci_dev *ndev, u8 gate, u8 idx,
struct sk_buff **skb);
NFC: nci: add nci_hci_clear_all_pipes functions nci_hci_clear_all_pipes might be use full in some cases for example after a firmware update. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-10-26 05:54:23 +08:00
int nci_hci_clear_all_pipes(struct nci_dev *ndev);
NFC: nci: Add HCI over NCI protocol support According to the NCI specification, one can use HCI over NCI to talk with specific NFCEE. The HCI network is viewed as one logical NFCEE. This is needed to support secure element running HCI only firmwares embedded on an NCI capable chipset, like e.g. the st21nfcb. There is some duplication between this piece of code and the HCI core code, but the latter would need to be abstracted even more to be able to use NCI as a logical transport for HCP packets. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-02 05:26:14 +08:00
int nci_hci_dev_session_init(struct nci_dev *ndev);
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
static inline struct sk_buff *nci_skb_alloc(struct nci_dev *ndev,
NFC: NCI code identation fixes Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-03-05 08:03:54 +08:00
unsigned int len,
gfp_t how)
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
{
struct sk_buff *skb;
skb = alloc_skb(len + ndev->tx_headroom + ndev->tx_tailroom, how);
if (skb)
skb_reserve(skb, ndev->tx_headroom);
return skb;
}
static inline void nci_set_parent_dev(struct nci_dev *ndev, struct device *dev)
{
nfc_set_parent_dev(ndev->nfc_dev, dev);
}
static inline void nci_set_drvdata(struct nci_dev *ndev, void *data)
{
ndev->driver_data = data;
}
static inline void *nci_get_drvdata(struct nci_dev *ndev)
{
return ndev->driver_data;
}
NFC: Introduce vendor commands structures Together with inline routines to associate a vendor commands array with an NFC device. Vendor commands allow vendors to implement their very specific operations from driver code instead of adding new stack ops for non NFC generic commands. Vendors need to select their own unique IDs and use that as a namespace for defining sub commands. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2014-10-14 07:42:23 +08:00
static inline int nci_set_vendor_cmds(struct nci_dev *ndev,
struct nfc_vendor_cmd *cmds,
int n_cmds)
{
return nfc_set_vendor_cmds(ndev->nfc_dev, cmds, n_cmds);
}
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
void nci_rsp_packet(struct nci_dev *ndev, struct sk_buff *skb);
void nci_ntf_packet(struct nci_dev *ndev, struct sk_buff *skb);
NFC: nci: Allow the driver to set handler for core nci ops The driver may be required to act when some responses or notifications arrive. For example the NCI core does not have a handler for NCI_OP_CORE_GET_CONFIG_RSP. The NFCC can send a config response that has to be read by the driver and the packet may contain vendor specific data. The Fields Peak driver needs to take certain actions when a reset notification arrives (packet also not handled by the nfc core). The driver handlers do not interfere with the core and they are called after the core processes the packet. Signed-off-by: Robert Dolca <robert.dolca@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-10-22 17:11:38 +08:00
inline int nci_prop_rsp_packet(struct nci_dev *ndev, __u16 opcode,
struct sk_buff *skb);
inline int nci_prop_ntf_packet(struct nci_dev *ndev, __u16 opcode,
struct sk_buff *skb);
inline int nci_core_rsp_packet(struct nci_dev *ndev, __u16 opcode,
NFC: nci: Handle proprietary response and notifications Allow for drivers to explicitly define handlers for each proprietary notifications and responses they expect to support. Reviewed-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-06-06 19:16:37 +08:00
struct sk_buff *skb);
NFC: nci: Allow the driver to set handler for core nci ops The driver may be required to act when some responses or notifications arrive. For example the NCI core does not have a handler for NCI_OP_CORE_GET_CONFIG_RSP. The NFCC can send a config response that has to be read by the driver and the packet may contain vendor specific data. The Fields Peak driver needs to take certain actions when a reset notification arrives (packet also not handled by the nfc core). The driver handlers do not interfere with the core and they are called after the core processes the packet. Signed-off-by: Robert Dolca <robert.dolca@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-10-22 17:11:38 +08:00
inline int nci_core_ntf_packet(struct nci_dev *ndev, __u16 opcode,
NFC: nci: Handle proprietary response and notifications Allow for drivers to explicitly define handlers for each proprietary notifications and responses they expect to support. Reviewed-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-06-06 19:16:37 +08:00
struct sk_buff *skb);
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
void nci_rx_data_packet(struct nci_dev *ndev, struct sk_buff *skb);
int nci_send_cmd(struct nci_dev *ndev, __u16 opcode, __u8 plen, void *payload);
int nci_send_data(struct nci_dev *ndev, __u8 conn_id, struct sk_buff *skb);
NFC: nci: Add function to get max packet size for conn FDP driver needs to send the firmware as regular packets (not fragmented). The driver should have a way to get the max packet size for a given connection. Signed-off-by: Robert Dolca <robert.dolca@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-10-22 17:11:34 +08:00
int nci_conn_max_data_pkt_payload_size(struct nci_dev *ndev, __u8 conn_id);
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
void nci_data_exchange_complete(struct nci_dev *ndev, struct sk_buff *skb,
NFC: nci: Add dynamic logical connections support The current NCI core only support the RF static connection. For other NFC features such as Secure Element communication, we may need to create logical connections to the NFCEE (Execution Environment. In order to track each logical connection ID dynamically, we add a linked list of connection info pointers to the nci_dev structure. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-02 05:26:08 +08:00
__u8 conn_id, int err);
NFC: nci: Add HCI over NCI protocol support According to the NCI specification, one can use HCI over NCI to talk with specific NFCEE. The HCI network is viewed as one logical NFCEE. This is needed to support secure element running HCI only firmwares embedded on an NCI capable chipset, like e.g. the st21nfcb. There is some duplication between this piece of code and the HCI core code, but the latter would need to be abstracted even more to be able to use NCI as a logical transport for HCP packets. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-02 05:26:14 +08:00
void nci_hci_data_received_cb(void *context, struct sk_buff *skb, int err);
NFC: Add NCI multiple targets support Add the ability to select between multiple targets in NCI. If only one target is found, it will be auto-activated. If more than one target is found, then DISCOVER_NTF will be generated for each target, and the host should select one by calling DISCOVER_SELECT_CMD. Then, the target will be activated. If the activation fails, GENERIC_ERROR_NTF is generated. Signed-off-by: Ilan Elias <ilane@ti.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-01-18 19:16:14 +08:00
void nci_clear_target_list(struct nci_dev *ndev);
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
/* ----- NCI requests ----- */
#define NCI_REQ_DONE 0
#define NCI_REQ_PEND 1
#define NCI_REQ_CANCELED 2
void nci_req_complete(struct nci_dev *ndev, int result);
NFC: nci: Add dynamic logical connections support The current NCI core only support the RF static connection. For other NFC features such as Secure Element communication, we may need to create logical connections to the NFCEE (Execution Environment. In order to track each logical connection ID dynamically, we add a linked list of connection info pointers to the nci_dev structure. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-02-02 05:26:08 +08:00
struct nci_conn_info *nci_get_conn_info_by_conn_id(struct nci_dev *ndev,
int conn_id);
NFC: nci: add nci_get_conn_info_by_id function This functin takes as a parameter a pointer to the nci_dev struct and the first byte from the values of the first domain specific parameter that was used for the connection creation. Signed-off-by: Robert Dolca <robert.dolca@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-10-22 17:11:41 +08:00
int nci_get_conn_info_by_id(struct nci_dev *ndev, u8 id);
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
/* ----- NCI status code ----- */
int nci_to_errno(__u8 code);
NFC: Add basic NCI over SPI The NFC Forum defines a transport interface based on Serial Peripheral Interface (SPI) for the NFC Controller Interface (NCI). This module implements the SPI transport of NCI, calling SPI module directly to read/write data to NFC controller (NFCC). NFCC driver should provide functions performing device open and close. It should also provide functions asserting/de-asserting interruption to prevent TX/RX race conditions. NFCC driver can also fix a delay between transactions if needed by the hardware. Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-05-29 21:35:02 +08:00
/* ----- NCI over SPI acknowledge modes ----- */
#define NCI_SPI_CRC_DISABLED 0x00
#define NCI_SPI_CRC_ENABLED 0x01
/* ----- NCI SPI structures ----- */
NFC: NCI: Simplify NCI SPI to become a simple framing/checking layer 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: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-09-05 17:02:21 +08:00
struct nci_spi {
NFC: NCI: Rename spi ndev -> nsdev and nci_dev -> ndev for consistency 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: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-09-02 18:35:39 +08:00
struct nci_dev *ndev;
NFC: Add basic NCI over SPI The NFC Forum defines a transport interface based on Serial Peripheral Interface (SPI) for the NFC Controller Interface (NCI). This module implements the SPI transport of NCI, calling SPI module directly to read/write data to NFC controller (NFCC). NFCC driver should provide functions performing device open and close. It should also provide functions asserting/de-asserting interruption to prevent TX/RX race conditions. NFCC driver can also fix a delay between transactions if needed by the hardware. Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-05-29 21:35:02 +08:00
struct spi_device *spi;
unsigned int xfer_udelay; /* microseconds delay between
transactions */
u8 acknowledge_mode;
NFC: Add NCI over SPI send 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>
2013-05-29 21:35:03 +08:00
struct completion req_completion;
u8 req_result;
NFC: Add basic NCI over SPI The NFC Forum defines a transport interface based on Serial Peripheral Interface (SPI) for the NFC Controller Interface (NCI). This module implements the SPI transport of NCI, calling SPI module directly to read/write data to NFC controller (NFCC). NFCC driver should provide functions performing device open and close. It should also provide functions asserting/de-asserting interruption to prevent TX/RX race conditions. NFCC driver can also fix a delay between transactions if needed by the hardware. Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-05-29 21:35:02 +08:00
};
NFC: NCI: Simplify NCI SPI to become a simple framing/checking layer 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: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-09-05 17:02:21 +08:00
/* ----- NCI SPI ----- */
struct nci_spi *nci_spi_allocate_spi(struct spi_device *spi,
u8 acknowledge_mode, unsigned int delay,
struct nci_dev *ndev);
NFC: NCI: Modify NCI SPI to implement CS/INT handshake per the spec 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: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-09-23 23:56:43 +08:00
int nci_spi_send(struct nci_spi *nspi,
struct completion *write_handshake_completion,
struct sk_buff *skb);
NFC: NCI: nci_spi_recv_frame() now returns (not forward) the read frame 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: Eric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-09-23 23:56:31 +08:00
struct sk_buff *nci_spi_read(struct nci_spi *nspi);
NFC: Add basic NCI over SPI The NFC Forum defines a transport interface based on Serial Peripheral Interface (SPI) for the NFC Controller Interface (NCI). This module implements the SPI transport of NCI, calling SPI module directly to read/write data to NFC controller (NFCC). NFCC driver should provide functions performing device open and close. It should also provide functions asserting/de-asserting interruption to prevent TX/RX race conditions. NFCC driver can also fix a delay between transactions if needed by the hardware. Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2013-05-29 21:35:02 +08:00
NFC: nci: add generic uart support Some NFC controller supports UART as host interface. As with SPI, a lot of code can be shared between vendor drivers. This patch add the generic support of UART and provides some extension API for vendor specific needs. This code is strongly inspired by the Bluetooth HCI ldisc implementation. NCI UART vendor drivers will have to register themselves to this layer via nci_uart_register. Underlying tty will have to be configured from user land thanks to an ioctl. Signed-off-by: Vincent Cuissard <cuissard@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2015-06-11 17:25:47 +08:00
/* ----- NCI UART ---- */
/* Ioctl */
#define NCIUARTSETDRIVER _IOW('U', 0, char *)
enum nci_uart_driver {
NCI_UART_DRIVER_MARVELL = 0,
NCI_UART_DRIVER_MAX
};
struct nci_uart;
struct nci_uart_ops {
int (*open)(struct nci_uart *nci_uart);
void (*close)(struct nci_uart *nci_uart);
int (*recv)(struct nci_uart *nci_uart, struct sk_buff *skb);
int (*recv_buf)(struct nci_uart *nci_uart, const u8 *data, char *flags,
int count);
int (*send)(struct nci_uart *nci_uart, struct sk_buff *skb);
void (*tx_start)(struct nci_uart *nci_uart);
void (*tx_done)(struct nci_uart *nci_uart);
};
struct nci_uart {
struct module *owner;
struct nci_uart_ops ops;
const char *name;
enum nci_uart_driver driver;
/* Dynamic data */
struct nci_dev *ndev;
spinlock_t rx_lock;
struct work_struct write_work;
struct tty_struct *tty;
unsigned long tx_state;
struct sk_buff_head tx_q;
struct sk_buff *tx_skb;
struct sk_buff *rx_skb;
int rx_packet_len;
void *drv_data;
};
int nci_uart_register(struct nci_uart *nu);
void nci_uart_unregister(struct nci_uart *nu);
void nci_uart_set_config(struct nci_uart *nu, int baudrate, int flow_ctrl);
NFC: basic NCI protocol implementation 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>
2011-09-18 16:19:35 +08:00
#endif /* __NCI_CORE_H */
Reference in New Issue Copy Permalink