- 07 3月, 2014 5 次提交
-
-
由 Alex Deucher 提交于
Should be at 0x8 rather than 0. fixes: https://bugzilla.kernel.org/show_bug.cgi?id=60523 Noticed by ArtForz on #radeon Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
Copy-paste typo. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Paul Bolle 提交于
Building radeon_ttm.o on 32 bit x86 triggers a warning: In file included from include/asm-generic/bug.h:13:0, from [...]/arch/x86/include/asm/bug.h:38, from include/linux/bug.h:4, from include/drm/drm_mm.h:39, from include/drm/drm_vma_manager.h:26, from include/drm/ttm/ttm_bo_api.h:35, from drivers/gpu/drm/radeon/radeon_ttm.c:32: drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_gtt_read': include/linux/kernel.h:712:17: warning: comparison of distinct pointer types lacks a cast [enabled by default] (void) (&_min1 == &_min2); \ ^ drivers/gpu/drm/radeon/radeon_ttm.c:938:22: note: in expansion of macro 'min' ssize_t cur_size = min(size, PAGE_SIZE - off); ^ Silence this warning by using min_t(). Since cur_size will never be negative and its upper bound is PAGE_SIZE, we can change its type to size_t and use min_t(size_t, [...]) here. Signed-off-by: NPaul Bolle <pebolle@tiscali.nl> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
由 Alex Deucher 提交于
Moving the pm resume up in the init order to fix dpm seems to have regressed somes cases with the old pm code. Move it back to late resume. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Lauri Kasanen 提交于
Without this, a bo may get created in the cpu-inaccessible vram. Before the CP engines get setup, all copies are done via cpu memcpy. This means that the cpu tries to read from inaccessible memory, fails, and the radeon module proceeds to disable acceleration. Doing this has no downsides, as the real VRAM size gets set as soon as the CP engines get init. This is a candidate for 3.14 fixes. v2: Add comment on why the function is used Signed-off-by: NLauri Kasanen <cand@gmx.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org
-
- 04 3月, 2014 3 次提交
-
-
由 Ville Syrjälä 提交于
Single-link DVI max dotclock is 165MHz. Filter out modes with higher dotclock when the monitor doesn't support HDMI. Modes higher than 165 MHz were allowed in commit 7d148ef5 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Jul 22 18:02:39 2013 +0200 drm/i915: fix hdmi portclock limits Also don't attempt to use 12bpc mode with DVI monitors. Cc: Adam Nielsen <a.nielsen@shikadi.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75345 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70331Tested-by: NRalf Jung <post+kernel@ralfj.de> Cc: stable@vger.kernel.org Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Paulo Zanoni 提交于
We need to read the correct register, not a register that doesn't exist and will trigger "Unclaimed register" messages when we touch it. Also rearrange the checks in an attempt to prevent this error from happening again. Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> [Jani: dropped an extra empty line introduced.] Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Imre Deak 提交于
We reserve the space for the power context in stolen memory at a fixed address from a delayed work. This races with the subsequent driver init/resume code which could allocate something at that address, so the reservation for the power context fails. Reserve the space up-front, so this can't happen. This also adds a missing struct_mutex lock around the stolen allocation, which wasn't taken in the delayed work path. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Cc: stable@vger.kernel.org Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 03 3月, 2014 3 次提交
-
-
由 Imre Deak 提交于
pci_get_class(class, from) drops the refcount for 'from', so the extra pci_dev_put we do on it will result in a use after free bug starting with the WARN below. Regression introduced in commit 6a9c4b35 Author: Rui Guo <firemeteor@users.sourceforge.net> Date: Wed Jun 19 21:10:23 2013 +0800 drm/i915: Fix PCH detect with multiple ISA bridges in VM [ 164.338460] WARNING: CPU: 1 PID: 2094 at include/linux/kref.h:47 klist_next+0xae/0x110() [ 164.347731] CPU: 1 PID: 2094 Comm: modprobe Tainted: G O 3.13.0-imre+ #354 [ 164.356468] Hardware name: Intel Corp. VALLEYVIEW B0 PLATFORM/NOTEBOOK, BIOS BYTICRB1.X64.0062.R70.1310112051 10/11/2013 [ 164.368796] Call Trace: [ 164.371609] [<ffffffff816a32a6>] dump_stack+0x4e/0x7a [ 164.377447] [<ffffffff8104f75d>] warn_slowpath_common+0x7d/0xa0 [ 164.384238] [<ffffffff8104f83a>] warn_slowpath_null+0x1a/0x20 [ 164.390851] [<ffffffff8169aeae>] klist_next+0xae/0x110 [ 164.396777] [<ffffffff8130a110>] ? pci_do_find_bus+0x70/0x70 [ 164.403286] [<ffffffff813cb4a9>] bus_find_device+0x89/0xc0 [ 164.409719] [<ffffffff8130a373>] pci_get_dev_by_id+0x63/0xa0 [ 164.416238] [<ffffffff8130a4e4>] pci_get_class+0x44/0x50 [ 164.422433] [<ffffffffa034821f>] intel_dsm_detect+0x16f/0x1f0 [i915] [ 164.429801] [<ffffffffa03482ae>] intel_register_dsm_handler+0xe/0x10 [i915] [ 164.437831] [<ffffffffa02d30fe>] i915_driver_load+0xafe/0xf30 [i915] [ 164.445126] [<ffffffff8158a150>] ? intel_alloc_coherent+0x110/0x110 [ 164.452340] [<ffffffffa0148c07>] drm_dev_register+0xc7/0x150 [drm] [ 164.459462] [<ffffffffa014b23f>] drm_get_pci_dev+0x11f/0x1f0 [drm] [ 164.466554] [<ffffffff816abb81>] ? _raw_spin_unlock_irqrestore+0x51/0x70 [ 164.474287] [<ffffffffa02cf7a6>] i915_pci_probe+0x56/0x60 [i915] [ 164.481185] [<ffffffff8130a028>] pci_device_probe+0x78/0xf0 [ 164.487603] [<ffffffff813cd495>] driver_probe_device+0x155/0x350 [ 164.494505] [<ffffffff813cd74e>] __driver_attach+0x6e/0xa0 [ 164.500826] [<ffffffff813cd6e0>] ? __device_attach+0x50/0x50 [ 164.507333] [<ffffffff813cb2be>] bus_for_each_dev+0x6e/0xc0 [ 164.513752] [<ffffffff813ccefe>] driver_attach+0x1e/0x20 [ 164.519870] [<ffffffff813cc958>] bus_add_driver+0x138/0x260 [ 164.526289] [<ffffffffa0188000>] ? 0xffffffffa0187fff [ 164.532116] [<ffffffff813cde78>] driver_register+0x98/0xe0 [ 164.538558] [<ffffffffa0188000>] ? 0xffffffffa0187fff [ 164.544389] [<ffffffff813087b0>] __pci_register_driver+0x60/0x70 [ 164.551336] [<ffffffffa014b37d>] drm_pci_init+0x6d/0x120 [drm] [ 164.558040] [<ffffffffa0188000>] ? 0xffffffffa0187fff [ 164.563928] [<ffffffffa018806a>] i915_init+0x6a/0x6c [i915] [ 164.570363] [<ffffffff810002da>] do_one_initcall+0xaa/0x160 [ 164.576783] [<ffffffff8103b140>] ? set_memory_nx+0x40/0x50 [ 164.583100] [<ffffffff810ce7f5>] load_module+0x1fb5/0x2550 [ 164.589410] [<ffffffff810caab0>] ? store_uevent+0x40/0x40 [ 164.595628] [<ffffffff810cee7d>] SyS_init_module+0xed/0x100 [ 164.602048] [<ffffffff816b3c52>] system_call_fastpath+0x16/0x1b v2: simplify the loop further (Chris) Signed-off-by: NImre Deak <imre.deak@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reported-by: NJesse Barnes <jbarnes@virtuousgeek.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65652 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74161Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Akash Goel 提交于
There is a conflict seen when requesting the kernel to reserve the physical space used for the stolen area. This is because some BIOS are wrapping the stolen area in the root PCI bus, but have an off-by-one error. As a workaround we retry the reservation with an offset of 1 instead of 0. v2: updated commit message & the comment in source file (Daniel) Signed-off-by: NAkash Goel <akash.goel@intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Tested-by: NArjan van de Ven <arjan@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Jani Nikula 提交于
i915gm and i945gm also seem to use and need the legacy combination mode bit in BLC_PWM_CTL. v2: Also do this for i915gm (Ville). Reported-and-tested-by: NLuis Ortega <luiorpe1@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75001Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 02 3月, 2014 3 次提交
-
-
由 Alexey Khoroshilov 提交于
vmw_takedown_otable_base() and vmw_mob_unbind() check for potential vmw_fifo_reserve() failure and print error message, but then immediately dereference NULL pointer. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru> Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
-
由 Thomas Hellstrom 提交于
Backing mob contents is propagated to user-space, so make sure backing mobs are cleared when allocated. This also accidently fix rendering errors with celestia when emulating legacy mode. Also update driver date. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NBrian Paul <brianp@vmware.com>
-
由 Thomas Hellstrom 提交于
These formats are deprecated. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Reviewed-by: NBrian Paul <brianp@vmware.com>
-
- 28 2月, 2014 9 次提交
-
-
由 Heinz Mauelshagen 提交于
When remapping a block to the cache's fast device that is larger than 2TB we must not truncate the destination sector to 32bits. The 32bit temporary result of from_cblock() was being overflowed in remap_to_cache() due to the logical left shift. Use an intermediate 64bit type to store the 32bit from_cblock() result to fix the overflow. Signed-off-by: NHeinz Mauelshagen <heinzm@redhat.com> Signed-off-by: NMike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
Now that we disable audio while setting up the audio hw, we should be able to set this up without hangs. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
由 Alex Deucher 提交于
Disable audio around audio hw setup. This may avoid hangs on certain asics. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
由 Alex Deucher 提交于
Properly clear the enable bit when audio disable is requested. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org
-
由 Jerome Glisse 提交于
Need to free the uvd ring. Also reshuffle gart tear down to happen after uvd tear down. Signed-off-by: NJérôme Glisse <jglisse@redhat.com> Cc: stable@vger.kernel.org Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Causes display problems. We had already disabled sharing for non-DP displays. Based on a patch from: Niels Ole Salscheider <niels_ole@salscheider-online.de> bug: https://bugzilla.kernel.org/show_bug.cgi?id=58121Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Christian König 提交于
Otherwise we might get a crash here. Signed-off-by: NChristian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Print the supported functions mask in addition to the version. This is useful in debugging PX problems since we can see what functions are available. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Mike Snitzer 提交于
It was always intended that a user could provide a thin metadata device that is larger than the max supported by the on-disk format. The extra space would just go unused. Unfortunately that never worked. If the user attempted to use a larger metadata device on creation they would get an error like the following: device-mapper: space map common: space map too large device-mapper: transaction manager: couldn't create metadata space map device-mapper: thin metadata: tm_create_with_sm failed device-mapper: table: 252:17: thin-pool: Error creating metadata object device-mapper: ioctl: error adding target to table Fix this by allowing the initial metadata space map creation to cap its size at the max number of blocks supported (DM_SM_METADATA_MAX_BLOCKS). get_metadata_dev_size() must also impose DM_SM_METADATA_MAX_BLOCKS (via THIN_METADATA_MAX_SECTORS), otherwise extending metadata would cap at THIN_METADATA_MAX_SECTORS_WARNING (which is larger than supported). Also, the calculation for THIN_METADATA_MAX_SECTORS didn't account for the sizeof the disk_bitmap_header. So the supported maximum metadata size is a bit smaller (reduced from 33423360 to 33292800 sectors). Lastly, remove the "excess space will not be used" warning message from get_metadata_dev_size(); it resulted in printing the warning multiple times. Factor out warn_if_metadata_device_too_big(), call it from pool_ctr() and maybe_resize_metadata_dev(). Signed-off-by: NMike Snitzer <snitzer@redhat.com> Acked-by: NJoe Thornber <ejt@redhat.com>
-
- 27 2月, 2014 3 次提交
-
-
由 Stanislaw Gruszka 提交于
ehci_irq() and ehci_hrtimer_func() can deadlock on ehci->lock when threadirqs option is used. To prevent the deadlock use spin_lock_irqsave() in ehci_irq(). This change can be reverted when hrtimer callbacks become threaded. Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com> Cc: stable <stable@vger.kernel.org> Acked-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Joerg Dorchain 提交于
Hello, the following patch adds an entry for the PID of a Cressi Leonardo diving computer interface to kernel 3.13.0. It is detected as FT232RL. Works with subsurface. Signed-off-by: NJoerg Dorchain <joerg@dorchain.net> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Lan Tianyu 提交于
acpi_processor_set_throttling() uses set_cpus_allowed_ptr() to make sure that the (struct acpi_processor)->acpi_processor_set_throttling() callback will run on the right CPU. However, the function may be called from a worker thread already bound to a different CPU in which case that won't work. Make acpi_processor_set_throttling() use work_on_cpu() as appropriate instead of abusing set_cpus_allowed_ptr(). Reported-and-tested-by: NJiri Olsa <jolsa@redhat.com> Signed-off-by: NLan Tianyu <tianyu.lan@intel.com> Cc: All applicable <stable@vger.kernel.org> [rjw: Changelog] Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 26 2月, 2014 8 次提交
-
-
由 Christian Engelmayer 提交于
Fix a memory leak in the lp3943_pwm_request_map() error handling path. Make sure already allocated pwm map memory is freed correctly. Detected by Coverity: CID 1162829. Signed-off-by: NChristian Engelmayer <cengelma@gmx.at> Acked-by: NMilo Kim <milo.kim@ti.com> Signed-off-by: NThierry Reding <thierry.reding@gmail.com>
-
由 Hannes Reinecke 提交于
An invalid ioctl will never be valid, irrespective of whether multipath has active paths or not. So for invalid ioctls we do not have to wait for multipath to activate any paths, but can rather return an error code immediately. This fix resolves numerous instances of: udevd[]: worker [] unexpectedly returned with status 0x0100 that have been seen during testing. Signed-off-by: NHannes Reinecke <hare@suse.de> Signed-off-by: NMike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org
-
由 Sebastian Capella 提交于
During restore, pm_notifier chain are called with PM_RESTORE_PREPARE. The firmware_class driver handler fw_pm_notify does not have a handler for this. As a result, it keeps a reader on the kmod.c umhelper_sem. During freeze_processes, the call to __usermodehelper_disable tries to take a write lock on this semaphore and hangs waiting. Signed-off-by: NSebastian Capella <sebastian.capella@linaro.org> Acked-by: NMing Lei <ming.lei@canonical.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Dirk Brandewie 提交于
Commit fcb6a15c (intel_pstate: Take core C0 time into account for core busy calculation) introduced a regression on some processor SKUs supported by intel_pstate. This was due to the truncation caused by using integer math to calculate core busy and C0 percentages. On a i7-4770K processor operating at 800Mhz going to 100% utilization the percent busy of the CPU using integer math is 22%, but it actually is 22.85%. This value scaled to the current frequency returned 97 which the PID interpreted as no error and did not adjust the P state. Tested on i7-4770K, i7-2600, i5-3230M. Fixes: fcb6a15c (intel_pstate: Take core C0 time into account for core busy calculation) References: https://lkml.org/lkml/2014/2/19/626 References: https://bugzilla.kernel.org/show_bug.cgi?id=70941Signed-off-by: NDirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Joe Perches 提交于
This 444 should have been octal. Signed-off-by: NJoe Perches <joe@perches.com> Cc: Alessandro Rubini <rubini@gnudd.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Joe Perches 提交于
These should have been octal. Signed-off-by: NJoe Perches <joe@perches.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 James Hogan 提交于
Fix irq_set_affinity callbacks in the Meta IRQ chip drivers to AND cpu_online_mask into the cpumask when picking a CPU to vector the interrupt to. As Thomas pointed out, the /proc/irq/$N/smp_affinity interface doesn't filter out offline CPUs, so without this patch if you offline CPU0 and set an IRQ affinity to 0x3 it vectors the interrupt onto CPU0 even though it is offline. Reported-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NJames Hogan <james.hogan@imgtec.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-metag@vger.kernel.org Cc: stable@vger.kernel.org
-
由 Dan Williams 提交于
Since commit 77873803 "net_dma: mark broken" we no longer pin dma engines active for the network-receive-offload use case. As a result the ->free_chan_resources() that occurs after the driver self test no longer has a NET_DMA induced ->alloc_chan_resources() to back it up. A late firing irq can lead to ksoftirqd spinning indefinitely due to the tasklet_disable() performed by ->free_chan_resources(). Only ->alloc_chan_resources() can clear this condition in affected kernels. This problem has been present since commit 3e037454 "I/OAT: Add support for MSI and MSI-X" in 2.6.24, but is now exposed. Given the NET_DMA use case is deprecated we can revisit moving the driver to use threaded irqs. For now, just tear down the irq and tasklet properly by: 1/ Disable the irq from triggering the tasklet 2/ Disable the irq from re-arming 3/ Flush inflight interrupts 4/ Flush the timer 5/ Flush inflight tasklets References: https://lkml.org/lkml/2014/1/27/282 https://lkml.org/lkml/2014/2/19/672 Cc: Ingo Molnar <mingo@elte.hu> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: <stable@vger.kernel.org> Reported-by: NMike Galbraith <bitbucket@online.de> Reported-by: NStanislav Fomichev <stfomichev@yandex-team.ru> Tested-by: NMike Galbraith <bitbucket@online.de> Tested-by: NStanislav Fomichev <stfomichev@yandex-team.ru> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NDan Williams <dan.j.williams@intel.com>
-
- 25 2月, 2014 6 次提交
-
-
由 Jean Delvare 提交于
pci_get_device() decrements the reference count of "from" (last argument) so when we break off the loop successfully we have only one device reference - and we don't know which device we have. If we want a reference to each device, we must take them explicitly and let the pci_get_device() walk complete to avoid duplicate references. This is serious, as over-putting device references will cause the device to eventually disappear. Without this fix, the kernel crashes after a few insmod/rmmod cycles. Tested on an Intel S7000FC4UR system with a 7300 chipset. Signed-off-by: NJean Delvare <jdelvare@suse.de> Link: http://lkml.kernel.org/r/20140224111656.09bbb7ed@endymion.delvare Cc: Mauro Carvalho Chehab <m.chehab@samsung.com> Cc: Doug Thompson <dougthompson@xmission.com> Cc: stable@vger.kernel.org Signed-off-by: NBorislav Petkov <bp@suse.de>
-
由 Jean Delvare 提交于
The reference count changes done by pci_get_device can be a little misleading when the usage diverges from the most common scheme. The reference count of the device passed as the last parameter is always decreased, even if the function returns no new device. So if we are going to try alternative device IDs, we must manually increment the device reference count before each retry. If we don't, we end up decreasing the reference count, and after a few modprobe/rmmod cycles the PCI devices will vanish. In other words and as Alan put it: without this fix the EDAC code corrupts the PCI device list. This fixes kernel bug #50491: https://bugzilla.kernel.org/show_bug.cgi?id=50491Signed-off-by: NJean Delvare <jdelvare@suse.de> Link: http://lkml.kernel.org/r/20140224093927.7659dd9d@endymion.delvareReviewed-by: NAlan Cox <alan@linux.intel.com> Cc: Mauro Carvalho Chehab <m.chehab@samsung.com> Cc: Doug Thompson <dougthompson@xmission.com> Cc: stable@vger.kernel.org Signed-off-by: NBorislav Petkov <bp@suse.de>
-
由 Manu Gupta 提交于
The D-Link DWA-123 REV D1 with USB ID 2001:3310 uses this driver. Signed-off-by: NManu Gupta <manugupt1@gmail.com> Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net> Cc: stable <stable@vger.kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Venkatesh Srinivas 提交于
The virtio spec requires byte 0 of the virtio-scsi LUN structure to be '1'. Signed-off-by: NVenkatesh Srinivas <venkateshs@google.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
由 Juergen Beisert 提交于
Releasing the touchscreen lets the internal statemachine left in a wrong state. Due to this the release coordinate will be reported again by accident when the next touchscreen event happens. This change sets up the correct state when waiting for the next touchscreen event. This has led to reported issues with calibrating the touchscreen. Bug was introduced somewhere in the series that began with 18da755d Staging/iio/adc/touchscreen/MXS: add proper clock handling in which the way this driver worked was substantially changed to be interrupt driven rather than relying on a busy loop. This was a regression in the 3.13 kernel. Signed-off-by: NJuergen Beisert <jbe@pengutronix.de> Tested-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com> Cc: stable@vger.kernel.org Signed-off-by: NJonathan Cameron <jic23@kernel.org>
-
由 Dr. Greg Wettstein 提交于
A selective retransmission request (SRR) is a fibre-channel protocol control request which provides support for requesting retransmission of a data sequence in response to an issue such as frame loss or corruption. These events are experienced infrequently in fibre-channel based networks which makes it difficult to test and assess codepaths which handle these events. We were fortunate enough, for some definition of fortunate, to have a metro-area single-mode SAN link which, at 10 GBPS sustained load levels, would consistently generate SRR's in a SCST based target implementation using our SCST/in-kernel Qlogic target interface driver. In response to an SRR the in-kernel Qlogic target driver immediately panics resulting in a catastrophic storage failure for serviced initiators. The culprit was a debug statement in the qla_target.c file which does not verify that a pointer to the SCSI CDB is not null. The unchecked pointer dereference results in the kernel panic and resultant system failure. The other two references to the SCSI CDB by the SRR handling code use a ternary operator to verify a non-null pointer is being acted on. This patch simply adds a similar test to the implicated debug statement. This patch is a candidate for any stable kernel being maintained since it addresses a potentially catastrophic event with minimal downside. Signed-off-by: NDr. Greg Wettstein <greg@enjellic.com> Cc: <stable@vger.kernel.org> #3.5+ Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-