1. 16 Feb, 2016 20 commits
    • Mauro Carvalho Chehab's avatar
      [media] smsusb: don't sleep while atomic · dd47fbd4
      Mauro Carvalho Chehab authored
      smscore_getbuffer() calls internally wait_event(), with can sleep.
      As smsusb_onresponse() is called on interrupt context, this causes
      the following warning:
      
      	BUG: sleeping function called from invalid context at drivers/media/common/siano/smscoreapi.c:1653
      	in_atomic(): 1, irqs_disabled(): 1, pid: 11084, name: systemd-udevd
      	INFO: lockdep is turned off.
      	irq event stamp: 0
      	hardirqs last  enabled at (0): [<          (null)>]           (null)
      	hardirqs last disabled at (0): [<ffffffff811480f7>] copy_process.part.7+0x10e7/0x56d0
      	softirqs last  enabled at (0): [<ffffffff81148193>] copy_process.part.7+0x1183/0x56d0
      	softirqs last disabled at (0): [<          (null)>]           (null)
      	CPU: 2 PID: 11084 Comm: systemd-udevd Tainted: G    B   W       4.5.0-rc3+ #47
      	Hardware name:                  /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015
      	 0000000000000000 ffff8803c6907a80 ffffffff81933901 ffff8802bd916000
      	 ffff8802bd9165c8 ffff8803c6907aa8 ffffffff811c6af5 ffff8802bd916000
      	 ffffffffa0ce9b60 0000000000000675 ffff8803c6907ae8 ffffffff811c6ce5
      	Call Trace:
      	 <IRQ>  [<ffffffff81933901>] dump_stack+0x85/0xc4
      	 [<ffffffff811c6af5>] ___might_sleep+0x245/0x3a0
      	 [<ffffffff811c6ce5>] __might_sleep+0x95/0x1a0
      	 [<ffffffffa0ce020a>] ? list_add_locked+0xca/0x140 [smsmdtv]
      	 [<ffffffffa0ce3b8d>] smscore_getbuffer+0x7d/0x120 [smsmdtv]
      	 [<ffffffff8123819d>] ? trace_hardirqs_off+0xd/0x10
      	 [<ffffffffa0ce3b10>] ? smscore_sendrequest_and_wait.isra.5+0x120/0x120 [smsmdtv]
      	 [<ffffffffa0ce020a>] ? list_add_locked+0xca/0x140 [smsmdtv]
      	 [<ffffffffa0ce13ca>] ? smscore_putbuffer+0x3a/0x40 [smsmdtv]
      	 [<ffffffffa0d107bc>] smsusb_submit_urb+0x2ec/0x4f0 [smsusb]
      	 [<ffffffffa0d10e36>] smsusb_onresponse+0x476/0x720 [smsusb]
      
      Let's add a work queue to handle the bottom half, preventing this
      problem.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      dd47fbd4
    • Mauro Carvalho Chehab's avatar
      [media] siano: firmware buffer is too small · 21cf734c
      Mauro Carvalho Chehab authored
      As pointed by KASAN:
      
      	BUG: KASAN: slab-out-of-bounds in memcpy+0x1d/0x40 at addr ffff880000038d8c
      	Read of size 128 by task systemd-udevd/2536
      	page:ffffea0000000800 count:1 mapcount:0 mapping:          (null) index:0x0 compound_mapcount: 0
      	flags: 0xffff8000004000(head)
      	page dumped because: kasan: bad access detected
      	CPU: 1 PID: 2536 Comm: systemd-udevd Not tainted 4.5.0-rc3+ #47
      	Hardware name:                  /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015
      	  ffff880000038d8c ffff8803b0f1f1e8 ffffffff81933901 0000000000000080
      	  ffff8803b0f1f280 ffff8803b0f1f270 ffffffff815602c5 ffffffff8284cf93
      	  ffffffff822ddc00 0000000000000282 0000000000000001 ffff88009c7c6000
      	Call Trace:
      	  [<ffffffff81933901>] dump_stack+0x85/0xc4
      	  [<ffffffff815602c5>] kasan_report_error+0x525/0x550
      	  [<ffffffff815606e9>] kasan_report+0x39/0x40
      	  [<ffffffff8155f84d>] memcpy+0x1d/0x40
      	  [<ffffffffa120cb90>] smscore_set_device_mode+0xee0/0x2560 [smsmdtv]
      
      Such error happens at the memcpy code below:
      
      0x4bc0 is in smscore_set_device_mode (drivers/media/common/siano/smscoreapi.c:975).
      970					      sizeof(u32) + payload_size));
      971
      972			data_msg->mem_addr = mem_address;
      973			memcpy(data_msg->payload, payload, payload_size);
      974
      975			rc = smscore_sendrequest_and_wait(coredev, data_msg,
      976					data_msg->x_msg_header.msg_length,
      977					&coredev->data_download_done);
      978
      979			payload += payload_size;
      
      The problem is that the Siano driver uses a header to store the firmware,
      with requires a few more bytes than allocated.
      
      Tested with:
      	PCTV 77e (2013:0257)
      	Hauppauge WinTV MiniStick (2040:5510)
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      21cf734c
    • Mauro Carvalho Chehab's avatar
      Merge branch 'fixes' into patchwork · 8c755c29
      Mauro Carvalho Chehab authored
      Some macros were changed/removed at the material for v4.5. We need
      to sync with those changes here, in order to avoid troubles.
      
      * v4l_for_linus:
        [media] media.h: get rid of MEDIA_ENT_F_CONN_TEST
        [media] [for,v4.5] media.h: increase the spacing between function ranges
        [media] media: i2c/adp1653: probe: fix erroneous return value
        [media] media: davinci_vpfe: fix missing unlock on error in vpfe_prepare_pipeline()
      8c755c29
    • Mauro Carvalho Chehab's avatar
      [media] media.h: get rid of MEDIA_ENT_F_CONN_TEST · 360104e3
      Mauro Carvalho Chehab authored
      Defining it as a connector was a bad idea. Remove it while it is
      not too late.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      360104e3
    • Mauro Carvalho Chehab's avatar
      [media] media.h: get rid of MEDIA_ENT_F_CONN_TEST · 9727a954
      Mauro Carvalho Chehab authored
      Defining it as a connector was a bad idea. Remove it while it is
      not too late.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      9727a954
    • Hans Verkuil's avatar
      [media] [for,v4.5] media.h: increase the spacing between function ranges · 1f452240
      Hans Verkuil authored
      Each function range is quite narrow and especially for connectors this
      will pose a problem. Increase the function ranges while we still can and
      move the connector range to the end so that range is practically limitless.
      
      [mchehab@osg.samsung.com: Rebased to apply at Linus tree]
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      1f452240
    • Mauro Carvalho Chehab's avatar
      [media] tvp5150: replace MEDIA_ENT_F_CONN_TEST by a control · c43875f6
      Mauro Carvalho Chehab authored
      MEDIA_ENT_F_CONN_TEST is not really a connector, it is actually
      a signal generator. Also, as other drivers use the
      V4L2_CID_TEST_PATTERN control for signal generators, let's change
      the driver accordingly.
      
      Tested with Terratec Grabster AV350.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      c43875f6
    • Mauro Carvalho Chehab's avatar
      [media] cx231xx: get rid of CX231XX_VMUX_DEBUG · 22d50e9a
      Mauro Carvalho Chehab authored
      This macro is not used inside the driver. get rid of it.
      Acked-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      22d50e9a
    • Mauro Carvalho Chehab's avatar
      [media] au0828: get rid of AU0828_VMUX_DEBUG · 34ac2532
      Mauro Carvalho Chehab authored
      This is not used on the driver. remove it.
      Acked-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      34ac2532
    • Mauro Carvalho Chehab's avatar
      [media] v4l2-mc: remove the unused sensor var · 153d41a1
      Mauro Carvalho Chehab authored
      This fixes this warning:
      
      	v4l2-mc.c: In function 'v4l2_mc_create_media_graph':
      	v4l2-mc.c:60:69: warning: variable 'sensor' set but not used [-Wunused-but-set-variable]
      
      We could solve it the other way: don't do the second loop for
      webcams. However, that would fail if a chip would have two sensors
      plugged. This is not the current case, but it doesn't hurt to be
      future-safe here, specially since this code runs only once during
      device probe. So, performance is not an issue here.
      Reported-by: default avatarHans Verkuil <hverkuil@xs4all.nl>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      153d41a1
    • Mauro Carvalho Chehab's avatar
      [media] cx231xx: create connectors at the media graph · 6168309a
      Mauro Carvalho Chehab authored
      We need to add connectors to the cx231xx graph.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      6168309a
    • Mauro Carvalho Chehab's avatar
      [media] cx231xx, em28xx: pass media_device to si2157 · 133bc4e4
      Mauro Carvalho Chehab authored
      As si2157 doesn't use the subdev, but has instead a binding
      logic that doesn't have any core framework, we need to manually
      pass the media_device struct via platform data on every place
      it is called.
      
      This fixes support for HVR-955Q when MC is enabled.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      133bc4e4
    • Mauro Carvalho Chehab's avatar
      [media] si2157: register as a tuner entity · 8b0a81c7
      Mauro Carvalho Chehab authored
      As this tuner doesn't use the usual subdev interface, we need
      to register it manually.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      8b0a81c7
    • Mauro Carvalho Chehab's avatar
      [media] cx231xx: use v4l2 core function to create the MC graph · 08f49200
      Mauro Carvalho Chehab authored
      Instead of having its own routine, use the one defined at the
      core, as it is generic enough to handle the cx231xx usecases.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      08f49200
    • Mauro Carvalho Chehab's avatar
      [media] em28xx-dvb: create RF connector on DVB-only mode · e9ef88bd
      Mauro Carvalho Chehab authored
      When in analog mode, the RF connector will be created by
      em28xx-video. However, when the device is in digital mode only,
      the RF connector is not shown. In this case, let the DVB
      core to create it for us.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      e9ef88bd
    • Mauro Carvalho Chehab's avatar
      [media] use v4l2_mc_usb_media_device_init() on most USB devices · 67873d4e
      Mauro Carvalho Chehab authored
      Except for the usbuvc driver (with has an embedded media_device
      struct on it), the other drivers have a pointer to media_device.
      
      On those drivers, replace their own implementation for the core
      one. That warrants that those subdev drivers will fill the
      media_device info the same way.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      67873d4e
    • Mauro Carvalho Chehab's avatar
      [media] allow overriding the driver name · bb07bd6b
      Mauro Carvalho Chehab authored
      On USB drivers, the dev struct is usually filled with the USB
      device. That would mean that the name of the driver specified
      by media_device.dev.driver.name would be "usb", instead of the
      name of the actual driver that created the media entity.
      
      Add an optional field at the internal struct to allow drivers
      to override the driver name.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      bb07bd6b
    • Mauro Carvalho Chehab's avatar
      [media] rc-core: don't lock device at rc_register_device() · c73bbaa4
      Mauro Carvalho Chehab authored
      The mutex lock at rc_register_device() was added by commit 08aeb7c9
      ("[media] rc: add locking to fix register/show race").
      
      It is meant to avoid race issues when trying to open a sysfs file while
      the RC register didn't complete.
      
      Adding a lock there causes troubles, as detected by the Kernel lock
      debug instrumentation at the Kernel:
      
          ======================================================
          [ INFO: possible circular locking dependency detected ]
          4.5.0-rc3+ #46 Not tainted
          -------------------------------------------------------
          systemd-udevd/2681 is trying to acquire lock:
           (s_active#171){++++.+}, at: [<ffffffff8171a115>] kernfs_remove_by_name_ns+0x45/0xa0
      
          but task is already holding lock:
           (&dev->lock){+.+.+.}, at: [<ffffffffa0724def>] rc_register_device+0xb2f/0x1450 [rc_core]
      
          which lock already depends on the new lock.
      
          the existing dependency chain (in reverse order) is:
      
          -> #1 (&dev->lock){+.+.+.}:
                 [<ffffffff8124817d>] lock_acquire+0x13d/0x320
                 [<ffffffff822de966>] mutex_lock_nested+0xb6/0x860
                 [<ffffffffa0721f2b>] show_protocols+0x3b/0x3f0 [rc_core]
                 [<ffffffff81cdaba5>] dev_attr_show+0x45/0xc0
                 [<ffffffff8171f1b3>] sysfs_kf_seq_show+0x203/0x3c0
                 [<ffffffff8171a6a1>] kernfs_seq_show+0x121/0x1b0
                 [<ffffffff81617c71>] seq_read+0x2f1/0x1160
                 [<ffffffff8171c911>] kernfs_fop_read+0x321/0x460
                 [<ffffffff815abc20>] __vfs_read+0xe0/0x3d0
                 [<ffffffff815ae90e>] vfs_read+0xde/0x2d0
                 [<ffffffff815b1d01>] SyS_read+0x111/0x230
                 [<ffffffff822e8636>] entry_SYSCALL_64_fastpath+0x16/0x76
      
          -> #0 (s_active#171){++++.+}:
                 [<ffffffff81244f24>] __lock_acquire+0x4304/0x5990
                 [<ffffffff8124817d>] lock_acquire+0x13d/0x320
                 [<ffffffff81717d3a>] __kernfs_remove+0x58a/0x810
                 [<ffffffff8171a115>] kernfs_remove_by_name_ns+0x45/0xa0
                 [<ffffffff81721592>] remove_files.isra.0+0x72/0x190
                 [<ffffffff8172174b>] sysfs_remove_group+0x9b/0x150
                 [<ffffffff81721854>] sysfs_remove_groups+0x54/0xa0
                 [<ffffffff81cd97d0>] device_remove_attrs+0xb0/0x140
                 [<ffffffff81cdb27c>] device_del+0x38c/0x6b0
                 [<ffffffffa0724b8b>] rc_register_device+0x8cb/0x1450 [rc_core]
                 [<ffffffffa1326a7b>] dvb_usb_remote_init+0x66b/0x14d0 [dvb_usb]
                 [<ffffffffa1321c81>] dvb_usb_device_init+0xf21/0x1860 [dvb_usb]
                 [<ffffffffa13517dc>] dib0700_probe+0x14c/0x410 [dvb_usb_dib0700]
                 [<ffffffff81dbb1dd>] usb_probe_interface+0x45d/0x940
                 [<ffffffff81ce7e7a>] driver_probe_device+0x21a/0xc30
                 [<ffffffff81ce89b1>] __driver_attach+0x121/0x160
                 [<ffffffff81ce21bf>] bus_for_each_dev+0x11f/0x1a0
                 [<ffffffff81ce6cdd>] driver_attach+0x3d/0x50
                 [<ffffffff81ce5df9>] bus_add_driver+0x4c9/0x770
                 [<ffffffff81cea39c>] driver_register+0x18c/0x3b0
                 [<ffffffff81db6e98>] usb_register_driver+0x1f8/0x440
                 [<ffffffffa074001e>] dib0700_driver_init+0x1e/0x1000 [dvb_usb_dib0700]
                 [<ffffffff810021b1>] do_one_initcall+0x141/0x300
                 [<ffffffff8144d8eb>] do_init_module+0x1d0/0x5ad
                 [<ffffffff812f27b6>] load_module+0x6666/0x9ba0
                 [<ffffffff812f5fe8>] SyS_finit_module+0x108/0x130
                 [<ffffffff822e8636>] entry_SYSCALL_64_fastpath+0x16/0x76
      
          other info that might help us debug this:
      
           Possible unsafe locking scenario:
      
                 CPU0                    CPU1
                 ----                    ----
            lock(&dev->lock);
                                         lock(s_active#171);
                                         lock(&dev->lock);
            lock(s_active#171);
      
           *** DEADLOCK ***
      
          3 locks held by systemd-udevd/2681:
           #0:  (&dev->mutex){......}, at: [<ffffffff81ce8933>] __driver_attach+0xa3/0x160
           #1:  (&dev->mutex){......}, at: [<ffffffff81ce8941>] __driver_attach+0xb1/0x160
           #2:  (&dev->lock){+.+.+.}, at: [<ffffffffa0724def>] rc_register_device+0xb2f/0x1450 [rc_core]
      
      In this specific case, some error happened during device init,
      causing IR to be disabled.
      
      Let's fix it by adding a var that will tell when the device is
      initialized. Any calls before that will return a -EINVAL.
      
      That should prevent the race issues.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      c73bbaa4
    • Mauro Carvalho Chehab's avatar
      [media] v4l2-mc: add a routine to create USB media_device · eee7d353
      Mauro Carvalho Chehab authored
      Instead of copying exactly the same code on all USB devices,
      add an ancillary routine that will create and fill the
      struct media_device with the values imported from the USB
      device.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      eee7d353
    • Mauro Carvalho Chehab's avatar
      [media] v4l2-mc.h: prevent it for being included twice · db152276
      Mauro Carvalho Chehab authored
      Don't let it be included twice, to avoid compiler issues.
      Acked-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      db152276
  2. 11 Feb, 2016 3 commits
  3. 10 Feb, 2016 17 commits