summaryrefslogtreecommitdiffstats
path: root/net/nfc
Commit message (Collapse)AuthorAgeFilesLines
...
* NFC: nfc_disable_se Remove useless blank line at beginning of functionChristophe Ricard2015-01-261-1/+0
| | | | | | | Remove one useless blank line at beginning of nfc_disable_se function. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: nfc_enable_se Remove useless blank line at beginning of functionChristophe Ricard2015-01-261-1/+0
| | | | | | | Remove one useless blank line at beginning of nfc_enable_se function. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* netlink: make nlmsg_end() and genlmsg_end() voidJohannes Berg2015-01-181-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Johannes Berg <johannes.berg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge tag 'master-2014-12-08' of ↵David S. Miller2014-12-0910-125/+1188
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next John W. Linville says: ==================== pull request: wireless-next 2014-12-08 Please pull this last batch of pending wireless updates for the 3.19 tree... For the wireless bits, Johannes says: "This time I have Felix's no-status rate control work, which will allow drivers to work better with rate control even if they don't have perfect status reporting. In addition to this, a small hwsim fix from Patrik, one of the regulatory patches from Arik, and a number of cleanups and fixes I did myself. Of note is a patch where I disable CFG80211_WEXT so that compatibility is no longer selectable - this is intended as a wake-up call for anyone who's still using it, and is still easily worked around (it's a one-line patch) before we fully remove the code as well in the future." For the Bluetooth bits, Johan says: "Here's one more bluetooth-next pull request for 3.19: - Minor cleanups for ieee802154 & mac802154 - Fix for the kernel warning with !TASK_RUNNING reported by Kirill A. Shutemov - Support for another ath3k device - Fix for tracking link key based security level - Device tree bindings for btmrvl + a state update fix - Fix for wrong ACL flags on LE links" And... "In addition to the previous one this contains two more cleanups to mac802154 as well as support for some new HCI features from the Bluetooth 4.2 specification. From the original request: 'Here's what should be the last bluetooth-next pull request for 3.19. It's rather large but the majority of it is the Low Energy Secure Connections feature that's part of the Bluetooth 4.2 specification. The specification went public only this week so we couldn't publish the corresponding code before that. The code itself can nevertheless be considered fairly mature as it's been in development for over 6 months and gone through several interoperability test events. Besides LE SC the pull request contains an important fix for command complete events for mgmt sockets which also fixes some leaks of hci_conn objects when powering off or unplugging Bluetooth adapters. A smaller feature that's part of the pull request is service discovery support. This is like normal device discovery except that devices not matching specific UUIDs or strong enough RSSI are filtered out. Other changes that the pull request contains are firmware dump support to the btmrvl driver, firmware download support for Broadcom BCM20702A0 variants, as well as some coding style cleanups in 6lowpan & ieee802154/mac802154 code.'" For the NFC bits, Samuel says: "With this one we get: - NFC digital improvements for DEP support: Chaining, NACK and ATN support added. - NCI improvements: Support for p2p target, SE IO operand addition, SE operands extensions to support proprietary implementations, and a few fixes. - NFC HCI improvements: OPEN_PIPE and NOTIFY_ALL_CLEARED support, and SE IO operand addition. - A bunch of minor improvements and fixes for STMicro st21nfcb and st21nfca" For the iwlwifi bits, Emmanuel says: "Major works are CSA and TDLS. On top of that I have a new firmware API for scan and a few rate control improvements. Johannes find a few tricks to improve our CPU utilization and adds support for a new spin of 7265 called 7265D. Along with this a few random things that don't stand out." And... "I deprecate here -8.ucode since -9 has been published long ago. Along with that I have a new activity, we have now better a infrastructure for firmware debugging. This will allow to have configurable probes insides the firmware. Luca continues his work on NetDetect, this feature is now complete. All the rest is minor fixes here and there." For the Atheros bits, Kalle says: "Only ath10k changes this time and no major changes. Most visible are: o new debugfs interface for runtime firmware debugging (Yanbo) o fix shared WEP (Sujith) o don't rebuild whenever kernel version changes (Johannes) o lots of refactoring to make it easier to add new hw support (Michal) There's also smaller fixes and improvements with no point of listing here." In addition, there are a few last minute updates to ath5k, ath9k, brcmfmac, brcmsmac, mwifiex, rt2x00, rtlwifi, and wil6210. Also included is a pull of the wireless tree to pick-up the fixes originally included in "pull request: wireless 2014-12-03"... Please let me know if there are problems! ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * NFC: NCI: Fix max length of General Bytes in ATR_RESJulien Lefrique2014-12-021-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Julien Lefrique <lefrique@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: nci: Fix warning: cast to restricted __le16Christophe Ricard2014-12-021-1/+1
| | | | | | | | | | | | | | | | 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: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: Fix warning "warning: incorrect type in assignment"Christophe Ricard2014-12-021-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: hci: Add specific hci macro to not create a pipeChristophe Ricard2014-12-021-0/+3
| | | | | | | | | | | | | | | | | | | | 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: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: Add se_io NFC operandChristophe Ricard2014-12-021-1/+46
| | | | | | | | | | | | | | | | 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>
| * NFC: netlink: Add new netlink command NFC_CMD_ACTIVATE_TARGETChristophe Ricard2014-12-021-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | 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: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: nci: Add support for different NCI_DEACTIVATE_TYPEChristophe Ricard2014-12-021-4/+6
| | | | | | | | | | | | | | | | | | | | 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: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: nci: Add management for NCI state for machine rf_deactivate_ntfChristophe Ricard2014-12-021-4/+14
| | | | | | | | | | | | | | | | | | | | 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: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: nci: Add status byte management in case of error.Christophe Ricard2014-12-021-2/+9
| | | | | | | | | | | | | | | | | | 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: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: hci: Add support for NOTIFY_ALL_PIPE_CLEAREDChristophe Ricard2014-12-021-0/+3
| | | | | | | | | | | | | | | | | | | | | | 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: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: hci: Add open pipe command handlerChristophe Ricard2014-12-021-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | 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: Arron Wang <arron.wang@intel.com> Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: nci: Add se_io NCI operandChristophe Ricard2014-12-021-0/+14
| | | | | | | | | | | | | | 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>
| * NFC: nci: Update nci_disable_se to run proprietary commands to disable a ↵Christophe Ricard2014-12-021-0/+5
| | | | | | | | | | | | | | | | | | | | 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>
| * NFC: nci: Update nci_enable_se to run proprietary commands to enable a ↵Christophe Ricard2014-12-021-0/+5
| | | | | | | | | | | | | | | | | | | | 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>
| * NFC: nci: Update nci_discover_se to run proprietary commands to discover all ↵Christophe Ricard2014-12-021-0/+5
| | | | | | | | | | | | | | | | | | | | 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>
| * NFC: nci: Fix sparse: symbol 'nci_get_prop_rf_protocol' was not declared.Christophe Ricard2014-12-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix sparse warning introduced by commit: 9e87f9a9c4c4754508b2c2638fbde9e10c7a103b 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 9e87f9a9c4c4754508b2c2638fbde9e10c7a103b make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: hci: Add se_io HCI operandChristophe Ricard2014-12-021-0/+14
| | | | | | | | | | | | | | 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>
| * NFC: NCI: Signal deactivation in Target modeJulien Lefrique2014-11-281-1/+16
| | | | | | | | | | | | | | | | | | 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: Julien Lefrique <lefrique@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: NCI: Handle Discovery deactivation typeJulien Lefrique2014-11-281-1/+4
| | | | | | | | | | | | | | | | 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: Julien Lefrique <lefrique@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: Fix a memory leakJulien Lefrique2014-11-281-1/+4
| | | | | | | | | | Signed-off-by: Julien Lefrique <lefrique@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: NCI: Forward data received in Target mode to nfc coreJulien Lefrique2014-11-281-1/+12
| | | | | | | | | | Signed-off-by: Julien Lefrique <lefrique@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: NCI: Implement Target mode send functionJulien Lefrique2014-11-281-0/+13
| | | | | | | | | | | | | | | | | | 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: Julien Lefrique <lefrique@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: NCI: Configure ATR_RES general bytesJulien Lefrique2014-11-281-1/+9
| | | | | | | | | | | | | | | | | | | | 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: Julien Lefrique <lefrique@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: NCI: Handle Target mode activationJulien Lefrique2014-11-281-24/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * NFC: NCI: Enable NFC-DEP in Listen A and Listen FJulien Lefrique2014-11-281-0/+29
| | | | | | | | | | | | | | | | 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: Julien Lefrique <lefrique@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: NCI: Add passive Listen modes in discover requestJulien Lefrique2014-11-281-10/+32
| | | | | | | | | | | | | | | | | | | | 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: Julien Lefrique <lefrique@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: llcp: Use list_for_each_entry in llcp_accept_pollAxel Lin2014-11-281-3/+3
| | | | | | | | | | | | | | | | | | list_for_each_entry_safe() is necessary if list objects are deleted from the list while traversing it. Not the case here, so we can use the base list_for_each_entry variant. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: Add NFC-DEP Target-side ATN SupportMark A. Greer2014-11-281-5/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an NFC-DEP target receives an ATN PDU, its supposed to respond with a similar ATN PDU. When the Target receives an I PDU with the PNI one less than the current PNI and the last PDU sent was an ATN PDU, the Target is to resend the last non-ATN PDU that it has sent. This is described in section 14.12.3.4 of the NFC Digital Protocol Spec. The digital layer's NFC-DEP code doesn't implement this so add that support. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: Add NFC-DEP Initiator-side ATN SupportMark A. Greer2014-11-281-6/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an NFC-DEP Initiator times out when waiting for a DEP_RES from the Target, its supposed to send an ATN to the Target. The Target should respond to the ATN with a similar ATN PDU and the Initiator can then resend the last non-ATN PDU that it sent. No more than 'N(retry,atn)' are to be send where 2 <= 'N(retry,atn)' <= 5. If the Initiator had just sent a NACK PDU when the timeout occurred, it is to continue sending NACKs until 'N(retry,nack)' NACKs have been send. This is described in section 14.12.5.6 of the NFC-DEP Digital Protocol Spec. The digital layer's NFC-DEP code doesn't implement this so add that support. The value chosen for 'N(retry,atn)' is 2. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: Add NFC-DEP Target-side NACK SupportMark A. Greer2014-11-281-11/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an NFC-DEP Target receives a NACK PDU with a PNI equal to 1 less than the current PNI, it is supposed to re-send the last PDU. This is implied in section 14.12.5.4 of the NFC Digital Protocol Spec. The digital layer's NFC-DEP code doesn't implement Target-side NACK handing so add it. The last PDU that was sent is saved in the 'nfc_digital_dev' structure's 'saved_skb' member. The skb will have an additional reference taken to ensure that the skb isn't freed when the driver performs a kfree_skb() on the skb. The length of the skb/PDU is also saved so the length can be restored when re-sending the PDU in the skb (the driver will perform an skb_pull() so an skb_push() needs to be done to restore the skb's data pointer/length). Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: Add NFC-DEP Initiator-side NACK SupportMark A. Greer2014-11-281-5/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an NFC-DEP Initiator receives a frame with an incorrect CRC or with a parity error, and the frame is at least 4 bytes long, its supposed to send a NACK to the Target. The Initiator can send up to 'N(retry,nack)' consecutive NACKs where 2 <= 'N(retry,nack)' <= 5. When the limit is exceeded, a PROTOCOL EXCEPTION is raised. Any other type of transmission error is to be ignored and the Initiator should continue waiting for a new frame. This is described in section 14.12.5.4 of the NFC Digital Protocol Spec. The digital layer's NFC-DEP code doesn't implement any of this so add it. This support diverges from the spec in two significant ways: a) NACKs will be sent for ANY error reported by the driver except a timeout. This is done because there is currently no way for the digital layer to distinguish a CRC or parity error from any other type of error reported by the driver. b) All other errors will cause a PROTOCOL EXCEPTION even frames with CRC errors that are less than 4 bytes. The value chosen for 'N(retry,nack)' is 2. Targets do not send NACK PDUs. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: Add NFC-DEP Receive Chaining SupportMark A. Greer2014-11-281-6/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the peer in an NFC-DEP exchange has a packet to send that is larger than the local maximum payload, it sets the 'MI' bit in the 'I' PDU. This indicates that NFC-DEP chaining is to occur. When such a PDU is received, the local side responds with an 'ACK' PDU and this continues until the peer sends an 'I' PDU with the 'MI' bit cleared. This indicates that the chaining sequence is complete and the entire packet has been transferred. Receiving chained PDUs is currently not supported by the digital layer so add that support. When a chaining sequence is initiated by the peer, the digital layer will allocate an skb large enough to hold 8 maximum sized frame payloads. The maximum payload can range from 64 to 254 bytes so 8 * 254 = 2032 seems like a reasonable compromise between potentially wasting memory and constantly reallocating new, larger skbs. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: Add NFC-DEP Send Chaining SupportMark A. Greer2014-11-281-17/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the NFC-DEP code is given a packet to send that is larger than the peer's maximum payload, its supposed to set the 'MI' bit in the 'I' PDU's Protocol Frame Byte (PFB). Setting this bit indicates that NFC-DEP chaining is to occur. When NFC-DEP chaining is progress, sender 'I' PDUs are acknowledged with 'ACK' PDUs until the last 'I' PDU in the chain (which has the 'MI' bit cleared) is responded to with a normal 'I' PDU. This can occur while in Initiator mode or in Target mode. Sender NFC-DEP chaining is currently not implemented in the digital layer so add that support. Unfortunately, since sending a frame may require writing the CRC to the end of the data, the relevant data part of the original skb must be copied for each intermediate frame. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: Implement NFC-DEP max payload lengthsMark A. Greer2014-11-281-10/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The maximum payload for NFC-DEP exchanges (i.e., the number of bytes between SoD and EoD) is negotiated using the ATR_REQ, ATR_RES, and PSL_REQ commands. The valid maximum lengths are 64, 128, 192, and 254 bytes. Currently, NFC-DEP code assumes that both sides are always using 254 byte maximums and ignores attempts by the peer to change it. Instead, implement the negotiation code, enforce the local maximum when receiving data from the peer, and don't send payloads that exceed the remote's maximum. The default local maximum is 254 bytes. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: Enforce NFC-DEP PNI sequencingMark A. Greer2014-11-281-3/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NFC-DEP DEP_REQ and DEP_RES exchanges using 'I' and 'ACK/NACK' PDUs have a sequence number called the Packet Number Information (PNI). The PNI is incremented (modulo 4) after every DEP_REQ/ DEP_RES pair and should be verified by the digital layer code. That verification isn't always done, though, so add code to make sure that it is done. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: Ensure no NAD byte in DEP_REQ and DEP_RES framesMark A. Greer2014-11-281-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | According to chapter 14 of the NFC-DEP Digital Protocol Spec., the NAD byte should never be present in DEP_REQ or DEP_RES frames. However, this is not enforced so add that enforcement code. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: Add Target-mode NFC-DEP DID SupportMark A. Greer2014-11-281-4/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When in Target mode, the Initiator specifies whether subsequent DEP_REQ and DEP_RES frames will include a DID byte by the value passed in the ATR_REQ. If the DID value in the ATR_REQ is '0' then no DID byte will be included. If the DID value is between '1' and '14' then a DID byte containing the same value must be included in subsequent DEP_REQ and DEP_RES frames. Any other DID value is invalid. This is specified in sections 14.8.1.2 and 14.8.2.2 of the NFC Digital Protocol Spec. Checking the DID value (if it should be there at all), is not currently supported by the digital layer's NFC-DEP code. Add this support by remembering the DID value in the ATR_REQ, checking the DID value of received DEP_REQ frames (if it should be there at all), and including the remembered DID value in DEP_RES frames when appropriate. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: Ensure no DID in NFC-DEP responsesMark A. Greer2014-11-281-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When in Initiator mode, the digital layer's NFC-DEP code always sets the Device ID (DID) value in the ATR_REQ to '0'. This means that subsequent DEP_REQ and DEP_RES frames must never include a DID byte. This is specified in sections 14.8.1.1 and 14.8.2.1 of the NFC Digital Protocol Spec. Currently, the digital layer's NFC-DEP code doesn't enforce this rule so add code to ensure that there is no DID byte in DEP_RES frames. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: Rearrange NFC-DEP DEP_REQ/DEP_RES CodeMark A. Greer2014-11-281-21/+22
| | | | | | | | | | | | | | | | | | | | | | | | Rearrange some of the code in digital_in_recv_dep_res() and digital_tg_recv_dep_req() so the initial code looks similar. The real reason is prepare the code for some upcoming patches that require these changes. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: Fix potential skb leaks in NFC-DEP codeMark A. Greer2014-11-281-8/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | When digital_in_send_cmd() or digital_tg_send_cmd() fail, they do not free the skb that was passed to them so the routine that allocated the skb should free it. Currently, there are several routines in the NFC-DEP code that don't do this so make them. Reviewed-by: Thierry Escande <thierry.escande@linux.intel.com> Tested-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* | new helper: memcpy_from_msg()Al Viro2014-11-242-3/+3
| | | | | | | | Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* | net: Add and use skb_copy_datagram_msg() helper.David S. Miller2014-11-052-2/+2
|/ | | | | | | | | | | | | | | This encapsulates all of the skb_copy_datagram_iovec() callers with call argument signature "skb, offset, msghdr->msg_iov, length". When we move to iov_iters in the networking, the iov_iter object will sit in the msghdr. Having a helper like this means there will be less places to touch during that transformation. Based upon descriptions and patch from Al Viro. Signed-off-by: David S. Miller <davem@davemloft.net>
* NFC: nci: Add support for proprietary RF ProtocolsChristophe Ricard2014-09-241-1/+8
| | | | | | | | | | | | | | | | | 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>
* NFC: NCI: Fix NCI RF FRAME interface usageVincent Cuissard2014-09-011-2/+5
| | | | | | | | | NCI RF FRAME interface is used for all kind of tags except ISODEP ones. So for all other kind of tags the status byte has to be removed. Signed-off-by: Vincent Cuissard <cuissard@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: NCI: Fix nci_register_device init sequenceVincent Cuissard2014-09-011-8/+5
| | | | | | | | | | | All contexts have to be initiliazed before calling nfc_register_device otherwise it is possible to call nci_dev_up before ending the nci_register_device function. In such case kernel will crash on non initialized variables. Signed-off-by: Vincent Cuissard <cuissard@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: NCI: Add support of ISO15693Vincent Cuissard2014-09-012-0/+39
| | | | | | | | | Update nci.h to respect latest NCI specification proposal (stop using proprietary opcodes). Handle ISO15693 parameters in NCI_RF_ACTIVATED_NTF handler. Signed-off-by: Vincent Cuissard <cuissard@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-02 05:32:51 +0000