02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

02 Apr, 2017

1 commit

  • It appears that TI WiLink devices including NFC (WL185x/WL189x) never
    shipped. The only information I found were announcements in Feb
    2012 about the parts. There's been no activity on this driver besided
    common changes since initially added in Jan 2012. There's also no in
    users that instantiate the platform device (nor DT bindings).

    This is a first step in removing TI ST (shared transport) driver in
    favor of extending the BT hci_ll driver to support WL183x chips.

    Cc: Ilan Elias
    Cc: Marcel Holtmann
    Cc: Samuel Ortiz
    Cc: Lauro Ramos Venancio
    Cc: Aloisio Almeida Jr
    Cc: linux-wireless@vger.kernel.org
    Signed-off-by: Rob Herring
    Signed-off-by: Samuel Ortiz

    Rob Herring
     

10 Apr, 2016

1 commit

  • The driver now has all core stuff isolated in one file, and all
    the hardware link specifics in another. Writing a pn533 driver
    on top of another hardware link is now just a matter of adding a
    new file for that new hardware specifics.

    The first user of this separation will be the i2c based pn532
    driver that reuses pn533 core implementation on top of an i2c
    layer.

    Signed-off-by: Michael Thalmeier
    Signed-off-by: Samuel Ortiz

    Michael Thalmeier
     

30 Dec, 2015

1 commit

  • This driver supports STMicroelectronics NFC Transceiver
    "ST95HF", in in initiator role to read/write ISO14443 Type 4A,
    ISO14443 Type 4B and ISO15693 Type5 tags.

    The ST95HF datasheet is available here:
    http://www.st.com/web/en/resource/technical/document/datasheet/DM00102056.pdf

    Signed-off-by: Shikha Singh
    Signed-off-by: Samuel Ortiz

    Shikha Singh
     

26 Oct, 2015

1 commit

  • Fields Peak complies with the ISO/IEC 14443A/B, 15693, 18092,
    and JIS X 6319-4. It is an NCI based controller.

    RF Protocols supported:
    - NFC Forum Type 1 Tags (Jewel, Topaz)
    - NFC Forum Type 2 Tags (Mifare UL)
    - NFC Forum Type 3 Tags (FeliCa)
    - NFC Forum Type 4A (ISO/IEC 14443 A-4 106kbps to 848kbps)
    - NFC Forum Type 4B (ISO/IEC 14443 B-4 106kbps to 848kbps)
    - NFCIP in passive and active modes (ISO/IEC 18092 106kbps
    to 424kbps)
    - B’ (based on ISO/IEC 14443 B-2)
    - iCLASS (based on ISO/IEC 15693-2)
    - Vicinity cards (ISO/IEC 15693-3)
    - Kovio tags (NFC Forum Type 2)

    The device can be enumerated using ACPI using the id INT339A.
    The 1st GPIO is the IRQ and the 2nd is the RESET pin.

    Signed-off-by: Robert Dolca
    Signed-off-by: Samuel Ortiz

    Robert Dolca
     

21 Aug, 2015

1 commit


10 Jun, 2015

1 commit


09 Jun, 2015

1 commit


26 Mar, 2015

1 commit


23 Jul, 2014

1 commit

  • Add driver for STMicroelectronics ST21NFCB NFC controller.
    ST21NFCB is using NCI protocol and a proprietary low level transport
    protocol called NDLC used on top.

    NDLC:
    The protocol defines 2 types of frame:
    - One type carrying NCI data (referred as DATAFRAME frames).
    - One type carrying protocol information used for flow control and error
    control mechanisms (referred as SUPERVISOR frames).

    After each frame transmission to the NFC controller, the device host
    SHALL waitfor an ACK (SUPERVISOR frame) reception before sending a
    new frame.
    The NFC controller MAY send a frame at anytime to the device host.
    The NFC controller MAY send a specific WAIT supervisor frame to indicate
    to device host that a NCI data packet has been received but that it could
    take significant time before the NFC controller sends an ACK and thus
    allows next data reception.

    Signed-off-by: Christophe Ricard
    Signed-off-by: Samuel Ortiz

    Christophe Ricard
     

22 Apr, 2014

1 commit

  • Add driver for STMicroelectronics ST21NFCA NFC controller.
    ST21NFCA is using HCI protocol, shdlc as LLC layer & I2C as
    communication protocol.

    Adding support for Reader/Writer mode with Tag type 1/2/3/4 A & B.
    It is using proprietary gate 15 for ISO14443-3 such as type 1 &
    type 2 tags. It is using proprietary gate 14 for type F tags.
    ST21NFCA_DEVICE_MGNT_GATE gives access to proprietary CLF configuration.
    Standard gate for ISO14443-4 A (13) & B (11) are also used.

    ST21NFCA specific mecanism:

    One particular point to notice for the data handling is that frame
    does not contain any length value. Therefore the i2c part of this driver
    is managing the reception with a read length sequence until the end of
    frame (0x7e) is reached.

    In order to avoid conflict between sof & eof a mecanism
    called byte stuffing concist of an escape byte (0x7d) insertion before
    special byte (0x7e, 0x7d). The special byte is then xored with 0x20.

    In this driver, When data are available in the CLF, the interrupt
    gpio is driven to active state and triggered an interrupt.
    Once the i2c_master_recv start, the interrupt gpio is driven to idle
    state until its complete. If the frame is incomplete or data are still
    available, interrupts will be triggered again.

    Signed-off-by: Christophe Ricard
    Signed-off-by: Samuel Ortiz

    Christophe Ricard
     

11 Mar, 2014

1 commit


07 Jan, 2014

1 commit


07 Oct, 2013

1 commit

  • This adds support for the Sony NFC USB dongle RC-S380, based on the
    Port-100 chip. This dongle is an analog frontend and does not implement
    the digital layer. This driver uses the nfc_digital module which is an
    implementation of the NFC Digital Protocol stack.

    This patch is a skeleton. It only registers the dongle against the NFC
    digital protocol stack. All NFC digital operation functions are stubbed
    out.

    Signed-off-by: Thierry Escande
    Cc: Stephen Tiedemann
    Tested-by: Cho, Yu-Chen
    Signed-off-by: Samuel Ortiz

    Thierry Escande
     

14 Jun, 2013

1 commit

  • This driver declares two virtual NFC devices supporting NFC-DEP protocol.
    An LLCP connection can be established between them and all packets sent
    from one device is sent back to the other, acting as loopback devices.

    Once established, the LLCP link can be disconnected by disabling the target
    device (with rfkill, nfctool, or neard disable-adapter test script).

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

    Thierry Escande
     

16 Apr, 2013

1 commit

  • This isolates the common code that is required to use an mei bus nfc
    device from an NFC HCI drivers. This prepares for future drivers for
    NFC chips connected behind an Intel Management Engine controller.
    The microread_mei HCI driver is also modified to use that common code.

    Signed-off-by: Eric Lapuyade
    Signed-off-by: Samuel Ortiz

    Eric Lapuyade
     

04 Feb, 2013

1 commit


10 Jan, 2013

1 commit


27 Oct, 2012

1 commit


25 Sep, 2012

1 commit


16 May, 2012

1 commit

  • This is an NFC driver for NXP pn544.
    Unlike pn544.c, this one is based on the NFC HCI and SHDLC kernel layers.

    Signed-off-by: Eric Lapuyade
    Signed-off-by: Samuel Ortiz
    Signed-off-by: John W. Linville

    Eric Lapuyade
     

21 Sep, 2011

1 commit


06 Jul, 2011

2 commits


14 Jan, 2011

1 commit

  • Creates a new "Near Field Communication" subsystem in drivers/nfc.
    http://en.wikipedia.org/wiki/Near_Field_Communication is useful ;)

    This is a driver for the pn544 NFC device. The driver transfers
    ETSI messages between the device and the user space.

    Signed-off-by: Matti J. Aaltonen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Matti J. Aaltonen