- 03 2月, 2015 5 次提交
-
-
由 Christophe Ricard 提交于
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: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
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: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
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: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
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: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
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: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
- 28 1月, 2015 6 次提交
-
-
由 Christophe Ricard 提交于
With the newly introduced pipes table hci_dev fields, the nfc_hci_pipe2gate routine is no longer needed. Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
When a command is received, it is sometime needed to let the CLF driver do some additional operations. (ex: count remaining pipe notification...) Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
We update the tracked pipes status when receiving HCI commands. Also we forward HCI errors and we reply to any HCI command, even though we don't support it. Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
As there can be several pipes connected to the same gate, we need to know which pipe ID to use when sending an HCI response. A gate ID is not enough. Instead of changing the nfc_hci_send_response() API to something not aligned with the rest of the HCI API, we call nfc_hci_hcp_message_tx directly. Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
In order to keep host source information on specific hci event (such as evt_connectivity or evt_transaction) and because 2 pipes can be connected to the same gate, it is necessary to add a table referencing every pipe with a {gate, host} tuple. Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
Several pipes may point to the same CLF gate, so getting the gate ID as an input is not enough. For example dual secure element may have 2 pipes (1 for uicc and 1 for eSE) pointing to the connectivity gate. As resolving gate and host IDs can be done from a pipe, we now pass the pipe ID to the event received handler. Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
- 27 1月, 2015 2 次提交
-
-
由 Christophe Ricard 提交于
Remove one useless blank line at beginning of nfc_disable_se function. Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
Remove one useless blank line at beginning of nfc_enable_se function. Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
- 18 1月, 2015 1 次提交
-
-
由 Johannes Berg 提交于
Contrary to common expectations for an "int" return, these functions return only a positive value -- if used correctly they cannot even return 0 because the message header will necessarily be in the skb. This makes the very common pattern of if (genlmsg_end(...) < 0) { ... } be a whole bunch of dead code. Many places also simply do return nlmsg_end(...); and the caller is expected to deal with it. This also commonly (at least for me) causes errors, because it is very common to write if (my_function(...)) /* error condition */ and if my_function() does "return nlmsg_end()" this is of course wrong. Additionally, there's not a single place in the kernel that actually needs the message length returned, and if anyone needs it later then it'll be very easy to just use skb->len there. Remove this, and make the functions void. This removes a bunch of dead code as described above. The patch adds lines because I did - return nlmsg_end(...); + nlmsg_end(...); + return 0; I could have preserved all the function's return values by returning skb->len, but instead I've audited all the places calling the affected functions and found that none cared. A few places actually compared the return value with <= 0 in dump functionality, but that could just be changed to < 0 with no change in behaviour, so I opted for the more efficient version. One instance of the error I've made numerous times now is also present in net/phonet/pn_netlink.c in the route_dumpit() function - it didn't check for <0 or <=0 and thus broke out of the loop every single time. I've preserved this since it will (I think) have caused the messages to userspace to be formatted differently with just a single message for every SKB returned to userspace. It's possible that this isn't needed for the tools that actually use this, but I don't even know what they are so couldn't test that changing this behaviour would be acceptable. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 03 12月, 2014 9 次提交
-
-
由 Julien Lefrique 提交于
The maximum size of ATR_REQ and ATR_RES is 64 bytes. The maximum number of General Bytes is calculated by the maximum number of data bytes in the ATR_REQ/ATR_RES, substracted by the number of mandatory data bytes. ATR_REQ: 16 mandatory data bytes, giving a maximum of 48 General Bytes. ATR_RES: 17 mandatory data bytes, giving a maximum of 47 General Bytes. Regression introduced in commit a99903ec. Signed-off-by: NJulien Lefrique <lefrique@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
Fixing: net/nfc/nci/ntf.c:106:31: warning: cast to restricted __le16 message when building with make C=1 CF=-D__CHECK_ENDIAN__ Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
Fix warnings: net/nfc/llcp_commands.c:421:14: warning: incorrect type in assignment (different base types) net/nfc/llcp_commands.c:421:14: expected unsigned short [unsigned] [usertype] miux net/nfc/llcp_commands.c:421:14: got restricted __be16 net/nfc/llcp_commands.c:477:14: warning: incorrect type in assignment (different base types) net/nfc/llcp_commands.c:477:14: expected unsigned short [unsigned] [usertype] miux net/nfc/llcp_commands.c:477:14: got restricted __be16 Procedure to reproduce: make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
Some pipe are only created by other host (different than the Terminal Host). The pipe values will for example be notified by NFC_HCI_ADM_NOTIFY_PIPE_CREATED. Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
se_io allows to send apdu over the CLF to the embedded Secure Element. Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
Some tag might get deactivated after some read or write tentative. This may happen for example with Mifare Ultralight C tag when trying to read the last 4 blocks (starting block 0x2c) configured as write only. NFC_CMD_ACTIVATE_TARGET will try to reselect the tag in order to detect if it got remove from the field or if it is still present. Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
nci_rf_deactivate_req only support NCI_DEACTIVATE_TYPE_IDLE_MODE. In some situation, it might be necessary to be able to support other NCI_DEACTIVATE_TYPE such as NCI_DEACTIVATE_TYPE_SLEEP_MODE in order for example to reactivate the selected target. Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
A notification for rf deaction can be IDLE_MODE, SLEEP_MODE, SLEEP_AF_MODE and DISCOVERY. According to each type and the NCI state machine is different (see figure 10 RF Communication State Machine in NCI specification) Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
The nci status byte was ignored. In case of tag reading for example, if the tag is removed from the antenna there is no way for the upper layers (aka: stack) to get inform about such event. Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
- 02 12月, 2014 8 次提交
-
-
由 Christophe Ricard 提交于
When switching from UICC to another, the CLF may signals to the Terminal Host that some existing pipe are cleared for future update. This notification needs to be "acked" by the Terminal Host with a ANY_OK message. Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
If our terminal connect with other host like UICC, it may create a pipe with us, the host controller will notify us new pipe created, after that UICC will open that pipe, if we don't handle that request, UICC may failed to continue initialize which may lead to card emulation feature failed to work Signed-off-by: NArron Wang <arron.wang@intel.com> Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
se_io allows to send apdu over the CLF to the embedded Secure Element. Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
Some NFC controller using NCI protocols may need a proprietary commands flow to disable a secure element Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
Some NFC controller using NCI protocols may need a proprietary commands flow to enable a secure element Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
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: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
Fix sparse warning introduced by commit: 9e87f9a9 It was generating the following warning: net/nfc/nci/ntf.c:170:7: sparse: symbol 'nci_get_prop_rf_protocol' was not declared. Should it be static? Procedure to reproduce it: # apt-get install sparse git checkout 9e87f9a9 make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ Signed-off-by: NFengguang Wu <fengguang.wu@intel.com> Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Christophe Ricard 提交于
se_io allows to send apdu over the CLF to the embedded Secure Element. Signed-off-by: NChristophe Ricard <christophe-h.ricard@st.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
- 28 11月, 2014 9 次提交
-
-
由 Julien Lefrique 提交于
Before signaling the deactivation, send a deactivation request if in RFST_DISCOVERY state because neard assumes polling is stopped and will try to restart it. Signed-off-by: NJulien Lefrique <lefrique@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Julien Lefrique 提交于
When the deactivation type reported by RF_DEACTIVATE_NTF is Discovery, go in RFST_DISCOVERY state. The NFCC stays in Poll mode and/or Listen mode. Signed-off-by: NJulien Lefrique <lefrique@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Julien Lefrique 提交于
Signed-off-by: NJulien Lefrique <lefrique@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Julien Lefrique 提交于
Signed-off-by: NJulien Lefrique <lefrique@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Julien Lefrique 提交于
As specified in NCI 1.0 and NCI 1.1, when using the NFC-DEP RF Interface, the DH and the NFCC shall only use the Static RF Connection for data communication with a Remote NFC Endpoint. Signed-off-by: NJulien Lefrique <lefrique@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Julien Lefrique 提交于
The Target responds to the ATR_REQ with the ATR_RES. Configure the General Bytes in ATR_RES with the first three octets equal to the NFC Forum LLCP magic number, followed by some LLC Parameters TLVs described in section 4.5 of [LLCP]. Signed-off-by: NJulien Lefrique <lefrique@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Julien Lefrique 提交于
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: NJulien Lefrique <lefrique@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Julien Lefrique 提交于
Send LA_SEL_INFO and LF_PROTOCOL_TYPE with NFC-DEP protocol enabled. Configure 212 Kbit/s and 412 Kbit/s bit rates for Listen F. Signed-off-by: NJulien Lefrique <lefrique@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Julien Lefrique 提交于
The Target mode protocols are given to the nci_start_poll() function but were previously ignored. To enable P2P Target, when NFC-DEP is requested as a Target mode protocol, add NFC-A and NFC-F Passive Listen modes in RF_DISCOVER_CMD command. Signed-off-by: NJulien Lefrique <lefrique@marvell.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-