28 Nov, 2014

13 commits

  • 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
    Tested-by: Thierry Escande
    Signed-off-by: Mark A. Greer
    Signed-off-by: Samuel Ortiz

    Mark A. Greer
     
  • 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
    Tested-by: Thierry Escande
    Signed-off-by: Mark A. Greer
    Signed-off-by: Samuel Ortiz

    Mark A. Greer
     
  • 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
    Tested-by: Thierry Escande
    Signed-off-by: Mark A. Greer
    Signed-off-by: Samuel Ortiz

    Mark A. Greer
     
  • 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
    Tested-by: Thierry Escande
    Signed-off-by: Mark A. Greer
    Signed-off-by: Samuel Ortiz

    Mark A. Greer
     
  • 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
    Tested-by: Thierry Escande
    Signed-off-by: Mark A. Greer
    Signed-off-by: Samuel Ortiz

    Mark A. Greer
     
  • 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
    Tested-by: Thierry Escande
    Signed-off-by: Mark A. Greer
    Signed-off-by: Samuel Ortiz

    Mark A. Greer
     
  • 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
    Tested-by: Thierry Escande
    Signed-off-by: Mark A. Greer
    Signed-off-by: Samuel Ortiz

    Mark A. Greer
     
  • 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
    Tested-by: Thierry Escande
    Signed-off-by: Mark A. Greer
    Signed-off-by: Samuel Ortiz

    Mark A. Greer
     
  • 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
    Tested-by: Thierry Escande
    Signed-off-by: Mark A. Greer
    Signed-off-by: Samuel Ortiz

    Mark A. Greer
     
  • 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
    Tested-by: Thierry Escande
    Signed-off-by: Mark A. Greer
    Signed-off-by: Samuel Ortiz

    Mark A. Greer
     
  • 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
    Tested-by: Thierry Escande
    Signed-off-by: Mark A. Greer
    Signed-off-by: Samuel Ortiz

    Mark A. Greer
     
  • 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
    Tested-by: Thierry Escande
    Signed-off-by: Mark A. Greer
    Signed-off-by: Samuel Ortiz

    Mark A. Greer
     
  • 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
    Tested-by: Thierry Escande
    Signed-off-by: Mark A. Greer
    Signed-off-by: Samuel Ortiz

    Mark A. Greer
     

01 Sep, 2014

1 commit

  • 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
    Tested-by: Thierry Escande
    Signed-off-by: Mark A. Greer
    Signed-off-by: Samuel Ortiz

    Mark A. Greer
     

06 Aug, 2014

1 commit

  • …inville/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>

    David S. Miller
     

21 Jul, 2014

1 commit

  • 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
    Signed-off-by: Mark A. Greer
    Signed-off-by: Samuel Ortiz

    Mark A. Greer
     

16 Jul, 2014

1 commit


26 May, 2014

1 commit


26 Jan, 2014

1 commit

  • Pull networking updates from David Miller:

    1) BPF debugger and asm tool by Daniel Borkmann.

    2) Speed up create/bind in AF_PACKET, also from Daniel Borkmann.

    3) Correct reciprocal_divide and update users, from Hannes Frederic
    Sowa and Daniel Borkmann.

    4) Currently we only have a "set" operation for the hw timestamp socket
    ioctl, add a "get" operation to match. From Ben Hutchings.

    5) Add better trace events for debugging driver datapath problems, also
    from Ben Hutchings.

    6) Implement auto corking in TCP, from Eric Dumazet. Basically, if we
    have a small send and a previous packet is already in the qdisc or
    device queue, defer until TX completion or we get more data.

    7) Allow userspace to manage ipv6 temporary addresses, from Jiri Pirko.

    8) Add a qdisc bypass option for AF_PACKET sockets, from Daniel
    Borkmann.

    9) Share IP header compression code between Bluetooth and IEEE802154
    layers, from Jukka Rissanen.

    10) Fix ipv6 router reachability probing, from Jiri Benc.

    11) Allow packets to be captured on macvtap devices, from Vlad Yasevich.

    12) Support tunneling in GRO layer, from Jerry Chu.

    13) Allow bonding to be configured fully using netlink, from Scott
    Feldman.

    14) Allow AF_PACKET users to obtain the VLAN TPID, just like they can
    already get the TCI. From Atzm Watanabe.

    15) New "Heavy Hitter" qdisc, from Terry Lam.

    16) Significantly improve the IPSEC support in pktgen, from Fan Du.

    17) Allow ipv4 tunnels to cache routes, just like sockets. From Tom
    Herbert.

    18) Add Proportional Integral Enhanced packet scheduler, from Vijay
    Subramanian.

    19) Allow openvswitch to mmap'd netlink, from Thomas Graf.

    20) Key TCP metrics blobs also by source address, not just destination
    address. From Christoph Paasch.

    21) Support 10G in generic phylib. From Andy Fleming.

    22) Try to short-circuit GRO flow compares using device provided RX
    hash, if provided. From Tom Herbert.

    The wireless and netfilter folks have been busy little bees too.

    * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next: (2064 commits)
    net/cxgb4: Fix referencing freed adapter
    ipv6: reallocate addrconf router for ipv6 address when lo device up
    fib_frontend: fix possible NULL pointer dereference
    rtnetlink: remove IFLA_BOND_SLAVE definition
    rtnetlink: remove check for fill_slave_info in rtnl_have_link_slave_info
    qlcnic: update version to 5.3.55
    qlcnic: Enhance logic to calculate msix vectors.
    qlcnic: Refactor interrupt coalescing code for all adapters.
    qlcnic: Update poll controller code path
    qlcnic: Interrupt code cleanup
    qlcnic: Enhance Tx timeout debugging.
    qlcnic: Use bool for rx_mac_learn.
    bonding: fix u64 division
    rtnetlink: add missing IFLA_BOND_AD_INFO_UNSPEC
    sfc: Use the correct maximum TX DMA ring size for SFC9100
    Add Shradha Shah as the sfc driver maintainer.
    net/vxlan: Share RX skb de-marking and checksum checks with ovs
    tulip: cleanup by using ARRAY_SIZE()
    ip_tunnel: clear IPCB in ip_tunnel_xmit() in case dst_link_failure() is called
    net/cxgb4: Don't retrieve stats during recovery
    ...

    Linus Torvalds
     

08 Jan, 2014

2 commits

  • This patch sets the correct rf tech value and crc functions in target
    mode when receiving a PSL_REQ, as done when receiving an ATR_REQ.

    Signed-off-by: Thierry Escande
    Signed-off-by: Samuel Ortiz

    Thierry Escande
     
  • The curr_protocol field of nfc_digital_dev structure used to determine
    if a target is currently active was set too soon, immediately when a
    target is found. This is not good since there is no other way than
    deactivate_target() to reset curr_protocol and if activate_target() is
    not called, the target remains active and it's not possible to put the
    device in poll mode anymore.

    With this patch curr_protocol is set when nfc core activates a target,
    puts a device up, or when an ATR_REQ is received in target mode.

    Signed-off-by: Thierry Escande
    Signed-off-by: Samuel Ortiz

    Thierry Escande
     

04 Jan, 2014

2 commits


19 Dec, 2013

1 commit


25 Sep, 2013

4 commits

  • We do not add the newline to the pr_fmt macro, in order to give more
    flexibility to the caller and to keep the logging style consistent with
    the rest of the NFC and kernel code.

    Signed-off-by: Samuel Ortiz

    Samuel Ortiz
     
  • They can be replaced by the standard pr_err and pr_debug one after
    defining the right pr_fmt macro.

    Signed-off-by: Samuel Ortiz

    Samuel Ortiz
     
  • This adds support for NFC-DEP target mode for NFC-A and NFC-F
    technologies.

    If the driver provides it, the stack uses an automatic mode for
    technology detection and automatic anti-collision. Otherwise the stack
    tries to use non-automatic synchronization and listens for SENS_REQ and
    SENSF_REQ commands.

    The detection, activation, and data exchange procedures work exactly
    the same way as in initiator mode, as described in the previous
    commits, except that the digital stack waits for commands and sends
    responses back to the peer device.

    Signed-off-by: Thierry Escande
    Signed-off-by: Samuel Ortiz

    Thierry Escande
     
  • This adds support for NFC-DEP protocol in initiator mode for NFC-A and
    NFC-F technologies.

    When a target is detected, the process flow is as follow:

    For NFC-A technology:
    1 - The digital stack receives a SEL_RES as the reply of the SEL_REQ
    command.
    2 - If b7 of SEL_RES is set, the peer device is configure for NFC-DEP
    protocol. NFC core is notified through nfc_targets_found().
    Execution continues at step 4.
    3 - Otherwise, it's a tag and the NFC core is notified. Detection
    ends.
    4 - The digital stacks sends an ATR_REQ command containing a randomly
    generated NFCID3 and the general bytes obtained from the LLCP layer
    of NFC core.

    For NFC-F technology:
    1 - The digital stack receives a SENSF_RES as the reply of the
    SENSF_REQ command.
    2 - If B1 and B2 of NFCID2 are 0x01 and 0xFE respectively, the peer
    device is configured for NFC-DEP protocol. NFC core is notified
    through nfc_targets_found(). Execution continues at step 4.
    3 - Otherwise it's a type 3 tag. NFC core is notified. Detection
    ends.
    4 - The digital stacks sends an ATR_REQ command containing the NFC-F
    NFCID2 as NFCID3 and the general bytes obtained from the LLCP layer
    of NFC core.

    For both technologies:
    5 - The digital stacks receives the ATR_RES response containing the
    NFCID3 and the general bytes of the peer device.
    6 - The digital stack notifies NFC core that the DEP link is up through
    nfc_dep_link_up().
    7 - The NFC core performs data exchange through tm_transceive().
    8 - The digital stack sends a DEP_REQ command containing an I PDU with
    the data from NFC core.
    9 - The digital stack receives a DEP_RES command
    10 - If the DEP_RES response contains a supervisor PDU with timeout
    extension request (RTOX) the digital stack sends a DEP_REQ
    command containing a supervisor PDU acknowledging the RTOX
    request. The execution continues at step 9.
    11 - If the DEP_RES response contains an I PDU, the response data is
    passed back to NFC core through the response callback. The
    execution continues at step 8.

    Signed-off-by: Thierry Escande
    Signed-off-by: Samuel Ortiz

    Thierry Escande