Fixes the following warning:
warning: 'dma_dmamask' defined but not used [-Wunused-variable]
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Don't call i2c_enable on resume because it causes a spurious
interrupt.
Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Also remove two warnings when CONFIG_SND_DEBUG is not set:
sound/pci/hda/patch_hdmi.c: In function ‘hdmi_intrinsic_event’:
sound/pci/hda/patch_hdmi.c:761:6: warning: unused variable ‘eldv’ [-Wunused-variable]
sound/pci/hda/patch_hdmi.c:760:6: warning: unused variable ‘pd’ [-Wunused-variable]
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch allows caching of the rindex glock. We were previously
setting the GL_NOCACHE bit when the glock was released. That forced
the rindex inode to be invalidated, which caused us to re-read
rindex at the next access. However, it caused the glock to be
unnecessarily bounced around the cluster. This patch allows
the glock to remain cached, but it still causes the rindex to be
re-read once it has been written to by gfs2_grow.
Ben and I have tested single-node gfs2_grow cases and I've tested
clustered gfs2_grow cases on my four-node cluster.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
in function nf_conntrack_init_net,when nf_conntrack_timeout_init falied,
we should call nf_conntrack_ecache_fini to do rollback.
but the current code calls nf_conntrack_timeout_fini.
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
It was reported that the Linux kernel sometimes logs:
klogd: [2629147.402413] kernel BUG at net / netfilter /
nf_conntrack_proto_tcp.c: 447!
klogd: [1072212.887368] kernel BUG at net / netfilter /
nf_conntrack_proto_tcp.c: 392
ipv4_get_l4proto() in nf_conntrack_l3proto_ipv4.c and tcp_error() in
nf_conntrack_proto_tcp.c should catch malformed packets, so the errors
at the indicated lines - TCP options parsing - should not happen.
However, tcp_error() relies on the "dataoff" offset to the TCP header,
calculated by ipv4_get_l4proto(). But ipv4_get_l4proto() does not check
bogus ihl values in IPv4 packets, which then can slip through tcp_error()
and get caught at the TCP options parsing routines.
The patch fixes ipv4_get_l4proto() by invalidating packets with bogus
ihl value.
The patch closes netfilter bugzilla id 771.
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
In the commit 77b0d60c5a,
"clockevents: Leave the broadcast device in shutdown mode when not needed",
we were bailing out too quickly in tick_broadcast_switch_to_oneshot(),
with out tracking the broadcast device mode change to 'TICKDEV_MODE_ONESHOT'.
This breaks the platforms which need broadcast device oneshot services during
deep idle states. tick_broadcast_oneshot_control() thinks that it is
in periodic mode and fails to take proper decisions based on the
CLOCK_EVT_NOTIFY_BROADCAST_[ENTER, EXIT] notifications during deep
idle entry/exit.
Fix this by tracking the broadcast device mode as 'TICKDEV_MODE_ONESHOT',
before leaving the broadcast HW device in shutdown mode if there are no active
requests for the moment.
Reported-and-tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: johnstul@us.ibm.com
Link: http://lkml.kernel.org/r/1334011304.12400.81.camel@sbsiddha-desk.sc.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Some r4xx chips have the wrong frev in the
DVOEncoderControl table. It should always be 1
on r4xx. Fixes modesetting on DVO on r4xx chips
with the bad frev.
Reported by twied on #radeon.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Since cmdbuf->size and cmdbuf->nbox are from userspace, a large value
would overflow the allocation size, leading to out-of-bounds access.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some architectures require that delays longer than a few
miliseconds are called through mdelay. This was triggered
on ARM randconfig builds.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
David pointed out, that WARN_ONCE() to report usage of an deprecated
misfeature make folks unhappy. Use printk_once() instead.
Andrew told me to stop grumbling and to remove the silly typecast
while touching the file.
Reported-by: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
handle_IRQ may briefly cause interrupts to be re-enabled during soft IRQ
processing on the exit path, leading to nested handling of VIC interrupts.
Since the current code does not re-read the VIC_IRQ_STATUS register, this
can lead to multiple invocations of the same interrupt handler and
spurious interrupts to be reported.
This patch changes the VIC interrupt dispatching code to re-read the
status register each time, avoiding duplicate invocations of the same
handler.
Acked-and-Tested-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Jamie Iles <jamie@jamieiles.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
commit 8878a539ff was done by me
to make the page fault handler retryable as well as interruptible.
Due to this commit, there is a mistake in the way in which
tsk->[maj|min]_flt counter gets incremented for VM_FAULT_ERROR:
If VM_FAULT_ERROR is returned in the fault flags by handle_mm_fault,
then either maj_flt or min_flt will get incremented. This is wrong
as in the case of a VM_FAULT_ERROR we need to be skip ahead to the
error handling code in do_page_fault.
Added a check after the call to __do_page_fault() to check for
(fault & VM_FAULT_ERROR).
Signed-off-by: Kautuk Consul <consul.kautuk@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add pointer and buttonpad properties for v4 hardware.
Also, Jachiet reported that on Asus UX31, right button has no effect.
It turns out v4 has only one button, the right-button effect is
implemented with software when Windows driver is installed, or in
firmware when touchpad is in relative mode. So remove BTN_RIGHT
while at it.
Reported-by: Jachiet Louis <louis@jachiet.com>
Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Acer VH40 has a Fn key toggling the touchpad on and off, but it's
implemented in system firmware, and the EC chip has to receive
reset command to activate this function. Also when this machine
wakes up after resume, psmouse_reset is necessary to bring the
touchpad back on.
Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
commit a546498f3b
introduced a regression on 32-bit when irq tracing
is enabled by exposing an old bug in our irq tracing
code for exception entry.
The code would save and restore some GPRs around the
calls to the C lockdep code, however, it tries to be
too smart for its own good and restores some of the
GPRs from the exception frame (as saved there on
exception entry).
However, for page faults, we do replace those GPRs with
arguments to do_page_fault before we call transfer_to_handler
and so restoring from the exception frame is plain wrong in
this case.
This was fine as long as we didn't touch the interrupt state
when taking page fault, but when I started doing it, it would
trigger the lockdep calls and the bug.
This fixes it by cleaning up that code a bit. It did create
a small stack frame for the sake of backtraces, so let's
make it a bit bigger and use it to save and restore the
stuff we care about.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
At the point of this error-handling code, both regions and the dma have
been allocated, so free it as done in previous and subsequent
error-handling code.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
At the point of this error-handling code, HAVE_DSPCODEH may be undefined,
so free INITCODE and PERMCODE as done elsewhere. A jump and label are
introduced to avoid code duplication.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Commit f02e8a6596 ("module: Sort exported symbols") sorts symbols
placing each of them in its own elf section. This sorting and merging
into the canonical sections are done by the linker.
Unfortunately modpost to generate Module.symvers file parses vmlinux.o
(which is not linked yet) and all modules object files (which aren't
linked yet). These aren't sanitized by the linker yet. That breaks
modpost that can't detect license properly for modules.
This patch makes modpost aware of the new exported symbols structure.
[ This above is a slightly corrected version of the explanation of the
problem, copied from commit 62a2635610 ("modpost: Fix modpost's
license checking V3"). That commit fixed the problem for module
object files, but not for vmlinux.o. This patch fixes modpost for
vmlinux.o. ]
Signed-off-by: Frank Rowand <frank.rowand@am.sony.com>
Signed-off-by: Alessio Igor Bogani <abogani@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The task handoff notifier leaks task_struct since it never gets freed
after the callback returns NOTIFY_OK, which means it is responsible for
doing so.
It turns out the lowmemorykiller actually doesn't need this notifier at
all. It's used to prevent unnecessary killing by waiting for a thread
to exit as a result of lowmem_shrink(), however, it's possible to do
this in the same way the kernel oom killer works by setting TIF_MEMDIE
and avoid killing if we're still waiting for it to exit.
The kernel oom killer will already automatically set TIF_MEMDIE for
threads that are attempting to allocate memory that have a fatal signal.
The thread selected by lowmem_shrink() will have such a signal after the
lowmemorykiller sends it a SIGKILL, so this won't result in an
unnecessary use of memory reserves for the thread to exit.
This has the added benefit that we don't have to rely on
CONFIG_PROFILING to prevent needlessly killing tasks.
Reported-by: Werner Landgraf <w.landgraf@ru.ru>
Cc: stable@vger.kernel.org
Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: Colin Cross <ccross@android.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch (as1538) causes uhci_hub_status_data() to return a nonzero
value when any port is undergoing a resume transition while the root
hub is suspended. This will allow usbcore to handle races between
root-hub suspend and port wakeup.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1537) adds a bit-array to ehci-hcd for keeping track of
which ports are undergoing a resume transition. If any of the bits
are set when ehci_hub_status_data() is called, the routine will return
a nonzero value even if no ports have any status changes pending.
This will allow usbcore to handle races between root-hub suspend and
port wakeup.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
CC: Chen Peter-B29397 <B29397@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1533) fixes a race between root-hub suspend and remote
wakeup. If a wakeup event occurs while a root hub is suspending, it
might not cause the suspend to fail. Although the host controller
drivers check for pending wakeup events at the start of their
bus_suspend routines, they generally do not check for wakeup events
while the routines are running.
In addition, if a wakeup event occurs any time after khubd is frozen
and before the root hub is fully suspended, it might not cause a
system sleep transition to fail. For example, the host controller
drivers do not fail root-hub suspends when a connect-change event is
pending.
To fix both these issues, this patch causes hcd_bus_suspend() to query
the controller driver's hub_status_data method after a root hub is
suspended, if the root hub is enabled for wakeup. Any pending status
changes will count as wakeup events, causing the root hub to be
resumed and the overall suspend to fail with -EBUSY.
A significant point is that not all events are reflected immediately
in the status bits. Both EHCI and UHCI controllers notify the CPU
when remote wakeup begins on a port, but the port's suspend-change
status bit doesn't get set until after the port has completed the
transition out of the suspend state, some 25 milliseconds later.
Consequently, the patch will interpret any nonzero return value from
hub_status_data as indicating a pending event, even if none of the
status bits are set in the data buffer. Follow-up patches make the
necessary changes to ehci-hcd and uhci-hcd.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
CC: Chen Peter-B29397 <B29397@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Just add new device id. 3G works fine, LTE not tested.
Signed-off-by: Anton Samokhvalov <pg83@yandex.ru>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There are two issues here, one is that the device is generating
spurious very fast modem status line changes somewhere:
CTS becomes high then low 18µs later:
[121226.924373] ftdi_process_packet: prev rng=0 dsr=10 dcd=0 cts=6
[121226.924378] ftdi_process_packet: status=10 prev=00 diff=10
[121226.924382] ftdi_process_packet: now rng=0 dsr=10 dcd=0 cts=7
(wake_up_interruptible is called)
[121226.924391] ftdi_process_packet: prev rng=0 dsr=10 dcd=0 cts=7
[121226.924394] ftdi_process_packet: status=00 prev=10 diff=10
[121226.924397] ftdi_process_packet: now rng=0 dsr=10 dcd=0 cts=8
(wake_up_interruptible is called)
This wakes up the task in TIOCMIWAIT:
[121226.924405] ftdi_ioctl: 19451 rng=0->0 dsr=10->10 dcd=0->0 cts=6->8
(wait from 20:51:46 returns and observes both changes)
Which then calls TIOCMIWAIT again:
20:51:46.400239 ioctl(3, TIOCMIWAIT, 0x20) = 0
22:11:09.441818 ioctl(3, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0
22:11:09.442812 ioctl(3, TIOCMIWAIT, 0x20) = -1 EIO (Input/output error)
(the second wake_up_interruptible takes effect and an I/O error occurs)
The other issue is that TIOCMIWAIT will wait forever (unless the task is
interrupted) if the device is removed.
This change removes the -EIO return that occurs if the counts don't
appear to have changed. Multiple counts may have been processed as
one or the waiting task may have started waiting after recording the
current count.
It adds a bool to indicate that the device has been removed so that
TIOCMIWAIT doesn't wait forever, and wakes up any tasks so that they can
return -EIO.
Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Handling of TIOCMIWAIT was changed by commit 1d749f9afa
USB: ftdi_sio.c: Use ftdi async_icount structure for TIOCMIWAIT, as in other drivers
FTDI_STATUS_B0_MASK does not indicate the changed modem status lines,
it indicates the value of the current modem status lines. An xor is
still required to determine which lines have changed.
The count was only being incremented if the line was high. The only
reason TIOCMIWAIT still worked was because the status packet is
repeated every 1ms, so the count was always changing. The wakeup
itself still ran based on the status lines changing.
This change fixes handling of updates to the modem status lines and
allows multiple processes to use TIOCMIWAIT concurrently.
Tested with two processes waiting on different status lines being
toggled independently.
Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Cc: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
IPv6 conntrack marked invalid packets as INVALID and let the user
drop those by an explicit rule, while IPv4 conntrack dropped such
packets itself.
IPv4 conntrack is changed so that it marks INVALID packets and let
the user to drop them.
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
This patch (as1532) fixes a mistake in the USB suspend code. When the
system is going to sleep, we should ignore errors in powering down USB
devices, because they don't really matter. The devices will go to low
power anyway when the entire USB bus gets suspended (except for
SuperSpeed devices; maybe they will need special treatment later).
However we should not ignore errors in suspending root hubs,
especially if the error indicates that the suspend raced with a wakeup
request. Doing so might leave the bus powered on while the system was
supposed to be asleep, or it might cause the suspend of the root hub's
parent controller device to fail, or it might cause a wakeup request
to be ignored.
The patch fixes the problem by ignoring errors only when the device in
question is not a root hub.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Chen Peter <B29397@freescale.com>
CC: <stable@vger.kernel.org>
Tested-by: Chen Peter <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch (as1536) fixes a bug in the USB serial core. Unloading and
reloading a serial driver while a serial device is plugged in causes
errors because of the code in usb_serial_disconnect() that tries to
make sure the port_remove method is called. With the new order of
driver registration introduced in the 3.4 kernel, this is definitely
not the right thing to do (if indeed it ever was).
The patch removes that whole section code, along with the mechanism
for keeping track of each port's registration state, which is no
longer needed. The driver core can handle all that stuff for us.
Note: This has been tested only with one or two USB serial drivers.
In theory, other drivers might still run into trouble. But if they
do, it will be the fault of the drivers, not of this patch -- that is,
the drivers will need to be fixed.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The right idProduct for Metrologic Bar Code Scanner
in Uni-Directional Serial Emulation mode is 0x0700.
Also rename idProduct for Bi-Directional mode to be a bit more informative.
Signed-off-by: Aleksey Babahin <tamerlan311@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
DTR/RTS should only be raised when changing baudrate from B0 and not on
any baud rate change (> B0).
Reported-by: Søren Holm <sgh@sgh.dk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This is needed to allow renaming network devices that have been moved
to another network namespace.
Signed-off-by: Tom Goff <thomas.goff@boeing.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix the following gcc complain
arch/um/kernel/skas/mmu.c: In function 'uml_setup_stubs':
arch/um/kernel/skas/mmu.c:106:16: warning: unused variable 'pages' [-Wunused-variable]
Signed-Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
... rather than open-coding the 64bit versions. endian.h has those guys.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Richard Weinberger <richard@nod.at>
This fixes:
note: expected ‘struct ida *’ but argument is of type ‘struct idr *’
warning: passing argument 1 of ‘ida_pre_get’ from incompatible pointer type
Reported-by: Arnd Bergman <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
soc_lock is already initialized by DEFINE_SPINLOCK.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Free extra as done in the error-handling code just above.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the rate-control indexing is incorrectly set up, mac80211 issues
a warning and returns NULL from the call to ieee80211_get_tx_rate().
When this happens, avoid a NULL pointer dereference.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When the control-rate tables are not set up correctly, it makes
little sense to spam the logs, thus change the WARN_ON to WARN_ON_ONCE.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Before the switch to asynchronous firmware loading (mainline commit b0302ab),
it was necessary to load firmware when initializing the first of the units
in a dual-mac system. After the change, it is necessary to load firmware in
both units.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The nl80211 handling code should ensure as much as
it can that the interface is in a valid state, it
can certainly ensure the interface is running.
Not doing so can cause calls through mac80211 into
the driver that result in warnings and unspecified
behaviour in the driver.
Cc: stable@vger.kernel.org
Reported-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The TU_TO_EXP_TIME() macro already includes the
"jiffies +" piece of the calculation, so don't
add jiffies again.
Reported-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Similar to the case where we are changing from one framebuffer to
another, we need to be sure that there are no pending WAIT_FOR_EVENTs on
the pipe for the current framebuffer before switching. If we disable the
pipe, and then try to execute a WAIT_FOR_EVENT it will block
indefinitely and cause a GPU hang.
We attempted to fix this in commit 85345517fe
(drm/i915: Retire any pending operations on the old scanout when switching)
for the case of mode switching, but this leaves the condition where we
are switching off the pipe vulnerable.
There still remains the race condition were a display may be unplugged,
switched off by the core, a uevent sent to notify the DDX and the DDX
may issue a WAIT_FOR_EVENT before it processes the uevent. This window
does not exist if the pipe is only switched off in response to the
uevent. Time to make sure that is so...
Reported-by: Francis Leblanc <Francis.Leblanc-Lebeau@verint.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36515
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45413
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
[danvet: fixup spelling in comment, noticed by Eugeni.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The destination color key is always enabled for IVB. Removed
the line that does this.
Signed-off-by: Armin Reese <armin.c.reese@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
