- 22 Sep, 2016 40 commits
-
-
Mauro Carvalho Chehab authored
Make sure that it won't go past the config buffers drivers/media/pci/cx23885/cx23885-dvb.c:1733 dvb_register() warn: buffer overflow 'netup_xc5000_config' 2 <= s32max drivers/media/pci/cx23885/cx23885-dvb.c:1745 dvb_register() warn: buffer overflow 'netup_stv0367_config' 2 <= s32max drivers/media/pci/cx23885/cx23885-dvb.c:1752 dvb_register() warn: buffer overflow 'netup_xc5000_config' 2 <= s32max Signed-off-by:Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
Matthias Schwarzott authored
This avoids some low-level operations. It has the benefit that now register values van be read from /sys/kernel/debug/regmap The maximum register value is just a guess - all higher addresses read as zero. Signed-off-by:
Matthias Schwarzott <zzam@gentoo.org> Signed-off-by:
-
Matthias Schwarzott authored
Now that there is a i2c_client, use the more specific dev for logging. Signed-off-by:
-
Matthias Schwarzott authored
Now that all users of legacy attach are converted it can be removed. Signed-off-by:
-
Matthias Schwarzott authored
Use new style attach. Signed-off-by:
-
Matthias Schwarzott authored
cx231xx does not yet support attaching new-style i2c_client DVB demod drivers. Add necessary code base on tuner support for i2c_client. Signed-off-by:
-
Matthias Schwarzott authored
Use new style attach. Signed-off-by:
-
Matthias Schwarzott authored
Afterwards it is possible to convert attaching in card drivers. Signed-off-by:
-
Matthias Schwarzott authored
When si2165_init fails, the clk values in state are still at zero. But the dvb-core ignores the return value of init will call tune afterwards. This will trigger a division by zero when tuning. At least check for the variables to be non-zero before dividing. This happened for a system with WinTV HVR-4400 PCIe-card after suspend-to-disk. Do suspend-to-disk without accessing the DVB device before. After wakeup try to tune. si2165_init fails at checking the chip_mode and aborts. Then si2165_set_if_freq_shift will fail with div-by-zero. Signed-off-by:
-
Sergei Shtylyov authored
Such fallback string is present in the 'soc_camera' version of the R-Car VIN driver, so need to add it here as well... Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Acked-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
-
Abylay Ospan authored
inside lgdt3306a_search we reading demod status 20 times with 50 msec sleep after each read. This gives us more than 1 sec of delay. Removing this delay should not affect demod functionality. Signed-off-by:
Abylay Ospan <aospan@netup.ru> Acked-by:
Michael Ira Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Bhaktipriya Shridhar authored
The workqueue "_irq_audio_queues" runs the audio upstream handler. It has a single work item(&dev->_audio_work_entry) and hence doesn't require ordering. Also, it is not being used on a memory reclaim path. Hence, the singlethreaded workqueue has been replaced with the use of system_wq. System workqueues have been able to handle high level of concurrency for a long time now and hence it's not required to have a singlethreaded workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue created with create_singlethread_workqueue(), system_wq allows multiple work items to overlap executions even on the same CPU; however, a per-cpu workqueue doesn't have any CPU locality or global ordering guarantee unless the target CPU is explicitly specified and thus the increase of local concurrency shouldn't make any difference. The work item has been flushed in cx25821_stop_upstream_audio() to ensure that nothing is pending when the driver is disconnected. Signed-off-by:
Bhaktipriya Shridhar <bhaktipriya96@gmail.com> Signed-off-by:
-
Bhaktipriya Shridhar authored
Workqueues shouldn't be freed. destroy_workqueue should be used instead. destroy_workqueue safely destroys a workqueue and ensures that all pending work items are done before destroying the workqueue. Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Abylay Ospan authored
if specified DVB-C bandwidth not supported then force 8MHz. Should work for most cases. Signed-off-by:
-
Sean Young authored
Add these options as module parameters for now; should other drivers need similar options we could add it to the LIRC api. Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Sean Young authored
This is a duplicate of the timeout in rc_dev. Signed-off-by:
-
Abylay Ospan authored
Added function to read BER for ISDB-T Also SNR values fixed for ISDB-T Signed-off-by:
-
Arnd Bergmann authored
Tha ARM randconfig builds came up with another rare build failure for the dib3000mc driver, when dvb-usb-dibusb-mb is built-in and dib3000mc is a loadable module: ERROR: "dibusb_dib3000mc_frontend_attach" [drivers/media/usb/dvb-usb/dvb-usb-nova-t-usb2.ko] undefined! ERROR: "dibusb_dib3000mc_tuner_attach" [drivers/media/usb/dvb-usb/dvb-usb-nova-t-usb2.ko] undefined! Apparently this used to be a valid configuration (build-time, not run-time), but broke as part of a cleanup. I tried reverting the cleanup, but saw that the code was still wrong then. This version adds a dependency for dib3000mb, to ensure that dib3000mb does not force the dibusb_dib3000mc_frontend_attach function to be built-in when dib3000mc is a loadable module. I have also checked the two other files that were changed in the original cleanup, and found them to be correct in either version, so I do not touch that part. As this is a rather obscure bug, there is no need for backports. Fixes: 028c70ff ("[media] dvb-usb/dvb-usb-v2: use IS_ENABLED") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
Tha ARM randconfig builds came up with another rare build failure for the dib3000mc driver, when dvb-usb-dibusb-mb is built-in and dib3000mc is a loadable module: ERROR: "dibusb_dib3000mc_frontend_attach" [drivers/media/usb/dvb-usb/dvb-usb-nova-t-usb2.ko] undefined! ERROR: "dibusb_dib3000mc_tuner_attach" [drivers/media/usb/dvb-usb/dvb-usb-nova-t-usb2.ko] undefined! Apparently this used to be a valid configuration (build-time, not run-time), but broke as part of a cleanup. I tried reverting the cleanup, but saw that the code was still wrong then. This tries to fix the code properly, by moving the problematic functions into a new file that now is built as a loadable module or built-in, whichever is correct for a particular configuration. It fixes the regression as well as the runtime problem that already existed. The new module dependency chain is now: dvb-usb-{dibusb_mc,a800,dib0700,umt-010,gp8psk} dvb-usb-dibusb-mb | | | | dvb-usb-dibusb-mc-common | ___________| | | | | | | dib3000mc (frontend) | | | dib3000mb (frontend) | | | | | | dvb-usb-dibusb-common I have also checked the two other files that were changed in the original cleanup, and found them to be correct in either version, so I do not touch that part. As this is a rather obscure bug, there is no need for backports. Fixes: 028c70ff ("[media] dvb-usb/dvb-usb-v2: use IS_ENABLED") Signed-off-by: -
Wei Yongjun authored
Add the missing platform_device_del() before return from lirc_parallel_init() in the error handling case. Signed-off-by:Wei Yongjun <yongjun_wei@trendmicro.com.cn>
-
Abylay Ospan authored
ensure multiple separate register reads are from the same snapshot Signed-off-by:
-
Sean Young authored
Currently we do not know what variant (bit length) of the nec protocol is used, other than from guessing from the length of the scancode. Now nec will be handled the same way as the sony protocol or the rc6 protocol; one variant per bit length. In the future we might want to expose the rc protocol type to userspace and we don't want to be introducing this world of pain into userspace too. Signed-off-by:
-
Sean Young authored
The hardware does not decode the 16, 20 or 24 bit variety. Signed-off-by:
-
Sean Young authored
When reporting decoded protocol use the enum rather than the bitmap. Signed-off-by:
-
Heiner Kallweit authored
Simplify the code a little. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
ir_raw_event_handle is called anyway after the hw fifo content stored in nvt->buf[] has been written to the kfifo. There is not really a benefit in the potential additional call to ir_raw_event_handle whilst nvt->buf[] is being processed. Getting rid of this additional call allows to simplify the code. Signed-off-by:
-
Heiner Kallweit authored
The call to nvt_get_rx_ir_data and nvt_process_rx_ir_data from the ISR is protected with spinlock nvt->lock. Therefore it's guaranteed that nvt->pkts is 0 when entering nvt_get_rx_ir_data (as nvt->pkts is set to 0 at the end of nvt_process_rx_ir_data). Having said that we can remove b_idx. Signed-off-by:
-
Heiner Kallweit authored
When removing module nuvoton-cir I get a fifo overrun warning. It turned out to be caused by a spurious interrupt when the logical CIR device is being disabled (although no interrupt source bit being set). Reading the interrupt status register returns 0xff, therefore the fifo overrun bit is mistakenly interpreted as being set. Fix this by ignoring interrupts when interrupt source and status register reads return 0xff. Signed-off-by:
-
Heiner Kallweit authored
When removing module ir_lirc_codec I got this deadlock warning. Fix this by introducing a separate mutex to protect access to available_protocols instead of using ir_raw_handler_lock for this purpose. ====================================================== [ INFO: possible circular locking dependency detected ] 4.7.0-next-20160729 #1 Not tainted ------------------------------------------------------- rmmod/2542 is trying to acquire lock: (&dev->lock){+.+.+.}, at: [<ffffffffa03b1267>] ir_raw_handler_unregister+0x77/0xd0 [rc_core] but task is already holding lock: (ir_raw_handler_lock){+.+.+.}, at: [<ffffffffa03b1212>] ir_raw_handler_unregister+0x22/0xd0 [rc_core] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (ir_raw_handler_lock){+.+.+.}: [<ffffffff810ab1f2>] lock_acquire+0xb2/0x1e0 [<ffffffff815c087f>] mutex_lock_nested+0x5f/0x360 [<ffffffffa03b1403>] ir_raw_get_allowed_protocols+0x13/0x30 [rc_core] [<ffffffffa03af8ea>] store_protocols+0x2fa/0x480 [rc_core] [<ffffffff8143e143>] dev_attr_store+0x13/0x20 [<ffffffff81213c50>] sysfs_kf_write+0x40/0x50 [<ffffffff81212f60>] kernfs_fop_write+0x150/0x1e0 [<ffffffff81197613>] __vfs_write+0x23/0x120 [<ffffffff81198740>] vfs_write+0xb0/0x190 [<ffffffff81199a34>] SyS_write+0x44/0xa0 [<ffffffff815c55a5>] entry_SYSCALL_64_fastpath+0x18/0xa8 -> #0 (&dev->lock){+.+.+.}: [<ffffffff810aac8c>] __lock_acquire+0x10fc/0x1270 [<ffffffff810ab1f2>] lock_acquire+0xb2/0x1e0 [<ffffffff815c087f>] mutex_lock_nested+0x5f/0x360 [<ffffffffa03b1267>] ir_raw_handler_unregister+0x77/0xd0 [rc_core] [<ffffffffa03c8c05>] ir_lirc_codec_exit+0x10/0x12 [ir_lirc_codec] [<ffffffff810e1b88>] SyS_delete_module+0x168/0x220 [<ffffffff815c55a5>] entry_SYSCALL_64_fastpath+0x18/0xa8 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(ir_raw_handler_lock); lock(&dev->lock); lock(ir_raw_handler_lock); lock(&dev->lock); *** DEADLOCK *** 1 lock held by rmmod/2542: #0: (ir_raw_handler_lock){+.+.+.}, at: [<ffffffffa03b1212>] ir_raw_handler_unregister+0x22/0xd0 [rc_core] stack backtrace: CPU: 0 PID: 2542 Comm: rmmod Not tainted 4.7.0-next-20160729 #1 Hardware name: ZOTAC ZBOX-CI321NANO/ZBOX-CI321NANO, BIOS B246P105 06/01/2015 0000000000000000 ffff88006e607cc0 ffffffff812715f5 ffffffff8232b230 ffffffff8232b230 ffff88006e607d00 ffffffff810a846e 00000000790107f0 ffff880079010818 ffff8800790107f0 1efeb9f4f0dd2e6f ffff880079010000 Call Trace: [<ffffffff812715f5>] dump_stack+0x68/0x93 [<ffffffff810a846e>] print_circular_bug+0x1be/0x210 [<ffffffff810aac8c>] __lock_acquire+0x10fc/0x1270 [<ffffffff810bcead>] ? debug_lockdep_rcu_enabled+0x1d/0x20 [<ffffffff810ab1f2>] lock_acquire+0xb2/0x1e0 [<ffffffffa03b1267>] ? ir_raw_handler_unregister+0x77/0xd0 [rc_core] [<ffffffff815c087f>] mutex_lock_nested+0x5f/0x360 [<ffffffffa03b1267>] ? ir_raw_handler_unregister+0x77/0xd0 [rc_core] [<ffffffff810a980e>] ? trace_hardirqs_on_caller+0xee/0x1b0 [<ffffffffa03b1267>] ir_raw_handler_unregister+0x77/0xd0 [rc_core] [<ffffffffa03c8c05>] ir_lirc_codec_exit+0x10/0x12 [ir_lirc_codec] [<ffffffff810e1b88>] SyS_delete_module+0x168/0x220 [<ffffffff815c55a5>] entry_SYSCALL_64_fastpath+0x18/0xa8 Signed-off-by: -
Ole Ernst authored
This partly reverts commit 078600f5. Due to the relocation of input_register_device() call, holding down a button on an IR remote no longer resulted in repeated key down events. Signed-off-by:
Ole Ernst <olebowle@gmx.com> Tested-by:
Matthias Reichl <hias@horus.com> Signed-off-by:
-
Antti Palosaari authored
Use regmap for I2C register access. Signed-off-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Antti Palosaari authored
Check demod and ts locks and report lock status according to those. Signed-off-by:
-
Antti Palosaari authored
Use correct device for logging functions as we now have it due to proper I2C client bindings. Signed-off-by:
-
Antti Palosaari authored
Add I2C driver bindings in order to support proper I2C driver registration with driver core. Signed-off-by:
-
Antti Palosaari authored
Return DVBv5 statistics via legacy DVBv3 API. Signed-off-by:
-
Antti Palosaari authored
Implement dvbv5 statistics for DVB-C. Signed-off-by:
-
Antti Palosaari authored
Implement dvbv5 statistics for DVB-T2. Signed-off-by:
-
Antti Palosaari authored
Implement dvbv5 statistics for DVB-T. Signed-off-by:
-
Antti Palosaari authored
Use 64-bit calculation. Return error if tuner does not provide get_if_frequency() callback. All currently used tuners has it. Signed-off-by:
-
Sakari Ailus authored
New IOCTLs (especially for the request API) do not necessarily need the graph mutex acquired. Leave this up to the drivers. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
