linux-stable.git/drivers/media, branch v3.18.4 Linux kernel stable tree vivid: fix CROP_BOUNDS typo for video output 2015-01-27T16:29:40+00:00 Hans Verkuil hverkuil@xs4all.nl 2014-12-06T10:30:03+00:00 24a209fd9b566f5f0ec3307cb2edba0d42c1d886 commit bb9ff078860f9d2f79d3a6bea3af9f48354ddb75 upstream. An error was returned if composing was not supported, instead of if cropping was not supported. A classic copy-and-paste bug. Found with v4l2-compliance. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit bb9ff078860f9d2f79d3a6bea3af9f48354ddb75 upstream.

An error was returned if composing was not supported, instead of if
cropping was not supported.

A classic copy-and-paste bug. Found with v4l2-compliance.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
img-ir/hw: Fix potential deadlock stopping timer 2015-01-27T16:29:40+00:00 James Hogan james.hogan@imgtec.com 2014-12-01T12:55:10+00:00 e6bd63e792d95c1dd9644c315951b734ef3680f3 commit ac03086067a5524ae9e020ba5712a208c67b2736 upstream. The end timer is used for switching back from repeat code timings when no repeat codes have been received for a certain amount of time. When the protocol is changed, the end timer is deleted synchronously with del_timer_sync(), however this takes place while holding the main spin lock, and the timer handler also needs to acquire the spin lock. This opens the possibility of a deadlock on an SMP system if the protocol is changed just as the repeat timer is expiring. One CPU could end up in img_ir_set_decoder() holding the lock and waiting for the end timer to complete, while the other CPU is stuck in the timer handler spinning on the lock held by the first CPU. Lockdep also spots a possible lock inversion in the same code, since img_ir_set_decoder() acquires the img-ir lock before the timer lock, but the timer handler will try and acquire them the other way around: ========================================================= [ INFO: possible irq lock inversion dependency detected ] 3.18.0-rc5+ #957 Not tainted --------------------------------------------------------- swapper/0/0 just changed the state of lock: (((&hw->end_timer))){+.-...}, at: [<4006ae5c>] _call_timer_fn+0x0/0xfc but this lock was taken by another, HARDIRQ-safe lock in the past: (&(&priv->lock)->rlock#2){-.....} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(((&hw->end_timer))); local_irq_disable(); lock(&(&priv->lock)->rlock#2); lock(((&hw->end_timer))); <Interrupt> lock(&(&priv->lock)->rlock#2); *** DEADLOCK *** This is fixed by releasing the main spin lock while performing the del_timer_sync() call. The timer is prevented from restarting before the lock is reacquired by a new "stopping" flag which img_ir_handle_data() checks before updating the timer. --------------------------------------------------------- swapper/0/0 just changed the state of lock: (((&hw->end_timer))){+.-...}, at: [<4006ae5c>] _call_timer_fn+0x0/0xfc but this lock was taken by another, HARDIRQ-safe lock in the past: (&(&priv->lock)->rlock#2){-.....} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(((&hw->end_timer))); local_irq_disable(); lock(&(&priv->lock)->rlock#2); lock(((&hw->end_timer))); <Interrupt> lock(&(&priv->lock)->rlock#2); *** DEADLOCK *** This is fixed by releasing the main spin lock while performing the del_timer_sync() call. The timer is prevented from restarting before the lock is reacquired by a new "stopping" flag which img_ir_handle_data() checks before updating the timer. Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Sifan Naeem <sifan.naeem@imgtec.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit ac03086067a5524ae9e020ba5712a208c67b2736 upstream.

The end timer is used for switching back from repeat code timings when
no repeat codes have been received for a certain amount of time. When
the protocol is changed, the end timer is deleted synchronously with
del_timer_sync(), however this takes place while holding the main spin
lock, and the timer handler also needs to acquire the spin lock.

This opens the possibility of a deadlock on an SMP system if the
protocol is changed just as the repeat timer is expiring. One CPU could
end up in img_ir_set_decoder() holding the lock and waiting for the end
timer to complete, while the other CPU is stuck in the timer handler
spinning on the lock held by the first CPU.

Lockdep also spots a possible lock inversion in the same code, since
img_ir_set_decoder() acquires the img-ir lock before the timer lock, but
the timer handler will try and acquire them the other way around:

=========================================================
[ INFO: possible irq lock inversion dependency detected ]
3.18.0-rc5+ #957 Not tainted
---------------------------------------------------------
swapper/0/0 just changed the state of lock:
 (((&hw->end_timer))){+.-...}, at: [<4006ae5c>] _call_timer_fn+0x0/0xfc
but this lock was taken by another, HARDIRQ-safe lock in the past:
 (&(&priv->lock)->rlock#2){-.....}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
 Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(((&hw->end_timer)));
                               local_irq_disable();
                               lock(&(&priv->lock)->rlock#2);
                               lock(((&hw->end_timer)));
  <Interrupt>
    lock(&(&priv->lock)->rlock#2);

 *** DEADLOCK ***

This is fixed by releasing the main spin lock while performing the
del_timer_sync() call. The timer is prevented from restarting before the
lock is reacquired by a new "stopping" flag which img_ir_handle_data()
checks before updating the timer.

---------------------------------------------------------
swapper/0/0 just changed the state of lock:
 (((&hw->end_timer))){+.-...}, at: [<4006ae5c>] _call_timer_fn+0x0/0xfc
but this lock was taken by another, HARDIRQ-safe lock in the past:
 (&(&priv->lock)->rlock#2){-.....}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
 Possible interrupt unsafe locking scenario:
       CPU0                    CPU1
       ----                    ----
  lock(((&hw->end_timer)));
                               local_irq_disable();
                               lock(&(&priv->lock)->rlock#2);
                               lock(((&hw->end_timer)));
  <Interrupt>
    lock(&(&priv->lock)->rlock#2);
 *** DEADLOCK ***
This is fixed by releasing the main spin lock while performing the
del_timer_sync() call. The timer is prevented from restarting before the
lock is reacquired by a new "stopping" flag which img_ir_handle_data()
checks before updating the timer.

Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Sifan Naeem <sifan.naeem@imgtec.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
img-ir/hw: Always read data to clear buffer 2015-01-27T16:29:40+00:00 Dylan Rajaratnam dylan.rajaratnam@imgtec.com 2014-11-17T12:17:45+00:00 7abbdc958907add5be23aac04e691c3706e3a852 commit ea0de4ec5489da0fe738b274effac4f950e93d76 upstream. A problem was found on Polaris where if the unit it booted via the power button on the infrared remote then the next button press on the remote would return the key code used to power on the unit. The sequence is: - The polaris powered off but with the powerdown controller (PDC) block still powered. - Press power key on remote, IR block receives the key. - Kernel starts, IR code is in IMG_IR_DATA_x but neither IMG_IR_RXDVAL or IMG_IR_RXDVALD2 are set. - Wait any amount of time. - Press any key. - IMG_IR_RXDVAL or IMG_IR_RXDVALD2 is set but IMG_IR_DATA_x is unchanged since the powerup key data was never read. This is worked around by always reading the IMG_IR_DATA_x in img_ir_set_decoder(), rather than only when the IMG_IR_RXDVAL or IMG_IR_RXDVALD2 bit is set. Signed-off-by: Dylan Rajaratnam <dylan.rajaratnam@imgtec.com> Signed-off-by: James Hogan <james.hogan@imgtec.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit ea0de4ec5489da0fe738b274effac4f950e93d76 upstream.

A problem was found on Polaris where if the unit it booted via the power
button on the infrared remote then the next button press on the remote
would return the key code used to power on the unit.

The sequence is:
 - The polaris powered off but with the powerdown controller (PDC) block
   still powered.
 - Press power key on remote, IR block receives the key.
 - Kernel starts, IR code is in IMG_IR_DATA_x but neither IMG_IR_RXDVAL
   or IMG_IR_RXDVALD2 are set.
 - Wait any amount of time.
 - Press any key.
 - IMG_IR_RXDVAL or IMG_IR_RXDVALD2 is set but IMG_IR_DATA_x is
   unchanged since the powerup key data was never read.

This is worked around by always reading the IMG_IR_DATA_x in
img_ir_set_decoder(), rather than only when the IMG_IR_RXDVAL or
IMG_IR_RXDVALD2 bit is set.

Signed-off-by: Dylan Rajaratnam <dylan.rajaratnam@imgtec.com>
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
uvcvideo: Fix destruction order in uvc_delete() 2015-01-27T16:29:40+00:00 Takashi Iwai tiwai@suse.de 2014-10-24T08:10:20+00:00 73db430b6665717ba49baa5f06b87e782877c23e commit 2228d80dd05a4fc5a410fde847677b8fb3eb23d7 upstream. We've got a bug report at disconnecting a Webcam, where the kernel spews warnings like below: WARNING: CPU: 0 PID: 8385 at ../fs/sysfs/group.c:219 sysfs_remove_group+0x87/0x90() sysfs group c0b2350c not found for kobject 'event3' CPU: 0 PID: 8385 Comm: queue2:src Not tainted 3.16.2-1.gdcee397-default #1 Hardware name: ASUSTeK Computer INC. A7N8X-E/A7N8X-E, BIOS ASUS A7N8X-E Deluxe ACPI BIOS Rev 1013 11/12/2004 c08d0705 ddc75cbc c0718c5b ddc75ccc c024b654 c08c6d44 ddc75ce8 000020c1 c08d0705 000000db c03d1ec7 c03d1ec7 00000009 00000000 c0b2350c d62c9064 ddc75cd4 c024b6a3 00000009 ddc75ccc c08c6d44 ddc75ce8 ddc75cfc c03d1ec7 Call Trace: [<c0205ba6>] try_stack_unwind+0x156/0x170 [<c02046f3>] dump_trace+0x53/0x180 [<c0205c06>] show_trace_log_lvl+0x46/0x50 [<c0204871>] show_stack_log_lvl+0x51/0xe0 [<c0205c67>] show_stack+0x27/0x50 [<c0718c5b>] dump_stack+0x3e/0x4e [<c024b654>] warn_slowpath_common+0x84/0xa0 [<c024b6a3>] warn_slowpath_fmt+0x33/0x40 [<c03d1ec7>] sysfs_remove_group+0x87/0x90 [<c05a2c54>] device_del+0x34/0x180 [<c05e3989>] evdev_disconnect+0x19/0x50 [<c05e06fa>] __input_unregister_device+0x9a/0x140 [<c05e0845>] input_unregister_device+0x45/0x80 [<f854b1d6>] uvc_delete+0x26/0x110 [uvcvideo] [<f84d66f8>] v4l2_device_release+0x98/0xc0 [videodev] [<c05a25bb>] device_release+0x2b/0x90 [<c04ad8bf>] kobject_cleanup+0x6f/0x1a0 [<f84d5453>] v4l2_release+0x43/0x70 [videodev] [<c0372f31>] __fput+0xb1/0x1b0 [<c02650c1>] task_work_run+0x91/0xb0 [<c024d845>] do_exit+0x265/0x910 [<c024df64>] do_group_exit+0x34/0xa0 [<c025a76f>] get_signal_to_deliver+0x17f/0x590 [<c0201b6a>] do_signal+0x3a/0x960 [<c02024f7>] do_notify_resume+0x67/0x90 [<c071ebb5>] work_notifysig+0x30/0x3b [<b7739e60>] 0xb7739e5f ---[ end trace b1e56095a485b631 ]--- The cause is that uvc_status_cleanup() is called after usb_put_*() in uvc_delete(). usb_put_*() removes the sysfs parent and eventually removes the children recursively, so the later device_del() can't find its sysfs. The fix is simply rearrange the call orders in uvc_delete() so that the child is removed before the parent. Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=897736 Reported-and-tested-by: Martin Pluskal <mpluskal@suse.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 2228d80dd05a4fc5a410fde847677b8fb3eb23d7 upstream.

We've got a bug report at disconnecting a Webcam, where the kernel
spews warnings like below:
  WARNING: CPU: 0 PID: 8385 at ../fs/sysfs/group.c:219 sysfs_remove_group+0x87/0x90()
  sysfs group c0b2350c not found for kobject 'event3'
  CPU: 0 PID: 8385 Comm: queue2:src Not tainted 3.16.2-1.gdcee397-default #1
  Hardware name: ASUSTeK Computer INC. A7N8X-E/A7N8X-E, BIOS ASUS A7N8X-E Deluxe ACPI BIOS Rev 1013  11/12/2004
    c08d0705 ddc75cbc c0718c5b ddc75ccc c024b654 c08c6d44 ddc75ce8 000020c1
    c08d0705 000000db c03d1ec7 c03d1ec7 00000009 00000000 c0b2350c d62c9064
    ddc75cd4 c024b6a3 00000009 ddc75ccc c08c6d44 ddc75ce8 ddc75cfc c03d1ec7
  Call Trace:
    [<c0205ba6>] try_stack_unwind+0x156/0x170
    [<c02046f3>] dump_trace+0x53/0x180
    [<c0205c06>] show_trace_log_lvl+0x46/0x50
    [<c0204871>] show_stack_log_lvl+0x51/0xe0
    [<c0205c67>] show_stack+0x27/0x50
    [<c0718c5b>] dump_stack+0x3e/0x4e
    [<c024b654>] warn_slowpath_common+0x84/0xa0
    [<c024b6a3>] warn_slowpath_fmt+0x33/0x40
    [<c03d1ec7>] sysfs_remove_group+0x87/0x90
    [<c05a2c54>] device_del+0x34/0x180
    [<c05e3989>] evdev_disconnect+0x19/0x50
    [<c05e06fa>] __input_unregister_device+0x9a/0x140
    [<c05e0845>] input_unregister_device+0x45/0x80
    [<f854b1d6>] uvc_delete+0x26/0x110 [uvcvideo]
    [<f84d66f8>] v4l2_device_release+0x98/0xc0 [videodev]
    [<c05a25bb>] device_release+0x2b/0x90
    [<c04ad8bf>] kobject_cleanup+0x6f/0x1a0
    [<f84d5453>] v4l2_release+0x43/0x70 [videodev]
    [<c0372f31>] __fput+0xb1/0x1b0
    [<c02650c1>] task_work_run+0x91/0xb0
    [<c024d845>] do_exit+0x265/0x910
    [<c024df64>] do_group_exit+0x34/0xa0
    [<c025a76f>] get_signal_to_deliver+0x17f/0x590
    [<c0201b6a>] do_signal+0x3a/0x960
    [<c02024f7>] do_notify_resume+0x67/0x90
    [<c071ebb5>] work_notifysig+0x30/0x3b
    [<b7739e60>] 0xb7739e5f
   ---[ end trace b1e56095a485b631 ]---

The cause is that uvc_status_cleanup() is called after usb_put_*() in
uvc_delete().  usb_put_*() removes the sysfs parent and eventually
removes the children recursively, so the later device_del() can't find
its sysfs.  The fix is simply rearrange the call orders in
uvc_delete() so that the child is removed before the parent.

Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=897736
Reported-and-tested-by: Martin Pluskal <mpluskal@suse.com>

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sound: simplify au0828 quirk table 2015-01-27T16:29:39+00:00 Mauro Carvalho Chehab mchehab@osg.samsung.com 2014-10-30T10:53:04+00:00 5eb7814b215eeeda452ad906fec2bfcd78b54fee commit 5d1f00a20d2d56ed480e64e938a2391353ee565b upstream. Add a macro to simplify au0828 quirk table. That makes easier to check it against the USB IDs at drivers/media/usb/au0828/au0828-cards.c. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 5d1f00a20d2d56ed480e64e938a2391353ee565b upstream.

Add a macro to simplify au0828 quirk table. That makes easier
to check it against the USB IDs at drivers/media/usb/au0828/au0828-cards.c.

Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
smiapp: Take mutex during PLL update in sensor initialisation 2015-01-27T16:29:39+00:00 Sakari Ailus sakari.ailus@linux.intel.com 2014-09-16T18:57:07+00:00 129d51a91f17a60e58d2c4201925710431610275 commit f85698cd296f08218a7750f321e94607da128600 upstream. The mutex does not serialise anything in this case but avoids a lockdep warning from the control framework. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit f85698cd296f08218a7750f321e94607da128600 upstream.

The mutex does not serialise anything in this case but avoids a lockdep
warning from the control framework.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
af9005: fix kernel panic on init if compiled without IR 2015-01-27T16:29:39+00:00 Frank Schaefer fschaefer.oss@googlemail.com 2014-09-29T18:17:35+00:00 8d5d2e131054a376d92e685b5946e23f853ffa07 commit 2279948735609d0d17d7384e776b674619f792ef upstream. This patches fixes an ancient bug in the dvb_usb_af9005 driver, which has been reported at least in the following threads: https://lkml.org/lkml/2009/2/4/350 https://lkml.org/lkml/2014/9/18/558 If the driver is compiled in without any IR support (neither DVB_USB_AF9005_REMOTE nor custom symbols), the symbol_request calls in af9005_usb_module_init() return pointers != NULL although the IR symbols are not available. This leads to the following oops: ... [ 8.529751] usbcore: registered new interface driver dvb_usb_af9005 [ 8.531584] BUG: unable to handle kernel paging request at 02e00000 [ 8.533385] IP: [<7d9d67c6>] af9005_usb_module_init+0x6b/0x9d [ 8.535613] *pde = 00000000 [ 8.536416] Oops: 0000 [#1] PREEMPT PREEMPT DEBUG_PAGEALLOCDEBUG_PAGEALLOC [ 8.537863] CPU: 0 PID: 1 Comm: swapper Not tainted 3.15.0-rc6-00151-ga5c075c #1 [ 8.539827] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [ 8.541519] task: 89c9a670 ti: 89c9c000 task.ti: 89c9c000 [ 8.541519] EIP: 0060:[<7d9d67c6>] EFLAGS: 00010206 CPU: 0 [ 8.541519] EIP is at af9005_usb_module_init+0x6b/0x9d [ 8.541519] EAX: 02e00000 EBX: 00000000 ECX: 00000006 EDX: 00000000 [ 8.541519] ESI: 00000000 EDI: 7da33ec8 EBP: 89c9df30 ESP: 89c9df2c [ 8.541519] DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068 [ 8.541519] CR0: 8005003b CR2: 02e00000 CR3: 05a54000 CR4: 00000690 [ 8.541519] Stack: [ 8.541519] 7d9d675b 89c9df90 7d992a49 7d7d5914 89c9df4c 7be3a800 7d08c58c 8a4c3968 [ 8.541519] 89c9df80 7be3a966 00000192 00000006 00000006 7d7d3ff4 8a4c397a 00000200 [ 8.541519] 7d6b1280 8a4c3979 00000006 000009a6 7da32db8 b13eec81 00000006 000009a6 [ 8.541519] Call Trace: [ 8.541519] [<7d9d675b>] ? ttusb2_driver_init+0x16/0x16 [ 8.541519] [<7d992a49>] do_one_initcall+0x77/0x106 [ 8.541519] [<7be3a800>] ? parameqn+0x2/0x35 [ 8.541519] [<7be3a966>] ? parse_args+0x113/0x25c [ 8.541519] [<7d992bc2>] kernel_init_freeable+0xea/0x167 [ 8.541519] [<7cf01070>] kernel_init+0x8/0xb8 [ 8.541519] [<7cf27ec0>] ret_from_kernel_thread+0x20/0x30 [ 8.541519] [<7cf01068>] ? rest_init+0x10c/0x10c [ 8.541519] Code: 08 c2 c7 05 44 ed f9 7d 00 00 e0 02 c7 05 40 ed f9 7d 00 00 e0 02 c7 05 3c ed f9 7d 00 00 e0 02 75 1f b8 00 00 e0 02 85 c0 74 16 <a1> 00 00 e0 02 c7 05 54 84 8e 7d 00 00 e0 02 a3 58 84 8e 7d eb [ 8.541519] EIP: [<7d9d67c6>] af9005_usb_module_init+0x6b/0x9d SS:ESP 0068:89c9df2c [ 8.541519] CR2: 0000000002e00000 [ 8.541519] ---[ end trace 768b6faf51370fc7 ]--- The prefered fix would be to convert the whole IR code to use the kernel IR infrastructure (which wasn't available at the time this driver had been created). Until anyone who still has this old hardware steps up an does the conversion, fix it by not calling the symbol_request calls if the driver is compiled in without the default IR symbols (CONFIG_DVB_USB_AF9005_REMOTE). Due to the IR related pointers beeing NULL by default, IR support will then be disabled. The downside of this solution is, that it will no longer be possible to compile custom IR symbols (not using CONFIG_DVB_USB_AF9005_REMOTE) in. Please note that this patch has NOT been tested with all possible cases. I don't have the hardware and could only verify that it fixes the reported bug. Reported-by: Fengguag Wu <fengguang.wu@intel.com> Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Acked-by: Luca Olivetti <luca@ventoso.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 2279948735609d0d17d7384e776b674619f792ef upstream.

This patches fixes an ancient bug in the dvb_usb_af9005 driver, which
has been reported at least in the following threads:
https://lkml.org/lkml/2009/2/4/350
https://lkml.org/lkml/2014/9/18/558

If the driver is compiled in without any IR support (neither
DVB_USB_AF9005_REMOTE nor custom symbols), the symbol_request calls in
af9005_usb_module_init() return pointers != NULL although the IR
symbols are not available.

This leads to the following oops:
...
[    8.529751] usbcore: registered new interface driver dvb_usb_af9005
[    8.531584] BUG: unable to handle kernel paging request at 02e00000
[    8.533385] IP: [<7d9d67c6>] af9005_usb_module_init+0x6b/0x9d
[    8.535613] *pde = 00000000
[    8.536416] Oops: 0000 [#1] PREEMPT PREEMPT DEBUG_PAGEALLOCDEBUG_PAGEALLOC
[    8.537863] CPU: 0 PID: 1 Comm: swapper Not tainted 3.15.0-rc6-00151-ga5c075c #1
[    8.539827] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[    8.541519] task: 89c9a670 ti: 89c9c000 task.ti: 89c9c000
[    8.541519] EIP: 0060:[<7d9d67c6>] EFLAGS: 00010206 CPU: 0
[    8.541519] EIP is at af9005_usb_module_init+0x6b/0x9d
[    8.541519] EAX: 02e00000 EBX: 00000000 ECX: 00000006 EDX: 00000000
[    8.541519] ESI: 00000000 EDI: 7da33ec8 EBP: 89c9df30 ESP: 89c9df2c
[    8.541519]  DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068
[    8.541519] CR0: 8005003b CR2: 02e00000 CR3: 05a54000 CR4: 00000690
[    8.541519] Stack:
[    8.541519]  7d9d675b 89c9df90 7d992a49 7d7d5914 89c9df4c 7be3a800 7d08c58c 8a4c3968
[    8.541519]  89c9df80 7be3a966 00000192 00000006 00000006 7d7d3ff4 8a4c397a 00000200
[    8.541519]  7d6b1280 8a4c3979 00000006 000009a6 7da32db8 b13eec81 00000006 000009a6
[    8.541519] Call Trace:
[    8.541519]  [<7d9d675b>] ? ttusb2_driver_init+0x16/0x16
[    8.541519]  [<7d992a49>] do_one_initcall+0x77/0x106
[    8.541519]  [<7be3a800>] ? parameqn+0x2/0x35
[    8.541519]  [<7be3a966>] ? parse_args+0x113/0x25c
[    8.541519]  [<7d992bc2>] kernel_init_freeable+0xea/0x167
[    8.541519]  [<7cf01070>] kernel_init+0x8/0xb8
[    8.541519]  [<7cf27ec0>] ret_from_kernel_thread+0x20/0x30
[    8.541519]  [<7cf01068>] ? rest_init+0x10c/0x10c
[    8.541519] Code: 08 c2 c7 05 44 ed f9 7d 00 00 e0 02 c7 05 40 ed f9 7d 00 00 e0 02 c7 05 3c ed f9 7d 00 00 e0 02 75 1f b8 00 00 e0 02 85 c0 74 16 <a1> 00 00 e0 02 c7 05 54 84 8e 7d 00 00 e0 02 a3 58 84 8e 7d eb
[    8.541519] EIP: [<7d9d67c6>] af9005_usb_module_init+0x6b/0x9d SS:ESP 0068:89c9df2c
[    8.541519] CR2: 0000000002e00000
[    8.541519] ---[ end trace 768b6faf51370fc7 ]---

The prefered fix would be to convert the whole IR code to use the kernel IR
infrastructure (which wasn't available at the time this driver had been created).

Until anyone who still has this old hardware steps up an does the conversion,
fix it by not calling the symbol_request calls if the driver is compiled in
without the default IR symbols (CONFIG_DVB_USB_AF9005_REMOTE).
Due to the IR related pointers beeing NULL by default, IR support will then be disabled.

The downside of this solution is, that it will no longer be possible to
compile custom IR symbols (not using CONFIG_DVB_USB_AF9005_REMOTE) in.

Please note that this patch has NOT been tested with all possible cases.
I don't have the hardware and could only verify that it fixes the reported
bug.

Reported-by: Fengguag Wu <fengguang.wu@intel.com>
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: Luca Olivetti <luca@ventoso.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
smiapp-pll: Correct clock debug prints 2015-01-27T16:29:39+00:00 Sakari Ailus sakari.ailus@linux.intel.com 2014-04-01T13:22:46+00:00 b5b7b720cb3674ae1be1daa64c670f348f644256 commit bc47150ab93988714d1fab7bc82fe5f505a107ad upstream. The PLL flags were not used correctly. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit bc47150ab93988714d1fab7bc82fe5f505a107ad upstream.

The PLL flags were not used correctly.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[media] rc-core: fix toggle handling in the rc6 decoder 2014-11-21T17:57:47+00:00 David Härdeman david@hardeman.nu 2014-11-20T21:09:54+00:00 d2a74581390d8e5ed09b12c9d4736847d918dfa6 The toggle bit shouldn't be cleared before the toggle value is calculated. This should probably go into 3.17.x as well. Fixes: 120703f9eb32 ([media] rc-core: document the protocol type) Cc: stable@vger.kernel.org # For v3.17 Tested-by: Stephan Raue <mailinglists@openelec.tv> Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> 
The toggle bit shouldn't be cleared before the toggle value is calculated.

This should probably go into 3.17.x as well.

Fixes: 120703f9eb32 ([media] rc-core: document the protocol type)

Cc: stable@vger.kernel.org # For v3.17
Tested-by: Stephan Raue <mailinglists@openelec.tv>
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[media] cx23885: use sg = sg_next(sg) instead of sg++ 2014-11-21T17:46:58+00:00 Hans Verkuil hverkuil@xs4all.nl 2014-11-21T09:20:56+00:00 7675fe99d280ea83388a4382c54573c80db37cda The cx23885 driver still used sg++ instead of sg = sg_next(sg). This worked with vb1 since that filled in the sglist manually, page-by-page, but it fails with vb2 which uses core scatterlist code that can combine contiguous scatterlist entries into one larger entry. This bug led to the following crash as reported by Mariusz: [20712.990258] BUG: Bad page state in process vb2-cx23885[0] pfn:2ca34 [20712.990265] page:ffffea00009c3b60 count:-1 mapcount:0 mapping: (null) index:0x0 [20712.990266] flags: 0x4000000000000000() [20712.990268] page dumped because: nonzero _count [20712.990269] Modules linked in: tun binfmt_misc nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_mark xt_REDIRECT xt_limit xt_conntrack xt_nat xt_tcpudp iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_filter ip_tables x_tables sit ip_tunnel nvidia(PO) stb6100 stv090x cx88_dvb videobuf_dvb cx88_vp3054_i2c tuner kvm_amd kvm cx8802 k10temp cx8800 cx88xx btcx_risc videobuf_dma_sg videobuf_core usb_storage ds2490 usbhid ftdi_sio cx23885 tveeprom cx2341x videobuf2_dvb videobuf2_core videobuf2_dma_sg videobuf2_memops asus_atk0110 snd_emu10k1 snd_hwdep snd_util_mem snd_ac97_codec ac97_bus snd_rawmidi snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd w1_therm wire ipv6 [20712.990301] CPU: 2 PID: 26942 Comm: vb2-cx23885[0] Tainted: P B W O 3.18.0-rc5-00001-gb3652d1 #2 [20712.990303] Hardware name: System manufacturer System Product Name/M4A785TD-V EVO, BIOS 2105 07/23/2010 [20712.990305] ffffffff81765734 ffff880137683a78 ffffffff815b6b32 0000000000000006 [20712.990307] ffffea00009c3b60 ffff880137683aa8 ffffffff8108ec27 ffffffff81765712 [20712.990309] ffffffff8189c840 0000000000000246 ffffea00009c3b60 ffff880137683b78 [20712.990312] Call Trace: [20712.990317] [<ffffffff815b6b32>] dump_stack+0x46/0x58 [20712.990321] [<ffffffff8108ec27>] bad_page+0xe9/0x107 [20712.990323] [<ffffffff810912ca>] get_page_from_freelist+0x3b2/0x505 [20712.990326] [<ffffffff8109150a>] __alloc_pages_nodemask+0xed/0x65f [20712.990330] [<ffffffff81047a52>] ? ttwu_do_activate.constprop.78+0x57/0x5c [20712.990332] [<ffffffff81049ff3>] ? try_to_wake_up+0x21b/0x22d [20712.990336] [<ffffffff810070f4>] dma_generic_alloc_coherent+0x6e/0xf5 [20712.990339] [<ffffffff810261a9>] gart_alloc_coherent+0x105/0x114 [20712.990341] [<ffffffff81025963>] ? flush_gart+0x39/0x3d [20712.990343] [<ffffffff810260a4>] ? gart_map_sg+0x3a0/0x3a0 [20712.990349] [<ffffffffa0141a1e>] cx23885_risc_databuffer+0xa7/0x133 [cx23885] [20712.990354] [<ffffffffa0142764>] cx23885_buf_prepare+0x121/0x134 [cx23885] [20712.990359] [<ffffffffa0144210>] buffer_prepare+0x14/0x16 [cx23885] [20712.990363] [<ffffffffa011f101>] __buf_prepare+0x190/0x279 [videobuf2_core] [20712.990366] [<ffffffffa011d906>] ? vb2_queue_or_prepare_buf+0xb8/0xc0 [videobuf2_core] [20712.990369] [<ffffffffa011f34b>] vb2_internal_qbuf+0x51/0x1e5 [videobuf2_core] [20712.990372] [<ffffffffa0120537>] vb2_thread+0x199/0x1f6 [videobuf2_core] [20712.990376] [<ffffffffa012039e>] ? vb2_fop_write+0xdf/0xdf [videobuf2_core] [20712.990379] [<ffffffff81043e61>] kthread+0xdf/0xe7 [20712.990381] [<ffffffff81043d82>] ? kthread_create_on_node+0x16d/0x16d [20712.990384] [<ffffffff815bd46c>] ret_from_fork+0x7c/0xb0 [20712.990386] [<ffffffff81043d82>] ? kthread_create_on_node+0x16d/0x16d Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Reported-by: Mariusz Bialonczyk <manio@skyboo.net> Tested-by: Mariusz Bialonczyk <manio@skyboo.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> 
The cx23885 driver still used sg++ instead of sg = sg_next(sg). This worked with
vb1 since that filled in the sglist manually, page-by-page, but it fails with vb2
which uses core scatterlist code that can combine contiguous scatterlist entries
into one larger entry.

This bug led to the following crash as reported by Mariusz:

[20712.990258] BUG: Bad page state in process vb2-cx23885[0]  pfn:2ca34
[20712.990265] page:ffffea00009c3b60 count:-1 mapcount:0 mapping:          (null) index:0x0
[20712.990266] flags: 0x4000000000000000()
[20712.990268] page dumped because: nonzero _count
[20712.990269] Modules linked in: tun binfmt_misc nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_mark xt_REDIRECT xt_limit xt_conntrack xt_nat xt_tcpudp iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_filter ip_tables x_tables sit ip_tunnel nvidia(PO) stb6100 stv090x cx88_dvb videobuf_dvb cx88_vp3054_i2c tuner kvm_amd kvm cx8802 k10temp cx8800 cx88xx btcx_risc videobuf_dma_sg videobuf_core usb_storage ds2490 usbhid ftdi_sio cx23885 tveeprom cx2341x videobuf2_dvb videobuf2_core videobuf2_dma_sg videobuf2_memops asus_atk0110 snd_emu10k1 snd_hwdep snd_util_mem snd_ac97_codec ac97_bus snd_rawmidi snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd w1_therm wire ipv6
[20712.990301] CPU: 2 PID: 26942 Comm: vb2-cx23885[0] Tainted: P    B   W  O   3.18.0-rc5-00001-gb3652d1 #2
[20712.990303] Hardware name: System manufacturer System Product Name/M4A785TD-V EVO, BIOS 2105    07/23/2010
[20712.990305]  ffffffff81765734 ffff880137683a78 ffffffff815b6b32 0000000000000006
[20712.990307]  ffffea00009c3b60 ffff880137683aa8 ffffffff8108ec27 ffffffff81765712
[20712.990309]  ffffffff8189c840 0000000000000246 ffffea00009c3b60 ffff880137683b78
[20712.990312] Call Trace:
[20712.990317]  [<ffffffff815b6b32>] dump_stack+0x46/0x58
[20712.990321]  [<ffffffff8108ec27>] bad_page+0xe9/0x107
[20712.990323]  [<ffffffff810912ca>] get_page_from_freelist+0x3b2/0x505
[20712.990326]  [<ffffffff8109150a>] __alloc_pages_nodemask+0xed/0x65f
[20712.990330]  [<ffffffff81047a52>] ? ttwu_do_activate.constprop.78+0x57/0x5c
[20712.990332]  [<ffffffff81049ff3>] ? try_to_wake_up+0x21b/0x22d
[20712.990336]  [<ffffffff810070f4>] dma_generic_alloc_coherent+0x6e/0xf5
[20712.990339]  [<ffffffff810261a9>] gart_alloc_coherent+0x105/0x114
[20712.990341]  [<ffffffff81025963>] ? flush_gart+0x39/0x3d
[20712.990343]  [<ffffffff810260a4>] ? gart_map_sg+0x3a0/0x3a0
[20712.990349]  [<ffffffffa0141a1e>] cx23885_risc_databuffer+0xa7/0x133 [cx23885]
[20712.990354]  [<ffffffffa0142764>] cx23885_buf_prepare+0x121/0x134 [cx23885]
[20712.990359]  [<ffffffffa0144210>] buffer_prepare+0x14/0x16 [cx23885]
[20712.990363]  [<ffffffffa011f101>] __buf_prepare+0x190/0x279 [videobuf2_core]
[20712.990366]  [<ffffffffa011d906>] ? vb2_queue_or_prepare_buf+0xb8/0xc0 [videobuf2_core]
[20712.990369]  [<ffffffffa011f34b>] vb2_internal_qbuf+0x51/0x1e5 [videobuf2_core]
[20712.990372]  [<ffffffffa0120537>] vb2_thread+0x199/0x1f6 [videobuf2_core]
[20712.990376]  [<ffffffffa012039e>] ? vb2_fop_write+0xdf/0xdf [videobuf2_core]
[20712.990379]  [<ffffffff81043e61>] kthread+0xdf/0xe7
[20712.990381]  [<ffffffff81043d82>] ? kthread_create_on_node+0x16d/0x16d
[20712.990384]  [<ffffffff815bd46c>] ret_from_fork+0x7c/0xb0
[20712.990386]  [<ffffffff81043d82>] ? kthread_create_on_node+0x16d/0x16d

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Reported-by: Mariusz Bialonczyk <manio@skyboo.net>
Tested-by: Mariusz Bialonczyk <manio@skyboo.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>