summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* 6lowpan: iphc: cleanup use of lowpan_fetch_skbAlexander Aring2014-07-301-6/+7
| | | | | | | | | We introduced the lowpan_fetch_skb function in some previous patches for 6lowpan to have a generic fetch function. This patch drops the old function and use the generic lowpan_fetch_skb one. Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* 6lowpan: iphc: use sizeof in udp uncompressionAlexander Aring2014-07-301-9/+14
| | | | | Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* 6lowpan: iphc: rename hc06_ptr pointer to hc_ptrAlexander Aring2014-07-301-56/+56
| | | | | | | | The hc06_ptr pointer variable stands for header compression draft-06. We are mostly rfc complaint. This patch rename the variable to normal hc_ptr. Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix SMP context tracking leading to a kernel crashJohan Hedberg2014-07-301-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The HCI_CONN_LE_SMP_PEND flag is supposed to indicate whether we have an SMP context or not. If the context creation fails, or some other error is indicated between setting the flag and creating the context the flag must be cleared first. This patch ensures that smp_chan_create() clears the flag in case of allocation failure as well as reorders code in smp_cmd_security_req() that could lead to returning an error between setting the flag and creating the context. Without the patch the following kind of kernel crash could be observed (this one because of unacceptable authentication requirements in a Security Request): [ +0.000855] kernel BUG at net/bluetooth/smp.c:606! [ +0.000000] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ +0.000000] CPU: 0 PID: 58 Comm: kworker/u5:2 Tainted: G W 3.16.0-rc1+ #785 [ +0.008391] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ +0.000000] Workqueue: hci0 hci_rx_work [ +0.000000] task: f4dc8f90 ti: f4ef0000 task.ti: f4ef0000 [ +0.000000] EIP: 0060:[<c13432b6>] EFLAGS: 00010246 CPU: 0 [ +0.000000] EIP is at smp_chan_destroy+0x1e/0x145 [ +0.000709] EAX: f46db870 EBX: 00000000 ECX: 00000000 EDX: 00000005 [ +0.000000] ESI: f46db870 EDI: f46db870 EBP: f4ef1dc0 ESP: f4ef1db0 [ +0.000000] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 [ +0.000000] CR0: 8005003b CR2: b666b0b0 CR3: 00022000 CR4: 00000690 [ +0.000000] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [ +0.000000] DR6: fffe0ff0 DR7: 00000400 [ +0.000000] Stack: [ +0.000000] 00000005 f17b7840 f46db870 f4ef1dd4 f4ef1de4 c1343441 c134342e 00000000 [ +0.000000] c1343441 00000005 00000002 00000000 f17b7840 f4ef1e38 c134452a 00002aae [ +0.000000] 01ef1e00 00002aae f46bd980 f46db870 00000039 ffffffff 00000007 f4ef1e34 [ +0.000000] Call Trace: [ +0.000000] [<c1343441>] smp_failure+0x64/0x6c [ +0.000000] [<c134342e>] ? smp_failure+0x51/0x6c [ +0.000000] [<c1343441>] ? smp_failure+0x64/0x6c [ +0.000000] [<c134452a>] smp_sig_channel+0xad6/0xafc [ +0.000000] [<c1053b61>] ? vprintk_emit+0x343/0x366 [ +0.000000] [<c133f34e>] l2cap_recv_frame+0x1337/0x1ac4 [ +0.000000] [<c133f34e>] ? l2cap_recv_frame+0x1337/0x1ac4 [ +0.000000] [<c1172307>] ? __dynamic_pr_debug+0x3e/0x40 [ +0.000000] [<c11702a1>] ? debug_smp_processor_id+0x12/0x14 [ +0.000000] [<c1340bc9>] l2cap_recv_acldata+0xe8/0x239 [ +0.000000] [<c1340bc9>] ? l2cap_recv_acldata+0xe8/0x239 [ +0.000000] [<c1169931>] ? __const_udelay+0x1a/0x1c [ +0.000000] [<c131f120>] hci_rx_work+0x1a1/0x286 [ +0.000000] [<c137244e>] ? mutex_unlock+0x8/0xa [ +0.000000] [<c131f120>] ? hci_rx_work+0x1a1/0x286 [ +0.000000] [<c1038fe5>] process_one_work+0x128/0x1df [ +0.000000] [<c1038fe5>] ? process_one_work+0x128/0x1df [ +0.000000] [<c10392df>] worker_thread+0x222/0x2de [ +0.000000] [<c10390bd>] ? process_scheduled_works+0x21/0x21 [ +0.000000] [<c103d34c>] kthread+0x82/0x87 [ +0.000000] [<c1040000>] ? create_new_namespaces+0x90/0x105 [ +0.000000] [<c13738e1>] ret_from_kernel_thread+0x21/0x30 [ +0.000000] [<c103d2ca>] ? __kthread_parkme+0x50/0x50 [ +0.000000] Code: 65 f4 89 f0 5b 5e 5f 5d 8d 67 f8 5f c3 57 8d 7c 24 08 83 e4 f8 ff 77 fc 55 89 e5 57 89 c7 56 53 52 8b 98 e0 00 00 00 85 db 75 02 <0f> 0b 8b b3 80 00 00 00 8b 00 c1 ee 03 83 e6 01 89 f2 e8 ef 09 [ +0.000000] EIP: [<c13432b6>] smp_chan_destroy+0x1e/0x145 SS:ESP 0068:f4ef1db0 Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* brcmfmac: Fix OOB interrupt not working for BCM43362Hans de Goede2014-07-291-0/+16
| | | | | | | | | | | | | | | It has taken me a long long time to get the OOB interrupt working on the AP6210 sdio wifi/bt module found on various Allwinner A20 boards. In the end I found these magic register pokes in the cubietruck kernel tree: https://github.com/cubieboard2/linux-sunxi/commit/7f08ba395617d17e7a711507503d89a50406fe7a This is also done for the bcm43362 in broadcom's internal/proprietary driver. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Arend van Spriel <arend@broadcom.com> [arend@broadcom.com: rebased changing BCM43362 chip id to fix compilation] Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* ath9k: Initialize channel context ops on ahb probeRajkumar Manoharan2014-07-291-0/+1
| | | | | | | | Not doing so, could fail on device probing when use_chanctx module param is set to true. Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* bcma: add support for BCM43131 that was found in Tenda W311ERafał Miłecki2014-07-293-0/+3
| | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* b43: add support for BCM43131 chipset with N-PHY rev 17Rafał Miłecki2014-07-293-2/+5
| | | | | | | | It contains radio 0x2057 rev 14 just like a BCM43217, so it doesn't require any magic. The main difference is that BCM4313 is 1x1:1. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmfmac: Fix some wrong register definesHans de Goede2014-07-291-6/+6
| | | | | Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* brcmfmac: add device tree support for SDIO devicesChen-Yu Tsai2014-07-294-0/+84
| | | | | | | | | | | | | | brcmfmac devices can use an out-of-band interrupt on a GPIO line. Currently this is specified using platform data. Add support for specifying out-of-band interrupt via device tree. Signed-off-by: Chen-Yu Tsai <wens@csie.org> [arend@broadcom.com: conditionalize more of-code, use driver debug routines] Signed-off-by: Arend van Spriel <arend@broadcom.com> [hdegoede@redhat.com: drop clk / reg_on gpio handling, as there is no consensus on how to handle this yet] Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* dt: bindings: add bindings for Broadcom bcm43xx sdio devicesArend van Spriel2014-07-291-0/+41
| | | | | | | | | | | | | | | | | | | The Broadcom bcm43xx sdio devices are fullmac devices that may be integrated in ARM platforms. Currently, the brcmfmac driver for these devices support use of platform data. This patch specifies the bindings that allow this platform data to be expressed in the devicetree. Reviewed-by: Hante Meuleman <meuleman@broadcom.com> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com> Reviewed-by: Daniel (Deognyoun) Kim <dekim@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by: Arend van Spriel <arend@broadcom.com> [hdegoede@redhat.com: drop clk / reg_on gpio handling, as there is no consensus on how to handle this yet] [hdegoede@redhat.com: move from bindings/staging to bindings] Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
* Merge branch 'for-upstream' of ↵John W. Linville2014-07-298-20/+260
|\ | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
| * Bluetooth: Fix incorrectly disabling page scan when toggling connectableJohan Hedberg2014-07-281-1/+13
| | | | | | | | | | | | | | | | | | If we have entries in the whitelist we shouldn't disable page scanning when disabling connectable mode. This patch adds the necessary check to the Set Connectable command handler. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * Bluetooth: Fix clearing HCI_PSCAN flagJohan Hedberg2014-07-281-1/+1
| | | | | | | | | | | | | | | | | | This patch fixes a typo in the hci_cc_write_scan_enable() function where we want to clear the HCI_PSCAN flag if the SCAN_PAGE bit of the HCI command parameter was not set. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * MAINTAINERS: add 6lowpan header fileAlexander Aring2014-07-281-0/+1
| | | | | | | | | | | | | | | | | | Since commit 68d96dcfc6c09b565d57897c127b61afbab74c6f ("MAINTAINERS: add net/6lowpan/ maintainer entry") we have a 6lowpan branch. This patch adds a forgotten file which should also be maintained by this branch. Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * Bluetooth: Set Simultaneous LE and BR/EDR controller option to zeroMarcel Holtmann2014-07-272-4/+4
| | | | | | | | | | | | | | | | | | With the Bluetooth 4.1 specification the Simultaneous LE and BR/EDR controller option has been deprecated. It shall be set to zero and ignored otherwise. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| * Bluetooth: Expose default LE advertising interval via debugfsGeorg Lukas2014-07-261-0/+60
| | | | | | | | | | | | | | | | Expose the default values for minimum and maximum LE advertising interval via debugfs for testing purposes. Signed-off-by: Georg Lukas <georg@op-co.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * Bluetooth: Provide defaults for LE advertising intervalGeorg Lukas2014-07-263-2/+6
| | | | | | | | | | | | | | | | | | Store the default values for minimum and maximum advertising interval with all the other controller defaults. These vaules are sent to the adapter whenever advertising is (re)enabled. Signed-off-by: Georg Lukas <georg@op-co.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
| * Bluetooth: Fix white list handling with resolvable private addressesMarcel Holtmann2014-07-262-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Devices using resolvable private addresses are required to provide an identity resolving key. These devices can not be found using the current controller white list support. This means if the kernel knows about any devices with an identity resolving key, the white list filtering must be disabled. However so far the kernel kept identity resolving keys around even for devices that are not using resolvable private addresses. The notification to userspace clearly hints to not store the key and so it is best to just remove the key from the kernel as well at that point. With this it easy now to detect when using the white list is possible or when kernel side resolving of addresses is required. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| * Bluetooth: Add support for using controller white list filteringMarcel Holtmann2014-07-261-0/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Bluetooth controller can use a white list filter when scanning to avoid waking up the host for devices that are of no interest. Devices marked as reporting, direct connection (incoming) or general connection are now added to the controller white list. The update of the white list happens just before enabling passive scanning. In case the white list is full and can not hold all devices, the white list is not used and the filter policy set to accept all advertisements. Using the white list for scanning allows for power saving with controllers that do not handle the duplicate filtering correctly. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| * Bluetooth: Fix issue with ADV_IND reports and auto-connection handlingMarcel Holtmann2014-07-234-4/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When adding remote devices to the kernel using the Add Device management command, these devices are explicitly allowed to connect. This kind of incoming connections are possible even when the controller itself is not connectable. For BR/EDR this distinction is pretty simple since there is only one type of incoming connections. With LE this is not that simple anymore since there are ADV_IND and ADV_DIRECT_IND advertising events. The ADV_DIRECT_IND advertising events are send for incoming (slave initiated) connections only. And this is the only thing the kernel should allow when adding devices using action 0x01. This meaning of incoming connections is coming from BR/EDR and needs to be mapped to LE the same way. Supporting the auto-connection of devices using ADV_IND advertising events is an important feature as well. However it does not map to incoming connections. So introduce a new action 0x02 that allows the kernel to connect to devices using ADV_DIRECT_IND and in addition ADV_IND advertising reports. This difference is represented by the new HCI_AUTO_CONN_DIRECT value for only connecting to ADV_DIRECT_IND. For connection to ADV_IND and ADV_DIRECT_IND the old value HCI_AUTO_CONN_ALWAYS is used. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| * Bluetooth: Ignore ADV_DIRECT_IND attempts from unknown devicesMarcel Holtmann2014-07-231-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | Unconditionally connecting to devices sending ADV_DIRECT_IND when the controller is in CONNECTABLE mode is a feature that is not fully working. The background scanning trigger for this has been removed, but the statement allowing it to happen in case some other part triggers is still present. So remove that code part as well to avoid unwanted connections. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| * Bluetooth: Get MWS transport configuration of the controllerMarcel Holtmann2014-07-232-0/+6
| | | | | | | | | | | | | | | | If the Bluetooth controller supports Get MWS Transport Layer Configuration command, then issue it during initialization. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| * Bluetooth: Read list of local codecs supported by the controllerMarcel Holtmann2014-07-232-0/+6
| | | | | | | | | | | | | | | | | | If the Bluetooth controller supports Read Local Supported Codecs command, then issue it during initialization so that the list of codecs is known. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| * Bluetooth: Avoid use of session socket after the session gets freedVignesh Raman2014-07-221-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The commits 08c30aca9e698faddebd34f81e1196295f9dc063 "Bluetooth: Remove RFCOMM session refcnt" and 8ff52f7d04d9cc31f1e81dcf9a2ba6335ed34905 "Bluetooth: Return RFCOMM session ptrs to avoid freed session" allow rfcomm_recv_ua and rfcomm_session_close to delete the session (and free the corresponding socket) and propagate NULL session pointer to the upper callers. Additional fix is required to terminate the loop in rfcomm_process_rx function to avoid use of freed 'sk' memory. The issue is only reproducible with kernel option CONFIG_PAGE_POISONING enabled making freed memory being changed and filled up with fixed char value used to unmask use-after-free issues. Signed-off-by: Vignesh Raman <Vignesh_Raman@mentor.com> Signed-off-by: Vitaly Kuzmichev <Vitaly_Kuzmichev@mentor.com> Acked-by: Dean Jenkins <Dean_Jenkins@mentor.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org
* | Merge tag 'for-linville-20140725' of git://github.com/kvalo/athJohn W. Linville2014-07-299-54/+217
|\ \
| * | ath10k: handle attention flags correctly when using A-MSDUJanusz Dziedzic2014-07-251-8/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case of A-MSDU RX we should check attention flags correctly to be sure we report correct FCS status for A-MSDU subframes. Without a patch we could report A-MSDU subframes with wrong FCS as a correct to the stack, next get a lot of DUP ACK TCP packets. Finally TP drop is seen and this drop depends on FCS errors ratio for A-MSDU frame. Example test case when TP drop is seen: - ath10k configured as an AP - used ath10k station - forced A-MSDU (7 frames) on STA - other traffic on channel (often FCS errors) - monitor iface added on AP - TCP STA -> AP traffic (iperf) a) Iperf logs for case without the patch: echo "1 64" > htt_max_amsdu_ampdu // disable A-MSDU [ ID] Interval Transfer Bandwidth [ 3] 0.0- 5.0 sec 56.6 MBytes 95.0 Mbits/sec [ 3] 5.0-10.0 sec 60.4 MBytes 101 Mbits/sec [ 3] 10.0-15.0 sec 60.2 MBytes 101 Mbits/sec [ 3] 15.0-20.0 sec 60.2 MBytes 101 Mbits/sec [ 3] 20.0-25.0 sec 63.8 MBytes 107 Mbits/sec [ 3] 25.0-30.0 sec 64.9 MBytes 109 Mbits/sec echo "7 64" > htt_max_amsdu_ampdu // set 7 A-MSDU subframes [ 3] 30.0-35.0 sec 40.0 MBytes 67.1 Mbits/sec [ 3] 35.0-40.0 sec 35.9 MBytes 60.2 Mbits/sec [ 3] 40.0-45.0 sec 36.9 MBytes 61.9 Mbits/sec [ 3] 45.0-50.0 sec 37.9 MBytes 63.5 Mbits/sec [ 3] 50.0-55.0 sec 34.5 MBytes 57.9 Mbits/sec [ 3] 55.0-60.0 sec 25.4 MBytes 42.6 Mbits/sec [ 3] 60.0-65.0 sec 48.2 MBytes 81.0 Mbits/sec [ 3] 65.0-70.0 sec 28.8 MBytes 48.2 Mbits/sec [ 3] 70.0-75.0 sec 29.2 MBytes 49.1 Mbits/sec [ 3] 75.0-80.0 sec 22.9 MBytes 38.4 Mbits/sec [ 3] 80.0-85.0 sec 26.4 MBytes 44.2 Mbits/sec [ 3] 85.0-90.0 sec 31.5 MBytes 52.8 Mbits/sec b) Iperf logs for case with patch: echo "1 64" > htt_max_amsdu_ampdu // disable A-MSDU [ 3] local 192.168.12.2 port 57512 connected with 192.168.12.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 5.0 sec 60.8 MBytes 102 Mbits/sec [ 3] 5.0-10.0 sec 62.2 MBytes 104 Mbits/sec [ 3] 10.0-15.0 sec 60.9 MBytes 102 Mbits/sec echo "7 64" > htt_max_amsdu_ampdu // set 7 A-MSDU subframes [ 3] 15.0-20.0 sec 68.1 MBytes 114 Mbits/sec [ 3] 20.0-25.0 sec 80.5 MBytes 135 Mbits/sec [ 3] 25.0-30.0 sec 83.0 MBytes 139 Mbits/sec [ 3] 30.0-35.0 sec 79.1 MBytes 133 Mbits/sec [ 3] 35.0-40.0 sec 77.1 MBytes 129 Mbits/sec [ 3] 40.0-45.0 sec 77.4 MBytes 130 Mbits/sec Reported-by: Denton Gentry <denton.gentry@gmail.com> Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
| * | ath10k: don't advertise IBSS iftype for 10.xMichal Kazior2014-07-251-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | The 10.x firmware does not support IBSS mode at all. It can't beacon and it crashes when trying to scan. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
| * | ath10k: fix Rx aggregation reorderingMichal Kazior2014-07-254-3/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Firmware doesn't perform Rx reordering so it is left to the host driver to do that. Use mac80211 to perform reordering instead of re-inventing the wheel. This fixes TCP throughput issues in some environments. Reported-by: Denton Gentry <denton.gentry@gmail.com> Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
| * | Merge remote-tracking branch 'wireless-next/master' into ath-nextKalle Valo2014-07-2465-856/+2245
| |\ \
| * | | ath10k: prevent endless pci rx loopMichal Kazior2014-07-221-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It was possible to enter an endless loop while processing a single pci copy engine pipe. This could effectively render ath10k incapable of responding to any requests. An example case when this could happen is when firmware generates a lot of events, e.g. spectral scan phyerr via WMI. Reported-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
| * | | ath10k: workaround qos nullfunc bugMichal Kazior2014-07-221-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently fw/hw generates a corrupted QoS Control Field in Qos NullFunc frames. The only way to workaround this is to downgrade frames to NullFunc. This should be okay since powersave is done by fw/hw and these frames are only used for CQM purposes (e.g. from hostapd to check if station is still connected). This doesn't fix any user visible bug that I know of. It just prevents from sending out funky frames on the air. Reported-by: Janusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
| * | | ath10k: simplify tx helpersMichal Kazior2014-07-223-32/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It always bugged me how tid is computed and stored in a temporary var before written to the control buffer. It was confusing and it made it difficult to work with tx helpers. While at it rename the qos workaround function as it was misleading - it's not a workaround but preparation for nwifi tx mode. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
| * | | ath10k: prevent some tx flushing failuresMichal Kazior2014-07-212-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Firmware could request inspection of some submitted tx requests. Since the callback wasn't implemented it was possible to bleed tx msdu_ids which could translate to tx flushing timeouts. There's nothing ath10k can do to help firmware with tx processing now so just report all tx frames as already inspected to prevent firmware from sending up inspection events and force it to report regular tx completion indications with discard status. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
| * | | ath10k: workaround boot issues with KVM/PCI-passthroughMichal Kazior2014-07-211-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently iomap writes that unmask CE irqs aren't propagated properly sometimes. Before failing try to poll for the control response message as it may have been delivered without an interrupt. Signed-off-by: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
* | | | Merge tag 'nfc-next-3.17-1' of ↵John W. Linville2014-07-2925-29/+2228
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next Samuel Ortiz <sameo@linux.intel.com> says: "NFC: 3.17 pull request This is the NFC pull request for 3.17. This is a rather quiet one, we have: - A new driver from ST Microelectronics for their NCI ST21NFCB, including device tree support. - p2p support for the ST21NFCA driver - A few fixes an enhancements for the NFC digital layer" Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | | | NFC: digital: Add 'tg_listen_md' and 'tg_get_rf_tech' driver hooksMark A. Greer2014-07-234-9/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The digital layer of the NFC subsystem currently supports a 'tg_listen_mdaa' driver hook that supports devices that can do mode detection and automatic anticollision. However, there are some devices that can do mode detection but not automatic anitcollision so add the 'tg_listen_md' hook to support those devices. In order for the digital layer to get the RF technology detected by the device from the driver, add the 'tg_get_rf_tech' hook. It is only valid to call this hook immediately after a successful call to 'tg_listen_md'. CC: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * | | | NFC: digital: Remove extra blank lineMark A. Greer2014-07-231-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove extra blank line that was inadvertently added by a recent commit. CC: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * | | | NFC: st21nfca: Adding P2P support to st21nfca in Initiator & Target modeChristophe Ricard2014-07-235-3/+993
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Support for Initiator and Target mode with ISO18092 commands support: - ATR_REQ/ATR_RES - PSL_REQ/PSL_RES - DEP_REQ/DEP_RES Work based on net/nfc/digital_dep.c. st21nfca is using: - Gate reader F for P2P in initiator mode. - Gate card F for P2P in target mode. Felica tag and p2p are differentiated with NFCID2. When starting with 01FE it is acting in p2p mode. On complete_target_discovered on ST21NFCA_RF_READER_F_GATE supported_protocols is set to NFC_PROTO_NFC_DEP_MASK for P2P. Tested against: Nexus S, Galaxy S2, Galaxy S3, Galaxy S3 Mini, Nexus 4 & Nexus 5. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * | | | NFC: st21nfca: Implement stop_poll HCI hookChristophe Ricard2014-07-231-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Send DM_DISCONNECT command to disconnect Terminal Host from the HCI network. - The persistent states of the terminal host pipes, including registry values, are not modifies. Therefore, there is no NVRAM update to disconnect the terminal host. - The terminal host RF card gates are disabled which means that there will be no event related to card RF gates until communication has been restored. - The terminal host RF reader request is reset so the RF reader polling for terminal host is disabled. To restore the communication, the terminal host can send any HCI command or event. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * | | | NFC: hci: Add stop_poll HCI operand.Christophe Ricard2014-07-232-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | stop_poll allows to stop CLF reader polling. Some other operations might be necessary for some CLF to stop polling. For example in card mode. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * | | | NFC: st21nfca: Improve read length sequence for P2P mode.Christophe Ricard2014-07-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A DEP_RES with a SUPERVISOR PDU can be up to 16 bytes long. In order to avoid useless read during p2p, extend first read sequence to 16 and reduce third sequence to 12 to keep same total on the full sequence. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * | | | NFC: st21nfca: Improved start of frame detectionChristophe Ricard2014-07-231-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A start of frame is 7E 00 not only 7E. Make sure the first read sequence is starting with 7E 00. For example: 7E FF FF FF FF is as a correct crc but it is a bad frame. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * | | | NFC: st21nfca: Free buffer in case no data are retrieved.Christophe Ricard2014-07-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case no data are retrieve through i2c or one specific case is not handled. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * | | | NFC: st21nfcb: few code clean upChristophe Ricard2014-07-232-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * | | | NFC: nci: Add T1T support notificationChristophe Ricard2014-07-231-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add T1T matching with Jewel during notification. It was causing "the target found does not have the desired protocol" to show up. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * | | | NFC: dts: st21nfcb_i2c: Add DTS DocumentationChristophe Ricard2014-07-231-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Describe the properties used by the st21nfcb NFC controller driver. Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * | | | NFC: st21nfcb: Add driver for STMicroelectronics ST21NFCB NFC chipChristophe Ricard2014-07-2310-2/+1047
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add driver for STMicroelectronics ST21NFCB NFC controller. ST21NFCB is using NCI protocol and a proprietary low level transport protocol called NDLC used on top. NDLC: The protocol defines 2 types of frame: - One type carrying NCI data (referred as DATAFRAME frames). - One type carrying protocol information used for flow control and error control mechanisms (referred as SUPERVISOR frames). After each frame transmission to the NFC controller, the device host SHALL waitfor an ACK (SUPERVISOR frame) reception before sending a new frame. The NFC controller MAY send a frame at anytime to the device host. The NFC controller MAY send a specific WAIT supervisor frame to indicate to device host that a NCI data packet has been received but that it could take significant time before the NFC controller sends an ACK and thus allows next data reception. Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * | | | NFC: digital: Add digital framing calls when in target modeMark A. Greer2014-07-212-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add new "NFC_DIGITAL_FRAMING_*" calls to the digital layer so the driver can make the necessary adjustments when performing anticollision while in target mode. The driver must ensure that the effect of these calls happens after the following response has been sent but before reception of the next request begins. Acked-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
| * | | | NFC: digital: Clear poll_tech_count before activating targetMark A. Greer2014-07-212-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, digital_target_found() has a race between the events started by calling nfc_targets_found() (which ultimately expect ddev->poll_tech_count to be zero) and setting ddev->poll_tech_count to zero after the call to nfc_targets_found(). When the race is "lost" (i.e., ddev->poll_tech_count is found to not be zero by the events started by nfc_targets_found()), an error message is printed and the target is not found. A similar race exists when digital_tg_recv_atr_req() calls nfc_tm_activated(). Fix this by first saving the current value of ddev->poll_tech_count and then clearing it before calling nfc_targets_found()/nfc_tm_activated(). Clearing ddev->poll_tech_count before calling nfc_targets_found()/nfc_tm_activated() eliminates the race. Saving the value is required so it can be restored when nfc_targets_found()/nfc_tm_activated() fails and polling needs to continue. Acked-by: Thierry Escande <thierry.escande@linux.intel.com> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-12 23:16:35 +0100