- 01 Feb, 2013 12 commits
-
-
Andre Guedes authored
This patch reduces the critical section protected by sco_conn_lock in sco_conn_ready function. The lock is acquired only when it is really needed. This patch fixes the following lockdep warning which is generated when the host terminates a SCO connection. Today, this warning is a false positive. There is no way those two threads reported by lockdep are running at the same time since hdev->workqueue (where rx_work is queued) is single-thread. However, if somehow this behavior is changed in future, we will have a potential deadlock. ====================================================== [ INFO: possible circular locking dependency detected ] 3.8.0-rc1+ #7 Not tainted ------------------------------------------------------- kworker/u:1H/1018 is trying to acquire lock: (&(&conn->lock)->rlock){+.+...}, at: [<ffffffffa0033ba6>] sco_chan_del+0x66/0x190 [bluetooth] but task is already holding lock: (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}, at: [<ffffffffa0033d5a>] sco_conn_del+0x8a/0xe0 [bluetooth] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}: [<ffffffff81083011>] lock_acquire+0xb1/0xe0 [<ffffffff813efd01>] _raw_spin_lock+0x41/0x80 [<ffffffffa003436e>] sco_connect_cfm+0xbe/0x350 [bluetooth] [<ffffffffa0015d6c>] hci_event_packet+0xd3c/0x29b0 [bluetooth] [<ffffffffa0004583>] hci_rx_work+0x133/0x870 [bluetooth] [<ffffffff8104d65f>] process_one_work+0x2bf/0x4f0 [<ffffffff81050022>] worker_thread+0x2b2/0x3e0 [<ffffffff81056021>] kthread+0xd1/0xe0 [<ffffffff813f14bc>] ret_from_fork+0x7c/0xb0 -> #0 (&(&conn->lock)->rlock){+.+...}: [<ffffffff81082215>] __lock_acquire+0x1465/0x1c70 [<ffffffff81083011>] lock_acquire+0xb1/0xe0 [<ffffffff813efd01>] _raw_spin_lock+0x41/0x80 [<ffffffffa0033ba6>] sco_chan_del+0x66/0x190 [bluetooth] [<ffffffffa0033d6d>] sco_conn_del+0x9d/0xe0 [bluetooth] [<ffffffffa0034653>] sco_disconn_cfm+0x53/0x60 [bluetooth] [<ffffffffa000fef3>] hci_disconn_complete_evt.isra.54+0x363/0x3c0 [bluetooth] [<ffffffffa00150f7>] hci_event_packet+0xc7/0x29b0 [bluetooth] [<ffffffffa0004583>] hci_rx_work+0x133/0x870 [bluetooth] [<ffffffff8104d65f>] process_one_work+0x2bf/0x4f0 [<ffffffff81050022>] worker_thread+0x2b2/0x3e0 [<ffffffff81056021>] kthread+0xd1/0xe0 [<ffffffff813f14bc>] ret_from_fork+0x7c/0xb0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(slock-AF_BLUETOOTH-BTPROTO_SCO); lock(&(&conn->lock)->rlock); lock(slock-AF_BLUETOOTH-BTPROTO_SCO); lock(&(&conn->lock)->rlock); *** DEADLOCK *** 4 locks held by kworker/u:1H/1018: #0: (hdev->name#2){.+.+.+}, at: [<ffffffff8104d5f8>] process_one_work+0x258/0x4f0 #1: ((&hdev->rx_work)){+.+.+.}, at: [<ffffffff8104d5f8>] process_one_work+0x258/0x4f0 #2: (&hdev->lock){+.+.+.}, at: [<ffffffffa000fbe9>] hci_disconn_complete_evt.isra.54+0x59/0x3c0 [bluetooth] #3: (slock-AF_BLUETOOTH-BTPROTO_SCO){+.+...}, at: [<ffffffffa0033d5a>] sco_conn_del+0x8a/0xe0 [bluetooth] stack backtrace: Pid: 1018, comm: kworker/u:1H Not tainted 3.8.0-rc1+ #7 Call Trace: [<ffffffff813e92f9>] print_circular_bug+0x1fb/0x20c [<ffffffff81082215>] __lock_acquire+0x1465/0x1c70 [<ffffffff81083011>] lock_acquire+0xb1/0xe0 [<ffffffffa0033ba6>] ? sco_chan_del+0x66/0x190 [bluetooth] [<ffffffff813efd01>] _raw_spin_lock+0x41/0x80 [<ffffffffa0033ba6>] ? sco_chan_del+0x66/0x190 [bluetooth] [<ffffffffa0033ba6>] sco_chan_del+0x66/0x190 [bluetooth] [<ffffffffa0033d6d>] sco_conn_del+0x9d/0xe0 [bluetooth] [<ffffffffa0034653>] sco_disconn_cfm+0x53/0x60 [bluetooth] [<ffffffffa000fef3>] hci_disconn_complete_evt.isra.54+0x363/0x3c0 [bluetooth] [<ffffffffa000fbd0>] ? hci_disconn_complete_evt.isra.54+0x40/0x3c0 [bluetooth] [<ffffffffa00150f7>] hci_event_packet+0xc7/0x29b0 [bluetooth] [<ffffffff81202e90>] ? __dynamic_pr_debug+0x80/0x90 [<ffffffff8133ff7d>] ? kfree_skb+0x2d/0x40 [<ffffffffa0021644>] ? hci_send_to_monitor+0x1a4/0x1c0 [bluetooth] [<ffffffffa0004583>] hci_rx_work+0x133/0x870 [bluetooth] [<ffffffff8104d5f8>] ? process_one_work+0x258/0x4f0 [<ffffffff8104d65f>] process_one_work+0x2bf/0x4f0 [<ffffffff8104d5f8>] ? process_one_work+0x258/0x4f0 [<ffffffff8104fdc1>] ? worker_thread+0x51/0x3e0 [<ffffffffa0004450>] ? hci_tx_work+0x800/0x800 [bluetooth] [<ffffffff81050022>] worker_thread+0x2b2/0x3e0 [<ffffffff8104fd70>] ? busy_worker_rebind_fn+0x100/0x100 [<ffffffff81056021>] kthread+0xd1/0xe0 [<ffffffff81055f50>] ? flush_kthread_worker+0xc0/0xc0 [<ffffffff813f14bc>] ret_from_fork+0x7c/0xb0 [<ffffffff81055f50>] ? flush_kthread_worker+0xc0/0xc0 Signed-off-by:Andre Guedes <andre.guedes@openbossa.org> Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk>
-
Johan Hedberg authored
This patch increments the management interface revision due to the various fixes, improvements and other changes that have gone in lately. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Acked-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Johan Hedberg authored
If a controller is powered on while the HCI_AUTO_OFF flag is set the link security setting (HCI_LINK_SECURITY) might not be in sync with the actual state of the controller (HCI_AUTH). This patch fixes the issue by checking for inequality between the intended and actual settings and sends a HCI_Write_Auth_Enable command if necessary. Signed-off-by:
-
Johan Hedberg authored
This patch adds the necessary code for encoding a list of 128-bit UUIDs into the EIR data. Signed-off-by:
-
Johan Hedberg authored
This patch adds the necessary code for inserting a list of 32-bit UUIDs into the EIR data. Signed-off-by:
-
Johan Hedberg authored
We will need to create three separate UUID lists in the EIR data (for 16, 32 and 128 bit UUIDs) so the code is easier to follow if each list is generated in their own function. Signed-off-by:
-
Johan Hedberg authored
The amount of data encoded so far in the create_eir() function can be calculated simply through the difference between the data and ptr pointer variables. The eir_len variable then becomes essentially useless. Signed-off-by:
-
Johan Hedberg authored
There's no need to use two separate loops to generate a UUID list for the EIR data. This patch merges the two loops previously used for the 16-bit UUID list generation into a single loop, thus simplifying the code a great deal. Signed-off-by:
-
Johan Hedberg authored
The UUID removal code can be simplified by using list_for_each_entry_safe instead of list_for_each_safe. Signed-off-by:
-
Johan Hedberg authored
The primary purpose of the UUIDs is to enable generation of EIR and AD data. In these data formats the UUIDs are split into separate fields based on whether they're 16, 32 or 128 bit UUIDs. To make the generation of these data fields simpler this patch adds a type member to the bt_uuid struct and assigns a value to it as soon as the UUID is added to the kernel. This way the type doesn't need to be calculated each time the UUID list is later iterated. Signed-off-by:
-
Johan Hedberg authored
The code for clearing the UUIDs list can be simplified by using list_for_each_entry_safe instead of list_for_each_safe. Signed-off-by:
-
Johan Hedberg authored
We should be encoding UUIDs to the EIR data in the same order that they were added to the kernel, i.e. each UUID should be added to the end of the UUIDs list. This patch fixes the issue by using list_add_tail instead of list_add for storing the UUIDs. Signed-off-by:
-
- 30 Jan, 2013 28 commits
-
-
Vladimir Kondratiev authored
In case vring setup with the firmware failed, success status was returned. fix it. Signed-off-by:
Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Vladimir Kondratiev authored
Firmware crash on attempt to delete Rx chain. Driver part of Rx chain removed only in preparation for the target reset; as reset is the only flow that removes Rx chain in the firmware. Signed-off-by:
-
Vladimir Kondratiev authored
Signed-off-by:
-
Vladimir Kondratiev authored
Signed-off-by:
-
Vladimir Kondratiev authored
Disable interrupts first to prevent spurious WMI events arrival Signed-off-by:
-
Vladimir Kondratiev authored
Signed-off-by:
-
Vladimir Kondratiev authored
When connect times out, scan was not re-enabled. Strictly say, it is firmware issue - it should issue "disconnect" event but it does not. Compensate in the driver. Signed-off-by:
-
Vladimir Kondratiev authored
Other parts of Rx path (BACK logic) will need to access associated data Signed-off-by:
-
Vladimir Kondratiev authored
Due to multi-tx-queue design, wil_start_xmit() used to be executed concurrently for different queues. Then, these transmits delivered to the same queue, creating race. As result, Tx descriptor may be skipped, causing stall in hardware. Convert to single Tx queue fixes it. Signed-off-by:
-
Vladimir Kondratiev authored
This allows to account for Tx errors Signed-off-by:
-
Vladimir Kondratiev authored
Move WMI related operations to wmi.c as helper functions Signed-off-by:
-
Vladimir Kondratiev authored
Introduce debug category "MISC", convert all raw wil_dbg() to this category. This improves dynamic debug manageability Signed-off-by:
-
Vladimir Kondratiev authored
Make printings from IRQ appears in dmesg in chronological order Signed-off-by:
-
Vladimir Kondratiev authored
In the firmware, added is ability to report internal errors using IRQ. Catch this IRQ and notify user space via netlink User space get notified like (udevadm monitor --kernel --property): KERNEL[12660.320520] change /devices/pci0000:00/0000:00:1c.1/0000:02:00.0/0000:03:01.0/0000:05:00.0/net/wlan12 (net) ACTION=change DEVPATH=/devices/pci0000:00/0000:00:1c.1/0000:02:00.0/0000:03:01.0/0000:05:00.0/net/wlan12 DEVTYPE=wlan EVENT=FW_ERROR IFINDEX=6 INTERFACE=wlan12 SEQNUM=2489 SOURCE=wil6210 SUBSYSTEM=net Signed-off-by:
-
Cyril Roelandt authored
Check that the array indexes are in-bounds before accessing the rate2 and tmp arrays. Found with the following semantic patch: <smpl> @@ identifier t; identifier idx; expression E; statement S; @@ * for (... ; <+... t[idx] ...+> && idx < E ; ...) S </smpl> Signed-off-by:
Cyril Roelandt <tipecaml@gmail.com> Acked-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
-
Larry Finger authored
Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Guenter Roeck authored
Fix: drivers/net/wireless/iwlegacy/4965.c: In function ‘il4965_post_associate’: drivers/net/wireless/iwlegacy/4965.c:1751:25: warning: variable ‘conf’ set but not used [-Wunused-but-set-variable] seen when building allmodconfig on x86_64 with W=1 by removing the unused variable. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Christian Lamparter authored
This patch is based on "iwlwifi: fix antenna bitmask". (362b0563) Like the new iwlagn devices, the old 4965N device only supports a maximum of three antennas. Hence only three bits are used, the fourth bit is likely the A-MPDU indicator. Cc: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Hauke Mehrtens authored
The old bcm47xx gpio code had support for gpio_to_irq, but the new code did not provide this function, but returned -ENXIO all the time. This patch adds the missing function. Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by:
-
Hauke Mehrtens authored
The old bcm47xx gpio code had support for gpio_to_irq, but the new code did not provide this function, but returned -ENXIO all the time. This patch adds the missing function. arch/mips/bcm47xx/wgt634u.c calls gpio_to_irq() and got the correct irq number with the old gpio handling code. With this patch the code in wgt634u.c should work again. I do not have a wgt634u to test this. Signed-off-by:
-
Bing Zhao authored
Instead of converting it to a bogus error code -1, we should return the original error code from lower layer driver. This error code will be printed so it may give user some clues on what has happened. Signed-off-by:
-
Alexey Khoroshilov authored
If pci_iomap() fails in mwifiex_pcie_init(), it breaks off initialization, deallocates all resources, but returns zero. The patch adds -EIO as return value in this case. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Acked-by:
-
Anatol Pomozov authored
Signed-off-by:
Anatol Pomozov <anatol.pomozov@gmail.com> Signed-off-by:
-
Yogesh Ashok Powar authored
While using STA mode in the AP firmware, avoid calling some firmware commands which are not supported by the AP firmware. Signed-off-by:
Yogesh Ashok Powar <yogeshp@marvell.com> Signed-off-by:
Nishant Sarmukadam <nishants@marvell.com> Signed-off-by:
-
Yogesh Ashok Powar authored
Choose interface specific function calls based on interface type instead of firmware types. Signed-off-by:
-
Yogesh Ashok Powar authored
Add and delete self entry in the firmware sta database for AP interface only. We do not need such an entry for STA interface. Signed-off-by:
-
Yogesh Ashok Powar authored
Firmware supports hardware encryption feature for the station interface running on AP firmware. Signed-off-by:
-
Yogesh Ashok Powar authored
Set mac type for station interface on AP firmware as secondary. This allows the firmware to set specific characteristics for the STA interface. Signed-off-by:
-
