aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2013-08-11Revert "cpuidle: Quickly notice prediction failure for repeat mode"Rafael J. Wysocki
commit 148519120c6d1f19ad53349683aeae9f228b0b8d upstream. Revert commit 69a37bea (cpuidle: Quickly notice prediction failure for repeat mode), because it has been identified as the source of a significant performance regression in v3.8 and later as explained by Jeremy Eder: We believe we've identified a particular commit to the cpuidle code that seems to be impacting performance of variety of workloads. The simplest way to reproduce is using netperf TCP_RR test, so we're using that, on a pair of Sandy Bridge based servers. We also have data from a large database setup where performance is also measurably/positively impacted, though that test data isn't easily share-able. Included below are test results from 3 test kernels: kernel reverts ----------------------------------------------------------- 1) vanilla upstream (no reverts) 2) perfteam2 reverts e11538d1f03914eb92af5a1a378375c05ae8520c 3) test reverts 69a37beabf1f0a6705c08e879bdd5d82ff6486c4 e11538d1f03914eb92af5a1a378375c05ae8520c In summary, netperf TCP_RR numbers improve by approximately 4% after reverting 69a37beabf1f0a6705c08e879bdd5d82ff6486c4. When 69a37beabf1f0a6705c08e879bdd5d82ff6486c4 is included, C0 residency never seems to get above 40%. Taking that patch out gets C0 near 100% quite often, and performance increases. The below data are histograms representing the %c0 residency @ 1-second sample rates (using turbostat), while under netperf test. - If you look at the first 4 histograms, you can see %c0 residency almost entirely in the 30,40% bin. - The last pair, which reverts 69a37beabf1f0a6705c08e879bdd5d82ff6486c4, shows %c0 in the 80,90,100% bins. Below each kernel name are netperf TCP_RR trans/s numbers for the particular kernel that can be disclosed publicly, comparing the 3 test kernels. We ran a 4th test with the vanilla kernel where we've also set /dev/cpu_dma_latency=0 to show overall impact boosting single-threaded TCP_RR performance over 11% above baseline. 3.10-rc2 vanilla RX + c0 lock (/dev/cpu_dma_latency=0): TCP_RR trans/s 54323.78 ----------------------------------------------------------- 3.10-rc2 vanilla RX (no reverts) TCP_RR trans/s 48192.47 Receiver %c0 0.0000 - 10.0000 [ 1]: * 10.0000 - 20.0000 [ 0]: 20.0000 - 30.0000 [ 0]: 30.0000 - 40.0000 [ 59]: *********************************************************** 40.0000 - 50.0000 [ 1]: * 50.0000 - 60.0000 [ 0]: 60.0000 - 70.0000 [ 0]: 70.0000 - 80.0000 [ 0]: 80.0000 - 90.0000 [ 0]: 90.0000 - 100.0000 [ 0]: Sender %c0 0.0000 - 10.0000 [ 1]: * 10.0000 - 20.0000 [ 0]: 20.0000 - 30.0000 [ 0]: 30.0000 - 40.0000 [ 11]: *********** 40.0000 - 50.0000 [ 49]: ************************************************* 50.0000 - 60.0000 [ 0]: 60.0000 - 70.0000 [ 0]: 70.0000 - 80.0000 [ 0]: 80.0000 - 90.0000 [ 0]: 90.0000 - 100.0000 [ 0]: ----------------------------------------------------------- 3.10-rc2 perfteam2 RX (reverts commit e11538d1f03914eb92af5a1a378375c05ae8520c) TCP_RR trans/s 49698.69 Receiver %c0 0.0000 - 10.0000 [ 1]: * 10.0000 - 20.0000 [ 1]: * 20.0000 - 30.0000 [ 0]: 30.0000 - 40.0000 [ 59]: *********************************************************** 40.0000 - 50.0000 [ 0]: 50.0000 - 60.0000 [ 0]: 60.0000 - 70.0000 [ 0]: 70.0000 - 80.0000 [ 0]: 80.0000 - 90.0000 [ 0]: 90.0000 - 100.0000 [ 0]: Sender %c0 0.0000 - 10.0000 [ 1]: * 10.0000 - 20.0000 [ 0]: 20.0000 - 30.0000 [ 0]: 30.0000 - 40.0000 [ 2]: ** 40.0000 - 50.0000 [ 58]: ********************************************************** 50.0000 - 60.0000 [ 0]: 60.0000 - 70.0000 [ 0]: 70.0000 - 80.0000 [ 0]: 80.0000 - 90.0000 [ 0]: 90.0000 - 100.0000 [ 0]: ----------------------------------------------------------- 3.10-rc2 test RX (reverts 69a37beabf1f0a6705c08e879bdd5d82ff6486c4 and e11538d1f03914eb92af5a1a378375c05ae8520c) TCP_RR trans/s 47766.95 Receiver %c0 0.0000 - 10.0000 [ 1]: * 10.0000 - 20.0000 [ 1]: * 20.0000 - 30.0000 [ 0]: 30.0000 - 40.0000 [ 27]: *************************** 40.0000 - 50.0000 [ 2]: ** 50.0000 - 60.0000 [ 0]: 60.0000 - 70.0000 [ 2]: ** 70.0000 - 80.0000 [ 0]: 80.0000 - 90.0000 [ 0]: 90.0000 - 100.0000 [ 28]: **************************** Sender: 0.0000 - 10.0000 [ 1]: * 10.0000 - 20.0000 [ 0]: 20.0000 - 30.0000 [ 0]: 30.0000 - 40.0000 [ 11]: *********** 40.0000 - 50.0000 [ 0]: 50.0000 - 60.0000 [ 1]: * 60.0000 - 70.0000 [ 0]: 70.0000 - 80.0000 [ 3]: *** 80.0000 - 90.0000 [ 7]: ******* 90.0000 - 100.0000 [ 38]: ************************************** These results demonstrate gaining back the tendency of the CPU to stay in more responsive, performant C-states (and thus yield measurably better performance), by reverting commit 69a37beabf1f0a6705c08e879bdd5d82ff6486c4. Requested-by: Jeremy Eder <jeder@redhat.com> Tested-by: Len Brown <len.brown@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11cpufreq: Fix cpufreq driver module refcount balance after suspend/resumeRafael J. Wysocki
commit 2a99859932281ed6c2ecdd988855f8f6838f6743 upstream. Since cpufreq_cpu_put() called by __cpufreq_remove_dev() drops the driver module refcount, __cpufreq_remove_dev() causes that refcount to become negative for the cpufreq driver after a suspend/resume cycle. This is not the only bad thing that happens there, however, because kobject_put() should only be called for the policy kobject at this point if the CPU is not the last one for that policy. Namely, if the given CPU is the last one for that policy, the policy kobject's refcount should be 1 at this point, as set by cpufreq_add_dev_interface(), and only needs to be dropped once for the kobject to go away. This actually happens under the cpu == 1 check, so it need not be done before by cpufreq_cpu_put(). On the other hand, if the given CPU is not the last one for that policy, this means that cpufreq_add_policy_cpu() has been called at least once for that policy and cpufreq_cpu_get() has been called for it too. To balance that cpufreq_cpu_get(), we need to call cpufreq_cpu_put() in that case. Thus, to fix the described problem and keep the reference counters balanced in both cases, move the cpufreq_cpu_get() call in __cpufreq_remove_dev() to the code path executed only for CPUs that share the policy with other CPUs. Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11Revert "cpuidle: Quickly notice prediction failure in general case"Rafael J. Wysocki
commit 228b30234f258a193317874854eee1ca7807186e upstream. Revert commit e11538d1 (cpuidle: Quickly notice prediction failure in general case), since it depends on commit 69a37be (cpuidle: Quickly notice prediction failure for repeat mode) that has been identified as the source of a significant performance regression in v3.8 and later. Requested-by: Jeremy Eder <jeder@redhat.com> Tested-by: Len Brown <len.brown@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11ACPI / battery: Fix parsing _BIX return valueLan Tianyu
commit 016d5baad04269e8559332df05f89bd95b52d6ad upstream. The _BIX method returns extended battery info as a package. According the ACPI spec (ACPI 5, Section 10.2.2.2), the first member of that package should be "Revision". However, the current ACPI battery driver treats the first member as "Power Unit" which should be the second member. This causes the result of _BIX return data parsing to be incorrect. Fix this by adding a new member called 'revision' to struct acpi_battery and adding the offsetof() information on it to extended_info_offsets[] as the first row. [rjw: Changelog] Reported-and-tested-by: Jan Hoffmann <jan.christian.hoffmann@gmail.com> References: http://bugzilla.kernel.org/show_bug.cgi?id=60519 Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11zram: protect sysfs handler from invalid memory accessJiang Liu
commit 5863e10b441e7ea4b492f930f1be180a97d026f3 upstream. Use zram->init_lock to protect access to zram->meta, otherwise it may cause invalid memory access if zram->meta has been freed by zram_reset_device(). This issue may be triggered by: Thread 1: while true; do cat mem_used_total; done Thread 2: while true; do echo 8M > disksize; echo 1 > reset; done Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Acked-by: Minchan Kim <minchan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11zram: avoid access beyond the zram deviceJiang Liu
commit 12a7ad3b810e77137d0caf97a6dd97591e075b30 upstream. Function valid_io_request() should verify the entire request are within the zram device address range. Otherwise it may cause invalid memory access when accessing/modifying zram->meta->table[index] because the 'index' is out of range. Then it may access non-exist memory, randomly modify memory belong to other subsystems, which is hard to track down. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11zram: avoid double free in function zram_bvec_write()Jiang Liu
commit 65c484609a3b25c35e4edcd5f2c38f98f5226093 upstream. When doing a patial write and the whole page is filled with zero, zram_bvec_write() will free uncmem twice. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Acked-by: Minchan Kim <minchan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11zram: destroy all devices on error recovery path in zram_init()Jiang Liu
commit 39a9b8ac9333e4268ecff7da6c9d1ab3823ff243 upstream. On error recovery path of zram_init(), it leaks the zram device object causing the failure. So change create_device() to free allocated resources on error path. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Acked-by: Minchan Kim <minchan@kernel.org> Acked-by: Jerome Marchand <jmarchan@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11zram: use zram->lock to protect zram_free_page() in swap free notify pathJiang Liu
commit 57ab048532c0d975538cebd4456491b5c34248f4 upstream. zram_slot_free_notify() is free-running without any protection from concurrent operations. So there are race conditions between zram_bvec_read()/zram_bvec_write() and zram_slot_free_notify(), and possible consequences include: 1) Trigger BUG_ON(!handle) on zram_bvec_write() side. 2) Access to freed pages on zram_bvec_read() side. 3) Break some fields (bad_compress, good_compress, pages_stored) in zram->stats if the swap layer makes concurrently call to zram_slot_free_notify(). So enhance zram_slot_free_notify() to acquire writer lock on zram->lock before calling zram_free_page(). Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11zram: avoid invalid memory access in zram_exit()Jiang Liu
commit 6030ea9b35971a4200062f010341ab832e878ac9 upstream. Memory for zram->disk object may have already been freed after returning from destroy_device(zram), then it's unsafe for zram_reset_device(zram) to access zram->disk again. We can't solve this bug by flipping the order of destroy_device(zram) and zram_reset_device(zram), that will cause deadlock issues to the zram sysfs handler. So fix it by holding an extra reference to zram->disk before calling destroy_device(zram). Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11mwifiex: fix wrong data rates in P2P clientAvinash Patil
commit 237b2ac8ac89a6b0120decdd05c7bf4637deb98a upstream. This patch fixes an issue wherein adhoc rates were being copied into association request from P2P client. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Stone Piao <piaoyun@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11mwifiex: check for bss_role instead of bss_mode for STA operationsAvinash Patil
commit 953b3539ef9301b8ef73f4b6e2fd824b86aae65a upstream. This patch fixes an issue wherein association would fail on P2P interfaces. This happened because we are checking priv->mode against NL80211_IFTYPE_STATION. While this check is correct for infrastructure stations, it would fail P2P clients for which mode is NL80211_IFTYPE_P2P_CLIENT. Better check would be bss_role which has only 2 values: STA/AP. Signed-off-by: Avinash Patil <patila@marvell.com> Signed-off-by: Stone Piao <piaoyun@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11mwifiex: Add missing endian conversion.Tomasz Moń
commit 83e612f632c3897be29ef02e0472f6d63e258378 upstream. Both type and pkt_len variables are in host endian and these should be in Little Endian in the payload. Signed-off-by: Tomasz Moń <desowin@gmail.com> Acked-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11rt2x00: fix stop queueStanislaw Gruszka
commit e2288b66fe7ff0288382b2af671b4da558b44472 upstream. Since we clear QUEUE_STARTED in rt2x00queue_stop_queue(), following call to rt2x00queue_pause_queue() reduce to noop, i.e we do not stop queue in mac80211. To fix that introduce rt2x00queue_pause_queue_nocheck() function, which will stop queue in mac80211 directly. Note that rt2x00_start_queue() explicitly set QUEUE_PAUSED bit. Note also that reordering operations i.e. first call to rt2x00queue_pause_queue() and then clear QUEUE_STARTED bit, will race with rt2x00queue_unpause_queue(), so calling ieee80211_stop_queue() directly is the only available solution to fix the problem without major rework. Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11Bluetooth: fix wrong use of PTR_ERR() in btusbAdam Lee
commit d9c78e9738ccd0017b10b8f44462aafb61904a4a upstream. PTR_ERR() returns a signed long type value which is limited by IS_ERR(), it must be a negative number whose range is [-MAX_ERRNO, 0). The bug here returns negative numbers as error codes, then check it by "if (ret < 0)", but -PTR_ERR() is actually positive. The wrong use here leads to failure as below, even panic. [ 12.958920] Bluetooth: hci0 command 0xfc8e tx timeout [ 14.961765] Bluetooth: hci0 command 0xfc8e tx timeout [ 16.964688] Bluetooth: hci0 command 0xfc8e tx timeout [ 20.954501] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110) [ 22.957358] Bluetooth: hci0 command 0xfc8e tx timeout [ 30.948922] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110) [ 32.951780] Bluetooth: hci0 command 0xfc8e tx timeout [ 40.943359] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110) [ 42.946219] Bluetooth: hci0 command 0xfc8e tx timeout [ 50.937812] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110) [ 52.940670] Bluetooth: hci0 command 0xfc8e tx timeout [ 60.932236] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110) [ 62.935092] Bluetooth: hci0 command 0xfc8e tx timeout [ 70.926688] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110) [ 72.929545] Bluetooth: hci0 command 0xfc8e tx timeout [ 80.921111] Bluetooth: hci0 sending Intel patch command (0xfc8e) failed (-110) [ 82.923969] Bluetooth: hci0 command 0xfc2f tx timeout [ 90.915542] Bluetooth: hci0 sending Intel patch command (0xfc2f) failed (-110) [ 92.918406] Bluetooth: hci0 command 0xfc11 tx timeout [ 100.909955] Bluetooth: hci0 sending Intel patch command (0xfc11) failed (-110) [ 102.912858] Bluetooth: hci0 command 0xfc60 tx timeout [ 110.904394] Bluetooth: hci0 sending Intel patch command (0xfc60) failed (-110) [ 112.907293] Bluetooth: hci0 command 0xfc11 tx timeout [ 120.898831] Bluetooth: hci0 exiting Intel manufacturer mode failed (-110) [ 120.904757] bluetoothd[1030]: segfault at 4 ip 00007f8b2eb55236 sp 00007fff53ff6920 error 4 in bluetoothd[7f8b2eaff000+cb000] Signed-off-by: Adam Lee <adam.lee@canonical.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11Bluetooth: Add support for Mediatek Bluetooth device [0e8d:763f]Cho, Yu-Chen
commit 178c059e7640aa8e50213400c6f3dde00189d979 upstream. This patch adds support for Mediatek Bluetooth device T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.01 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0e8d ProdID=763f Rev= 1.00 S: Manufacturer=MediaTek S: Product=BT S: SerialNumber=1.0 C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=450mA A: FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=ff Prot=ff I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=125us E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms Signed-off-by: Cho, Yu-Chen <acho@suse.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11Bluetooth: Add support for Atheros [0cf3:e003]AceLan Kao
commit 1d5b569ef85d013a775560a90050dc630614c045 upstream. Add support for the AR9462 chip T: Bus=02 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=e003 Rev=00.02 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11Bluetooth: Add support for Atheros [0cf3:3121]AceLan Kao
commit 1ebd0b21ab14efb75950079840eac29afea2a26e upstream. Add support for the AR3012 chip. T: Bus=03 Lev=01 Prnt=01 Port=06 Cnt=01 Dev#= 6 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=3121 Rev=00.02 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11Bluetooth: ath3k: Add support for ID 0x13d3/0x3402Sujith Manoharan
commit 5b77a1f3d7b7360dc2b7c6d2188d39b9f8432907 upstream. T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3402 Rev= 0.02 S: Manufacturer=Atheros Communications S: Product=Bluetooth USB Host Controller S: SerialNumber=Alaska Day 2006 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Bug: https://bugzilla.kernel.org/show_bug.cgi?id=59701 Signed-off-by: Sujith Manoharan <sujith@msujith.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11Bluetooth: ath3k: don't use stack memory for DMAStanislaw Gruszka
commit 517828a87994f41af6ae5a0f96f0f069f05baa81 upstream. Memory allocated by vmalloc (including stack) can not be used for DMA, i.e. data pointer on usb_control_msg() should not point to stack memory. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=977558 Reported-and-tested-by: Andy Lawrence <dr.diesel@gmail.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11Bluetooth: ath3k: Add support for Fujitsu Lifebook UH5x2 [04c5:1330]Thomas Loo
commit 84eb2ae1807dd1467bf6f500fc69ae61f1907b75 upstream. The Fujitsu Lifebook UH552/UH572 ships with a Qualcomm AR9462/AR3012 WLAN/BT-Combo card. Add device ID to the ath3k driver to enable the bluetooth side of things. Patch against v3.10. T: Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04c5 ProdID=1330 Rev=00.02 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by: Thomas Loo <tloo@saltstorm.net> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11ath: wil6210: Fix build errorLarry Finger
commit 5d21608a592a9afcac8d82c6478a564e911ce70b upstream. Building driver wil6210 in 3.10 and 3.11 kernels yields the following errors: CC [M] drivers/net/wireless/ath/wil6210/debugfs.o drivers/net/wireless/ath/wil6210/debugfs.c: In function 'wil_print_ring': drivers/net/wireless/ath/wil6210/debugfs.c:163:11: error: pointer targets in passing argument 5 of 'hex_dump_to_buffer' differ in signedness [-Werror=pointer-sign] false); ^ In file included from include/linux/kernel.h:13:0, from include/linux/cache.h:4, from include/linux/time.h:4, from include/linux/stat.h:18, from include/linux/module.h:10, from drivers/net/wireless/ath/wil6210/debugfs.c:17: include/linux/printk.h:361:13: note: expected 'char *' but argument is of type 'unsigned char *' extern void hex_dump_to_buffer(const void *buf, size_t len, ^ drivers/net/wireless/ath/wil6210/debugfs.c: In function 'wil_txdesc_debugfs_show': drivers/net/wireless/ath/wil6210/debugfs.c:429:10: error: pointer targets in passing argument 5 of 'hex_dump_to_buffer' differ in signedness [-Werror=pointer-sign] sizeof(printbuf), false); ^ In file included from include/linux/kernel.h:13:0, from include/linux/cache.h:4, from include/linux/time.h:4, from include/linux/stat.h:18, from include/linux/module.h:10, from drivers/net/wireless/ath/wil6210/debugfs.c:17: include/linux/printk.h:361:13: note: expected 'char *' but argument is of type 'unsigned char *' extern void hex_dump_to_buffer(const void *buf, size_t len, ^ cc1: all warnings being treated as errors make[5]: *** [drivers/net/wireless/ath/wil6210/debugfs.o] Error 1 make[4]: *** [drivers/net/wireless/ath/wil6210] Error 2 make[3]: *** [drivers/net/wireless/ath] Error 2 make[2]: *** [drivers/net/wireless] Error 2 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 These errors are fixed by changing the type of the buffer from "unsigned char *" to "char *". Reported-by: Thomas Fjellstrom <thomas@fjellstrom.ca> Tested-by: Thomas Fjellstrom <thomas@fjellstrom.ca> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Thomas Fjellstrom <thomas@fjellstrom.ca> Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11ixgbe: Fix Tx Hang issue with lldpad on 82598EBJacob Keller
commit 1eb9ac14c34a948bf1538bfb9034e8ab29099a64 upstream. This patch fixes an issue with the 82598EB device, where lldpad is causing Tx Hangs on the card as soon as it attempts to configure DCB for the device. The adapter will continually Tx hang and reset in a loop. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Tested-by: Jack Morgan <jack.morgan@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11ath9k_htc: reboot firmware if it was loadedOleksij Rempel
commit 4928bd2ef8ece262f4f314630219999a91eaa440 upstream. Currently ath9k_htc will reboot firmware only if interface was ever started. Which lead to the problem in case where interface was never started but module need to be reloaded. This patch will partially fix bug "ath9k_htc: Target is unresponsive" https://github.com/qca/open-ath9k-htc-firmware/issues/1 Reproduction case: - plug adapter - make sure nothing will touch it. Stop Networkmanager or blacklist mac address of this adapter. - rmmod ath9k_htc; sleep 1; modprobe ath9k_htc Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11ath9k_htc: do some initial hardware configurationOleksij Rempel
commit dc2a87f519a4d8cb376ab54f22b6b98a943b51ce upstream. Currently we configure harwdare and clock, only after interface start. In this case, if we reload module or reboot PC without configuring adapter, firmware will freeze. There is no software way to reset adpter. This patch add initial configuration and set it in disabled state, to avoid this freeze. Behaviour of this patch should be similar to: ifconfig wlan0 up; ifconfig wlan0 down. Bug: https://github.com/qca/open-ath9k-htc-firmware/issues/1 Tested-by: Bo Shi <cnshibo@gmail.com> Signed-off-by: Oleksij Rempel <linux@rempel-privat.de> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11iwlwifi: mvm: fix flushing not started aggregation sessionsJohannes Berg
commit b6658ff80c43bcf84be0bbe371c88af1452e7776 upstream. When a not fully started aggregation session is destroyed and flushed, we get a warning, e.g. WARNING: at drivers/net/wireless/iwlwifi/pcie/tx.c:1142 iwl_trans_pcie_txq_disable+0x11c/0x160 queue 16 not used Modules linked in: [...] Pid: 5135, comm: hostapd Tainted: G W O 3.5.0 #10 Call Trace: wlan0: driver sets block=0 for sta 00:03:7f:10:44:d3 [<ffffffff81036492>] warn_slowpath_common+0x72/0xa0 [<ffffffff81036577>] warn_slowpath_fmt+0x47/0x50 [<ffffffffa0368d6c>] iwl_trans_pcie_txq_disable+0x11c/0x160 [iwlwifi] [<ffffffffa03a2099>] iwl_mvm_sta_tx_agg_flush+0xe9/0x150 [iwlmvm] [<ffffffffa0396c43>] iwl_mvm_mac_ampdu_action+0xf3/0x1e0 [iwlmvm] [<ffffffffa0293ad3>] ___ieee80211_stop_tx_ba_session+0x193/0x920 [mac80211] [<ffffffffa0294ed8>] __ieee80211_stop_tx_ba_session+0x48/0x70 [mac80211] [<ffffffffa029159f>] ieee80211_sta_tear_down_BA_sessions+0x4f/0x80 [mac80211] [<ffffffffa028a686>] __sta_info_destroy+0x66/0x370 [mac80211] [<ffffffffa028abb4>] sta_info_destroy_addr_bss+0x44/0x70 [mac80211] [<ffffffffa02a3e26>] ieee80211_del_station+0x26/0x50 [mac80211] [<ffffffffa01e6395>] nl80211_del_station+0x85/0x200 [cfg80211] when a station deauthenticated from us without fully setting up the aggregation session. Fix this by checking the aggregation state before removing the hardware queue. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11iwlwifi: add DELL SKU for 5150 HMCEmmanuel Grumbach
commit a1923f1d4723e5757cefdd60f7c7ab30e472007a upstream. This SKU was missing in the list of supported devices https://bugzilla.kernel.org/show_bug.cgi?id=60577 Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11iwlwifi: mvm: refuse connection to APs with BI < 16Johannes Berg
commit 48bc13072109ea58465542aa1ee31b4e1065468a upstream. Due to a firmware bug, it crashes when the beacon interval is smaller than 16. Avoid this by refusing the station state change creating the AP station, causing mac80211 to abandon the attempt to connect to the AP, and eventually wpa_s to blacklist it. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11iwlwifi: mvm: fix bug in scan ssidDavid Spinadel
commit fe04e83706037802c502ea41c0d1799ec35fc0d7 upstream. Increment index in each iteration. Without this increment we are overriding the added SSIDs and we will send only the last SSId and (n_ssids - 1) broadcast probes. Signed-off-by: David Spinadel <david.spinadel@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11iwlwifi: mvm: fix L2P BA ressources leakEmmanuel Grumbach
commit 93a426673fbfeae7fa6b27008828e2ac4c08dbee upstream. We didn't release the Rx AMPDU ressources properly. This bug led to firmware assert after 16 BA sessions. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11USB: mos7840: fix pointer castsJohan Hovold
commit 683a0e4d7971c3186dc4d429027debfe309129aa upstream. Silence compiler warnings on 64-bit systems introduced by commit 05cf0dec ("USB: mos7840: fix race in led handling") which uses the usb-serial data pointer to temporarily store the device type during probe but failed to add the required casts. [gregkh - change uintptr_t to unsigned long] Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11USB: mos7840: fix race in led handlingJohan Hovold
commit 05cf0dec5ccc696a7636c84b265b477173498156 upstream. Fix race in LED handling introduced by commit 0eafe4de ("USB: serial: mos7840: add support for MCS7810 devices") which reused the port control urb for manipulating the LED without making sure that the urb is not already in use. This could lead to the control urb being manipulated while in flight. Fix by adding a dedicated LED urb and ctrlrequest along with a LED-busy flag to handle concurrency. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11USB: mos7840: fix device-type detectionJohan Hovold
commit 40c24f2893ba0ba7df485871f6aac0c197ceef5b upstream. Fix race in device-type detection introduced by commit 0eafe4de ("USB: serial: mos7840: add support for MCS7810 devices") which used a static variable to hold the device type. Move type detection to probe and use serial data to store the device type. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11USB: mos7840: fix race in register handlingJohan Hovold
commit d8a083cc746664916d9d36ed9e4d08a29525f245 upstream. Fix race in mos7840_get_reg which unconditionally manipulated the control urb (which may already be in use) by adding a control-urb busy flag. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11dma: pl330: Fix cyclic transfersLars-Peter Clausen
commit fc51446021f42aca8906e701fc2292965aafcb15 upstream. Allocate a descriptor for each period of a cyclic transfer, not just the first. Also since the callback needs to be called for each finished period make sure to initialize the callback and callback_param fields of each descriptor in a cyclic transfer. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11serial/mxs-auart: increase time to wait for transmitter to become idleUwe Kleine-König
commit 079a036f4283e2b0e5c26080b8c5112bc0cc1831 upstream. Without this patch the driver waits ~1 ms for the UART to become idle. At 115200n8 this time is (theoretically) enough to transfer 11.5 characters (= 115200 bits/s / (10 Bits/char) * 1ms). As the mxs-auart has a fifo size of 16 characters the clock is gated too early. The problem is worse for lower baud rates. This only happens to really shut down the transmitter in the middle of a transfer if /dev/ttyAPPx isn't opened in userspace (e.g. by a getty) but was at least once (because the bootloader doesn't disable the transmitter). So increase the timeout to 20 ms which should be enough for 9600n8, too. Moreover skip gating the clock if the timeout is elapsed. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11serial: arc_uart: Fix module aliasAxel Lin
commit d5a12ea7a9e58d9e5c19d25cb668aadb396423ec upstream. Platform drivers use "platform:" prefix in module alias. Also use DRIVER_NAME in MODULE_ALIAS to make module autoloading work. Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Vineet Gupta <vgupta@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11serial/mxs-auart: fix race condition in interrupt handlerUwe Kleine-König
commit d970d7fe65adff5efe75b4a73c4ffc9be57089f7 upstream. The handler needs to ack the pending events before actually handling them. Otherwise a new event might come in after it it considered non-pending or handled and is acked then without being handled. So this event is only noticed when the next interrupt happens. Without this patch an i.MX28 based machine running an rt-patched kernel regularly hangs during boot. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11hwmon: (max6697) fix MAX6581 idealityVivien Didelot
commit 5c52add19733eb36d8619713312f5604efef3502 upstream. Without this patch, the values for ideality (register 0x4b) and ideality selection mask (register 0x4c) are inverted. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11parisc: Fix interrupt routing for C8000 serial portsThomas Bogendoerfer
commit dd5e6d6a3db09b16b7c222943977865eead88cc3 upstream. We can't use dev->mod_index for selecting the interrupt routing entry, because it's not an index into interrupt routing table. It will be even wrong on a machine with 2 CPUs (4 cores). But all needed information is contained in the PAT entries for the serial ports. mod[0] contains the iosapic address and mod_info has some indications for the interrupt input (at least it looks like it). This patch implements the searching for the right iosapic and uses this interrupt input information. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11parisc: agp/parisc-agp: allow binding of user memory to the AGP GARTAlex Ivanov
commit 06f0cce43a32bd2357cea1d8733bba48693d556b upstream. Allow binding of user memory to the AGP GART on systems with HP Quicksilver AGP bus. This resolves 'bind memory failed' error seen in dmesg: [29.365973] [TTM] AGP Bind memory failed. … [29.367030] [drm] Forcing AGP to PCI mode The system doesn't more fail to bind the memory, and hence not falling back to the PCI mode (if other failures aren't detected). This is just a simple write down from the following patches: agp/amd-k7: Allow binding user memory to the AGP GART agp/hp-agp: Allow binding user memory to the AGP GART Signed-off-by: Alex Ivanov <gnidorah@p0n4ik.tk> Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-11powerpc/windfarm: Fix noisy slots-fan on Xserve (rm31)Aaro Koskinen
commit fe956a1d4081ce1a959f87df397a15e252201f10 upstream. slots-fan on G5 Xserve is always running at full speed with windfarm_rm31 driver, resulting in a very high acoustic noise level. It seems the fan parameters are incorrect, and have been copied from the Drive Bay fan (RPM, not present on rm31) of the legacy therm_pm72 driver. This patch changes the parameters to match the Slots fan (PWM) of therm_pm72. With the patch, slots-fan speed drops from 99% to 19% during normal use, and slots-temp settle to ~42'C. Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04drm/i915: Correct obj->mm_list link to dev_priv->dev_priv->mm.inactive_listXiong Zhang
commit 067556084a0e412013af6b0250a3143ae5afde6d upstream. obj->mm_list link to dev_priv->mm.inactive_list/active_list obj->global_list link to dev_priv->mm.unbound_list/bound_list This regression has been introduced in commit 93927ca52a55c23e0a6a305e7e9082e8411ac9fa Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Jan 10 18:03:00 2013 +0100 drm/i915: Revert shrinker changes from "Track unbound pages" Cc: stable@vger.kernel.org Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com> [danvet: Add regression notice.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Zhouping Liu <zliu@redhat.com>
2013-08-04iscsi-target: Fix iscsit_sequence_cmd reject handling for iserNicholas Bellinger
commit 561bf15892375597ee59d473a704a3e634c4f311 upstream This patch moves ISCSI_OP_REJECT failures into iscsit_sequence_cmd() in order to avoid external iscsit_reject_cmd() reject usage for all PDU types. It also updates PDU specific handlers for traditional iscsi-target code to not reset the session after posting a ISCSI_OP_REJECT during setup. (v2: Fix CMDSN_LOWER_THAN_EXP for ISCSI_OP_SCSI to call target_put_sess_cmd() after iscsit_sequence_cmd() failure) Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Cc: Or Gerlitz <ogerlitz@mellanox.com> Cc: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04iscsi-target: Fix iscsit_add_reject* usage for iserNicholas Bellinger
commit ba159914086f06532079fc15141f46ffe7e04a41 upstream This patch changes iscsit_add_reject() + iscsit_add_reject_from_cmd() usage to not sleep on iscsi_cmd->reject_comp to address a free-after-use usage bug in v3.10 with iser-target code. It saves ->reject_reason for use within iscsit_build_reject() so the correct value for both transport cases. It also drops the legacy fail_conn parameter usage throughput iscsi-target code and adds two iscsit_add_reject_cmd() and iscsit_reject_cmd helper functions, along with various small cleanups. (v2: Re-enable target_put_sess_cmd() to be called from iscsit_add_reject_from_cmd() for rejects invoked after target_get_sess_cmd() has been called) Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Cc: Or Gerlitz <ogerlitz@mellanox.com> Cc: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04radeon kms: do not flush uninitialized hotplug workSergey Senozhatsky
commit a01c34f72e7cd2624570818f579b5ab464f93de2 upstream. Fix a warning from lockdep caused by calling flush_work() for uninitialized hotplug work. Initialize hotplug_work, audio_work and reset_work upon successful radeon_irq_kms_init() completion and thus perform hotplug flush_work only when rdev->irq.installed is true. [ 4.790019] [drm] Loading CEDAR Microcode [ 4.790943] r600_cp: Failed to load firmware "radeon/CEDAR_smc.bin" [ 4.791152] [drm:evergreen_startup] *ERROR* Failed to load firmware! [ 4.791330] radeon 0000:01:00.0: disabling GPU acceleration [ 4.792633] INFO: trying to register non-static key. [ 4.792792] the code is fine but needs lockdep annotation. [ 4.792953] turning off the locking correctness validator. [ 4.793114] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc0-dbg-10676-gfe56456-dirty #1816 [ 4.793314] Hardware name: Acer Aspire 5741G /Aspire 5741G , BIOS V1.20 02/08/2011 [ 4.793507] ffffffff821fd810 ffff8801530b9a18 ffffffff8160434e 0000000000000002 [ 4.794155] ffff8801530b9ad8 ffffffff810b8404 ffff8801530b0798 ffff8801530b0000 [ 4.794789] ffff8801530b9b00 0000000000000046 00000000000004c0 ffffffff00000000 [ 4.795418] Call Trace: [ 4.795573] [<ffffffff8160434e>] dump_stack+0x4e/0x82 [ 4.795731] [<ffffffff810b8404>] __lock_acquire+0x1a64/0x1d30 [ 4.795893] [<ffffffff814a87f0>] ? dev_vprintk_emit+0x50/0x60 [ 4.796034] [<ffffffff810b8fb4>] lock_acquire+0xa4/0x200 [ 4.796216] [<ffffffff8106cd75>] ? flush_work+0x5/0x280 [ 4.796375] [<ffffffff8106cdad>] flush_work+0x3d/0x280 [ 4.796520] [<ffffffff8106cd75>] ? flush_work+0x5/0x280 [ 4.796682] [<ffffffff810b659d>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [ 4.796862] [<ffffffff8131d775>] ? delay_tsc+0x95/0xf0 [ 4.797024] [<ffffffff8141bb8b>] radeon_irq_kms_fini+0x2b/0x70 [ 4.797186] [<ffffffff814557c9>] evergreen_init+0x2a9/0x2e0 [ 4.797347] [<ffffffff813ebb1f>] radeon_device_init+0x5ef/0x700 [ 4.797511] [<ffffffff81335bc7>] ? pci_find_capability+0x47/0x50 [ 4.797672] [<ffffffff813edaed>] radeon_driver_load_kms+0x8d/0x150 [ 4.797843] [<ffffffff813ce426>] drm_get_pci_dev+0x166/0x280 [ 4.798007] [<ffffffff8116cff5>] ? kfree+0xf5/0x2e0 [ 4.798168] [<ffffffff813ea298>] ? radeon_pci_probe+0x98/0xd0 [ 4.798329] [<ffffffff813ea2aa>] radeon_pci_probe+0xaa/0xd0 [ 4.798489] [<ffffffff81339404>] pci_device_probe+0x84/0xe0 [ 4.798644] [<ffffffff814ac7d6>] driver_probe_device+0x76/0x240 [ 4.798805] [<ffffffff814aca73>] __driver_attach+0x93/0xa0 [ 4.798948] [<ffffffff814ac9e0>] ? __device_attach+0x40/0x40 [ 4.799126] [<ffffffff814aa82b>] bus_for_each_dev+0x6b/0xb0 [ 4.799272] [<ffffffff814ac2be>] driver_attach+0x1e/0x20 [ 4.799434] [<ffffffff814abec0>] bus_add_driver+0x1f0/0x280 [ 4.799596] [<ffffffff814ad0e4>] driver_register+0x74/0x150 [ 4.799758] [<ffffffff8133923d>] __pci_register_driver+0x5d/0x60 [ 4.799936] [<ffffffff81d16efc>] ? ttm_init+0x67/0x67 [ 4.800081] [<ffffffff813ce655>] drm_pci_init+0x115/0x130 [ 4.800243] [<ffffffff81d16efc>] ? ttm_init+0x67/0x67 [ 4.800405] [<ffffffff81d16f98>] radeon_init+0x9c/0xba [ 4.800586] [<ffffffff810002ca>] do_one_initcall+0xfa/0x150 [ 4.800746] [<ffffffff81073f60>] ? parse_args+0x120/0x330 [ 4.800909] [<ffffffff81cdafae>] kernel_init_freeable+0x111/0x191 [ 4.801052] [<ffffffff81cda87a>] ? do_early_param+0x88/0x88 [ 4.801233] [<ffffffff815fb670>] ? rest_init+0x140/0x140 [ 4.801393] [<ffffffff815fb67e>] kernel_init+0xe/0x180 [ 4.801556] [<ffffffff8160dcac>] ret_from_fork+0x7c/0xb0 [ 4.801718] [<ffffffff815fb670>] ? rest_init+0x140/0x140 Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04xen/evtchn: avoid a deadlock when unbinding an event channelDavid Vrabel
commit 179fbd5a45f0d4034cc6fd37b8d367a3b79663c4 upstream. Unbinding an event channel (either with the ioctl or when the evtchn device is closed) may deadlock because disable_irq() is called with port_user_lock held which is also locked by the interrupt handler. Think of the IOCTL_EVTCHN_UNBIND is being serviced, the routine has just taken the lock, and an interrupt happens. The evtchn_interrupt is invoked, tries to take the lock and spins forever. A quick glance at the code shows that the spinlock is a local IRQ variant. Unfortunately that does not help as "disable_irq() waits for the interrupt handler on all CPUs to stop running. If the irq occurs on another VCPU, it tries to take port_user_lock and can't because the unbind ioctl is holding it." (from David). Hence we cannot depend on the said spinlock to protect us. We could make it a system wide IRQ disable spinlock but there is a better way. We can piggyback on the fact that the existence of the spinlock is to make get_port_user() checks be up-to-date. And we can alter those checks to not depend on the spin lock (as it's protected by u->bind_mutex in the ioctl) and can remove the unnecessary locking (this is IOCTL_EVTCHN_UNBIND) path. In the interrupt handler we cannot use the mutex, but we do not need it. "The unbind disables the irq before making the port user stale, so when you clear it you are guaranteed that the interrupt handler that might use that port cannot be running." (from David). Hence this patch removes the spinlock usage on the teardown path and piggybacks on disable_irq happening before we muck with the get_port_user() data. This ensures that the interrupt handler will never run on stale data. Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> [v1: Expanded the commit description a bit] Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04tty_port: Fix refcounting leak in tty_port_tty_hangup()Gianluca Anzolin
commit 1d9e689c934bd5ecb0f273c6c65e0655c5cfee5f upstream. The function tty_port_tty_hangup() could leak a reference to the tty_struct: struct tty_struct *tty = tty_port_tty_get(port); if (tty && (!check_clocal || !C_CLOCAL(tty))) { tty_hangup(tty); tty_kref_put(tty); } If tty != NULL and the second condition is false we never call tty_kref_put and the reference is leaked. Fix by always calling tty_kref_put() which accepts a NULL argument. The patch fixes a regression introduced by commit aa27a094. Acked-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Gianluca Anzolin <gianluca@sottospazio.it> Acked-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04usb: gadget: udc-core: fix the typo of udc state attributeRong Wang
commit 1894870eb4240399fabc6f0cb8c6fff4e6edbe83 upstream. The name of udc state attribute file under sysfs is registered as "state", while usb_gadget_set_state take it as "status" when it's going to update. This patch fixes the typo. Signed-off-by: Rong Wang <Rong.Wang@csr.com> Signed-off-by: Barry Song <Baohua.Song@csr.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-08-04USB: serial: ftdi_sio: add more RT Systems ftdi devicesRick Farina (Zero_Chaos)
commit fed1f1ed90bce42ea010e2904cbc04e7b8304940 upstream. RT Systems makes many usb serial cables based on the ftdi_sio driver for programming various amateur radios. This patch is a full listing of their current product offerings and should allow these cables to all be recognized. Signed-off-by: Rick Farina (Zero_Chaos) <zerochaos@gentoo.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-30 15:15:42 +0000