aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* ethernet: unify return value of .ndo_set_mac_address if address is invalidDanny Kukawka2012-02-23
| | | | | | | | | Unify return value of .ndo_set_mac_address if the given address isn't valid. Return -EADDRNOTAVAIL as eth_mac_addr() already does if is_valid_ether_addr() fails. Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'for-davem' of ↵David S. Miller2012-02-23
|\ | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc-next
| * sfc: Correct efx_for_each_possible_channel_tx_queue() to skip non-TX channelsBen Hutchings2012-02-22
| | | | | | | | | | | | | | | | | | efx_for_each_possible_channel_tx_queue() should do nothing for RX-only or extra channels. The current definition results in allocating additional unused hardware TX queues when using the mqprio qdisc and either separate_tx_channels or SR-IOV. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
| * sfc: Minor formatting cleanupBen Hutchings2012-02-22
| | | | | | | | | | | | Fix some indentation and line continuations. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
| * sfc: Reverse initial buffer table allocation to allow for later resizingBen Hutchings2012-02-22
| | | | | | | | | | | | | | | | | | | | We have a very simple way of allocating buffer table entries to queues, which is just to take the next one available. The extra channels are the highest numbered channels but they need to be allocated the lowest entries so that the traffic channels can be allocated new entries without any collisions. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
| * sfc: Correct validation of peer_page_count in efx_vfdi_set_status_page()Ben Hutchings2012-02-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | efx_vfdi_set_status_page() validates the peer page count by calculating the size of a request containing that many addresses and comparing that with the maximum valid request size (4KB). The calculation involves a multiplication that may overflow on a 32-bit system. We use kcalloc() to allocate memory to store the addresses; that also does a multiplication and it does check for integer overflow, so any values larger than 0x1fffffff will be rejected. However, values in the range [0x1fffffffc, 0x1fffffff] pass boh tests and result in an attempt to allocate nearly 4GB on the heap. This should be rejected rather quickly as it's obviously impossible on a 32-bit system, and indeed the maximum possible heap allocation is 32MB. Still, let's make absolutely sure by fixing the initial validation. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
| * sfc: Specify that the VFDI status page has page alignment and sizeBen Hutchings2012-02-22
| | | | | | | | | | | | | | | | | | | | | | | | This requirement was meant to be implied in the name 'status page'. One out-of-tree VF driver allocates a buffer using the structure size and not a full page - hence the current odd specification - but in practice that allocation will be padded and aligned to at least 4KB. Therefore, we can specify this and have the option to extend the structure up to 4KB without worrying about VF drivers using odd-shaped buffers. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
* | tg3: Create timer helper functionsMatt Carlson2012-02-23
| | | | | | | | | | | | | | | | | | | | | | This patch seeks to clean up the timer related code. It begins by moving one-time timer setup code from tg3_open() to tg3_init_one(). It then creates a function that encapsulates the code needed to start the timer. A tg3_timer_stop() function was added for parity. Finally, this patch moves all the timer functions to a more suitable location. Signed-off-by: Matt Carlson <mcarlson@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | tg3: Clear RECOVERY_PENDING with reset_task_cancelMatt Carlson2012-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If an error happens in the tx completion thread, tg3_reset_task will be scheduled and TX_RECOVERY_PENDING will be set. The TX_RECOVERY_PENDING flag causes tg3_poll[_msix] to return early before doing much of its work. Tg3_reset_task() gets canceled when the configuration of the device is changing, which always results in a chip reset. When this happens, the TX_RECOVERY_PENDING flag may be left set, which would unnecessarily hinder tg3_poll from doing work. This patch fixes the problem. Signed-off-by: Matt Carlson <mcarlson@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | tg3: Remove SPEED_UNKNOWN checksMatt Carlson2012-02-23
| | | | | | | | | | | | | | | | | | | | | | tg3_phy_copper_begin() has code that configures the link advertisements through the use of the link_config.speed and link_config.duplex members. The driver does not internally use these members in this way, nor is it (currently) permitted via the ethtool interface. This patch removes the dead code. Signed-off-by: Matt Carlson <mcarlson@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | tg3: Fix link check in tg3_adjust_linkMatt Carlson2012-02-23
| | | | | | | | | | | | | | | | | | | | | | | | | | The tg3 driver tried to detect link changes by comparing the tg3 local active_speed member with SPEED_UNKNOWN (or formerly SPEED_INVALID). This check is not correct, since phylib will never set its speed member to either of these two values. The code only appeared to work because tg3 initializes active_speed to SPEED_INVALID during tg3_init_one. This patch introduces a new "old_link" tg3 member and then compares the phy_device's link member against it to detect link state changes. Signed-off-by: Matt Carlson <mcarlson@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | af_unix: MSG_TRUNC support for dgram socketsEric Dumazet2012-02-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Piergiorgio Beruto expressed the need to fetch size of first datagram in queue for AF_UNIX sockets and suggested a patch against SIOCINQ ioctl. I suggested instead to implement MSG_TRUNC support as a recv() input flag, as already done for RAW, UDP & NETLINK sockets. len = recv(fd, &byte, 1, MSG_PEEK | MSG_TRUNC); MSG_TRUNC asks recv() to return the real length of the packet, even when is was longer than the passed buffer. There is risk that a userland application used MSG_TRUNC by accident (since it had no effect on af_unix sockets) and this might break after this patch. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Tested-by: Piergiorgio Beruto <piergiorgio.beruto@gmail.com> CC: Michael Kerrisk <mtk.manpages@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | net/ieee802154/6lowpan.c: reuse eth_mac_addr()Danny Kukawka2012-02-22
| | | | | | | | | | | | | | | | | | | | | | Use eth_mac_addr() for .ndo_set_mac_address, remove lowpan_set_address since it do currently the same as eth_mac_addr(). Additional advantage: eth_mac_addr() already checks if the given address is valid Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de> Acked-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | 3com/typhoon: reuse eth_mac_addr()Danny Kukawka2012-02-22
| | | | | | | | | | | | | | | | | | | | | | Use eth_mac_addr() for .ndo_set_mac_address, remove typhoon_set_mac_address() since it do currently the same as eth_mac_addr(). Additional advantage: eth_mac_addr() already checks if the given address is valid. Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de> Acked-by: Dave Dillow <dave@thedillows.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | tg3: remove IRQF_SAMPLE_RANDOM flagDavidlohr Bueso2012-02-22
| | | | | | | | | | | | | | | | This driver is the last user of the IRQF_SAMPLE_RANDOM flag for net drivers, and since add_*_randomness interfaces have now deprecated the flag as a source of external noise, we can remove it. Signed-off-by: Davidlohr Bueso <dave@gnu.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge branch 'for-davem' of ↵David S. Miller2012-02-21
|\ \ | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next
| * \ Merge branch 'master' of ↵John W. Linville2012-02-21
| |\ \ | | |/ | |/| | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem
| | * Merge branch 'master' of ↵John W. Linville2012-02-15
| | |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless Conflicts: net/mac80211/debugfs_sta.c net/mac80211/sta_info.h
| | | * ath9k: stop on rates with idx -1 in ath9k rate control's .tx_statusPavel Roskin2012-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rate control algorithms are supposed to stop processing when they encounter a rate with the index -1. Checking for rate->count not being zero is not enough. Allowing a rate with negative index leads to memory corruption in ath_debug_stat_rc(). One consequence of the bug is discussed at https://bugzilla.redhat.com/show_bug.cgi?id=768639 Signed-off-by: Pavel Roskin <proski@gnu.org> Cc: stable@vger.kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | | * mwifiex: clear previous security setting during associationAmitkumar Karwar2012-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Driver maintains different flags for WEP, WPA, WPA2 security modes. Appropriate flag is set using security information provided in connect request. mwifiex_is_network_compatible() routine uses them to check if driver's setting is compatible with AP. Association is aborted if the routine fails. For some corner cases, it is observed that association is failed even for valid security information based on association history. This patch fixes the problem by clearing previous security setting during each association. We should set WEP key provided in connect request as default tx key. This missing change is also added here. 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>
| | | * mac80211: do not call rate control .tx_status before .rate_initFelix Fietkau2012-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most rate control implementations assume .get_rate and .tx_status are only called once the per-station data has been fully initialized. minstrel_ht crashes if this assumption is violated. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Tested-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | | * mac80211: call rate control only after initJohannes Berg2012-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are situations where we don't have the necessary rate control information yet for station entries, e.g. when associating. This currently doesn't really happen due to the dummy station handling; explicitly disabling rate control when it's not initialised will allow us to remove dummy stations. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | | * Bluetooth: Fix possible use after free in delete pathUlisses Furquim2012-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to use the _sync() version for cancelling the info and security timer in the L2CAP connection delete path. Otherwise the delayed work handler might run after the connection object is freed. Signed-off-by: Ulisses Furquim <ulisses@profusion.mobi> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | | * Bluetooth: Remove usage of __cancel_delayed_work()Ulisses Furquim2012-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | __cancel_delayed_work() is being used in some paths where we cannot sleep waiting for the delayed work to finish. However, that function might return while the timer is running and the work will be queued again. Replace the calls with safer cancel_delayed_work() version which spins until the timer handler finishes on other CPUs and cancels the delayed work. Signed-off-by: Ulisses Furquim <ulisses@profusion.mobi> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | | * Bluetooth: btusb: Add vendor specific ID (0a5c 21f3) for BCM20702A0Manoj Iyer2012-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=03 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0a5c ProdID=21f3 Rev=01.12 S: Manufacturer=Broadcom Corp S: Product=BCM20702A0 S: SerialNumber=74DE2B344A7B C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com> Tested-by: Dennis Chua <dennis.chua@canonical.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | | * Bluetooth: Add missing QUIRK_NO_RESET test to hci_dev_do_closeJohan Hedberg2012-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We should only perform a reset in hci_dev_do_close if the HCI_QUIRK_NO_RESET flag is set (since in such a case a reset will not be performed when initializing the device). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
| | | * Bluetooth: Fix RFCOMM session reference counting issueOctavian Purdila2012-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is an imbalance in the rfcomm_session_hold / rfcomm_session_put operations which causes the following crash: [ 685.010159] BUG: unable to handle kernel paging request at 6b6b6b6b [ 685.010169] IP: [<c149d76d>] rfcomm_process_dlcs+0x1b/0x15e [ 685.010181] *pdpt = 000000002d665001 *pde = 0000000000000000 [ 685.010191] Oops: 0000 [#1] PREEMPT SMP [ 685.010247] [ 685.010255] Pid: 947, comm: krfcommd Tainted: G C 3.0.16-mid8-dirty #44 [ 685.010266] EIP: 0060:[<c149d76d>] EFLAGS: 00010246 CPU: 1 [ 685.010274] EIP is at rfcomm_process_dlcs+0x1b/0x15e [ 685.010281] EAX: e79f551c EBX: 6b6b6b6b ECX: 00000007 EDX: e79f40b4 [ 685.010288] ESI: e79f4060 EDI: ed4e1f70 EBP: ed4e1f68 ESP: ed4e1f50 [ 685.010295] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 685.010303] Process krfcommd (pid: 947, ti=ed4e0000 task=ed43e5e0 task.ti=ed4e0000) [ 685.010308] Stack: [ 685.010312] ed4e1f68 c149eb53 e5925150 e79f4060 ed500000 ed4e1f70 ed4e1f80 c149ec10 [ 685.010331] 00000000 ed43e5e0 00000000 ed4e1f90 ed4e1f9c c149ec87 0000bf54 00000000 [ 685.010348] 00000000 ee03bf54 c149ec37 ed4e1fe4 c104fe01 00000000 00000000 00000000 [ 685.010367] Call Trace: [ 685.010376] [<c149eb53>] ? rfcomm_process_rx+0x6e/0x74 [ 685.010387] [<c149ec10>] rfcomm_process_sessions+0xb7/0xde [ 685.010398] [<c149ec87>] rfcomm_run+0x50/0x6d [ 685.010409] [<c149ec37>] ? rfcomm_process_sessions+0xde/0xde [ 685.010419] [<c104fe01>] kthread+0x63/0x68 [ 685.010431] [<c104fd9e>] ? __init_kthread_worker+0x42/0x42 [ 685.010442] [<c14dae82>] kernel_thread_helper+0x6/0xd This issue has been brought up earlier here: https://lkml.org/lkml/2011/5/21/127 The issue appears to be the rfcomm_session_put in rfcomm_recv_ua. This operation doesn't seem be to required as for the non-initiator case we have the rfcomm_process_rx doing an explicit put and in the initiator case the last dlc_unlink will drive the reference counter to 0. There have been several attempts to fix these issue: 6c2718d Bluetooth: Do not call rfcomm_session_put() for RFCOMM UA on closed socket 683d949 Bluetooth: Never deallocate a session when some DLC points to it but AFAICS they do not fix the issue just make it harder to reproduce. Signed-off-by: Octavian Purdila <octavian.purdila@intel.com> Signed-off-by: Gopala Krishna Murala <gopala.krishna.murala@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | | * Bluetooth: Fix potential deadlockAndre Guedes2012-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't need to use the _sync variant in hci_conn_hold and hci_conn_put to cancel conn->disc_work delayed work. This way we avoid potential deadlocks like this one reported by lockdep. ====================================================== [ INFO: possible circular locking dependency detected ] 3.2.0+ #1 Not tainted ------------------------------------------------------- kworker/u:1/17 is trying to acquire lock: (&hdev->lock){+.+.+.}, at: [<ffffffffa0041155>] hci_conn_timeout+0x62/0x158 [bluetooth] but task is already holding lock: ((&(&conn->disc_work)->work)){+.+...}, at: [<ffffffff81035751>] process_one_work+0x11a/0x2bf which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 ((&(&conn->disc_work)->work)){+.+...}: [<ffffffff81057444>] lock_acquire+0x8a/0xa7 [<ffffffff81034ed1>] wait_on_work+0x3d/0xaa [<ffffffff81035b54>] __cancel_work_timer+0xac/0xef [<ffffffff81035ba4>] cancel_delayed_work_sync+0xd/0xf [<ffffffffa00554b0>] smp_chan_create+0xde/0xe6 [bluetooth] [<ffffffffa0056160>] smp_conn_security+0xa3/0x12d [bluetooth] [<ffffffffa0053640>] l2cap_connect_cfm+0x237/0x2e8 [bluetooth] [<ffffffffa004239c>] hci_proto_connect_cfm+0x2d/0x6f [bluetooth] [<ffffffffa0046ea5>] hci_event_packet+0x29d1/0x2d60 [bluetooth] [<ffffffffa003dde3>] hci_rx_work+0xd0/0x2e1 [bluetooth] [<ffffffff810357af>] process_one_work+0x178/0x2bf [<ffffffff81036178>] worker_thread+0xce/0x152 [<ffffffff81039a03>] kthread+0x95/0x9d [<ffffffff812e7754>] kernel_thread_helper+0x4/0x10 -> #1 (slock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+...}: [<ffffffff81057444>] lock_acquire+0x8a/0xa7 [<ffffffff812e553a>] _raw_spin_lock_bh+0x36/0x6a [<ffffffff81244d56>] lock_sock_nested+0x24/0x7f [<ffffffffa004d96f>] lock_sock+0xb/0xd [bluetooth] [<ffffffffa0052906>] l2cap_chan_connect+0xa9/0x26f [bluetooth] [<ffffffffa00545f8>] l2cap_sock_connect+0xb3/0xff [bluetooth] [<ffffffff81243b48>] sys_connect+0x69/0x8a [<ffffffff812e6579>] system_call_fastpath+0x16/0x1b -> #0 (&hdev->lock){+.+.+.}: [<ffffffff81056d06>] __lock_acquire+0xa80/0xd74 [<ffffffff81057444>] lock_acquire+0x8a/0xa7 [<ffffffff812e3870>] __mutex_lock_common+0x48/0x38e [<ffffffff812e3c75>] mutex_lock_nested+0x2a/0x31 [<ffffffffa0041155>] hci_conn_timeout+0x62/0x158 [bluetooth] [<ffffffff810357af>] process_one_work+0x178/0x2bf [<ffffffff81036178>] worker_thread+0xce/0x152 [<ffffffff81039a03>] kthread+0x95/0x9d [<ffffffff812e7754>] kernel_thread_helper+0x4/0x10 other info that might help us debug this: Chain exists of: &hdev->lock --> slock-AF_BLUETOOTH-BTPROTO_L2CAP --> (&(&conn->disc_work)->work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((&(&conn->disc_work)->work)); lock(slock-AF_BLUETOOTH-BTPROTO_L2CAP); lock((&(&conn->disc_work)->work)); lock(&hdev->lock); *** DEADLOCK *** 2 locks held by kworker/u:1/17: #0: (hdev->name){.+.+.+}, at: [<ffffffff81035751>] process_one_work+0x11a/0x2bf #1: ((&(&conn->disc_work)->work)){+.+...}, at: [<ffffffff81035751>] process_one_work+0x11a/0x2bf stack backtrace: Pid: 17, comm: kworker/u:1 Not tainted 3.2.0+ #1 Call Trace: [<ffffffff812e06c6>] print_circular_bug+0x1f8/0x209 [<ffffffff81056d06>] __lock_acquire+0xa80/0xd74 [<ffffffff81021ef2>] ? arch_local_irq_restore+0x6/0xd [<ffffffff81022bc7>] ? vprintk+0x3f9/0x41e [<ffffffff81057444>] lock_acquire+0x8a/0xa7 [<ffffffffa0041155>] ? hci_conn_timeout+0x62/0x158 [bluetooth] [<ffffffff812e3870>] __mutex_lock_common+0x48/0x38e [<ffffffffa0041155>] ? hci_conn_timeout+0x62/0x158 [bluetooth] [<ffffffff81190fd6>] ? __dynamic_pr_debug+0x6d/0x6f [<ffffffffa0041155>] ? hci_conn_timeout+0x62/0x158 [bluetooth] [<ffffffff8105320f>] ? trace_hardirqs_off+0xd/0xf [<ffffffff812e3c75>] mutex_lock_nested+0x2a/0x31 [<ffffffffa0041155>] hci_conn_timeout+0x62/0x158 [bluetooth] [<ffffffff810357af>] process_one_work+0x178/0x2bf [<ffffffff81035751>] ? process_one_work+0x11a/0x2bf [<ffffffff81055af3>] ? lock_acquired+0x1d0/0x1df [<ffffffffa00410f3>] ? hci_acl_disconn+0x65/0x65 [bluetooth] [<ffffffff81036178>] worker_thread+0xce/0x152 [<ffffffff810407ed>] ? finish_task_switch+0x45/0xc5 [<ffffffff810360aa>] ? manage_workers.isra.25+0x16a/0x16a [<ffffffff81039a03>] kthread+0x95/0x9d [<ffffffff812e7754>] kernel_thread_helper+0x4/0x10 [<ffffffff812e5db4>] ? retint_restore_args+0x13/0x13 [<ffffffff8103996e>] ? __init_kthread_worker+0x55/0x55 [<ffffffff812e7750>] ? gs_change+0x13/0x13 Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Reviewed-by: Ulisses Furquim <ulisses@profusion.mobi> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | | * Bluetooth: silence lockdep warningOctavian Purdila2012-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since bluetooth uses multiple protocols types, to avoid lockdep warnings, we need to use different lockdep classes (one for each protocol type). This is already done in bt_sock_create but it misses a couple of cases when new connections are created. This patch corrects that to fix the following warning: <4>[ 1864.732366] ======================================================= <4>[ 1864.733030] [ INFO: possible circular locking dependency detected ] <4>[ 1864.733544] 3.0.16-mid3-00007-gc9a0f62 #3 <4>[ 1864.733883] ------------------------------------------------------- <4>[ 1864.734408] t.android.btclc/4204 is trying to acquire lock: <4>[ 1864.734869] (rfcomm_mutex){+.+.+.}, at: [<c14970ea>] rfcomm_dlc_close+0x15/0x30 <4>[ 1864.735541] <4>[ 1864.735549] but task is already holding lock: <4>[ 1864.736045] (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [<c1498bf7>] lock_sock+0xa/0xc <4>[ 1864.736732] <4>[ 1864.736740] which lock already depends on the new lock. <4>[ 1864.736750] <4>[ 1864.737428] <4>[ 1864.737437] the existing dependency chain (in reverse order) is: <4>[ 1864.738016] <4>[ 1864.738023] -> #1 (sk_lock-AF_BLUETOOTH){+.+.+.}: <4>[ 1864.738549] [<c1062273>] lock_acquire+0x104/0x140 <4>[ 1864.738977] [<c13d35c1>] lock_sock_nested+0x58/0x68 <4>[ 1864.739411] [<c1493c33>] l2cap_sock_sendmsg+0x3e/0x76 <4>[ 1864.739858] [<c13d06c3>] __sock_sendmsg+0x50/0x59 <4>[ 1864.740279] [<c13d0ea2>] sock_sendmsg+0x94/0xa8 <4>[ 1864.740687] [<c13d0ede>] kernel_sendmsg+0x28/0x37 <4>[ 1864.741106] [<c14969ca>] rfcomm_send_frame+0x30/0x38 <4>[ 1864.741542] [<c1496a2a>] rfcomm_send_ua+0x58/0x5a <4>[ 1864.741959] [<c1498447>] rfcomm_run+0x441/0xb52 <4>[ 1864.742365] [<c104f095>] kthread+0x63/0x68 <4>[ 1864.742742] [<c14d5182>] kernel_thread_helper+0x6/0xd <4>[ 1864.743187] <4>[ 1864.743193] -> #0 (rfcomm_mutex){+.+.+.}: <4>[ 1864.743667] [<c1061ada>] __lock_acquire+0x988/0xc00 <4>[ 1864.744100] [<c1062273>] lock_acquire+0x104/0x140 <4>[ 1864.744519] [<c14d2c70>] __mutex_lock_common+0x3b/0x33f <4>[ 1864.744975] [<c14d303e>] mutex_lock_nested+0x2d/0x36 <4>[ 1864.745412] [<c14970ea>] rfcomm_dlc_close+0x15/0x30 <4>[ 1864.745842] [<c14990d9>] __rfcomm_sock_close+0x5f/0x6b <4>[ 1864.746288] [<c1499114>] rfcomm_sock_shutdown+0x2f/0x62 <4>[ 1864.746737] [<c13d275d>] sys_socketcall+0x1db/0x422 <4>[ 1864.747165] [<c14d42f0>] syscall_call+0x7/0xb Signed-off-by: Octavian Purdila <octavian.purdila@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | | * Bluetooth: Fix using an absolute timeout on hci_conn_put()Vinicius Costa Gomes2012-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | queue_delayed_work() expects a relative time for when that work should be scheduled. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | | * Bluetooth: l2cap_set_timer needs jiffies as timeout valueAndrzej Kaczmarek2012-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After moving L2CAP timers to workqueues l2cap_set_timer expects timeout value to be specified in jiffies but constants defined in miliseconds are used. This makes timeouts unreliable when CONFIG_HZ is not set to 1000. __set_chan_timer macro still uses jiffies as input to avoid multiple conversions from/to jiffies for sk_sndtimeo value which is already specified in jiffies. Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> Ackec-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | | * Bluetooth: Fix sk_sndtimeo initialization for L2CAP socketAndrzej Kaczmarek2012-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sk_sndtime value should be specified in jiffies thus initial value needs to be converted from miliseconds. Otherwise this timeout is unreliable when CONFIG_HZ is not set to 1000. Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | | * Bluetooth: Remove bogus inline declaration from l2cap_chan_connectJohan Hedberg2012-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As reported by Dan Carpenter this function causes a Sparse warning and shouldn't be declared inline: include/net/bluetooth/l2cap.h:837:30 error: marked inline, but without a definition" Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org>
| | | * Bluetooth: Don't mark non xfer isoc endpoint URBs with URB_ISO_ASAPDaniel Wagner2012-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ 2096.384084] btusb_send_frame:684: hci0 [ 2096.384087] usb 3-1: BOGUS urb flags, 2 --> 0 [ 2096.384091] Bluetooth: hci0 urb ffff8801b61d3a80 submission failed (22) According the documentation in usb_submit_urb() URB_ISO_ASAP flag is only allowed for endpoints of type USB_ENDPOINT_XFER_ISOC. This reverts commit b8aabfc92249b239c425da7e4ca85b7e4855e984. Signed-off-by: Daniel Wagner <daniel.wagner@bmw-carit.de> Acked-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | | * Bluetooth: Fix l2cap conn failures for ssp devicesPeter Hurley2012-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 330605423c fixed l2cap conn establishment for non-ssp remote devices by not setting HCI_CONN_ENCRYPT_PEND every time conn security is tested (which was always returning failure on any subsequent security checks). However, this broke l2cap conn establishment for ssp remote devices when an ACL link was already established at SDP-level security. This fix ensures that encryption must be pending whenever authentication is also pending. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Tested-by: Daniel Wagner <daniel.wagner@bmw-carit.de> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
| | * | rtlwifi: Modify rtl_pci_init to return 0 on successJohn W. Linville2012-02-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes problem where caller would think routine succeeded when it failed leading to divide by zero panic. (This also reverts an earlier attempt, commit 42bc0c97 "rtlwifi: Return correct failure code on error". -- JWL) Signed-off-by: Simon Graham <simon.graham@virtualcomputer.com> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | mac80211: do not call rate control .tx_status before .rate_initFelix Fietkau2012-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most rate control implementations assume .get_rate and .tx_status are only called once the per-station data has been fully initialized. minstrel_ht crashes if this assumption is violated. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Tested-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | rtlwifi: Return correct failure code on errorSimon Graham2012-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Callers of rtl_pci_init expect zero to be returned on error. Returning the error code leads to, amongst other things, divide by zero panics attempting to use the ring size that is set to zero. Signed-off-by: Simon Graham <simon.graham@virtualcomputer.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | mac80211: rename mesh static path_lookup()Luis R. Rodriguez2012-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you want to use mesh support from mac80211 on a recent kernel on 2.6.24 you'll run into a name clash when compiling against include/linux/namei.h, so rename this routine. /home/mcgrof/tmp/compat-wireless-3.2.5-1/net/mac80211/mesh_pathtbl.c: At top level: /home/mcgrof/tmp/compat-wireless-3.2.5-1/net/mac80211/mesh_pathtbl.c:342:26: error: conflicting types for ‘path_lookup’ include/linux/namei.h:71:12: note: previous declaration of ‘path_lookup’ was here Although this could sit as a separate patch in compat-wireless it seems best to just merge upstream. Cc: Javier Cardona <javier@cozybit.com> Signed-off-by: Luis R. Rodriguez <mcgrof@frijolero.org> Acked-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | rtlwifi: Handle previous allocation failures when freeing device memorySimon Graham2012-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Handle previous allocation failures when freeing device memory Signed-off-by: Simon Graham <simon.graham@virtualcomputer.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | mac80211: add #ifdef CONFIG_MAC80211_VERBOSE_DEBUG for a debug printkFelix Fietkau2012-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When not debugging mac80211 code, station state transitions do not need to show up in the kernel log. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | rt2x00: Correctly set txmixer_gain in RT3572 channel switching.Gertjan van Wingerde2012-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Align with the v2.5.0.0 Ralink RT3572 driver. Save the EEPROM txmixer_gain values inside the rt2800 driver data structure and use it throughout the code. Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | rt2x00: Fix RT3572 channel switch RFCSR 7 programming.Gertjan van Wingerde2012-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Align with the v2.5.0.0 Ralink RT3572 driver. Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | rt2x00: Align RT3572 channel switch RFCSR 1 programming with Ralink driver.Gertjan van Wingerde2012-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Align with the v2.5.0.0 Ralink RT3572 driver. Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | rt2x00: Fix RFCSR 12 & 13 programming on RT3572 channel switching.Gertjan van Wingerde2012-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Align with v2.5.0.0 Ralink RT3572 driver for 2.4GHz band channel switch. Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | rt2x00: Use saved BBP 25 and 26 values when configuring channel on RT3572.Gertjan van Wingerde2012-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This brings the rt2800 channel switching code for RT3572 closer to the v2.5.0.0 Ralink RT3572 driver. Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | rt2x00: Update comment on freq_offset field in struct rt2x00_dev.Gertjan van Wingerde2012-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The comment states that the field is only used for rt61pci and rt73usb. However, it is now used by rt2800pci and rt2800usb as well, so the comment is not correct anymore. Update the comment to not state any low-level drivers anymore. Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | rt2x00: Use struct rt2x00_dev driver data in rt2800{pci,usb}.Gertjan van Wingerde2012-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Start using the struct rt2x00_dev driver data in rt2800 for the calibration data. Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | rt2x00: Introduce concept of driver data in struct rt2x00_dev.Gertjan van Wingerde2012-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We are getting more and more fields in struct rt2x00_dev that are specific to one or two of the low-level drivers. Instead of putting these fields inside the main structure and thus clobbering all low-level drivers with these fields, introduce the concept of driver data inside struct rt2x00_dev, whose size is indicated by the low-level driver and which can be populated by the low-level driver. Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| | * | orinoco: Remove old mailing lists from MAINTAINERSDavid Gibson2012-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The two orinoco mailing lists on sourceforge were set up many years ago and are now more or less moribund. I'd like to shut them down, so I don't have to keep filtering the spam from them (which is most of what comes through now). In preparation, this patch removes the reference to them from the MAINTAINERS file. Any remaining discussion of this approaching obsolete driver can go to the linux-wireless list. Signed-off-by: David Gibson <hermes@gibson.dropbear.id.au> Acked-by: Pavel Roskin <proski@gnu.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
generated by cgit v1.2.2 (git 2.25.0) at 2025-01-09 02:06:18 -0500