aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* brcmfmac: expose sdio internal counters in debugfsArend van Spriel2012-06-13
| | | | | | | | | | | The structure brcmf_sdio contains a number of counters that are useful for debugging. These were not available in user-space. This patch exposes them in debugfs under the filename 'counters'. Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmfmac: add debugfs helper functionsArend van Spriel2012-06-13
| | | | | | | | | | | | | | | | | | | This patch adds debugfs support to brcmfmac. It provide helper functions to setup the debugfs folder structure for the driver, which has following hierarchy: <debugfs_mount>/brcmfmac/<dev_name>/ ie.: /sys/kernel/debug/brcmfmac/mmc0:0001:2/ The new source file provides functions to create and remove the two folders and a function to retrieve the device-specific folder so files can be created in it. Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmsmac: fix smatch warning found in ampdu.cArend van Spriel2012-06-13
| | | | | | | | | | | | | This patch fixes potential NULL pointer dereference in ampdu. This was found running smatch static code checker. Smatch warning says: drivers/net/wireless/brcm80211/brcmsmac/ampdu.c:741 brcms_c_sendampdu() warn: variable dereferenced before check 'p' Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmsmac: remove brcms_set_hint() functionArend van Spriel2012-06-13
| | | | | | | | | | The function brcms_set_hint() does not add any functionality so regulatory_hint() can be called directly. The error value has been removed from the message when regulatory_hint() fails. Reported-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* iwlwifi: WARN only once when we have trouble in reclaimEmmanuel Grumbach2012-06-13
| | | | | | | | | | | This flow can actually happen due to a corner case in mac80211: the station is deleted before we get a chance to reclaim all the packets in flight in AGG queue. The tid_data for this station is zeroed, and we lose the match with the Tx queue. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* iwlwifi: use request_module instead of _nowaitJohannes Berg2012-06-13
| | | | | | | | | | | | | Since request_module_nowait() can't be backported use request_module() instead -- we don't need the asynchronous behaviour of request_module_nowait() here since we're running in the firmware request work struct. Tested-by: Donald H Fry <donald.h.fry@intel.com> Reviewed-by: Donald H Fry <donald.h.fry@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* iwlwifi: fix 6035 device parametersJohannes Berg2012-06-13
| | | | | | | | | | | Due to commit 26a7ca9a71a ("iwlwifi: refactor EEPROM reading/parsing") adding a new parameter, while commit d2c8b15d0cb ("iwlwifi: use correct supported firmware for 6035 and 6000g2") added a new device structure we need to add the parameter to the new device structure to make 6035 device work. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Merge remote-tracking branch 'wireless-next/master' into iwlwifi-nextJohannes Berg2012-06-13
|\
| * Merge branch 'master' of ↵John W. Linville2012-06-12
| |\ | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless Conflicts: MAINTAINERS drivers/net/wireless/iwlwifi/pcie/trans.c
| | * mac80211: add back channel change flagStanislaw Gruszka2012-06-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 24398e39c8ee4a9d9123eed322b859ece4d16cac Author: Johannes Berg <johannes.berg@intel.com> Date: Wed Mar 28 10:58:36 2012 +0200 mac80211: set HT channel before association removed IEEE80211_CONF_CHANGE_CHANNEL argument from ieee80211_hw_config, which is required by iwl4965 driver, otherwise that driver does not configure channel properly and is not able to associate. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * NFC: Fix possible NULL ptr deref when getting the name of a socketSasha Levin2012-06-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | llcp_sock_getname() might get called before the LLCP socket was created. This condition isn't checked, and llcp_sock_getname will simply deref a NULL ptr in that case. This exists starting with d646960 ("NFC: Initial LLCP support"). Signed-off-by: Sasha Levin <levinsasha928@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * iwlwifi: disable the buggy chain extension feature in HWEmmanuel Grumbach2012-06-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This feature has been reported to be buggy and enabled by default. We therefore need to disable it manually. Cc: stable@vger.kernel.org Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * iwlwifi: don't mess up the SCD when removing a keyEmmanuel Grumbach2012-06-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we remove a key, we put a key index which was supposed to tell the fw that we are actually removing the key. But instead the fw took that index as a valid index and messed up the SRAM of the device. This memory corruption on the device mangled the data of the SCD. The impact on the user is that SCD queue 2 got stuck after having removed keys. The message is the log that was printed is: Queue 2 stuck for 10000ms This doesn't seem to fix the higher queues that get stuck from time to time. Cc: stable@vger.kernel.org [2.6.27+] Reviewed-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * bcma: fix null pointer in bcma_core_pci_irq_ctlHauke Mehrtens2012-06-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pc could be null if hosttype != BCMA_HOSTTYPE_PCI. If we are on a device without a pci core this function is called with pc = null by b43 and brcmsmac. If the host type is PCI we have a pci core as well and pc can not be null. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * b43: do not call ieee80211_unregister_hw if we are not registredOleksij Rempel2012-06-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | this patch fixes kernel Oops on "rmmod b43" if firmware was not loaded: BUG: unable to handle kernel NULL pointer dereference at 0000000000000088 IP: [<ffffffff8104e988>] drain_workqueue+0x25/0x142 PGD 153ac6067 PUD 153b82067 PMD 0 Oops: 0000 [#1] SMP Signed-off-by: Oleksij Rempel <bug-track@fisher-privat.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * iwlwifi: use correct supported firmware for 6035 and 6000g2Meenakshi Venkataraman2012-06-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My patch iwlwifi: use correct released ucode version did not correctly report supported firmware for the 6035 device. This patch fixes it. The minimum supported firmware version for 6035 is v6. Also correct the minimum supported firmware version for the 6000g2 series of devices. Cc: stable@kernel.org Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * wireless: add my new trees to MAINTAINERSJohannes Berg2012-06-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add my new trees to the MAINTAINERS file for the components that I maintain in the new trees. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * mac80211_hwsim: Set IEEE80211_STAT_ACK flag when userspace indicates that ↵Qasim Javed2012-06-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the frame has been acknowledged. The station fail average is not updated correctly since the IEEE80211_STAT_ACK flag is not set when using wmediumd with mac80211_hwsim. Set this flag when wmediumd indicates that the frame was successfully transmitted (eventually). Signed-off-by: Qasim Javed <qasimj@gmail.com> Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * rtl8187: ->brightness_set can not sleepStanislaw Gruszka2012-06-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix: BUG: sleeping function called from invalid context at kernel/workqueue.c:2547 in_atomic(): 1, irqs_disabled(): 0, pid: 629, name: wpa_supplicant 2 locks held by wpa_supplicant/629: #0: (rtnl_mutex){+.+.+.}, at: [<c08b2b84>] rtnl_lock+0x14/0x20 #1: (&trigger->leddev_list_lock){.+.?..}, at: [<c0867f41>] led_trigger_event+0x21/0x80 Pid: 629, comm: wpa_supplicant Not tainted 3.3.0-0.rc3.git5.1.fc17.i686 Call Trace: [<c046a9f6>] __might_sleep+0x126/0x1d0 [<c0457d6c>] wait_on_work+0x2c/0x1d0 [<c045a09a>] __cancel_work_timer+0x6a/0x120 [<c045a160>] cancel_delayed_work_sync+0x10/0x20 [<f7dd3c22>] rtl8187_led_brightness_set+0x82/0xf0 [rtl8187] [<c0867f7c>] led_trigger_event+0x5c/0x80 [<f7ff5e6d>] ieee80211_led_radio+0x1d/0x40 [mac80211] [<f7ff3583>] ieee80211_stop_device+0x13/0x230 [mac80211] Removing _sync is ok, because if led_on work is currently running it will be finished before led_off work start to perform, since they are always queued on the same mac80211 local->workqueue. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=795176 Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * net/wireless: ipw2100: Fix WARN_ON occurring in wiphy_register called by ↵Stanislav Yakovlev2012-06-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ipw2100_pci_init_one The problem was found by Larry Finger: http://marc.info/?l=linux-wireless&m=133702401700614&w=2 The problem is identical to the one for ipw2200 which is already fixed: http://marc.info/?l=linux-wireless&m=133457257407196&w=2 [ 17.766431] ------------[ cut here ]------------ [ 17.766467] WARNING: at net/wireless/core.c:562 wiphy_register+0x34c/0x3c0 [cfg80211]() [ 17.766471] Hardware name: Latitude D600 [ 17.766474] Modules linked in: ipw2100(+) libipw pcmcia cfg80211 ppdev parport_pc yenta_socket sr_mod pcmcia_rsrc parport iTCO_wdt cdrom sg rfkill pcmcia_ core lib80211 tg3 video button battery ac iTCO_vendor_support joydev shpchp pcspkr pciehp pci_hotplug autofs4 radeon ttm drm_kms_helper uhci_hcd ehci_hcd rtc _cmos thermal drm hwmon i2c_algo_bit i2c_core processor usbcore usb_common ata_generic ata_piix ahci libahci libata [ 17.766525] Pid: 474, comm: modprobe Not tainted 3.4.0-rc7-wl+ #6 [ 17.766528] Call Trace: [ 17.766541] [<c066ad08>] ? printk+0x28/0x2a [ 17.766552] [<c0230edd>] warn_slowpath_common+0x6d/0xa0 [ 17.766563] [<e0b253bc>] ? wiphy_register+0x34c/0x3c0 [cfg80211] [ 17.766573] [<e0b253bc>] ? wiphy_register+0x34c/0x3c0 [cfg80211] [ 17.766578] [<c0230f2d>] warn_slowpath_null+0x1d/0x20 [ 17.766588] [<e0b253bc>] wiphy_register+0x34c/0x3c0 [cfg80211] [ 17.766605] [<e0b5b0d6>] ipw2100_wdev_init+0x196/0x1c0 [ipw2100] [ 17.766616] [<e0b5d962>] ipw2100_pci_init_one+0x2b2/0x694 [ipw2100] [ 17.766632] [<c047ce52>] local_pci_probe+0x42/0xb0 [ 17.766637] [<c047e2b0>] pci_device_probe+0x60/0x90 [ 17.766645] [<c0376de2>] ? sysfs_create_link+0x12/0x20 [ 17.766654] [<c050f1f6>] really_probe+0x56/0x2e0 [ 17.766659] [<c037636d>] ? create_dir+0x5d/0xa0 [ 17.766667] [<c0518c6b>] ? pm_runtime_barrier+0x3b/0xa0 [ 17.766672] [<c050f5e4>] driver_probe_device+0x44/0xa0 [ 17.766677] [<c047e227>] ? pci_match_device+0x97/0xa0 [ 17.766681] [<c050f6c9>] __driver_attach+0x89/0x90 [ 17.766686] [<c050f640>] ? driver_probe_device+0xa0/0xa0 [ 17.766691] [<c050da2a>] bus_for_each_dev+0x3a/0x70 [ 17.766695] [<c050ee6c>] driver_attach+0x1c/0x30 [ 17.766699] [<c050f640>] ? driver_probe_device+0xa0/0xa0 [ 17.766704] [<c050ea77>] bus_add_driver+0x187/0x280 [ 17.766710] [<c045b9cd>] ? kset_find_obj+0x2d/0x60 [ 17.766715] [<c047e2e0>] ? pci_device_probe+0x90/0x90 [ 17.766719] [<c047e2e0>] ? pci_device_probe+0x90/0x90 [ 17.766724] [<c050fb85>] driver_register+0x65/0x110 [ 17.766729] [<c047e09d>] __pci_register_driver+0x3d/0xa0 [ 17.766738] [<e09f705c>] ipw2100_init+0x5c/0x1000 [ipw2100] [ 17.766743] [<c020110f>] do_one_initcall+0x2f/0x170 [ 17.766749] [<e09f7000>] ? 0xe09f6fff [ 17.766757] [<c0287ce8>] sys_init_module+0xa8/0x210 [ 17.766766] [<c067a075>] syscall_call+0x7/0xb [ 17.766769] ---[ end trace 559898c6bb0d1c75 ]--- [ 17.767093] ipw2100: probe of 0000:02:03.0 failed with error -5 This warning appears only if we apply Ben Hutchings' fix http://marc.info/?l=linux-wireless&m=132720204412667&w=2 for the bug reported by Cesare Leonardi http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656813 with cfg80211 warning during device registration ("cfg80211: failed to add phy80211 symlink to netdev!"). We separate device bring up and registration with network stack to avoid the problem. Signed-off-by: Stanislav Yakovlev <stas.yakovlev@gmail.com> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | ssb: add missing PCI ID for b/g/n single band BCM4322Jonas Gorski2012-06-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | 14e4:432c is found on some bcm63xx devices. The device is working fine with b43. Reported-by: Álvaro Fernández Rojas <noltari@gmail.com> Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | ath9k_hw: Initvals update for AR9462Sujith Manoharan2012-06-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MSI is enabled by default for most of the 4th generation chips. Add this for AR9462 - this fixes PowerSave operation, the chip was not entering Network-Sleep mode earlier. With proper powering down of the MAC now, power consumption in associated state is reduced considerably. Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | mwifiex: scan less channels per scan command to improve Tx trafficAmitkumar Karwar2012-06-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently 4 channels are scanned per scan command. if scan request is issued by user during Tx traffic, radio will be out of channel for "4 * per_chan_scan_time" for each scan command and will not be able to receive Rx packets. This adds delay in data traffic. We can minimize it by reducing number of channels scanned per scan command in this scenario. We can not always scan 1 channel per scan command due to limitation of number of command buffers. So we add code to decide number of channels scanned per scan command in associated state. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | mwifiex: fix simultaneous scan and Tx traffic problemAmitkumar Karwar2012-06-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If scan operation is started when Tx traffic is already running, driver locks Tx queue until it gets completed. With this logic there is a delay for Tx packets. This patch implements new approach to give Tx path higher priority in this case. Driver internally sends multiple synchronous scan commands to firmware when scan is requested by user. Now we will make sure that Tx queue is empty everytime before sending next scan command. If Tx queue isn't empty scan command will be postponsed by 20msec. This rule will be followed until Tx queue becomes empty or timeout of 1 second happens. In case of timeout scan operation will be aborted. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | mwifiex: shorten per channel scan timeBing Zhao2012-06-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the scan time per channel for active scanning is set to 200ms. It takes quite a while to finsh scanning on all channels, especially with a dual band configuration. Change the per channel scan time settings to the following values: passive scan: 110ms active scan: 30ms specific scan: 30ms Above settings have been tested on x86 and arm platforms. Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | Merge branch 'for-john' of ↵John W. Linville2012-06-11
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Conflicts: drivers/net/wireless/iwlwifi/iwl-eeprom.c
| * \ \ Merge tag 'nfc-next-3.6-1' of ↵John W. Linville2012-06-11
| |\ \ \ | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-3.0
| | * | | NFC: Monitor pn533 target modeSamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When receiving a DEP link down event, we should cancel all pending URBs if we're activated as a target or if we're an initiator. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Convert pn533 from semaphore to mutexSamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Set the proper baud rate when trying to activate pn533 targetsSamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We get the right baud rate from the last polled modulation. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Destroy LLCP timout workqueue when releasing the linkSamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Switch to Initiator mode when getting NFC_ATTR_PROTOCOLSSamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | That is needed for keeping backward compatibility with apps using the old netlink polling API (NFC_ATTR_PROTOCOLS instead of NFC_ATTR_IM_PROTOCOLS). Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Send a receiver ready frame only to reply to an I frameSamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sending an RR as a reply to another RR is fine but not quite logical. We should send RRs only as a reply to I frames. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Requeue lost LLCP framesSamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When receiving an I or RR frame telling us that some of the pending queues were not received, we should requeue them before the currently pending ones. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Implement pn533 polling loopSamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After going through all the modulations, the pn533 driver spends 2 seconds listening for targets. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Add type A and type F parameters for pn533 target modeSamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Without those settings several devices will not activate pn533 as a target. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Add passive initiator data for pn533Samuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When trying to enable a DEP link as a passive initiator, pn533 needs to provide the polling request command payload. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Configure pn533 RF timingsSamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Those define the ATR_RES response timeout after which the pn533 considers the target to be mute. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Unregister device if pn533 initial configuration failsSamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Reset poll mod list when stopping pn533 pollSamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Call the DEP link down ops even when in target modeSamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Even in target mode we need to let the driver know that we want to bring the DEP link down. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Don't hold a NULL connecting LLCP socket lockSamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Implement the pn533 target mode Tx opSamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Implement the pn533 target mode data fetching routineSamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This one needs to be called as soon as we are activated as a target, for the pn533 to receive the first SYMM and keep the LLCP link alive. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Introduce target mode rx data callbackSamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This routine will be called by drivers whenever they receive data in target mode. This should be unexpected events and as such should be handled by a standalone API (i.e. not as a callback pointer from an existing API). Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Introduce target mode tx opsSamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | And rename the initiator mode data exchange ops for consistency sake. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Set the NFC device RF mode appropriatelySamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Add target mode activation netlink eventSamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Userspace gets a netlink event upon target mode activation. The LLCP layer is also signaled when we get an ATR_REQ in order to get the remote general bytes. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Implement pn533 target mode polling loopSamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We only want to support p2p target mode for now, no host card emulation. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| | * | | NFC: Add target mode protocols to the polling loop startup routineSamuel Ortiz2012-06-04
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>