1. 03 Mar, 2017 4 commits
    • Sean Young's avatar
      [media] rc: raw decoder for keymap protocol is not loaded on register · 41380868
      Sean Young authored
      When the protocol is set via the sysfs protocols attribute, the
      decoder is loaded. However, when it is not when a device is first
      plugged in or registered.
      
      Fixes: acc1c3c6 ("[media] media: rc: load decoder modules on-demand")
      Signed-off-by: default avatarSean Young <sean@mess.org>
      Cc: <stable@vger.kernel.org> # v4.5+
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      41380868
    • Heiner Kallweit's avatar
      [media] rc: nuvoton: fix deadlock in nvt_write_wakeup_codes · c1305a40
      Heiner Kallweit authored
      nvt_write_wakeup_codes acquires the same lock as the ISR but doesn't
      disable interrupts on the local CPU. This caused the following
      deadlock. Fix this by using spin_lock_irqsave.
      
      [  432.362008] ================================
      [  432.362074] WARNING: inconsistent lock state
      [  432.362144] 4.10.0-rc7-next-20170210 #1 Not tainted
      [  432.362219] --------------------------------
      [  432.362286] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
      [  432.362379] swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
      [  432.362457]  (&(&nvt->lock)->rlock){?.+...}, at: [<ffffffffa016b17d>] nvt_cir_isr+0x2d/0x520 [nuvoton_cir]
      [  432.362611] {HARDIRQ-ON-W} state was registered at:
      [  432.362686]
      [  432.362698] [<ffffffff810adb7c>] __lock_acquire+0x5dc/0x1260
      [  432.362812]
      [  432.362817] [<ffffffff810aec29>] lock_acquire+0xe9/0x1d0
      [  432.362927]
      [  432.362934] [<ffffffff81609f63>] _raw_spin_lock+0x33/0x50
      [  432.363045]
      [  432.363051] [<ffffffffa016b822>] nvt_write_wakeup_codes.isra.12+0x22/0xe0 [nuvoton_cir]
      [  432.363193]
      [  432.363199] [<ffffffffa016b9bf>] wakeup_data_store+0xdf/0xf0 [nuvoton_cir]
      [  432.363327]
      [  432.363333] [<ffffffff81484223>] dev_attr_store+0x13/0x20
      [  432.363441]
      [  432.363449] [<ffffffff81232450>] sysfs_kf_write+0x40/0x50
      [  432.363558]
      [  432.363564] [<ffffffff81231640>] kernfs_fop_write+0x150/0x1e0
      [  432.363676]
      [  432.363685] [<ffffffff811b36a3>] __vfs_write+0x23/0x120
      [  432.363791]
      [  432.363798] [<ffffffff811b4d53>] vfs_write+0xc3/0x1e0
      [  432.363902]
      [  432.363909] [<ffffffff811b6124>] SyS_write+0x44/0xa0
      [  432.364012]
      [  432.364021] [<ffffffff81002c47>] do_syscall_64+0x57/0x140
      [  432.364129]
      [  432.364135] [<ffffffff8160a9e4>] return_from_SYSCALL_64+0x0/0x7a
      [  432.364252] irq event stamp: 415118
      [  432.364313] hardirqs last  enabled at (415115): [<ffffffff814fd2eb>] cpuidle_enter_state+0x11b/0x370
      [  432.364445] hardirqs last disabled at (415116): [<ffffffff8160b2cb>] common_interrupt+0x8b/0x90
      [  432.364573] softirqs last  enabled at (415118): [<ffffffff8106157c>] _local_bh_enable+0x1c/0x50
      [  432.364699] softirqs last disabled at (415117): [<ffffffff810629a3>] irq_enter+0x43/0x60
      [  432.364814]
                     other info that might help us debug this:
      [  432.364909]  Possible unsafe locking scenario:
      
      [  432.367821]        CPU0
      [  432.370645]        ----
      [  432.373432]   lock(&(&nvt->lock)->rlock);
      [  432.376228]   <Interrupt>
      [  432.378982]     lock(&(&nvt->lock)->rlock);
      [  432.381757]
                      *** DEADLOCK ***
      
      [  432.389888] no locks held by swapper/0/0.
      [  432.392574]
                     stack backtrace:
      [  432.397774] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.0-rc7-next-20170210 #1
      [  432.400375] Hardware name: ZOTAC ZBOX-CI321NANO/ZBOX-CI321NANO, BIOS B246P105 06/01/2015
      [  432.403023] Call Trace:
      [  432.405636]  <IRQ>
      [  432.408208]  dump_stack+0x68/0x93
      [  432.410775]  print_usage_bug+0x1dd/0x1f0
      [  432.413334]  mark_lock+0x559/0x5c0
      [  432.415871]  ? print_shortest_lock_dependencies+0x1a0/0x1a0
      [  432.418431]  __lock_acquire+0x6b1/0x1260
      [  432.420941]  lock_acquire+0xe9/0x1d0
      [  432.423396]  ? nvt_cir_isr+0x2d/0x520 [nuvoton_cir]
      [  432.425844]  _raw_spin_lock+0x33/0x50
      [  432.428252]  ? nvt_cir_isr+0x2d/0x520 [nuvoton_cir]
      [  432.430670]  nvt_cir_isr+0x2d/0x520 [nuvoton_cir]
      [  432.433085]  __handle_irq_event_percpu+0x43/0x330
      [  432.435493]  handle_irq_event_percpu+0x1e/0x50
      [  432.437884]  handle_irq_event+0x34/0x60
      [  432.440236]  handle_edge_irq+0x6a/0x150
      [  432.442561]  handle_irq+0x15/0x20
      [  432.444854]  do_IRQ+0x57/0x110
      [  432.447115]  common_interrupt+0x90/0x90
      [  432.449380] RIP: 0010:cpuidle_enter_state+0x120/0x370
      [  432.451653] RSP: 0018:ffffffff81c03dd8 EFLAGS: 00000206 ORIG_RAX: ffffffffffffffcc
      [  432.453994] RAX: ffffffff81c14500 RBX: 0000000000000008 RCX: 00000064aac6f2d2
      [  432.456349] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff81c14500
      [  432.458704] RBP: ffffffff81c03e18 R08: cccccccccccccccd R09: 0000000000000018
      [  432.461072] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880100a21260
      [  432.463450] R13: ffffffff81c7e6f8 R14: 0000000000000008 R15: ffffffff81c7e6e0
      [  432.465819]  </IRQ>
      [  432.468104]  ? cpuidle_enter_state+0x11b/0x370
      [  432.470413]  cpuidle_enter+0x12/0x20
      [  432.472698]  call_cpuidle+0x1e/0x40
      [  432.474967]  do_idle+0xe3/0x1c0
      [  432.477172]  cpu_startup_entry+0x18/0x20
      [  432.479376]  rest_init+0x130/0x140
      [  432.481565]  start_kernel+0x3cc/0x3d9
      [  432.483750]  x86_64_start_reservations+0x2a/0x2c
      [  432.485980]  x86_64_start_kernel+0x178/0x18b
      [  432.488222]  start_cpu+0x14/0x14
      [  432.490453]  ? start_cpu+0x14/0x14
      
      Fixes: 97c12974 "[media] rc: nuvoton-cir: Add support wakeup via sysfs filter callback"
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarSean Young <sean@mess.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      c1305a40
    • Sean Young's avatar
      [media] lirc: fix dead lock between open and wakeup_filter · db5b15b7
      Sean Young authored
      The locking in lirc needs improvement, but for now just fix this potential
      deadlock.
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      4.10.0-rc1+ #1 Not tainted
      -------------------------------------------------------
      bash/2502 is trying to acquire lock:
       (ir_raw_handler_lock){+.+.+.}, at: [<ffffffffc06f6a5e>] ir_raw_encode_scancode+0x3e/0xb0 [rc_core]
      
                     but task is already holding lock:
       (&dev->lock){+.+.+.}, at: [<ffffffffc06f511f>] store_filter+0x9f/0x240 [rc_core]
      
                     which lock already depends on the new lock.
      
                     the existing dependency chain (in reverse order) is:
      
                     -> #2 (&dev->lock){+.+.+.}:
      
      [<ffffffffa110adad>] lock_acquire+0xfd/0x200
      [<ffffffffa1921327>] mutex_lock_nested+0x77/0x6d0
      [<ffffffffc06f436a>] rc_open+0x2a/0x80 [rc_core]
      [<ffffffffc07114ca>] lirc_dev_fop_open+0xda/0x1e0 [lirc_dev]
      [<ffffffffa12975e0>] chrdev_open+0xb0/0x210
      [<ffffffffa128eb5a>] do_dentry_open+0x20a/0x2f0
      [<ffffffffa128ffcc>] vfs_open+0x4c/0x80
      [<ffffffffa12a35ec>] path_openat+0x5bc/0xc00
      [<ffffffffa12a5271>] do_filp_open+0x91/0x100
      [<ffffffffa12903f0>] do_sys_open+0x130/0x220
      [<ffffffffa12904fe>] SyS_open+0x1e/0x20
      [<ffffffffa19278c1>] entry_SYSCALL_64_fastpath+0x1f/0xc2
                     -> #1 (lirc_dev_lock){+.+.+.}:
      [<ffffffffa110adad>] lock_acquire+0xfd/0x200
      [<ffffffffa1921327>] mutex_lock_nested+0x77/0x6d0
      [<ffffffffc0711f47>] lirc_register_driver+0x67/0x59b [lirc_dev]
      [<ffffffffc06db7f4>] ir_lirc_register+0x1f4/0x260 [ir_lirc_codec]
      [<ffffffffc06f6cac>] ir_raw_handler_register+0x7c/0xb0 [rc_core]
      [<ffffffffc0398010>] 0xffffffffc0398010
      [<ffffffffa1002192>] do_one_initcall+0x52/0x1b0
      [<ffffffffa11ef5c8>] do_init_module+0x5f/0x1fa
      [<ffffffffa11566b5>] load_module+0x2675/0x2b00
      [<ffffffffa1156dcf>] SYSC_finit_module+0xdf/0x110
      [<ffffffffa1156e1e>] SyS_finit_module+0xe/0x10
      [<ffffffffa1003f5c>] do_syscall_64+0x6c/0x1f0
      [<ffffffffa1927989>] return_from_SYSCALL_64+0x0/0x7a
                     -> #0 (ir_raw_handler_lock){+.+.+.}:
      [<ffffffffa110a7b7>] __lock_acquire+0x10f7/0x1290
      [<ffffffffa110adad>] lock_acquire+0xfd/0x200
      [<ffffffffa1921327>] mutex_lock_nested+0x77/0x6d0
      [<ffffffffc06f6a5e>] ir_raw_encode_scancode+0x3e/0xb0 [rc_core]
      [<ffffffffc0b0f492>] loop_set_wakeup_filter+0x62/0xbd [rc_loopback]
      [<ffffffffc06f522a>] store_filter+0x1aa/0x240 [rc_core]
      [<ffffffffa15e46f8>] dev_attr_store+0x18/0x30
      [<ffffffffa13318e5>] sysfs_kf_write+0x45/0x60
      [<ffffffffa1330b55>] kernfs_fop_write+0x155/0x1e0
      [<ffffffffa1290797>] __vfs_write+0x37/0x160
      [<ffffffffa12921f8>] vfs_write+0xc8/0x1e0
      [<ffffffffa12936e8>] SyS_write+0x58/0xc0
      [<ffffffffa19278c1>] entry_SYSCALL_64_fastpath+0x1f/0xc2
      
                     other info that might help us debug this:
      
      Chain exists of:
                       ir_raw_handler_lock --> lirc_dev_lock --> &dev->lock
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&dev->lock);
                                     lock(lirc_dev_lock);
                                     lock(&dev->lock);
        lock(ir_raw_handler_lock);
      
                      *** DEADLOCK ***
      
      4 locks held by bash/2502:
       #0:  (sb_writers#4){.+.+.+}, at: [<ffffffffa12922c5>] vfs_write+0x195/0x1e0
       #1:  (&of->mutex){+.+.+.}, at: [<ffffffffa1330b1f>] kernfs_fop_write+0x11f/0x1e0
       #2:  (s_active#215){.+.+.+}, at: [<ffffffffa1330b28>] kernfs_fop_write+0x128/0x1e0
       #3:  (&dev->lock){+.+.+.}, at: [<ffffffffc06f511f>] store_filter+0x9f/0x240 [rc_core]
      
                     stack backtrace:
      CPU: 3 PID: 2502 Comm: bash Not tainted 4.10.0-rc1+ #1
      Hardware name:                  /DG45ID, BIOS IDG4510H.86A.0135.2011.0225.1100 02/25/2011
      Call Trace:
       dump_stack+0x86/0xc3
       print_circular_bug+0x1be/0x210
       __lock_acquire+0x10f7/0x1290
       lock_acquire+0xfd/0x200
       ? ir_raw_encode_scancode+0x3e/0xb0 [rc_core]
       ? ir_raw_encode_scancode+0x3e/0xb0 [rc_core]
       mutex_lock_nested+0x77/0x6d0
       ? ir_raw_encode_scancode+0x3e/0xb0 [rc_core]
       ? loop_set_wakeup_filter+0x44/0xbd [rc_loopback]
       ir_raw_encode_scancode+0x3e/0xb0 [rc_core]
       loop_set_wakeup_filter+0x62/0xbd [rc_loopback]
       ? loop_set_tx_duty_cycle+0x70/0x70 [rc_loopback]
       store_filter+0x1aa/0x240 [rc_core]
       dev_attr_store+0x18/0x30
       sysfs_kf_write+0x45/0x60
       kernfs_fop_write+0x155/0x1e0
       __vfs_write+0x37/0x160
       ? rcu_read_lock_sched_held+0x4a/0x80
       ? rcu_sync_lockdep_assert+0x2f/0x60
       ? __sb_start_write+0x10c/0x220
       ? vfs_write+0x195/0x1e0
       ? security_file_permission+0x3b/0xc0
       vfs_write+0xc8/0x1e0
       SyS_write+0x58/0xc0
       entry_SYSCALL_64_fastpath+0x1f/0xc2
      Signed-off-by: default avatarSean Young <sean@mess.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      db5b15b7
    • Sean Young's avatar
      [media] serial_ir: ensure we're ready to receive interrupts · 0265634e
      Sean Young authored
      When the interrupt requested with devm_request_irq(), serial_ir.rcdev
      is still null so will cause null deference if the irq handler is called
      early on.
      
      Also ensure that timeout_timer is setup.
      
      Link: http://lkml.kernel.org/r/CA+55aFxsh2uF8gi5sN_guY3Z+tiLv7LpJYKBw+y8vqLzp+TsnQ@mail.gmail.com
      
      [mchehab@s-opensource.com: moved serial_ir_probe() back to its original place]
      
      Cc: <stable@vger.kernel.org> # 4.10
      Signed-off-by: default avatarSean Young <sean@mess.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      0265634e
  2. 08 Feb, 2017 22 commits
  3. 07 Feb, 2017 2 commits
  4. 03 Feb, 2017 12 commits
    • Tuukka Toivonen's avatar
      [media] v4l2-async: failing functions shouldn't have side effects · 47b037a0
      Tuukka Toivonen authored
      v4l2-async had several functions doing some operations and then
      not undoing the operations in a failure situation. For example,
      v4l2_async_test_notify() moved a subdev into notifier's done list
      even if registering the subdev (v4l2_device_register_subdev) failed.
      If the subdev was allocated and v4l2_async_register_subdev() called
      from the driver's probe() function, as usually, the probe()
      function freed the allocated subdev and returned a failure.
      Nevertheless, the subdev was still left into the notifier's done
      list, causing an access to already freed memory when the notifier
      was later unregistered.
      
      A hand-edited call trace leaving freed subdevs into the notifier:
      
      v4l2_async_register_notifier(notifier, asd)
      cameradrv_probe
       sd = devm_kzalloc()
       v4l2_async_register_subdev(sd)
        v4l2_async_test_notify(notifier, sd, asd)
         list_move(sd, &notifier->done)
         v4l2_device_register_subdev(notifier->v4l2_dev, sd)
          cameradrv_registered(sd) -> fails
      ->v4l2_async_register_subdev returns failure
      ->cameradrv_probe returns failure
      ->devres frees the allocated sd
      ->sd was freed but it still remains in the notifier's list.
      
      This patch fixes this and several other cases where a failing
      function could leave nodes into a linked list while the caller
      might free the node due to a failure.
      Signed-off-by: default avatarTuukka Toivonen <tuukka.toivonen@intel.com>
      Acked-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      47b037a0
    • Dan Carpenter's avatar
      [media] mantis_dvb: fix some error codes in mantis_dvb_init() · 79a2eda8
      Dan Carpenter authored
      We should be returning negative error codes here or it leads to a crash.
      This also silences a static checker warning.
      
      	drivers/media/pci/mantis/mantis_cards.c:250 mantis_pci_probe()
      	warn: 'mantis->dmxdev.dvbdev->fops' double freed
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      79a2eda8
    • Javier Martinez Canillas's avatar
      [media] exynos-gsc: Avoid spamming the log on VIDIOC_TRY_FMT · c2987aaf
      Javier Martinez Canillas authored
      There isn't an ioctl to enum the supported field orders, so a user-space
      application can call VIDIOC_TRY_FMT using different field orders to know
      if one is supported. For example, GStreamer does this so during playback
      dozens of the following messages appear in the kernel log buffer:
      
      [ 442.143393] Not supported field order(4)
      
      Instead of printing this as an error, just keep it as debug information.
      Signed-off-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      c2987aaf
    • Mauro Carvalho Chehab's avatar
      [media] dvb-usb: don't use stack for firmware load · 43fab979
      Mauro Carvalho Chehab authored
      As reported by Marc Duponcheel <marc@offline.be>, firmware load on
      dvb-usb is using the stack, with is not allowed anymore on default
      Kernel configurations:
      
      [ 1025.958836] dvb-usb: found a 'WideView WT-220U PenType Receiver (based on ZL353)' in cold state, will try to load a firmware
      [ 1025.958853] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-zl0353-01.fw'
      [ 1025.958855] dvb-usb: could not stop the USB controller CPU.
      [ 1025.958856] dvb-usb: error while transferring firmware (transferred size: -11, block size: 3)
      [ 1025.958856] dvb-usb: firmware download failed at 8 with -22
      [ 1025.958867] usbcore: registered new interface driver dvb_usb_dtt200u
      
      [    2.789902] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-zl0353-01.fw'
      [    2.789905] ------------[ cut here ]------------
      [    2.789911] WARNING: CPU: 3 PID: 2196 at drivers/usb/core/hcd.c:1584 usb_hcd_map_urb_for_dma+0x430/0x560 [usbcore]
      [    2.789912] transfer buffer not dma capable
      [    2.789912] Modules linked in: btusb dvb_usb_dtt200u(+) dvb_usb_af9035(+) btrtl btbcm dvb_usb dvb_usb_v2 btintel dvb_core bluetooth rc_core rfkill x86_pkg_temp_thermal intel_powerclamp coretemp crc32_pclmul aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd drm_kms_helper syscopyarea sysfillrect pcspkr i2c_i801 sysimgblt fb_sys_fops drm i2c_smbus i2c_core r8169 lpc_ich mfd_core mii thermal fan rtc_cmos video button acpi_cpufreq processor snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd crc32c_intel ahci libahci libata xhci_pci ehci_pci xhci_hcd ehci_hcd usbcore usb_common dm_mirror dm_region_hash dm_log dm_mod
      [    2.789936] CPU: 3 PID: 2196 Comm: systemd-udevd Not tainted 4.9.0-gentoo #1
      [    2.789937] Hardware name: ASUS All Series/H81I-PLUS, BIOS 0401 07/23/2013
      [    2.789938]  ffffc9000339b690 ffffffff812bd397 ffffc9000339b6e0 0000000000000000
      [    2.789939]  ffffc9000339b6d0 ffffffff81055c86 000006300339b6a0 ffff880116c0c000
      [    2.789941]  0000000000000000 0000000000000000 0000000000000001 ffff880116c08000
      [    2.789942] Call Trace:
      [    2.789945]  [<ffffffff812bd397>] dump_stack+0x4d/0x66
      [    2.789947]  [<ffffffff81055c86>] __warn+0xc6/0xe0
      [    2.789948]  [<ffffffff81055cea>] warn_slowpath_fmt+0x4a/0x50
      [    2.789952]  [<ffffffffa006d460>] usb_hcd_map_urb_for_dma+0x430/0x560 [usbcore]
      [    2.789954]  [<ffffffff814ed5a8>] ? io_schedule_timeout+0xd8/0x110
      [    2.789956]  [<ffffffffa006e09c>] usb_hcd_submit_urb+0x9c/0x980 [usbcore]
      [    2.789958]  [<ffffffff812d0ebf>] ? copy_page_to_iter+0x14f/0x2b0
      [    2.789960]  [<ffffffff81126818>] ? pagecache_get_page+0x28/0x240
      [    2.789962]  [<ffffffff8118c2a0>] ? touch_atime+0x20/0xa0
      [    2.789964]  [<ffffffffa006f7c4>] usb_submit_urb+0x2c4/0x520 [usbcore]
      [    2.789967]  [<ffffffffa006feca>] usb_start_wait_urb+0x5a/0xe0 [usbcore]
      [    2.789969]  [<ffffffffa007000c>] usb_control_msg+0xbc/0xf0 [usbcore]
      [    2.789970]  [<ffffffffa067903d>] usb_cypress_writemem+0x3d/0x40 [dvb_usb]
      [    2.789972]  [<ffffffffa06791cf>] usb_cypress_load_firmware+0x4f/0x130 [dvb_usb]
      [    2.789973]  [<ffffffff8109dbbe>] ? console_unlock+0x2fe/0x5d0
      [    2.789974]  [<ffffffff8109e10c>] ? vprintk_emit+0x27c/0x410
      [    2.789975]  [<ffffffff8109e40a>] ? vprintk_default+0x1a/0x20
      [    2.789976]  [<ffffffff81124d76>] ? printk+0x43/0x4b
      [    2.789977]  [<ffffffffa0679310>] dvb_usb_download_firmware+0x60/0xd0 [dvb_usb]
      [    2.789979]  [<ffffffffa0679898>] dvb_usb_device_init+0x3d8/0x610 [dvb_usb]
      [    2.789981]  [<ffffffffa069e302>] dtt200u_usb_probe+0x92/0xd0 [dvb_usb_dtt200u]
      [    2.789984]  [<ffffffffa007420c>] usb_probe_interface+0xfc/0x270 [usbcore]
      [    2.789985]  [<ffffffff8138bf95>] driver_probe_device+0x215/0x2d0
      [    2.789986]  [<ffffffff8138c0e6>] __driver_attach+0x96/0xa0
      [    2.789987]  [<ffffffff8138c050>] ? driver_probe_device+0x2d0/0x2d0
      [    2.789988]  [<ffffffff81389ffb>] bus_for_each_dev+0x5b/0x90
      [    2.789989]  [<ffffffff8138b7b9>] driver_attach+0x19/0x20
      [    2.789990]  [<ffffffff8138b33c>] bus_add_driver+0x11c/0x220
      [    2.789991]  [<ffffffff8138c91b>] driver_register+0x5b/0xd0
      [    2.789994]  [<ffffffffa0072f6c>] usb_register_driver+0x7c/0x130 [usbcore]
      [    2.789994]  [<ffffffffa06a5000>] ? 0xffffffffa06a5000
      [    2.789996]  [<ffffffffa06a501e>] dtt200u_usb_driver_init+0x1e/0x20 [dvb_usb_dtt200u]
      [    2.789997]  [<ffffffff81000408>] do_one_initcall+0x38/0x140
      [    2.789998]  [<ffffffff8116001c>] ? __vunmap+0x7c/0xc0
      [    2.789999]  [<ffffffff81124fb0>] ? do_init_module+0x22/0x1d2
      [    2.790000]  [<ffffffff81124fe8>] do_init_module+0x5a/0x1d2
      [    2.790002]  [<ffffffff810c96b1>] load_module+0x1e11/0x2580
      [    2.790003]  [<ffffffff810c68b0>] ? show_taint+0x30/0x30
      [    2.790004]  [<ffffffff81177250>] ? kernel_read_file+0x100/0x190
      [    2.790005]  [<ffffffff810c9ffa>] SyS_finit_module+0xba/0xc0
      [    2.790007]  [<ffffffff814f13e0>] entry_SYSCALL_64_fastpath+0x13/0x94
      [    2.790008] ---[ end trace c78a74e78baec6fc ]---
      
      So, allocate the structure dynamically.
      
      Cc: stable@vger.kernel.org # Kernel 4.9+
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      43fab979
    • Christophe JAILLET's avatar
      [media] exynos4-is: Add missing 'of_node_put' · 2b2d1d40
      Christophe JAILLET authored
      It is likely that a "of_node_put(ep)" is missing here.
      There is one in the previous error handling code, and one a few lines
      below in the normal case as well.
      Signed-off-by: default avatarChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      2b2d1d40
    • Bhumika Goyal's avatar
      [media] media: dvb-frontends: constify vb2_ops structure · dd93e79c
      Bhumika Goyal authored
      Declare vb2_ops structure as const as it is only stored in
      the ops field of a vb2_queue structure. This field is of type
      const, so vb2_ops structures having same properties can be made
      const too.
      Done using Coccinelle:
      
      @r1 disable optional_qualifier@
      identifier i;
      position p;
      @@
      static struct vb2_ops i@p={...};
      
      @ok1@
      identifier r1.i;
      position p;
      struct sta2x11_vip vip;
      struct vb2_queue q;
      @@
      (
      vip.vb_vidq.ops=&i@p
      |
      q.ops=&i@p
      )
      
      @bad@
      position p!={r1.p,ok1.p};
      identifier r1.i;
      @@
      i@p
      
      @depends on !bad disable optional_qualifier@
      identifier r1.i;
      @@
      +const
      struct vb2_ops i;
      
      File size details of media/dvb-frontends/rtl2832_sdr.o file remains the
      same before and after applying the patch.
      Signed-off-by: default avatarBhumika Goyal <bhumirks@gmail.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      dd93e79c
    • Bhumika Goyal's avatar
      [media] media: pci: constify vb2_ops structure · 8b6fe20a
      Bhumika Goyal authored
      Declare vb2_ops structure as const as it is only stored in
      the ops field of a vb2_queue structure. This field is of type
      const, so vb2_ops structures having same properties can be made
      const too.
      Done using Coccinelle:
      
      @r1 disable optional_qualifier@
      identifier i;
      position p;
      @@
      static struct vb2_ops i@p={...};
      
      @ok1@
      identifier r1.i;
      position p;
      struct sta2x11_vip vip;
      struct vb2_queue q;
      @@
      (
      vip.vb_vidq.ops=&i@p
      |
      q.ops=&i@p
      )
      
      @bad@
      position p!={r1.p,ok1.p};
      identifier r1.i;
      @@
      i@p
      
      @depends on !bad disable optional_qualifier@
      identifier r1.i;
      @@
      +const
      struct vb2_ops i;
      
      File size before:
         text	   data	    bss	    dec	    hex	filename
         8448	    440	      0	   8888	   22b8	media/pci/sta2x11/sta2x11_vip.o
      
      File size after:
         text	   data	    bss	    dec	    hex	filename
         8552	    352	      0	   8904	   22c8	media/pci/sta2x11/sta2x11_vip.o
      Signed-off-by: default avatarBhumika Goyal <bhumirks@gmail.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      8b6fe20a
    • Laurent Pinchart's avatar
      [media] v4l: subdev: Clean up properly in subdev devnode registration error path · 909aa003
      Laurent Pinchart authored
      Set the subdev devnode pointer right after registration to ensure that
      later errors won't skip the subdev when unregistering all devnodes.
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Acked-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      909aa003
    • Baruch Siach's avatar
      [media] coda: add Freescale firmware compatibility location · 8af7779f
      Baruch Siach authored
      The Freescale provided imx-vpu looks for firmware files under /lib/firmware/vpu
      by default. Make coda look there for firmware files to ease the update path.
      
      Cc: Fabio Estevam <festevam@gmail.com>
      Signed-off-by: default avatarBaruch Siach <baruch@tkos.co.il>
      Reviewed-by: default avatarFabio Estevam <fabio.estevam@nxp.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      8af7779f
    • Sean Young's avatar
      [media] mce_kbd: add missing keys from UK layout · 44750606
      Sean Young authored
      The UK layout of the Microsoft Remote Keyboard has two missing keys:
      the hash key, and the messenger key which is sent using rc6 mce.
      Signed-off-by: default avatarSean Young <sean@mess.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      44750606
    • Sean Young's avatar
      [media] lirc: cannot read from tx-only device · 32002f72
      Sean Young authored
      Bail out early, otherwise we follow a null pointer.
      Signed-off-by: default avatarSean Young <sean@mess.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      32002f72
    • Martin Blumenstingl's avatar
      7a6628b5