15 Mar, 2014

2 commits


24 Feb, 2014

1 commit


18 Jan, 2014

1 commit


15 Jan, 2014

1 commit


04 Jan, 2014

2 commits

  • SE discovery errors are currently overwriting the dev_up() return error.
    This is wrong for many reasons:

    - We don't want to report an error if we actually brought the device up
    but it failed to discover SEs. By doing so we pretend we don't have an
    NFC functional device even we do. The only thing we could not do was
    checking for SEs availability. This is the false negative case.

    - In some cases the actual device power up failed but the SE discovery
    succeeded. Userspace then believes the device is up while it's not.
    This is the false positive case.

    Signed-off-by: Samuel Ortiz

    Samuel Ortiz
     
  • With commit e29a9e2ae165620d, we set the active_target pointer from
    nfc_dep_link_is_up() in order to support the case where the target
    detection and the DEP link setting are done atomically by the driver.
    That can only happen in initiator mode, so we need to check for that
    otherwise we fail to bring a p2p link in target mode.

    Signed-off-by: Arron Wang
    Signed-off-by: Samuel Ortiz

    Arron Wang
     

11 Dec, 2013

1 commit

  • Several files refer to an old address for the Free Software Foundation
    in the file header comment. Resolve by replacing the address with
    the URL so that we do not have to keep
    updating the header comments anytime the address changes.

    CC: linux-wireless@vger.kernel.org
    CC: Lauro Ramos Venancio
    CC: Aloisio Almeida Jr
    CC: Samuel Ortiz
    Signed-off-by: Jeff Kirsher
    Signed-off-by: John W. Linville

    Jeff Kirsher
     

25 Sep, 2013

2 commits

  • As we can potentially get DEP up events without having sent a netlink
    command, we need to set the active target properly from dep_link_is_up.
    Spontaneous DEP up events can come from devices that detected an active
    p2p target. In that case there is no need to call the netlink DEP up
    command as the link is already up and running.

    Signed-off-by: Samuel Ortiz

    Samuel Ortiz
     
  • This will be needed by all NFC driver implementing the SE ops.

    Signed-off-by: Arron Wang
    Signed-off-by: Samuel Ortiz

    Arron Wang
     

14 Aug, 2013

4 commits


31 Jul, 2013

1 commit


14 Jun, 2013

7 commits

  • Called via netlink, this API will enable or disable a specific secure
    element. When a secure element is enabled, it will handle card emulation
    and more generically ISO-DEP target mode, i.e. all target mode cases
    except for p2p target mode.

    Signed-off-by: Samuel Ortiz

    Samuel Ortiz
     
  • Signed-off-by: Samuel Ortiz

    Samuel Ortiz
     
  • When an NFC driver or host controller stack discovers a secure element,
    it will call nfc_add_se(). In order for userspace applications to use
    these secure elements, a netlink event will then be sent with the SE
    index and its type. With that information userspace applications can
    decide wether or not to enable SEs, through their indexes.

    Signed-off-by: Samuel Ortiz

    Samuel Ortiz
     
  • This API will allow NFC drivers to add and remove the secure elements
    they know about or detect. Typically this should be called (asynchronously
    or not) from the driver or the host interface stack detect_se hook.

    Signed-off-by: Samuel Ortiz

    Samuel Ortiz
     
  • Secure elements need to be discovered after enabling the NFC controller.
    This is typically done by the NCI core and the HCI drivers (HCI does not
    specify how to discover SEs, it is left to the specific drivers).
    Also, the SE enable/disable API explicitely takes a SE index as its
    argument.

    Signed-off-by: Samuel Ortiz

    Samuel Ortiz
     
  • Supported secure elements are typically found during a discovery process
    initiated when the NFC controller is up and running. For a given NFC
    chipset there can be many configurations (embedded SE or not, with or
    without a SIM card wired to the NFC controller SWP interface, etc...) and
    thus driver code will never know before hand which SEs are available.
    So we remove this field, it will be replaced by a real SE discovery
    mechanism.

    Signed-off-by: Samuel Ortiz

    Samuel Ortiz
     
  • As several NFC chipsets can have their firmwares upgraded and
    reflashed, this patchset adds a new netlink command to trigger
    that the driver loads or flashes a new firmware. This will allows
    userspace triggered firmware upgrade through netlink.
    The firmware name or hint is passed as a parameter, and the driver
    will eventually fetch the firmware binary through the request_firmware
    API.
    The cmd can only be executed when the nfc dev is not in use. Actual
    firmware loading/flashing is an asynchronous operation. Result of the
    operation shall send a new event up to user space through the nfc dev
    multicast socket. During operation, the nfc dev is not openable and
    thus not usable.

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

    Eric Lapuyade
     

12 Apr, 2013

1 commit

  • All NFC devices will now get proper RFKILL support as long as they provide
    some dev_up and dev_down hooks. Rfkilling an NFC device will bring it down
    while it is left to userspace to bring it back up when being rfkill unblocked.
    This is very similar to what Bluetooth does.

    Acked-by: Marcel Holtmann
    Signed-off-by: Samuel Ortiz

    Samuel Ortiz
     

11 Apr, 2013

1 commit


22 Feb, 2013

1 commit

  • Pull driver core patches from Greg Kroah-Hartman:
    "Here is the big driver core merge for 3.9-rc1

    There are two major series here, both of which touch lots of drivers
    all over the kernel, and will cause you some merge conflicts:

    - add a new function called devm_ioremap_resource() to properly be
    able to check return values.

    - remove CONFIG_EXPERIMENTAL

    Other than those patches, there's not much here, some minor fixes and
    updates"

    Fix up trivial conflicts

    * tag 'driver-core-3.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (221 commits)
    base: memory: fix soft/hard_offline_page permissions
    drivercore: Fix ordering between deferred_probe and exiting initcalls
    backlight: fix class_find_device() arguments
    TTY: mark tty_get_device call with the proper const values
    driver-core: constify data for class_find_device()
    firmware: Ignore abort check when no user-helper is used
    firmware: Reduce ifdef CONFIG_FW_LOADER_USER_HELPER
    firmware: Make user-mode helper optional
    firmware: Refactoring for splitting user-mode helper code
    Driver core: treat unregistered bus_types as having no devices
    watchdog: Convert to devm_ioremap_resource()
    thermal: Convert to devm_ioremap_resource()
    spi: Convert to devm_ioremap_resource()
    power: Convert to devm_ioremap_resource()
    mtd: Convert to devm_ioremap_resource()
    mmc: Convert to devm_ioremap_resource()
    mfd: Convert to devm_ioremap_resource()
    media: Convert to devm_ioremap_resource()
    iommu: Convert to devm_ioremap_resource()
    drm: Convert to devm_ioremap_resource()
    ...

    Linus Torvalds
     

07 Feb, 2013

1 commit

  • All in-kernel users of class_find_device() don't really need mutable
    data for match callback.

    In two places (kernel/power/suspend_test.c, drivers/scsi/osd/osd_uld.c)
    this patch changes match callbacks to use const search data.

    The const is propagated to rtc_class_open() and power_supply_get_by_name()
    parameters.

    Note that there's a dev reference leak in suspend_test.c that's not
    touched in this patch.

    Signed-off-by: Michał Mirosław
    Acked-by: Grant Likely
    Signed-off-by: Greg Kroah-Hartman

    Michał Mirosław
     

10 Jan, 2013

2 commits

  • Each NFC adapter can have several links to different secure elements and
    that property needs to be exported by the drivers.
    A secure element link can be enabled and disabled, and card emulation will
    be handled by the currently active one. Otherwise card emulation will be
    host implemented.

    Signed-off-by: Samuel Ortiz

    Samuel Ortiz
     
  • When an adapter is removed, it will unregister itself from hci and/or
    nfc core. In order to do that safely, work tasks must first be canceled
    and prevented to be scheduled again, before the hci or nfc device can be
    destroyed.

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

    Eric Lapuyade
     

27 Oct, 2012

4 commits


03 Oct, 2012

1 commit

  • The network merge brought in a few users of functions that got
    deprecated by the workqueue cleanups: the 'system_nrt_wq' is now the
    same as the regular system_wq, since all workqueues are now non-
    reentrant.

    Similarly, remove one use of flush_work_sync() - the regular
    flush_work() has become synchronous, and the "_sync()" version is thus
    deprecated as being superfluous.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

25 Sep, 2012

1 commit

  • NFC is using a number of custom ordered workqueues w/ WQ_MEM_RECLAIM.
    WQ_MEM_RECLAIM is unnecessary unless NFC is gonna be used as transport
    for storage device, and all use cases match one work item to one
    ordered workqueue - IOW, there's no actual ordering going on at all
    and using system_nrt_wq gives the same behavior.

    There's nothing to be gained by using custom workqueues. Use
    system_nrt_wq instead and drop all the custom ones.

    Signed-off-by: Tejun Heo
    Signed-off-by: Samuel Ortiz

    Tejun Heo
     

10 Jul, 2012

6 commits