- 06 9月, 2014 1 次提交
-
-
由 Pawel Moll 提交于
The function cleaning up an initialized event was called from the "event_del" handler, instead of being used as the "destroy" callback. In case of events group allocation this caused NULL pointer dereference (as events are added and deleted multiple times then). Fixed now. Signed-off-by: NPawel Moll <mail@pawelmoll.com> Signed-off-by: NKevin Hilman <khilman@linaro.org>
-
- 05 9月, 2014 2 次提交
-
-
由 Ben Skeggs 提交于
Fixes not being able to init fence subsystem when multiple boards are present. Reported-by: NIlia Mirkin <imirkin@alum.mit.edu> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Sergei Shtylyov 提交于
This reverts commit 150b8be3. The I2C core's per-adapter locks can't protect from IRQs, so the driver still needs a spinlock to protect the register accesses. Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com> Cc: stable@vger.kernel.org # 3.16+ Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 04 9月, 2014 3 次提交
-
-
由 Jiri Kosina 提交于
There is a following AB-BA dependency between cpu_hotplug.lock and cpuidle_lock: 1) cpu_hotplug.lock -> cpuidle_lock enable_nonboot_cpus() _cpu_up() cpu_hotplug_begin() LOCK(cpu_hotplug.lock) cpu_notify() ... acpi_processor_hotplug() cpuidle_pause_and_lock() LOCK(cpuidle_lock) 2) cpuidle_lock -> cpu_hotplug.lock acpi_os_execute_deferred() workqueue ... acpi_processor_cst_has_changed() cpuidle_pause_and_lock() LOCK(cpuidle_lock) get_online_cpus() LOCK(cpu_hotplug.lock) Fix this by reversing the order acpi_processor_cst_has_changed() does thigs -- let it first execute the protection against CPU hotplug by calling get_online_cpus() and obtain the cpuidle lock only after that (and perform the symmentric change when allowing CPUs hotplug again and dropping cpuidle lock). Spotted by lockdep. Signed-off-by: NJiri Kosina <jkosina@suse.cz> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Yasuaki Ishimatsu 提交于
The _SUN device indentification object is not guaranteed to return the same value every time it is executed, so we should not cache its return value, but rather execute it every time as needed. If it is cached, an incorrect stale value may be used in some situations. This issue was exposed by commit 202317a5 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace). Fix it by avoiding to cache the return value of _SUN. Fixes: 202317a5 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace) Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ [ rjw: Changelog ] Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Dan Carpenter 提交于
The current code just returns -EINVAL because mode can't be equal to both 1 and 2. Also this function is messy so I have cleaned it up: 1) Remove initializers like "int time = -1". Initializing variables to garbage values turns off GCC's uninitialized variable warnings so it can lead to bugs. 2) Use kstrtoint() instead of sscanf(). 3) Use SCI_KBD_MODE_FNZ and SCI_KBD_MODE_AUTO instead of magic numbers 1 and 2. 4) Don't check for "mode == -1" because that can't happen. 5) Preserve the error code from toshiba_kbd_illum_status_set(). Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
-
- 03 9月, 2014 6 次提交
-
-
由 Gabriele Mazzotta 提交于
It should have been removed with commit d1b68485 ("cpufreq / intel_pstate: Optimize intel_pstate_set_policy") Signed-off-by: NGabriele Mazzotta <gabriele.mzt@gmail.com> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Jacob Pan 提交于
Many CPUs do not support complete set of RAPL domains, as a result this detection failed message is very misleading and can be annoying. [ 5.082632] intel_rapl: RAPL domain core detection failed [ 5.088370] intel_rapl: RAPL domain uncore detection failed So lower the warning message to info and only print out the RAPL domains that are supported. Signed-off-by: NJacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Jason Baron 提交于
I've confirmed that monitoring the package power usage as well as setting power limits appear to be working as expected. Supports the package and dram domains. Tested aginst cpu: Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz Signed-off-by: NJason Baron <jbaron@akamai.com> Acked-by: NJacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Benjamin Tissoires 提交于
On the Toshiba Tecra Z40, after a suspend-to-disk, some FN hotkeys driven by toshiba_acpi are not functional. Calling the ACPI object ENAB on resume makes them back alive. Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: NMatthew Garrett <matthew.garrett@nebula.com> Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
-
由 Mathias Krause 提交于
This is a follow-up patch to commit 49458e83 ("ideapad-laptop: Constify DMI table and other r/o variables") to do what its commit message says. The actual commit differs from the patch posted at https://www.mail-archive.com/platform-driver-x86@vger.kernel.org/msg05340.html significantly, probably due to a bad merge conflict resolution. Fix up the mess and constify the DMI table for real and fix the bogus double-const of ideapad_rfk_data[]. Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NMathias Krause <minipli@googlemail.com> Cc: Matthew Garrett <matthew.garrett@nebula.com> Cc: Ike Panhc <ike.pan@canonical.com> Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
-
由 Jiri Kosina 提交于
This reverts commit 8b37e1be. It's broken as it changes led_blink_set() in a way that it can now sleep (while synchronously waiting for workqueue to be cancelled). That's a problem, because it's possible that this function gets called from atomic context (tpt_trig_timer() takes a readlock and thus disables preemption). This has been brought up 3 weeks ago already [1] but no proper fix has materialized, and I keep seeing the problem since 3.17-rc1. [1] https://lkml.org/lkml/2014/8/16/128 BUG: sleeping function called from invalid context at kernel/workqueue.c:2650 in_atomic(): 1, irqs_disabled(): 0, pid: 2335, name: wpa_supplicant 5 locks held by wpa_supplicant/2335: #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c7c92>] rtnl_lock+0x12/0x20 #1: (&wdev->mtx){+.+.+.}, at: [<ffffffffc06e649c>] cfg80211_mgd_wext_siwessid+0x5c/0x180 [cfg80211] #2: (&local->mtx){+.+.+.}, at: [<ffffffffc0817dea>] ieee80211_prep_connection+0x17a/0x9a0 [mac80211] #3: (&local->chanctx_mtx){+.+.+.}, at: [<ffffffffc08081ed>] ieee80211_vif_use_channel+0x5d/0x2a0 [mac80211] #4: (&trig->leddev_list_lock){.+.+..}, at: [<ffffffffc081e68c>] tpt_trig_timer+0xec/0x170 [mac80211] CPU: 0 PID: 2335 Comm: wpa_supplicant Not tainted 3.17.0-rc3 #1 Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 ffff8800360b5a50 ffff8800751f76d8 ffffffff8159e97f ffff8800360b5a30 ffff8800751f76e8 ffffffff810739a5 ffff8800751f77b0 ffffffff8106862f ffffffff810685d0 0aa2209200000000 ffff880000000004 ffff8800361c59d0 Call Trace: [<ffffffff8159e97f>] dump_stack+0x4d/0x66 [<ffffffff810739a5>] __might_sleep+0xe5/0x120 [<ffffffff8106862f>] flush_work+0x5f/0x270 [<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80 [<ffffffff810945ca>] ? mark_held_locks+0x6a/0x90 [<ffffffff81068a5f>] ? __cancel_work_timer+0x6f/0x100 [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100 [<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10 [<ffffffff8147cf3b>] led_blink_set+0x1b/0x40 [<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211] [<ffffffffc081ecdd>] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211] [<ffffffffc07e4278>] __ieee80211_recalc_idle+0x98/0x140 [mac80211] [<ffffffffc07e59ce>] ieee80211_idle_off+0xe/0x10 [mac80211] [<ffffffffc0804e5b>] ieee80211_add_chanctx+0x3b/0x220 [mac80211] [<ffffffffc08062e4>] ieee80211_new_chanctx+0x44/0xf0 [mac80211] [<ffffffffc080838a>] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211] [<ffffffffc0817df8>] ieee80211_prep_connection+0x188/0x9a0 [mac80211] [<ffffffffc081c246>] ieee80211_mgd_auth+0x256/0x2e0 [mac80211] [<ffffffffc07eab33>] ieee80211_auth+0x13/0x20 [mac80211] [<ffffffffc06cb006>] cfg80211_mlme_auth+0x106/0x270 [cfg80211] [<ffffffffc06ce085>] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211] [<ffffffffc06cf670>] cfg80211_connect+0x3f0/0x540 [cfg80211] [<ffffffffc06e6148>] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211] [<ffffffffc06e651e>] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211] [<ffffffffc06e36c0>] ? cfg80211_wext_giwessid+0x50/0x50 [cfg80211] [<ffffffffc06e36dd>] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211] [<ffffffff81584d0c>] ioctl_standard_iw_point+0x14c/0x3e0 [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff8158502a>] ioctl_standard_call+0x8a/0xd0 [<ffffffff81584fa0>] ? ioctl_standard_iw_point+0x3e0/0x3e0 [<ffffffff81584b76>] wireless_process_ioctl.constprop.10+0xb6/0x100 [<ffffffff8158521d>] wext_handle_ioctl+0x5d/0xb0 [<ffffffff814cfb29>] dev_ioctl+0x329/0x620 [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff8149c7f2>] sock_ioctl+0x142/0x2e0 [<ffffffff811b0140>] do_vfs_ioctl+0x300/0x520 [<ffffffff815a67fb>] ? sysret_check+0x1b/0x56 [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff811b03e1>] SyS_ioctl+0x81/0xa0 [<ffffffff815a67d6>] system_call_fastpath+0x1a/0x1f wlan0: send auth to 00:0b:6b:3c:8c:e4 (try 1/3) wlan0: authenticated wlan0: associate with 00:0b:6b:3c:8c:e4 (try 1/3) wlan0: RX AssocResp from 00:0b:6b:3c:8c:e4 (capab=0x431 status=0 aid=2) wlan0: associated IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready cfg80211: Calling CRDA for country: NA wlan0: Limiting TX power to 27 (27 - 0) dBm as advertised by 00:0b:6b:3c:8c:e4 ================================= [ INFO: inconsistent lock state ] 3.17.0-rc3 #1 Not tainted --------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes: ((&(&led_cdev->blink_work)->work)){+.?...}, at: [<ffffffff810685d0>] flush_work+0x0/0x270 {SOFTIRQ-ON-W} state was registered at: [<ffffffff81094dbe>] __lock_acquire+0x30e/0x1a30 [<ffffffff81096c81>] lock_acquire+0x91/0x110 [<ffffffff81068608>] flush_work+0x38/0x270 [<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100 [<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10 [<ffffffff8147cf3b>] led_blink_set+0x1b/0x40 [<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211] [<ffffffffc081ecdd>] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211] [<ffffffffc07e4278>] __ieee80211_recalc_idle+0x98/0x140 [mac80211] [<ffffffffc07e59ce>] ieee80211_idle_off+0xe/0x10 [mac80211] [<ffffffffc0804e5b>] ieee80211_add_chanctx+0x3b/0x220 [mac80211] [<ffffffffc08062e4>] ieee80211_new_chanctx+0x44/0xf0 [mac80211] [<ffffffffc080838a>] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211] [<ffffffffc0817df8>] ieee80211_prep_connection+0x188/0x9a0 [mac80211] [<ffffffffc081c246>] ieee80211_mgd_auth+0x256/0x2e0 [mac80211] [<ffffffffc07eab33>] ieee80211_auth+0x13/0x20 [mac80211] [<ffffffffc06cb006>] cfg80211_mlme_auth+0x106/0x270 [cfg80211] [<ffffffffc06ce085>] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211] [<ffffffffc06cf670>] cfg80211_connect+0x3f0/0x540 [cfg80211] [<ffffffffc06e6148>] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211] [<ffffffffc06e651e>] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211] [<ffffffffc06e36dd>] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211] [<ffffffff81584d0c>] ioctl_standard_iw_point+0x14c/0x3e0 [<ffffffff8158502a>] ioctl_standard_call+0x8a/0xd0 [<ffffffff81584b76>] wireless_process_ioctl.constprop.10+0xb6/0x100 [<ffffffff8158521d>] wext_handle_ioctl+0x5d/0xb0 [<ffffffff814cfb29>] dev_ioctl+0x329/0x620 [<ffffffff8149c7f2>] sock_ioctl+0x142/0x2e0 [<ffffffff811b0140>] do_vfs_ioctl+0x300/0x520 [<ffffffff811b03e1>] SyS_ioctl+0x81/0xa0 [<ffffffff815a67d6>] system_call_fastpath+0x1a/0x1f irq event stamp: 493416 hardirqs last enabled at (493416): [<ffffffff81068a5f>] __cancel_work_timer+0x6f/0x100 hardirqs last disabled at (493415): [<ffffffff81067e9f>] try_to_grab_pending+0x1f/0x160 softirqs last enabled at (493408): [<ffffffff81053ced>] _local_bh_enable+0x1d/0x50 softirqs last disabled at (493409): [<ffffffff81054c75>] irq_exit+0xa5/0xb0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock((&(&led_cdev->blink_work)->work)); <Interrupt> lock((&(&led_cdev->blink_work)->work)); *** DEADLOCK *** 2 locks held by swapper/0/0: #0: (((&tpt_trig->timer))){+.-...}, at: [<ffffffff810b4c50>] call_timer_fn+0x0/0x180 #1: (&trig->leddev_list_lock){.+.?..}, at: [<ffffffffc081e68c>] tpt_trig_timer+0xec/0x170 [mac80211] stack backtrace: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.0-rc3 #1 Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 ffffffff8246eb30 ffff88007c203b00 ffffffff8159e97f ffffffff81a194c0 ffff88007c203b50 ffffffff81599c29 0000000000000001 ffffffff00000001 ffff880000000000 0000000000000006 ffffffff81a194c0 ffffffff81093ad0 Call Trace: <IRQ> [<ffffffff8159e97f>] dump_stack+0x4d/0x66 [<ffffffff81599c29>] print_usage_bug+0x1f4/0x205 [<ffffffff81093ad0>] ? check_usage_backwards+0x140/0x140 [<ffffffff810944d3>] mark_lock+0x223/0x2b0 [<ffffffff81094d60>] __lock_acquire+0x2b0/0x1a30 [<ffffffff81096c81>] lock_acquire+0x91/0x110 [<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80 [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [<ffffffff81068608>] flush_work+0x38/0x270 [<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80 [<ffffffff810945ca>] ? mark_held_locks+0x6a/0x90 [<ffffffff81068a5f>] ? __cancel_work_timer+0x6f/0x100 [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [<ffffffff8109469d>] ? trace_hardirqs_on_caller+0xad/0x1c0 [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100 [<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10 [<ffffffff8147cf3b>] led_blink_set+0x1b/0x40 [<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211] [<ffffffff810b4cc5>] call_timer_fn+0x75/0x180 [<ffffffff810b4c50>] ? process_timeout+0x10/0x10 [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [<ffffffff810b50ac>] run_timer_softirq+0x1fc/0x2f0 [<ffffffff81054805>] __do_softirq+0x115/0x2e0 [<ffffffff81054c75>] irq_exit+0xa5/0xb0 [<ffffffff810049b3>] do_IRQ+0x53/0xf0 [<ffffffff815a74af>] common_interrupt+0x6f/0x6f <EOI> [<ffffffff8147b56e>] ? cpuidle_enter_state+0x6e/0x180 [<ffffffff8147b732>] cpuidle_enter+0x12/0x20 [<ffffffff8108bba0>] cpu_startup_entry+0x330/0x360 [<ffffffff8158fb51>] rest_init+0xc1/0xd0 [<ffffffff8158fa90>] ? csum_partial_copy_generic+0x170/0x170 [<ffffffff81af3ff2>] start_kernel+0x44f/0x45a [<ffffffff81af399c>] ? set_init_arg+0x53/0x53 [<ffffffff81af35ad>] x86_64_start_reservations+0x2a/0x2c [<ffffffff81af36a0>] x86_64_start_kernel+0xf1/0xf4 Cc: Vincent Donnefort <vdonnefort@gmail.com> Cc: Hugh Dickins <hughd@google.com> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: NJiri Kosina <jkosina@suse.cz> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
- 02 9月, 2014 11 次提交
-
-
由 Marek Roszko 提交于
The driver was not bound checking the received length byte to ensure it was within the the buffer size that is allocated for SMBus blocks. This resulted in buffer overflows whenever an invalid length byte was received. It also failed to ensure the length byte was not zero. If it received zero, it would end up in an infinite loop as the at91_twi_read_next_byte function returned immediately without allowing RHR to be read to clear the RXRDY interrupt. Tested agaisnt a SMBus compliant battery. Signed-off-by: NMarek Roszko <mark.roszko@gmail.com> Acked-by: NLudovic Desroches <ludovic.desroches@atmel.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
-
由 addy ke 提交于
In rk3x SOC, the I2C controller can receive/transmit up to 32 bytes data in one chunk, so the size of data to be write/read to/from TXDATAx/RXDATAx must be less than or equal 32 bytes at a time. Tested on rk3288-pinky board, elan receive 158 bytes data. Signed-off-by: NAddy Ke <addy.ke@rock-chips.com> Acked-by: NMax Schwarz <max.schwarz@online.de> Reviewed-by: NDoug Anderson <dianders@chromium.org> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
-
由 Simon Lindgren 提交于
There is a race condition in at91_do_twi_xfer when signals arrive. If a signal is recieved while waiting for a transfer to complete wait_for_completion_interruptible_timeout() will return -ERESTARTSYS. This is not handled correctly resulting in interrupts still being enabled and a transfer being in flight when we return. Symptoms include a range of oopses and bus lockups. Oopses can happen when the transfer completes because the interrupt handler will corrupt the stack. If a new transfer is started before the interrupt fires the controller will start a new transfer in the middle of the old one, resulting in confused slaves and a locked bus. To avoid this, use wait_for_completion_io_timeout instead so that we don't have to deal with gracefully shutting down the transfer and disabling the interrupts. Signed-off-by: NSimon Lindgren <simon@aqwary.com> Acked-by: NLudovic Desroches <ludovic.desroches@atmel.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
-
由 Chen-Yu Tsai 提交于
The "clock-frequency" DT property is listed as optional, However, the current code stores the return value of of_property_read_u32 in the return code of mv64xxx_of_config, but then forgets to clear it after setting the default value of "clock-frequency". It is then passed out to the main probe function, resulting in a probe failure when "clock-frequency" is missing. This patch checks and then throws away the return value of of_property_read_u32, instead of storing it and having to clear it afterwards. This issue was discovered after the property was removed from all sunxi DTs. Fixes: 4c730a06 ("i2c: mv64xxx: Set bus frequency to 100kHz if clock-frequency is not provided") Signed-off-by: NChen-Yu Tsai <wens@csie.org> Cc: stable@vger.kernel.org Acked-by: NAndrew Lunn <andrew@lunn.ch> Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Sergei Shtylyov 提交于
Sometimes the MNR and MST interrupts happen simultaneously (stop automatically follows NACK, according to the manuals) and in such case the ID_NACK flag isn't set since the MST interrupt handling precedes MNR and all interrupts are cleared and disabled then, so that MNR interrupt is never noticed -- this causes NACK'ed transfers to be falsely reported as successful. Exchanging MNR and MST handlers fixes this issue, however the MNR bit somehow gets set again even after being explicitly cleared, so I decided to completely suppress handling of all disabled interrupts (which is a good thing anyway)... Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com> Cc: stable@vger.kernel.org Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Ville Syrjälä 提交于
When intel_tv_detect() fails to do load detection it would forget to drop the locks and clean up the acquire context. Fix it up. This is a regression from: commit 208bf9fd Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Aug 11 13:15:35 2014 +0300 drm/i915: Fix locking for intel_enable_pipe_a() v2: Make the code more readable (Chris) v3: Drop WARN_ON(type < 0) (Chris) Cc: stable@vger.kernel.org Cc: Tibor Billes <tbilles@gmx.com> Reported-by: NTibor Billes <tbilles@gmx.com> Tested-by: NTibor Billes <tbilles@gmx.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Lan Tianyu 提交于
Clevo W350etq's EC will not produce GPE interrupt some time after booting. The ACPI notify event won't trigger when the issue takes place. After debugging, adding msi quirk for the machine can fix the issue. This patch is to add msi quirk for the machine. Link: https://bugzilla.kernel.org/show_bug.cgi?id=77431 Reported-and-tested-by: qbanin@gmail.com Signed-off-by: NLan Tianyu <tianyu.lan@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Hans de Goede 提交于
Link: https://bugs.freedesktop.org/show_bug.cgi?id=81515Reported-and-tested-by: NHohahiu <rakothedin@gmail.com> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Hans de Goede 提交于
Some laptops have a working acpi_video backlight control, and using native backlight on these causes a regression where backlight control does not work when userspace is not handling brightness key events. Disable native_backlight on these to fix this. Link: https://bugzilla.kernel.org/show_bug.cgi?id=81691Reported-and-tested-by: NAndre Müller <andre.muller@web.de> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Hans de Goede 提交于
Commit 751109aa ("ACPI / video: Change the default for video.use_native_backlight to 1") has changed the default for use_native_backlight from 0 to 1, but instead of changing use_native_backlight_dmi to true, and leaving use_native_backlight_param at -1, it has changed use_native_backlight_param to 1. This causes acpi_video_use_native_backlight() to always think that a value was specified through the param, making it impossible to add a dmi based quirk to force 0 now that the default is 1. This fixes this by restoring the use_native_backlight_param default to -1, and instead setting the use_native_backlight_dmi default to true. Fixes: 751109aa (ACPI / video: Change the default for video.use_native_backlight to 1) Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Mika Westerberg 提交于
Adds ACPICA kernel runtime support to validate contents/format of the _DSD package, similar to the iASL support. Ported by Mika Westerberg. Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NBob Moore <robert.moore@intel.com> Signed-off-by: NLv Zheng <lv.zheng@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 01 9月, 2014 3 次提交
-
-
由 Dave Airlie 提交于
In the HPD pulse handler we check for long pulses if the port is actually connected, however we do that for IBX, but we use the pulse handling code on GM45 systems as well, so we need to use a diffent check. This patch refactors the digital port connected check out of the g4x detection path and reuses it in the hpd pulse path. Fixes: http://lkml.kernel.org/r/1409382202.5141.36.camel@marge.simpson.netReported-by: NMike Galbraith <umgwanakikbuti@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Acked-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Thomas Hellstrom 提交于
The code waiting for fifo idle was incorrect and could possibly spin forever under certain circumstances. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reported-by: NMark Sheldon <markshel@vmware.com> Reviewed-by: NJakob Bornecrantz <jakob@vmware.com> Reivewed-by: NMark Sheldon <markshel@vmware.com> Cc: <stable@vger.kernel.org>
-
由 Thomas Hellstrom 提交于
At the same time, make error paths return early for clarity. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Njakob Bornecrantz <jakob@vmware.com> Cc: <stable@vger.kernel.org>
-
- 31 8月, 2014 2 次提交
-
-
由 Geert Uytterhoeven 提交于
Fix tx/rx mixup, which broke transmit-only transfers. Introduced by commit 4240305f7cbdc7782aa8bc40cc702775d9ac0839 ("spi: sh-msiof: Fix leaking of unused DMA descriptors"). Reported-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be> Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NMark Brown <broonie@linaro.org>
-
由 Mark Brown 提交于
If the device can't support block writes then don't attempt to use raw syncing which will automatically generate block writes for adjacent registers, use the existing _single() block syncing implementation. Reported-by: NJarkko Nikula <jarkko.nikula@linux.intel.com> Tested-by: NJarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: NMark Brown <broonie@linaro.org> Cc: stable@vger.kernel.org
-
- 30 8月, 2014 2 次提交
-
-
The rtc-s5m driver used to support devices without irq specified in the past. Re-add this support. The patch fixes boot for Insignal's Exynos4412 based Origen board. Error messages before the patch: ... Unable to handle kernel NULL pointer dereference at virtual address 00000094 pgd = c0004000 [00000094] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.16.0-next-20140804-00008-ga59480f-dirty #701 task: ea80f000 ti: ea882000 task.ti: ea882000 PC is at regmap_irq_get_virq+0x0/0x28 LR is at s5m_rtc_probe+0xdc/0x310 pc : [<c02574fc>] lr : [<c02de75c>] psr: 80000153 sp : ea883e48 ip : 00000000 fp : 00000000 r10: 0000000c r9 : c05de7ac r8 : eaabc600 r7 : eaa6b4d0 r6 : c0439e8c r5 : eaabc610 r4 : eab30e50 r3 : 00000000 r2 : 00000000 r1 : 0000000c r0 : 00000000 Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 4000404a DAC: 00000015 Process swapper/0 (pid: 1, stack limit = 0xea882240) Backtrace: regmap_irq_get_virq s5m_rtc_probe platform_drv_probe driver_probe_device __driver_attach bus_for_each_dev bus_add_driver driver_register do_one_initcall kernel_init_freeable kernel_init ---[ end trace a954d7f019122700 ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ... Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com> Tested-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com> Acked-by: NKyungmin Park <kyungmin.park@samsung.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Chao Yu 提交于
Since we allocate a temporary buffer in zram_bvec_read to handle partial page operations in commit 924bd88d ("Staging: zram: allow partial page operations"), our ->failed_reads value may be incorrect as we do not increase its value when failing to allocate the temporary buffer. Let's fix this issue and correct the annotation of failed_reads. Signed-off-by: NChao Yu <chao2.yu@samsung.com> Acked-by: NMinchan Kim <minchan@kernel.org> Cc: Nitin Gupta <ngupta@vflare.org> Acked-by: NJerome Marchand <jmarchan@redhat.com> Acked-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 29 8月, 2014 5 次提交
-
-
由 Michael Auchter 提交于
These resources are managed by devres, and should not be explicitly released. Signed-off-by: NMichael Auchter <a@phire.org> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
由 Jiang Liu 提交于
Now IOAPIC driver dynamically allocates IRQ numbers for IOAPIC pins. We need to keep IRQ assignment for PCI devices during runtime power management, otherwise it may cause failure of device wakeups. Commit 3eec5952 "x86, irq, PCI: Keep IRQ assignment for PCI devices during suspend/hibernation" has fixed the issue for suspend/ hibernation, we also need the same fix for runtime device sleep too. Fix: https://bugzilla.kernel.org/show_bug.cgi?id=83271Reported-and-Tested-by: NEmanueL Czirai <amanual@openmailbox.org> Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: EmanueL Czirai <amanual@openmailbox.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Grant Likely <grant.likely@linaro.org> Link: http://lkml.kernel.org/r/1409304383-18806-1-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
-
由 Doug Anderson 提交于
If our client is requesting a clock that is above the maximum clock then the following division will result in 0: rs->max_freq / rs->speed We'll then program 0 into the SPI_BAUDR register. The Rockchip TRM says: "If the value is 0, the serial output clock (sclk_out) is disabled." It's much better to end up with the fastest possible clock rather than a clock that is off, so enforce a minimum value. Signed-off-by: NDoug Anderson <dianders@chromium.org> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Mikulas Patocka 提交于
The DM crypt target accesses memory beyond allocated space resulting in a crash on 32 bit x86 systems. This bug is very old (it dates back to 2.6.25 commit 3a7f6c99 "dm crypt: use async crypto"). However, this bug was masked by the fact that kmalloc rounds the size up to the next power of two. This bug wasn't exposed until 3.17-rc1 commit 298a9fa0 ("dm crypt: use per-bio data"). By switching to using per-bio data there was no longer any padding beyond the end of a dm-crypt allocated memory block. To minimize allocation overhead dm-crypt puts several structures into one block allocated with kmalloc. The block holds struct ablkcipher_request, cipher-specific scratch pad (crypto_ablkcipher_reqsize(any_tfm(cc))), struct dm_crypt_request and an initialization vector. The variable dmreq_start is set to offset of struct dm_crypt_request within this memory block. dm-crypt allocates the block with this size: cc->dmreq_start + sizeof(struct dm_crypt_request) + cc->iv_size. When accessing the initialization vector, dm-crypt uses the function iv_of_dmreq, which performs this calculation: ALIGN((unsigned long)(dmreq + 1), crypto_ablkcipher_alignmask(any_tfm(cc)) + 1). dm-crypt allocated "cc->iv_size" bytes beyond the end of dm_crypt_request structure. However, when dm-crypt accesses the initialization vector, it takes a pointer to the end of dm_crypt_request, aligns it, and then uses it as the initialization vector. If the end of dm_crypt_request is not aligned on a crypto_ablkcipher_alignmask(any_tfm(cc)) boundary the alignment causes the initialization vector to point beyond the allocated space. Fix this bug by calculating the variable iv_size_padding and adding it to the allocated size. Also correct the alignment of dm_crypt_request. struct dm_crypt_request is specific to dm-crypt (it isn't used by the crypto subsystem at all), so it is aligned on __alignof__(struct dm_crypt_request). Also align per_bio_data_size on ARCH_KMALLOC_MINALIGN, so that it is aligned as if the block was allocated with kmalloc. Reported-by: NKrzysztof Kolasa <kkolasa@winsoft.pl> Tested-by: NMilan Broz <gmazyland@gmail.com> Signed-off-by: NMikulas Patocka <mpatocka@redhat.com> Signed-off-by: NMike Snitzer <snitzer@redhat.com>
-
由 Robert Coulson 提交于
After the conversion rate is changed, the zbits are not updated, but should be, since they are used later in the set_temp function. Fixes: a50d9a4d ("hwmon: (ds1621) Fix temperature rounding operations") Reported-by: NMurat Ilsever <murat.ilsever@gmail.com> Signed-off-by: NRobert Coulson <rob.coulson@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
- 28 8月, 2014 5 次提交
-
-
由 Tony Lindgren 提交于
Commit 43fef47f (mfd: twl4030-power: Add a configuration to turn off oscillator during off-idle) added support for configuring the PMIC to cut off resources during deeper idle states to save power. This however caused regression for n900 display power that needed the PMIC configuration to be disabled with commit d937678a (ARM: dts: Revert enabling of twl configuration for n900). Turns out the root cause of the problem is that we must use TWL4030_RESCONFIG_UNDEF instead of DEV_GRP_NULL to avoid disabling regulators that may have been enabled before the init function for twl4030-power.c runs. With TWL4030_RESCONFIG_UNDEF we let the regulator framework control the regulators like it should. Here we need to only configure the sys_clken and sys_off_mode triggers for the regulators that cannot be done by the regulator framework as it's not running at that point. This allows us to enable the PMIC configuration for n900. Fixes: 43fef47f (mfd: twl4030-power: Add a configuration to turn off oscillator during off-idle) Cc: stable@vger.kernel.org # v3.16 Signed-off-by: NTony Lindgren <tony@atomide.com> Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: NLee Jones <lee.jones@linaro.org>
-
由 Hans de Goede 提交于
I've received a bug report from a user that the touchpad control part of the ideapad-laptop ACPI interface does work for him on his "Lenovo Yoga 2 13", and that this patch causes a regression for him. Since it did not work for me when I had a "Lenovo Yoga 2 11" in my own hands (loaned from a friend). It seems that this is a bit of hit and miss. Since the result of having a false positive here is worse, then the minor annoyance of a false touchpad disabled messages being shown after suspend / resume on models (or is it firmware versions?) where the interface does not work, simply revert the patch. This reverts commit f79a9013. Reported-by: NGOESSEL Guillaume <g_goessel@outlook.com> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
-
由 Mathias Krause 提交于
The __init annotations for the DMI callback functions are wrong as this code can be called even after the module has been initialized, e.g. like this: # echo 1 > /sys/bus/pci/devices/0000:00:02.0/remove # modprobe i915 # echo 1 > /sys/bus/pci/rescan The first command will remove the PCI device from the kernel's device list so the second command won't see it right away. But as it registers a PCI driver it'll see it on the third command. If the system happens to match one of the DMI table entries we'll try to call a function in long released memory and generate an Oops, at best. Fix this by removing the bogus annotation. Modpost should have caught that one but it ignores section reference mismatches from the .rodata section. :/ Fixes: 25e341cf ("drm/i915: quirk away broken OpRegion VBT") Fixes: 8ca4013d ("CHROMIUM: i915: Add DMI override to skip CRT...") Fixes: 425d244c ("drm/i915: ignore LVDS on intel graphics systems...") Signed-off-by: NMathias Krause <minipli@googlemail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Duncan Laurie <dlaurie@chromium.org> Cc: Jarod Wilson <jarod@redhat.com> Cc: Rusty Russell <rusty@rustcorp.com.au> # Can modpost be fixed? Cc: stable@vger.kernel.org Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Thierry Reding 提交于
kerneldoc doesn't know how to parse variables, so don't let it try. Signed-off-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
-
由 Y.C. Chen 提交于
This avoid reading past the end of the list for certain modes Signed-off-by: NY.C. Chen <yc_chen@aspeedtech.com> Reviewed-by: NEgbert Eich <eich@freedesktop.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-