aboutsummaryrefslogtreecommitdiffstats
path: root/net
Commit message (Collapse)AuthorAge
* mac80211: fix auth/assoc timeout handlingJohannes Berg2013-02-15
| | | | | | | | | | | | | | | | | | | | | | | In my commit 1672c0e31917f49d31d30d79067103432bc20cc7 ("mac80211: start auth/assoc timeout on frame status") I broke auth/assoc timeout handling: in case we wait for the TX status, it now leaves the timeout field set to 0, which is a valid time and can compare as being before now ("jiffies"). Thus, if the work struct runs for some other reason, the auth/assoc is treated as having timed out. Fix this by introducing a separate "timeout_started" variable that tracks whether the timeout has started and is checked before timing out. Additionally, for proper TX status handling the change requires that the skb->dev pointer is set up for all the frames, so set it up for all frames in mac80211. Reported-by: Wojciech Dubowik <Wojciech.Dubowik@neratec.com> Tested-by: Wojciech Dubowik <Wojciech.Dubowik@neratec.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix ieee80211_sta_tx_notify for nullfuncWojciech Dubowik2013-02-15
| | | | | | | | | | | Function ieee80211_sta_reset_conn_monitor has been resetting probe_send_count too early and nullfunc check was never called after succesfull ack. Reported-by: Magnus Cederlöf <mcider@gmail.com> Tested-by: Magnus Cederlöf <mcider@gmail.com> Signed-off-by: Wojciech Dubowik <Wojciech.Dubowik@neratec.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: consolidate MBSS change notificationThomas Pedersen2013-02-15
| | | | | | | | | | | | A few mesh utility functions will call ieee80211_bss_info_change_notify(), and then the caller might notify the driver of the same change again. Avoid this redundancy by propagating the BSS changes and generally calling bss_info_change_notify() once per change. Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix WPA with VLAN on AP side with ps-staMichael Braun2013-02-15
| | | | | | | | | | | | | When sending a broadcast while at least on of the connected stations is sleeping, it gets queued and send after a DTIM beacon is sent. If the packet was to be sent on a vlan interface, the vif used for dequeing from the per-bss queue does not hold the per-vlan sdata. The correct sdata is required to use the correct per-vlan broadcast/multicast key. This patch fixes this by restoring the per-vlan sdata using the skb->dev entry. Signed-off-by: Michael Braun <michael-dev@fami-braun.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: free ps->bc_buf skbs on vlan device stopMichael Braun2013-02-15
| | | | | | | | When the vlan device is removed, ps->bc_buf processing can no longer send its frames. Signed-off-by: Michael Braun <michael-dev@fami-braun.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add radar detection command/eventSimon Wunderlich2013-02-15
| | | | | | | | | | | | | | | | Add command to trigger radar detection in the driver/FW. Once radar detection is started it should continuously monitor for radars as long as the channel active. If radar is detected usermode notified with 'radar detected' event. Scanning and remain on channel functionality must be disabled while doing radar detection/scanning, and vice versa. Based on original patch by Victor Goldenshtein <victorg@ti.com> Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* nl80211/cfg80211: add radar detection command/eventSimon Wunderlich2013-02-15
| | | | | | | | | | | | | | | | | Add new NL80211_CMD_RADAR_DETECT, which starts the Channel Availability Check (CAC). This command will also notify the usermode about events (CAC finished, CAC aborted, radar detected, NOP finished). Once radar detection has started it should continuously monitor for radars as long as the channel is active. This patch enables DFS for AP mode in nl80211/cfg80211. Based on original patch by Victor Goldenshtein <victorg@ti.com> Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> [remove WIPHY_FLAG_HAS_RADAR_DETECT again -- my mistake] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: configuration for WoWLAN over TCPJohannes Berg2013-02-13
| | | | | | | | | | Intel Wireless devices are able to make a TCP connection after suspending, sending some data and waking up when the connection receives wakeup data (or breaks). Add the WoWLAN configuration and feature advertising API for it. Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211/minstrel_ht: add support for using CCK ratesFelix Fietkau2013-02-13
| | | | | | | | | | | | When MCS rates start to get bad in 2.4 GHz because of long range or strong interference, CCK rates can be a lot more robust. This patch adds a pseudo MCS group containing CCK rates (long preamble in the lower 4 slots, short preamble in the upper slots). Signed-off-by: Felix Fietkau <nbd@openwrt.org> [make minstrel_ht_get_stats static] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: check vendor IE length to avoid overrunLuciano Coelho2013-02-13
| | | | | | | | | | | | | | cfg80211_find_vendor_ie() was checking only that the vendor IE would fit in the remaining IEs buffer. If a corrupt includes a vendor IE that is too small, we could potentially overrun the IEs buffer. Fix this by checking that the vendor IE fits in the reported IE length field and skip it otherwise. Reported-by: Jouni Malinen <j@w1.fi> Signed-off-by: Luciano Coelho <coelho@ti.com> [change BUILD_BUG_ON to != 1 (from >= 2)] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* nl80211: add packet offset information for wowlan patternAmitkumar Karwar2013-02-13
| | | | | | | | | | | | If user knows the location of a wowlan pattern to be matched in Rx packet, he can provide an offset with the pattern. This will help drivers to ignore initial bytes and match the pattern efficiently. Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> [refactor pattern sending] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: allow driver to be stateless wrt. SMSP requestsEmmanuel Grumbach2013-02-12
| | | | | | | | Bail out if no update is made to the SMPS state. This allows the driver to avoid duplicating the state. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Add flushes before going off-channelSeth Forshee2013-02-11
| | | | | | | | | | | | | | | | | | We've got a couple of races when enabling powersave with an AP for off-channel operation. The first is fairly simple. If we go off-channel before the nullfunc frame to enable PS is transmitted then it may not be received by the AP. Add a flush after enabling off-channel PS to prevent this from happening. The second race is a bit more subtle. If the driver supports QoS and has frames queued when the nullfunc frame is queued, those frames may get transmitted after the nullfunc frame. If PM is not set then the AP is being told that we've exited PS before we go off-channel and may try to deliver frames. To prevent this, add a flush after stopping the queues but before passing the nullfunc frame to the driver. Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Fix tx queue handling during scansSeth Forshee2013-02-11
| | | | | | | | | | | | | | | | | | | | | | Scans currently work by stopping the netdev tx queues but leaving the mac80211 queues active. This stops the flow of incoming packets while still allowing mac80211 to transmit nullfunc and probe request frames to facilitate scanning. However, the driver may try to wake the mac80211 queues while in this state, which will also wake the netdev queues. To prevent this, add a new queue stop reason, IEEE80211_QUEUE_STOP_REASON_OFFCHANNEL, to be used when stopping the tx queues for off-channel operation. This prevents the netdev queues from waking when a driver wakes the mac80211 queues. This also stops all frames from being transmitted, even those meant to be sent off-channel. Add a new tx control flag, IEEE80211_TX_CTL_OFFCHAN_TX_OK, which allows frames to be transmitted when the queues are stopped only for the off-channel stop reason. Update all locations transmitting off-channel frames to use this flag. Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211/minstrel_ht: remove the sampling bypass check for the lowest rateFelix Fietkau2013-02-11
| | | | | | | | It's more of an unnecessary micro-optimization and it prevents switching from long-GI to short-GI in HT20/single-stream for the lowest rate Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211/minstrel_ht: show the number of retries for each rate in debugfsFelix Fietkau2013-02-11
| | | | | Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove unused code to mark AP station authenticatedJohannes Berg2013-02-11
| | | | | | | | When we get to association, the AP station already exists and is marked authenticated, so moving it into IEEE80211_STA_AUTH again is a NOP, remove it. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: simplify idle handlingJohannes Berg2013-02-11
| | | | | | | | | | Now that we have channel contexts, idle is (pretty much) equivalent to not having a channel context. Change the code to use this relation so that there no longer is a need for a lot of idle recalculate calls everywhere. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove IEEE80211_HW_SCAN_WHILE_IDLEJohannes Berg2013-02-11
| | | | | | | | | | | | | | There are only a few drivers that use HW scan, and all of those don't need a non-idle transition before starting the scan -- some don't even care about idle at all. Remove the flag and code associated with it. The only driver that really actually needed this is wl1251 and it can just do it itself in the hw_scan callback -- implement that. Acked-by: Luciano Coelho <coelho@ti.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove dynamic PS driver interfaceJohannes Berg2013-02-11
| | | | | | | | The functions were added for some sort of Bluetooth coexistence, but aren't used, so remove them again. Reviewed-by: Luciano Coelho <coelho@ti.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: introduce beacon-only timing dataJohannes Berg2013-02-11
| | | | | | | | | | | | | | In order to be able to predict the next DTIM TBTT in the driver, add the ability to use timing data from beacons only with the new hardware flag IEEE80211_HW_TIMING_BEACON_ONLY and the BSS info value sync_dtim_count which is only valid if the timing data came from a beacon. The data can only come from a beacon, and if no beacon was received before association it is updated later together with the DTIM count notification. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: move TSF into IEsJohannes Berg2013-02-11
| | | | | | | | | | | | | | | While technically the TSF isn't an IE, it can be necessary to distinguish between the TSF from a beacon and a probe response, in particular in order to know the next DTIM TBTT, as not all APs are spec compliant wrt. TSF==0 being a DTIM TBTT and thus the DTIM count needs to be taken into account as well. To allow this, move the TSF into the IE struct so it can be known whence it came. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: remove scan ies NULL checkJohannes Berg2013-02-11
| | | | | | | | | There's no way scan BSS IEs can be NULL as even if the allocation fails the frame is discarded. Remove some code checking for this and document that it is always non-NULL. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add vif debugfs driver callbacksAlexander Bondar2013-02-11
| | | | | | | | | | | | | Add debugfs driver callbacks so drivers can add debugfs entries for interfaces. Note that they _must_ remove the entries again as add/remove in the driver doesn't correspond to add/remove in debugfs; the former is up/down while the latter is netdev create/destroy. Signed-off-by: Alexander Bondar <alexander.bondar@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: track hidden SSID networks properlyJohannes Berg2013-02-11
| | | | | | | | | | | | | | | | | | Currently, cfg80211 will copy beacon IEs from a previously received hidden SSID beacon to a probe response entry, if that entry is created after the beacon entry. However, if it is the other way around, or if the beacon is updated, such changes aren't propagated. Fix this by tracking the relation between the probe response and beacon BSS structs in this case. In case drivers have private data stored in a BSS struct and need access to such data from a beacon entry, cfg80211 now provides the hidden_beacon_bss pointer from the probe response entry to the beacon entry. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: explicitly copy channels to VLANs where neededJohannes Berg2013-02-11
| | | | | | | | | | | | | | | | | | | Currently the code assigns channel contexts to VLANs (for use by the TX/RX code) when the AP master gets its channel context assigned. This works fine, but in the upcoming radar detection work the VLANs don't require a channel context (during radar detection) and assigning one to them anyway causes issues with locking and also inconsistencies -- a VLAN interface that is added before radar detection would get the channel context, while one added during it wouldn't. Fix these issues moving the channel context copying to a new explicit operation that will not be used in the radar detection code. Acked-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix chandef tracing bugJohannes Berg2013-02-11
| | | | | | | | The chandef tracing writes center_freq1 twice, so that it is always 0 (no driver supports 80+80 yet) and leaves center_freq2 unset. Fix this mistake. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix AP beacon loss messagesJohannes Berg2013-02-11
| | | | | | | | The messages currently refer to probe request probes, but on some devices null data packets will be used instead. Make the messages more generic. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: protect rx-path with spinlockChristian Lamparter2013-02-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes the problem which was discussed in "mac80211: Fix PN corruption in case of multiple virtual interface" [1]. Amit Shakya reported a serious issue with my patch: mac80211: serialize rx path workers" [2]: In case, ieee80211_rx_handlers processing is going on for skbs received on one vif and at the same time, rx aggregation reorder timer expires on another vif then sta_rx_agg_reorder_timer_expired is invoked and it will push skbs into the single queue (local->rx_skb_queue). ieee80211_rx_handlers in the while loop assumes that the skbs are for the same sdata and sta. This assumption doesn't hold good in this scenario and the PN gets corrupted by PN received in other vif's skb, causing traffic to stop due to PN mismatch." [1] Message-Id: http://mid.gmane.org/201302041844.44436.chunkeey@googlemail.com [2] Commit-Id: 24a8fdad35835e8d71f7 Reported-by: Amit Shakya <amit.shakya@stericsson.com> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Add the DS Params for mesh to every bandEmanuel Taube2013-02-11
| | | | | | | | There seems to be no reason, why it has to be limited to 2.4 GHz. Signed-off-by: Emanuel Taube <emanuel.taube@gmail.com> [remove 'local' variable] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix mesh sta teardownThomas Pedersen2013-02-11
| | | | | | | | | | | | | | | | | The patch "mac80211: clean up mesh sta allocation warning" moved some mesh initialization into a path which is only called when the kernel handles peering. This causes a hang when mac80211 tries to clean up a userspace-allocated station entry and delete a timer which has never been initialized. To avoid this, only do any mesh sta peering teardown if the kernel is actually handling it. The same is true when quiescing before suspend. Signed-off-by: Thomas Pedersen <thomas@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wireless: fix kernel-docJohannes Berg2013-02-11
| | | | | | | | | | Fix most kernel-doc warnings, for some reason it seems to have issues with __aligned, don't remove the documentation entries it considers to be in excess due to that. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: pass wiphy to cfg80211_ref_bss/put_bssJohannes Berg2013-02-11
| | | | | | | | | This prepares for using the spinlock instead of krefs which is needed in the next patch to track the refs of combined BSSes correctly. Acked-by: Bing Zhao <bzhao@marvell.com> [mwifiex] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: fix radar check for P2P_DEVICEIlan Peer2013-02-11
| | | | | | | Radar is not required for P2P_DEVICE interfaces. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: Fix memory leakLarry Finger2013-02-11
| | | | | | | | | | When a driver requests a specific regulatory domain after cfg80211 already has one, a struct ieee80211_regdomain is leaked. Reported-by: Larry Finger <Larry.Finger@lwfinger.net> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Merge remote-tracking branch 'wireless-next/master' into HEADJohannes Berg2013-02-11
|\
| * NFC: llcp: integer underflow in nfc_llcp_set_remote_gb()Dan Carpenter2013-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If gb_len is less than 3 it would cause an integer underflow and possibly memory corruption in nfc_llcp_parse_gb_tlv(). I removed the old test for gb_len == 0. I also removed the test for ->remote_gb == NULL. It's not possible for ->remote_gb to be NULL and we have already dereferenced ->remote_gb_len so it's too late to test. The old test return -ENODEV but my test returns -EINVAL. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * Merge branch 'for-john' of ↵John W. Linville2013-02-08
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Fixed-up drivers/net/wireless/iwlwifi/mvm/mac80211.c to change change IEEE80211_HW_NEED_DTIM_PERIOD to IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC as requested by Johannes Berg. -- JWL Signed-off-by: John W. Linville <linville@tuxdriver.com>
| * | Bluetooth: Refactor mgmt_pending_foreachAndre Guedes2013-02-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch does a trivial refactor in mgmt_pending_foreach function. It replaces list_for_each_safe by list_for_each_entry_safe, simplifying the function. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
| * | Bluetooth: Remove unneeded lockingAndre Guedes2013-02-01
| | | | | | | | | | | | | | | | | | | | | | | | This patch removes unneeded locking in hci_le_adv_report_evt. There is no need to lock hdev before calling mgmt_device_found. Signed-off-by: Andre Guedes <andre.guedes@openbossa.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
| * | Bluetooth: Reduce critical section in sco_conn_readyAndre Guedes2013-02-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | Bluetooth: Increment Management interface revisionJohan Hedberg2013-02-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
| * | Bluetooth: Fix link security setting when powering onJohan Hedberg2013-02-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
| * | Bluetooth: Add support for 128-bit UUIDs in EIR dataJohan Hedberg2013-02-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the necessary code for encoding a list of 128-bit UUIDs into the EIR data. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
| * | Bluetooth: Add support for 32-bit UUIDs in EIR dataJohan Hedberg2013-02-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the necessary code for inserting a list of 32-bit UUIDs into the EIR data. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
| * | Bluetooth: Refactor UUID-16 list generation into its own functionJohan Hedberg2013-02-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
| * | Bluetooth: Remove useless eir_len variable from EIR creationJohan Hedberg2013-02-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
| * | Bluetooth: Simplify UUID16 list generation for EIRJohan Hedberg2013-02-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
| * | Bluetooth: Simplify UUID removal codeJohan Hedberg2013-02-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
| * | Bluetooth: Keep track of UUID type upon additionJohan Hedberg2013-02-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <johan.hedberg@intel.com> Acked-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
generated by cgit v1.2.2 (git 2.25.0) at 2025-02-20 19:22:43 -0500