1. 14 6月, 2013 4 次提交
    • S
      NFC: Add secure elements addition and removal API · fed7c25e
      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: NSamuel Ortiz <sameo@linux.intel.com>
      fed7c25e
    • S
      NFC: Extend and fix the internal secure element API · 0a946301
      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: NSamuel Ortiz <sameo@linux.intel.com>
      0a946301
    • S
      NFC: Remove the static supported_se field · 0b456c41
      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: NSamuel Ortiz <sameo@linux.intel.com>
      0b456c41
    • E
      NFC: Add firmware upload netlink command · 9674da87
      Eric Lapuyade 提交于
      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: NEric Lapuyade <eric.lapuyade@intel.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      9674da87
  2. 12 4月, 2013 1 次提交
  3. 11 4月, 2013 1 次提交
  4. 07 2月, 2013 1 次提交
  5. 10 1月, 2013 2 次提交
  6. 27 10月, 2012 4 次提交
  7. 03 10月, 2012 1 次提交
    • L
      workqueue: avoid using deprecated functions · 916082b0
      Linus Torvalds 提交于
      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: NLinus Torvalds <torvalds@linux-foundation.org>
      916082b0
  8. 25 9月, 2012 1 次提交
    • T
      NFC: Use system_nrt_wq instead of custom ones · 474fee3d
      Tejun Heo 提交于
      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: NTejun Heo <tj@kernel.org>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      474fee3d
  9. 10 7月, 2012 6 次提交
  10. 05 6月, 2012 7 次提交
  11. 16 5月, 2012 2 次提交
  12. 16 4月, 2012 1 次提交
  13. 13 4月, 2012 5 次提交
  14. 07 3月, 2012 2 次提交
  15. 25 1月, 2012 1 次提交
  16. 15 12月, 2011 1 次提交
    • S
      NFC: Initial LLCP support · d646960f
      Samuel Ortiz 提交于
      This patch is an initial implementation for the NFC Logical Link Control
      protocol. It's also known as NFC peer to peer mode.
      This is a basic implementation as it lacks SDP (services Discovery
      Protocol), frames aggregation support, and frame rejecion parsing.
      Follow up patches will implement those missing features.
      This code has been tested against a Nexus S phone implementing LLCP 1.0.
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d646960f