summaryrefslogtreecommitdiffstats
path: root/net/nfc (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
| * 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>
* NFC: digital: Add Inititor-side PSL supportMark A. Greer2014-08-311-0/+101
| | | | | | | | | | | | | In order to operate at the fasted bit rate possible, add initiator-side support for PSL REQ while in P2P mode. The PSL REQ will switch the RF technology to 424F whenever possible. 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>
* Merge tag 'master-2014-07-31' of ↵David S. Miller2014-08-056-20/+128
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next Conflicts: net/6lowpan/iphc.c Minor conflicts in iphc.c were changes overlapping with some style cleanups. John W. Linville says: ==================== Please pull this last(?) batch of wireless change intended for the 3.17 stream... For the NFC bits, Samuel says: "This is a rather quiet one, we have: - A new driver from ST Microelectronics for their NCI ST21NFCB, including device tree support. - p2p support for the ST21NFCA driver - A few fixes an enhancements for the NFC digital laye" For the Atheros bits, Kalle says: "Michal and Janusz did some important RX aggregation fixes, basically we were missing RX reordering altogether. The 10.1 firmware doesn't support Ad-Hoc mode and Michal fixed ath10k so that it doesn't advertise Ad-Hoc support with that firmware. Also he implemented a workaround for a KVM issue." For the Bluetooth bits, Gustavo and Johan say: "To quote Gustavo from his previous request: 'Some last minute fixes for -next. We have a fix for a use after free in RFCOMM, another fix to an issue with ADV_DIRECT_IND and one for ADV_IND with auto-connection handling. Last, we added support for reading the codec and MWS setting for controllers that support these features.' Additionally there are fixes to LE scanning, an update to conform to the 4.1 core specification as well as fixes for tracking the page scan state. All of these fixes are important for 3.17." And, "We've got: - 6lowpan fixes/cleanups - A couple crash fixes, one for the Marvell HCI driver and another in LE SMP. - Fix for an incorrect connected state check - Fix for the bondable requirement during pairing (an issue which had crept in because of using "pairable" when in fact the actual meaning was "bondable" (these have different meanings in Bluetooth)" Along with those are some late-breaking hardware support patches in brcmfmac and b43 as well as a stray ath9k patch. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * NFC: digital: Add 'tg_listen_md' and 'tg_get_rf_tech' driver hooksMark A. Greer2014-07-233-9/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The digital layer of the NFC subsystem currently supports a 'tg_listen_mdaa' driver hook that supports devices that can do mode detection and automatic anticollision. However, there are some devices that can do mode detection but not automatic anitcollision so add the 'tg_listen_md' hook to support those devices. In order for the digital layer to get the RF technology detected by the device from the driver, add the 'tg_get_rf_tech' hook. It is only valid to call this hook immediately after a successful call to 'tg_listen_md'. CC: 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: hci: Add stop_poll HCI operand.Christophe Ricard2014-07-231-2/+5
| | | | | | | | | | | | | | | | stop_poll allows to stop CLF reader polling. Some other operations might be necessary for some CLF to stop polling. For example in card mode. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: nci: Add T1T support notificationChristophe Ricard2014-07-231-1/+3
| | | | | | | | | | | | | | | | | | Add T1T matching with Jewel during notification. It was causing "the target found does not have the desired protocol" to show up. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * NFC: digital: Add digital framing calls when in target modeMark A. Greer2014-07-211-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add new "NFC_DIGITAL_FRAMING_*" calls to the digital layer so the driver can make the necessary adjustments when performing anticollision while in target mode. The driver must ensure that the effect of these calls happens after the following response has been sent but before reception of the next request begins. Acked-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: Clear poll_tech_count before activating targetMark A. Greer2014-07-212-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, digital_target_found() has a race between the events started by calling nfc_targets_found() (which ultimately expect ddev->poll_tech_count to be zero) and setting ddev->poll_tech_count to zero after the call to nfc_targets_found(). When the race is "lost" (i.e., ddev->poll_tech_count is found to not be zero by the events started by nfc_targets_found()), an error message is printed and the target is not found. A similar race exists when digital_tg_recv_atr_req() calls nfc_tm_activated(). Fix this by first saving the current value of ddev->poll_tech_count and then clearing it before calling nfc_targets_found()/nfc_tm_activated(). Clearing ddev->poll_tech_count before calling nfc_targets_found()/nfc_tm_activated() eliminates the race. Saving the value is required so it can be restored when nfc_targets_found()/nfc_tm_activated() fails and polling needs to continue. Acked-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: Check for NFC-DEP before checking for Type 4 tagMark A. Greer2014-07-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In digital_in_recv_sel_res(), the code that determines the tag type will interpret bits 7:6 (lsb being b1 as per the Digital Specification) of a SEL RES set to 11b as a Type 4 tag. This is okay except that the neard will interpret the same value as an NFC-DEP device (in src/tag.c:set_tag_type() in the neard source). Make the digital layer's interpretation match neard's interpretation by changing the order of the checks in digital_in_recv_sel_res() so that a value of 11b in bits 7:6 is interpreted as an NFC-DEP device instead of a Type 4 tag. Acked-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: remove unnecessary break after gotoFabian Frederick2014-07-161-2/+0
|/ | | | | Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: add __pskb_copy_fclone and pskb_copy_for_cloneOctavian Purdila2014-06-122-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are several instances where a pskb_copy or __pskb_copy is immediately followed by an skb_clone. Add a couple of new functions to allow the copy skb to be allocated from the fclone cache and thus speed up subsequent skb_clone calls. Cc: Alexander Smirnov <alex.bluesman.smirnov@gmail.com> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Cc: Marek Lindner <mareklindner@neomailbox.ch> Cc: Simon Wunderlich <sw@simonwunderlich.de> Cc: Antonio Quartulli <antonio@meshcoding.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: Johan Hedberg <johan.hedberg@gmail.com> Cc: Arvid Brodin <arvid.brodin@alten.se> Cc: Patrick McHardy <kaber@trash.net> Cc: Pablo Neira Ayuso <pablo@netfilter.org> Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> Cc: Lauro Ramos Venancio <lauro.venancio@openbossa.org> Cc: Aloisio Almeida Jr <aloisio.almeida@openbossa.org> Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Jon Maloy <jon.maloy@ericsson.com> Cc: Allan Stephens <allan.stephens@windriver.com> Cc: Andrew Hendry <andrew.hendry@gmail.com> Cc: Eric Dumazet <edumazet@google.com> Reviewed-by: Christoph Paasch <christoph.paasch@uclouvain.be> Signed-off-by: Octavian Purdila <octavian.purdila@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* NFC: nfc_sock_link() can be staticFengguang Wu2014-05-261-2/+2
| | | | | | | CC: Hiren Tandel <hirent@marvell.com> CC: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: digital_in_send_attrib_req() can be staticFengguang Wu2014-05-261-1/+1
| | | | | | | CC: "Mark A. Greer" <mgreer@animalcreek.com> CC: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Randomize poll cyclesThierry Escande2014-05-261-2/+4
| | | | | | | | | | | This change adds some entropy to polling cycles, choosing the next polling rf technology randomly. This reflects the change done in the pn533 driver, avoiding possible infinite loop for devices that export 2 targets on 2 different modulations. If the first target is not readable, we will stay in an error loop for ever. Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Return proper error code when sending ATR_REQThierry Escande2014-05-261-3/+2
| | | | | | | | The error code returned by digital_in_send_cmd() was not returned by digital_in_send_atr_req(). Signed-off-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: NCI: Send all NCI frames to raw socketsHiren Tandel2014-05-201-0/+9
| | | | | | | | | | So that anyone listening on SOCKPROTO_RAW for raw frames will get all NCI frames, in both directions. This actually implements userspace NFC NCI sniffing. It's now up to userspace to decode those frames. Signed-off-by: Hiren Tandel <hirent@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: Add RAW socket type support for SOCKPROTO_RAWHiren Tandel2014-05-204-11/+102
| | | | | | | | | | This allows for a more generic NFC sniffing by using SOCKPROTO_RAW SOCK_RAW to read RAW NFC frames. This is for sniffing anything but LLCP (HCI, NCI, etc...). Signed-off-by: Hiren Tandel <hirent@marvell.com> Signed-off-by: Rahul Tank <rahult@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: NCI: No need to reverse ATR_RES ResponseHiren Tandel2014-05-191-5/+2
| | | | | | | | | | ATR_RES response received within Activation Parameters is already in correct order. Reversing it fails LLCP magic number check and so P2P functionality fails. Signed-off-by: Hiren Tandel <hirent@marvell.com> Signed-off-by: Rahul Tank <rahult@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
* NFC: digital: Handle multiple SENSF_REQ framesMark A. Greer2014-05-191-1/+13
| | | | | | | | | | | | | | | According to section 5.15.1.3 of the NFC Activity Specification, multiple SENSF_REQ commands can be received by a target before it receives an ATR_REQ command. To handle this, add a routine that checks whether a SENSF_REQ or ATR_REQ has been recieved. If its a SENSF_REQ, respond appropriately and continue waiting for a ATR_REQ. If its an ATR_REQ, handle it as before. CC: 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: SENSF_RES excludes RD when SENSF_REQ RC is zeroMark A. Greer2014-05-191-1/+1
| | | | | | | | | | | | | The check in digital_tg_send_sensf_res() that excludes the 'RD' field from the SENSF_RES is inverted. The 'RD' field should be excluded when the SENSF_REQ 'RC' field is equal to DIGITAL_SENSF_REQ_RC_NONE instead of when its not equal. This is described in section 6.6.2.11 of the NFC Digital Specification. CC: 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: hci: Fix sparse: cast to restricted __be16Christophe Ricard2014-04-221-1/+1
| | | | | | | | Fixing "sparse: cast to restricted __be16" 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: digital: Add support for ISO/IEC 14443-B ProtocolMark A. Greer2014-04-223-2/+233
| | | | | | | | | | | Add support for the ISO/IEC 14443-B protocol and Type 4B tags. It is expected that there will be only one tag within range so the full anticollision scheme is not implemented. Only the SENSB_REQ/SENSB_RES and ATTRIB_REQ/ATTRIB_RES are implemented. CC: 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: hci: Add load_session HCI operandChristophe Ricard2014-04-221-24/+21
| | | | | | | | | | load_session allows a CLF to restore the gate <-> pipe table from some proprietary location. The main advantage to add this function is to reduce the memory wear by running pipe creation (and storing) only once. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-28 14:33:51 +0100