- 25 9月, 2012 40 次提交
-
-
由 Samuel Ortiz 提交于
linux-nfc@lists.01.org is where all the Linux NFC related discussions take place, and one can also send kernel patches there. Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Cong Wang 提交于
This was scheduled for 3.6, we're late. Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com> Acked-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Eric Lapuyade 提交于
Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Eric Lapuyade 提交于
Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Wei Yongjun 提交于
The dereference should be moved below the NULL test. spatch with a semantic match is used to found this. (http://coccinelle.lip6.fr/) Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Wei Yongjun 提交于
spatch with a semantic match is used to found this. (http://coccinelle.lip6.fr/) Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Samuel Ortiz 提交于
After fixing the LLC Makefile, we no longer need those exports. Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 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>
-
由 Eric Lapuyade 提交于
This is used by HCI drivers such as the one for the pn544 which require communications between HCI and the chip to use shdlc. Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Eric Lapuyade 提交于
This is a passthrough llc. It can be used by HCI drivers that don't need link layer control. HCI will then write directly to the driver, and driver will deliver incoming frames directly to HCI without any processing. Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Eric Lapuyade 提交于
The LLC layer manages modules that control the link layer protocol (such as shdlc) between HCI and an HCI driver. The driver must simply specify the required llc when it registers with HCI. Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 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>
-
由 Eric Lapuyade 提交于
This method initiates execution of an HCI cmd. Result will be delivered through an asynchronous callback. Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Eric Lapuyade 提交于
Make it match the data_exchange_cb_t so that it can be used directly in the implementation of an asynchronous hci_transceive Signed-off-by: NEric Lapuyade <eric.lapuyade@intel.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Waldemar Rymarkiewicz 提交于
Driver must handle its data added to the frame, so at this point removeing control field of shdlc frame is enough. 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>
-
由 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>
-
由 Wei Yongjun 提交于
nfc_llcp_build_tlv() malloced the memory and should be free in nfc_llcp_build_gb() after used, and the same in the error handling case, otherwise it will cause memory leak. spatch with a semantic match is used to found this problem. (http://coccinelle.lip6.fr/) Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Wei Yongjun 提交于
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 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>
-
由 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>
-
由 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>
-
由 Syam Sidhardhan 提交于
This patch remove the repeated code for checking llcp_sock & llcp_sock->dev against NULL. Signed-off-by: NSyam Sidhardhan <s.syam@samsung.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 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>
-
由 Ilan Elias 提交于
During NFC-DEP target activation, store the remote general bytes to be used later in dep_link_up. When dep_link_up is called, activate the NFC-DEP target, and forward the remote general bytes. When dep_link_down is called, deactivate the target. Signed-off-by: NIlan Elias <ilane@ti.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Ilan Elias 提交于
Signed-off-by: NIlan Elias <ilane@ti.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 Ilan Elias 提交于
If initiator protocol is NFC-DEP, set the local general bytes in nci_start_poll. Signed-off-by: NIlan Elias <ilane@ti.com> Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
-
由 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>
-
由 Chun-Yeow Yeoh 提交于
Hardware support for MFP is not available in ath5k. Thus, this implementation allows the mac80211 stack to do the actuall crypto operation. Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Christian Lamparter 提交于
Previously, it was not possible to connect to networks which requires 11w to be supported by the stations. While the documentation hints that there's some hardware support for offloading MFP "decryption", this simple implementation relies on the mac80211 stack to do the actual crypto operations. Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Christian Lamparter 提交于
Previously, it was not possible to connect to networks which requires 11w to be supported by the stations. Note: As all current (and old) firmwares corrupt incoming, protected management frames, the decryption offloading needs to be disabled. This will be done automatically if needed. Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Johannes Berg 提交于
Instead of copying from a constant array (which is still needed for other purposes) Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Paul Bolle 提交于
Building the libipw component without CONFIG_LIBIPW_DEBUG set triggers this GCC warning: drivers/net/wireless/ipw2x00/libipw_wx.c:526:21: warning: unused variable 'dev' [-Wunused-variable] The cause of this warning is that, without CONFIG_LIBIPW_DEBUG set, LIBIPW_DEBUG_WX compiles away. Fix it by substituting ieee->dev for (its equivalent) dev. Signed-off-by: NPaul Bolle <pebolle@tiscali.nl> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Rafał Miłecki 提交于
Signed-off-by: NRafał Miłecki <zajec5@gmail.com> Tested-by: NJack <x6719620@gmail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Amitkumar Karwar 提交于
Currently scan operation is delayed/aborted based on Tx traffic consistency. This decision is taken after receiving scan response of first scan command from FW. But when heavy traffic is running, we can not even afford to send first scan command and go off channel for 30msec. We will block scan request in this case. Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Amitkumar Karwar 提交于
By default, device is disconnected before entering suspend state. User can keep the connection alive by using module parameter "disconect_on_suspend=0". Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com> Signed-off-by: NBing Zhao <bzhao@marvell.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Arend van Spriel 提交于
Field 'pub' in struct brcmf_cfg80211_priv was types as void pointer and filled with parameter passed in brcmf_cfg80211_attach(). This patch makes the type specific, ie. struct brcmf_pub. Reviewed-by: NHante Meuleman <meuleman@broadcom.com> Signed-off-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Arend van Spriel 提交于
Small step to fix structure commenting using kernel-doc syntax. Reviewed-by: NHante Meuleman <meuleman@broadcom.com> Signed-off-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Hante Meuleman 提交于
On a usb error the lock bit should be cleared. Reviewed-by: NArend Van Spriel <arend@broadcom.com> Signed-off-by: NHante Meuleman <meuleman@broadcom.com> Signed-off-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Piotr Haber 提交于
This patch fixes a bug when device is being started while RfKill switch is engaged, leading to hang due to partial initialization of hardware. Tested-by: <dragonn@op.pl> Reviewed-by: NArend van Spriel <arend@broadcom.com> Reviewed-by: NHante Meuleman <meuleman@broadcom.com> Signed-off-by: NPiotr Haber <phaber@broadcom.com> Signed-off-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
由 Hante Meuleman 提交于
clean up code. Reviewed-by: NArend Van Spriel <arend@broadcom.com> Signed-off-by: NHante Meuleman <meuleman@broadcom.com> Signed-off-by: NArend van Spriel <arend@broadcom.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-