Add the USB ID for the Xbox 360 Thrustmaster Ferrari 458 Racing Wheel.
Signed-off-by: NTommi Rantala <tt.rantala@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The check to see whether the device is already disabled in
max77693_haptic_disable() was inversed, this change corrects it.
Signed-off-by: NJaewon Kim <jaewon02.kim@samsung.com>
Reviewed-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

xenkbd_disconnect_backend doesn't free grant table entry.  This bug affects
live migration.

xenkbd_disconnect_backend uses gnttab_end_foreign_access_ref to handle
grant table entry which doesn't really free an entry.

Thus every time we do xenkbd_resume, grant table entry increses by one. As
an grant table entry occupies 8 bytes, an grant table page has at most 512
entries. Every 512 times we do xenkdb_resume, grant table pages increses by
one.

After around 3500 times of live migration, grant table pages will increase
by 7, causing too many pages to populate and hitting max_pages limit when
assigning pages.Thus assign_pages will fail, so will live migration.
Signed-off-by: NChang Huaixin <huaixin.chx@alibaba-inc.com>
Acked-by: NDavid Vrabel <david.vrabel@citrix.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Since the change to struct input_mt_pos some variables are now bitfields
instead of integers. Automatic conversion from integer to bitfield entry
destroys information, therefore enforce boolean interpretation instead.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1114768
Fixes: 02d04254 ("Input: alps - use struct input_mt_pos to track coordinates")
Signed-off-by: NAndreas Bosch <linux@progandy.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Active multiplexing is a nice feature as it allows several pointing devices
(such as touchpad and external mouse) use their native protocols at the
same time. Unfortunately many manufacturers do not implement the feature
properly even though they advertise it. The problematic implementations are
never fixed, since Windows by default does not use this mode, and move from
one BIOS/model of laptop to another. When active multiplexing is broken
turning it on usually results in touchpad, keyboard, or both unresponsive.

With PS/2 usage on decline (most of PS/2 devices in use nowadays are
internal laptop touchpads), I expect number of users who have laptops with
working MUX implementation, docking stations with external PS/2 ports, and
who are still using external PS/2 mice, to be rather small. Let's flip the
default to be OFF and allow activating it through i8042.nomux=0 kernel
option.  We'll also keep DMI table where we can record known good models.
Acked-by: NJiri Kosina <jkosina@suse.cz>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Without this the aux port does not get detected, and consequently the
touchpad will not work.

https://bugzilla.redhat.com/show_bug.cgi?id=1110011

Cc: stable@vger.kernel.org
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Unfortunately, ForcePad capability is not actually exported over PS/2, so
we have to resort to DMI checks.

Cc: stable@vger.kernel.org
Reported-by: NNicole Faerber <nicole.faerber@kernelconcepts.de>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This patch adds support for the ar1021 i2c based touchscreen.
The driver is quite simple and only supports the Touch
Reporting Protocol.

This is the final version for an RFC patch send a while ago.
http://www.spinics.net/lists/linux-input/msg29419.htmlSigned-off-by: NChristian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

To enable the cros_ec_keyb driver to be auto-loaded when build as
module add an of match table (and export it) to match the modalias
information passed on to userspace as the Cros EC MFD driver registers
the MFD subdevices with an of_compatibility string.
Signed-off-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk>
Reviewed-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Fix the format string for serio device name generation to avoid negative
device numbers when the id exceeds the maximum signed integer value.
Signed-off-by: NRichard Leitner <richard.leitner@skidata.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Fix the format string for input device name generation to avoid negative
device numbers when the id exceeds the maximum signed integer value.
Signed-off-by: NRichard Leitner <richard.leitner@skidata.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Let's automatically set EV_ABS bit in device's event type list when calling
input_set_abs_params() so that drivers do not have to do it explicitly.

These calls are never in a hot paths so we won't lose much time by setting
the same bit several times.
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

In case we start with the device not fully quiesced we should make sure we
cancel the workqueue after freeing interrupt.
Signed-off-by: NPramod Gurav <pramod.gurav@smartplayin.com>
Acked-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This change switch to managed resources to simplifies error handling
and module unloading and does away with platform_driver remove function.
Signed-off-by: NPramod Gurav <pramod.gurav@smartplayin.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The 'max' size passed into the function is measured in number of bits
(KEY_MAX, LED_MAX, etc) so we need to convert it accordingly before trying
to copy the data out, otherwise we will try copying too much and end up
with up with a page fault.
Reported-by: NPavel Machek <pavel@ucw.cz>
Reviewed-by: NPavel Machek <pavel@ucw.cz>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The uas driver uses the block layer tag for USB3 stream IDs.  With
blk-mq we can get larger tag numbers that the queue depth, which breaks
this assumption.  A fix is under way for 3.18, but sits on top of
large changes so can't easily be backported.   Set the disable_blk_mq
path so that a uas device can't easily crash the system when using
blk-mq for SCSI.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

The runtime pm calls need to be done before populating the children via the
i2c_add_adapter call.  If this is not done, a child can run into issues trying
to do i2c read/writes due to the pm_runtime_sync failing.
Signed-off-by: NAndy Gross <agross@codeaurora.org>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

i2cdetect -q was broken (everything was a false positive, and no transfers were
actually being sent over i2c). The way it works is by sending a 0 length write
request and checking for NACK. This patch fixes the 0 length writes and actually
sends them.
Reported-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NAlexandru M Stan <amstan@chromium.org>
Tested-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NMax Schwarz <max.schwarz@online.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

It has come to my attention (thanks Martin) that 'discard_zeroes_data'
is only a hint.  Some devices in some cases don't do what it
says on the label.

The use of DISCARD in RAID5 depends on reads from discarded regions
being predictably zero.  If a write to a previously discarded region
performs a read-modify-write cycle it assumes that the parity block
was consistent with the data blocks.  If all were zero, this would
be the case.  If some are and some aren't this would not be the case.
This could lead to data corruption after a device failure when
data needs to be reconstructed from the parity.

As we cannot trust 'discard_zeroes_data', ignore it by default
and so disallow DISCARD on all raid4/5/6 arrays.

As many devices are trustworthy, and as there are benefits to using
DISCARD, add a module parameter to over-ride this caution and cause
DISCARD to work if discard_zeroes_data is set.

If a site want to enable DISCARD on some arrays but not on others they
should select DISCARD support at the filesystem level, and set the
raid456 module parameter.
    raid456.devices_handle_discard_safely=Y

As this is a data-safety issue, I believe this patch is suitable for
-stable.
DISCARD support for RAID456 was added in 3.7

Cc: Shaohua Li <shli@kernel.org>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Mike Snitzer <snitzer@redhat.com>
Cc: Heinz Mauelshagen <heinzm@redhat.com>
Cc: stable@vger.kernel.org (3.7+)
Acked-by: NMartin K. Petersen <martin.petersen@oracle.com>
Acked-by: NMike Snitzer <snitzer@redhat.com>
Fixes: 620125f2Signed-off-by: NNeilBrown <neilb@suse.de>

Linus commit 05c63c2f modified the
runtime suspend/resume paths to skip over display-related tasks to
avoid locking issues on resume.

Unfortunately, this resulted in the display hardware being left in
a partially initialised state, preventing subsequent modesets from
completing.

This commit unifies the (many) suspend/resume paths, bringing back
display (and fbcon) handling in the runtime paths.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Preparation for some runtime pm fixes.  Currently we skip over fbcon
suspend/resume in the runtime path, which causes issues on resume if
fbcon tries to write to the framebuffer before the BAR subdev has
been resumed to restore the BAR1 VM setup.

As we might be woken up via a sysfs connector, we are unable to call
fb_set_suspend() in the resume path as it could make its way down to
a modeset and cause all sorts of locking hilarity.

To solve this, we'll just delay the fbcon resume to a workqueue.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Xorg (and any non-DRM client really) doesn't have permission to directly
touch VRAM on nv50 and up, which the fence code prior to g84 depends on.

It's less invasive to temporarily grant it premission to do so, as it
previously did, than it is to rework fencenv50 to use the VM.  That
will come later on.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Reported in fdo#82527 comment #2.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The firmware would be clear when the power cut is enabled for
RTL8153.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The xxx_clear_bp() is used to halt the firmware. It only necessary
for updating the new firmware. Besides, depend on the version of
the current firmware, it may have problem to halt the firmware
directly. Finally, halt the firmware would let the firmware code
useless, and the bugs which are fixed by the firmware would occur.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This driver, similar to tg3, has a check that will
cause full sized 802.1ad frames to be dropped.  The
frame will be larger then the standard mtu due to the
presense of vlan header that has not been stripped.
The driver should not drop this frame and should process
it just like it does for 802.1q.

CC: Sony Chacko <sony.chacko@qlogic.com>
CC: Dept-HSGLinuxNICDev@qlogic.com
Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When receiving a vlan-tagged frame that still contains
a vlan header, the length of the packet will be greater
then MTU+ETH_HLEN since it will account of the extra
vlan header.  TG3 checks this for the case for 802.1Q,
but not for 802.1ad.  As a result, full sized 802.1ad
frames get dropped by the card.

Add a check for 802.1ad protocol when receving full
sized frames.
Suggested-by: NPrashant Sreedharan <prashant@broadcom.com>
CC: Prashant Sreedharan <prashant@broadcom.com>
CC: Michael Chan <mchan@broadcom.com>
Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix the serial console on machines where the serial port is located on
the SuperIO chip.
Signed-off-by: NHelge Deller <deller@gmx.de>
Cc: Peter Hurley <peter@hurleysoftware.com>

cxgbi_inet6addr_handler() can be called in interrupt context, so use rcu
protected list while finding netdev.  This is observed as a scheduling in
atomic oops when running over ipv6.

Fixes: fc8d0590 ("libcxgbi: Add ipv6 api to driver")
Fixes: 759a0cc5 ("cxgb4i: Add ipv6 code to driver, call into libcxgbi ipv6 api")
Signed-off-by: NAnish Bhatt <anish@chelsio.com>
Signed-off-by: NKaren Xie <kxie@chelsio.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

The flag of RTL8152_UNPLUG should only be set when the device is
unplugged, not each time the rtl8152_disconnect() is called.
Otherwise, the device wouldn't be stopped normally.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

o Driver is not updating sw_consumer while processing Tx completion
  when interface is going down. Due to this interface down path gets
  stuck forever waiting for NAPI to complete.
Signed-off-by: NManish Chopra <manish.chopra@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

o __netxen_nic_down() function might sleep while holding spinlock_t(tx_clean_lock).
  Acquire this lock for only releasing TX buffers instead of taking it
  for whole down path.
Reported-by: NMike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: NManish Chopra <manish.chopra@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 8e30444e ("cpufreq: fix cpufreq suspend/resume for intel_pstate")
introduced a bug where the governors wouldn't be stopped anymore for
->target{_index}() drivers during suspend. This happens because
'cpufreq_suspended' is updated before stopping the governors during suspend
and due to this __cpufreq_governor() would return early due to this check:

	/* Don't start any governor operations if we are entering suspend */
	if (cpufreq_suspended)
		return 0;

Fixes: 8e30444e ("cpufreq: fix cpufreq suspend/resume for intel_pstate")
Cc: 3.15+ <stable@vger.kernel.org> # 3.15+: 8e30444e "cpufreq: fix cpufreq suspend/resume for intel_pstate"
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

After the packet is successfully sent, we should not touch the skb
as it may have been freed. This patch is based on the work done by
Long Li <longli@microsoft.com>.

In this version of the patch I have fixed issues pointed out by David.
David, please queue this up for stable.
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Tested-by: NLong Li <longli@microsoft.com>
Tested-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Some of the Thinkpads' firmware will issue a backlight change request
through i915 operation region unconditionally on AC plug/unplug, the
backlight level used is arbitrary and thus should be ignored. This is
handled by commit 0b9f7d93 (ACPI / i915: ignore firmware requests
for backlight change). Then there is a Dell laptop whose vendor backlight
interface also makes use of operation region to change backlight level
and with the above commit, that interface no long works. The condition
used to ignore the backlight change request from firmware is thus
changed to: if the vendor backlight interface is not in use and the ACPI
backlight interface is broken, we ignore the requests; oterwise, we keep
processing them.

Fixes: 0b9f7d93 (ACPI / i915: ignore firmware requests for backlight change)
Link: https://lkml.org/lkml/2014/9/23/854Reported-and-tested-by: NPali Rohár <pali.rohar@gmail.com>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

When the CONFIG_HAVE_CLK is selected for the system, the stmmac_pci_probe
will fail with dmesg:
[    2.167225] stmmaceth 0000:00:14.6: enabling device (0000 -> 0002)
[    2.178267] stmmaceth 0000:00:14.6: enabling bus mastering
[    2.178436] stmmaceth 0000:00:14.6: irq 24 for MSI/MSI-X
[    2.178703] stmmaceth 0000:00:14.6: stmmac_dvr_probe: warning: cannot
get CSR clock
[    2.186503] stmmac_pci_probe: main driver probe failed
[    2.194003] stmmaceth 0000:00:14.6: disabling bus mastering
[    2.196473] stmmaceth: probe of 0000:00:14.6 failed with error -2

This patch fix the issue by breaking the dependency to devm_clk_get()
as the CSR clock can be obtained at priv->plat->clk_csr from pci driver.
Reported-by: NTobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Signed-off-by: NKweh, Hock Leong <hock.leong.kweh@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

As we use WC updates of the PTE, we are responsible for notifying the
hardware when to flush its TLBs. Do so after we zap all the PTEs before
suspend (and the BIOS tries to read our GTT).

Fixes a regression from

commit 828c7908
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date:   Wed Oct 16 09:21:30 2013 -0700

    drm/i915: Disable GGTT PTEs on GEN6+ suspend

that survived and continue to cause harm even after

commit e568af1c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Mar 26 20:08:20 2014 +0100

    drm/i915: Undo gtt scratch pte unmapping again

v2: Trivial rebase.
v3: Fixes requires pointer dances.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82340
Tested-by: ming.yao@intel.com
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Todd Previte <tprevite@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

When building this driver as a module, we get a helpful warning
about the return type:

drivers/cpufreq/integrator-cpufreq.c:232:2: warning: initialization from incompatible pointer type
  .remove = __exit_p(integrator_cpufreq_remove),

If the remove callback returns void, the caller gets an undefined
value as it expects an integer to be returned. This fixes the
problem by passing down the value from cpufreq_unregister_driver.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Fix the following bug introduced by commit 8fec051e (cpufreq:
Convert existing drivers to use cpufreq_freq_transition_{begin|end})
that forgot to move the spin_lock() in pcc_cpufreq_target() past
cpufreq_freq_transition_begin() which calls wait_event():

BUG: sleeping function called from invalid context at drivers/cpufreq/cpufreq.c:370
in_atomic(): 1, irqs_disabled(): 0, pid: 2636, name: modprobe
Preemption disabled at:[<ffffffffa04d74d7>] pcc_cpufreq_target+0x27/0x200 [pcc_cpufreq]
[   51.025044]
CPU: 57 PID: 2636 Comm: modprobe Tainted: G            E  3.17.0-default #7
Hardware name: Hewlett-Packard ProLiant DL980 G7, BIOS P66 07/07/2010
 00000000ffffffff ffff88026c46b828 ffffffff81589dbd 0000000000000000
 ffff880037978090 ffff88026c46b848 ffffffff8108e1df ffff880037978090
 0000000000000000 ffff88026c46b878 ffffffff8108e298 ffff88026d73ec00
Call Trace:
 [<ffffffff81589dbd>] dump_stack+0x4d/0x90
 [<ffffffff8108e1df>] ___might_sleep+0x10f/0x180
 [<ffffffff8108e298>] __might_sleep+0x48/0xd0
 [<ffffffff8145b905>] cpufreq_freq_transition_begin+0x75/0x140 drivers/cpufreq/cpufreq.c:370 wait_event(policy->transition_wait, !policy->transition_ongoing);
 [<ffffffff8108fc99>] ? preempt_count_add+0xb9/0xc0
 [<ffffffffa04d7513>] pcc_cpufreq_target+0x63/0x200 [pcc_cpufreq] drivers/cpufreq/pcc-cpufreq.c:207 spin_lock(&pcc_lock);
 [<ffffffff810e0d0f>] ? update_ts_time_stats+0x7f/0xb0
 [<ffffffff8145be55>] __cpufreq_driver_target+0x85/0x170
 [<ffffffff8145e4c8>] od_check_cpu+0xa8/0xb0
 [<ffffffff8145ef10>] dbs_check_cpu+0x180/0x1d0
 [<ffffffff8145f310>] cpufreq_governor_dbs+0x3b0/0x720
 [<ffffffff8145ebe3>] od_cpufreq_governor_dbs+0x33/0xe0
 [<ffffffff814593d9>] __cpufreq_governor+0xa9/0x210
 [<ffffffff81459fb2>] cpufreq_set_policy+0x1e2/0x2e0
 [<ffffffff8145a6cc>] cpufreq_init_policy+0x8c/0x110
 [<ffffffff8145c9a0>] ? cpufreq_update_policy+0x1b0/0x1b0
 [<ffffffff8108fb99>] ? preempt_count_sub+0xb9/0x100
 [<ffffffff8145c6c6>] __cpufreq_add_dev+0x596/0x6b0
 [<ffffffffa016c608>] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq]
 [<ffffffff8145c7ee>] cpufreq_add_dev+0xe/0x10
 [<ffffffff81408e81>] subsys_interface_register+0xc1/0xf0
 [<ffffffff8108fb99>] ? preempt_count_sub+0xb9/0x100
 [<ffffffff8145b3d7>] cpufreq_register_driver+0x117/0x2a0
 [<ffffffffa016c65d>] pcc_cpufreq_init+0x55/0x9f8 [pcc_cpufreq]
 [<ffffffffa016c608>] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq]
 [<ffffffff81000298>] do_one_initcall+0xc8/0x1f0
 [<ffffffff811a731d>] ? __vunmap+0x9d/0x100
 [<ffffffff810eb9a0>] do_init_module+0x30/0x1b0
 [<ffffffff810edfa6>] load_module+0x686/0x710
 [<ffffffff810ebb20>] ? do_init_module+0x1b0/0x1b0
 [<ffffffff810ee1db>] SyS_init_module+0x9b/0xc0
 [<ffffffff8158f7a9>] system_call_fastpath+0x16/0x1b

Fixes: 8fec051e (cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end})
Reported-and-tested-by: NMike Galbraith <umgwanakikbuti@gmail.com>
Cc: 3.15+ <stable@vger.kernel.org> # 3.15+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The reset_resume call is needed, otherwise it will break resume
on some conditions, depending on the usb ehci/xhci controller.

This reverts commit b89193e0.
Reported-by: NJohannes Stezenbach <js@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>