summaryrefslogtreecommitdiff
path: root/include/net/nfc
diff options
context:
space:
mode:
authorMark A. Greer <mgreer@animalcreek.com>2014-09-23 23:38:10 (GMT)
committerSamuel Ortiz <sameo@linux.intel.com>2014-11-28 11:39:21 (GMT)
commitc12715ab3f0122971f75731b9c2f5b35836165cb (patch)
tree697dfc8815cefd45c1c5f992928c768560015e5d /include/net/nfc
parent3bd2a5bcc6cd7b8d588aa9ffa947177721eba18e (diff)
downloadlinux-c12715ab3f0122971f75731b9c2f5b35836165cb.tar.xz
NFC: digital: Add NFC-DEP Receive Chaining Support
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>
Diffstat (limited to 'include/net/nfc')
0 files changed, 0 insertions, 0 deletions