1. 25 9月, 2012 7 次提交
    • E
      NFC: Changed HCI and PN544 HCI driver to use the new HCI LLC Core · 412fda53
      Eric Lapuyade 提交于
      The previous shdlc HCI driver and its header are removed from the tree.
      PN544 now registers directly with HCI and passes the name of the llc it
      requires (shdlc).
      HCI instantiation now allocates the required llc instance. The llc is
      started when the HCI device is brought up.
      Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      412fda53
    • E
      NFC: Modified hci_transceive to become an asynchronous operation · f3e8fb55
      Eric Lapuyade 提交于
      This enables the completion callback to be called from a different
      context, preventing a possible deadlock if the callback resulted in the
      invocation of a nested call to the currently locked nfc_dev.
      This is also more in line with the im_transceive nfc_ops for NFC Core or
      NCI drivers which already behave asynchronously.
      Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      f3e8fb55
    • W
      NFC: Remove crc generation from shdlc layer · ade67208
      Waldemar Rymarkiewicz 提交于
      Checksum is specific for a chip spcification and it varies
      (in size and type) between different hardware. It should be
      handled in the driver then.
      
      Moreover, shdlc spec doesn't mention crc as a part of the frame.
      
      Update pn544_hci driver as well.
      Signed-off-by: NWaldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
      Acked-by: NEric Lapuyade <eric.lapuyade@intel.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      ade67208
    • S
      NFC: Set the IRQF_ONESHOT flag from the pn544_hci IRQ handler request · f2ce3982
      Samuel Ortiz 提交于
      As we don't have a primary handler but only a threaded one, __setup_irq()
      ends up failing if we don't set this flag.
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      f2ce3982
    • T
      NFC: Don't use WQ_MEM_RECLAIM for pn533 · 58637c9b
      Tejun Heo 提交于
      NFC driver doesn't sit in memory reclaim path and has no reason to use
      WQ_MEM_RECLAIM.  Drop WQ_MEM_RECLAIM from pn533->wq and use
      alloc_ordered_workqueue() instead of WQ_UNBOUND w/ max_active == 1.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      58637c9b
    • S
      NFC: Use module_platform_driver macro for nfcwilink.c · 058576dd
      Syam Sidhardhan 提交于
      Simplify the code by make use of module_platform_driver macro.
      Signed-off-by: NSyam Sidhardhan <s.syam@samsung.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      058576dd
    • S
      NFC: Queue pn533 commands · 5d50b364
      Samuel Ortiz 提交于
      Instead of returning EBUSY when getting a command while another one is
      running, we queue them. Upon completion of the pending command, the next
      one is processed.
      Besides the fact that it simplifies the pn533 locking scheme, it also
      comes with the nice side effect of fixing the following warning:
      
      [   82.274297] =====================================
      [   82.274297] [ BUG: bad unlock balance detected! ]
      [   82.274298] 3.5.0-rc1+ #1 Not tainted
      [   82.274299] -------------------------------------
      [   82.274300] kworker/u:1/16 is trying to release lock (&dev->cmd_lock) at:
      [   82.274305] [<ffffffff8144f246>] mutex_unlock+0x9/0xb
      [   82.274305] but there are no more locks to release!
      [   82.274306]
      [   82.274306] other info that might help us debug this:
      [   82.274306] 2 locks held by kworker/u:1/16:
      [   82.274311]  #0:  (pn533){.+.+..}, at: [<ffffffff8103a67d>]
      +process_one_work+0x145/0x2e2
      [   82.274314]  #1:  ((&dev->cmd_work)){+.+...}, at: [<ffffffff8103a67d>]
      +process_one_work+0x145/0x2e2
      [   82.274314]
      [   82.274314] stack backtrace:
      [   82.274315] Pid: 16, comm: kworker/u:1 Not tainted 3.5.0-rc1+ #1
      [   82.274315] Call Trace:
      [   82.274317]  [<ffffffff8144f246>] ? mutex_unlock+0x9/0xb
      [   82.274321]  [<ffffffff81059841>] print_unlock_inbalance_bug+0xda/0xe4
      [   82.274323]  [<ffffffff8105c74c>] lock_release_non_nested+0xb2/0x232
      [   82.274325]  [<ffffffff8105a61e>] ? mark_held_locks+0x6d/0x95
      [   82.274326]  [<ffffffff8144f246>] ? mutex_unlock+0x9/0xb
      [   82.274328]  [<ffffffff81451105>] ? _raw_spin_unlock_irqrestore+0x40/0x5c
      [   82.274329]  [<ffffffff8144f246>] ? mutex_unlock+0x9/0xb
      [   82.274330]  [<ffffffff8105ca42>] lock_release+0x176/0x1ac
      [   82.274333]  [<ffffffff8123de14>] ? pn533_send_complete+0xa8/0xa8
      [   82.274334]  [<ffffffff8144f1d6>] __mutex_unlock_slowpath+0xb0/0x117
      [   82.274336]  [<ffffffff8144f246>] mutex_unlock+0x9/0xb
      [   82.274337]  [<ffffffff8123de65>] pn533_wq_cmd_complete+0x51/0x55
      [   82.274338]  [<ffffffff8103a6db>] process_one_work+0x1a3/0x2e2
      [   82.274340]  [<ffffffff8103a67d>] ? process_one_work+0x145/0x2e2
      [   82.274341]  [<ffffffff8103b119>] worker_thread+0xcf/0x153
      [   82.274343]  [<ffffffff8103b04a>] ? manage_workers.isra.22+0x16b/0x16b
      [   82.274344]  [<ffffffff8103b04a>] ? manage_workers.isra.22+0x16b/0x16b
      [   82.274346]  [<ffffffff8103eb11>] kthread+0x95/0x9d
      [   82.274348]  [<ffffffff81452ef4>] kernel_thread_helper+0x4/0x10
      [   82.274351]  [<ffffffff81046561>] ? finish_task_switch+0x45/0xc3
      [   82.274352]  [<ffffffff814514f0>] ? retint_restore_args+0x13/0x13
      [   82.274353]  [<ffffffff8103ea7c>] ? __init_kthread_worker+0x55/0x55
      [   82.274354]  [<ffffffff81452ef0>] ? gs_change+0x13/0x13
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      5d50b364
  2. 10 7月, 2012 5 次提交
  3. 05 6月, 2012 15 次提交
  4. 25 5月, 2012 1 次提交
  5. 16 5月, 2012 3 次提交
  6. 13 4月, 2012 2 次提交
  7. 07 3月, 2012 6 次提交
  8. 25 1月, 2012 1 次提交