24 Sep, 2014

1 commit

  • 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
    Signed-off-by: Samuel Ortiz

    Christophe Ricard
     

01 Sep, 2014

4 commits


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
     

23 Jul, 2014

3 commits

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

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

    Christophe Ricard
     
  • 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
    Signed-off-by: Samuel Ortiz

    Christophe Ricard
     

21 Jul, 2014

3 commits

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

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

    Mark A. Greer
     

16 Jul, 2014

1 commit


12 Jun, 2014

1 commit

  • 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
    Cc: Dmitry Eremin-Solenikov
    Cc: Marek Lindner
    Cc: Simon Wunderlich
    Cc: Antonio Quartulli
    Cc: Marcel Holtmann
    Cc: Gustavo Padovan
    Cc: Johan Hedberg
    Cc: Arvid Brodin
    Cc: Patrick McHardy
    Cc: Pablo Neira Ayuso
    Cc: Jozsef Kadlecsik
    Cc: Lauro Ramos Venancio
    Cc: Aloisio Almeida Jr
    Cc: Samuel Ortiz
    Cc: Jon Maloy
    Cc: Allan Stephens
    Cc: Andrew Hendry
    Cc: Eric Dumazet
    Reviewed-by: Christoph Paasch
    Signed-off-by: Octavian Purdila
    Signed-off-by: David S. Miller

    Octavian Purdila
     

26 May, 2014

4 commits


20 May, 2014

5 commits

  • 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
    Signed-off-by: Samuel Ortiz

    Hiren Tandel
     
  • 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
    Signed-off-by: Rahul Tank
    Signed-off-by: Samuel Ortiz

    Hiren Tandel
     
  • 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
    Signed-off-by: Rahul Tank
    Signed-off-by: Samuel Ortiz

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

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

    Mark A. Greer
     

22 Apr, 2014

4 commits


12 Apr, 2014

1 commit

  • Several spots in the kernel perform a sequence like:

    skb_queue_tail(&sk->s_receive_queue, skb);
    sk->sk_data_ready(sk, skb->len);

    But at the moment we place the SKB onto the socket receive queue it
    can be consumed and freed up. So this skb->len access is potentially
    to freed up memory.

    Furthermore, the skb->len can be modified by the consumer so it is
    possible that the value isn't accurate.

    And finally, no actual implementation of this callback actually uses
    the length argument. And since nobody actually cared about it's
    value, lots of call sites pass arbitrary values in such as '0' and
    even '1'.

    So just remove the length argument from the callback, that way there
    is no confusion whatsoever and all of these use-after-free cases get
    fixed as a side effect.

    Based upon a patch by Eric Dumazet and his suggestion to audit this
    issue tree-wide.

    Signed-off-by: David S. Miller

    David S. Miller
     

18 Mar, 2014

1 commit

  • Samuel Ortiz says:

    "NFC: 3.15: First pull request

    This is the NFC pull request for 3.15. With this one we have:

    - Support for ISO 15693 a.k.a. NFC vicinity a.k.a. Type 5 tags. ISO
    15693 are long range (1 - 2 meters) vicinity tags/cards. The kernel
    now supports those through the NFC netlink and digital APIs.

    - Support for TI's trf7970a chipset. This chipset relies on the NFC
    digital layer and the driver currently supports type 2, 4A and 5 tags.

    - Support for NXP's pn544 secure firmare download. The pn544 C3 chipsets
    relies on a different firmware download protocal than the C2 one. We
    now support both and use the right one depending on the version we
    detect at runtime.

    - Support for 4A tags from the NFC digital layer.

    - A bunch of cleanups and minor fixes from Axel Lin and Thierry Escande."

    Signed-off-by: John W. Linville

    John W. Linville
     

15 Mar, 2014

3 commits


11 Mar, 2014

1 commit


24 Feb, 2014

5 commits


17 Feb, 2014

2 commits