- 19 Aug, 2019 19 commits
-
-
Boris Brezillon authored
Some decoders use intra slice/frame references. The capture buffer pointed by these references might be new and thus have invalid timestamp which prevents the decoder logic from retrieving the vb2_buffer object based on the output buf timestamp. Copy all metadata (including the timestamp) before starting the decode operation. Suggested-by:
Jonas Karlman <jonas@kwiboo.se> Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Tested-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
-
Ezequiel Garcia authored
The cedrus VPU is slice-based and expects V4L2_PIX_FMT_H264_SLICE buffers to contain H264 slices with no start code. Expose this to userspace with the newly added menu control. These two controls are specified as mandatory for applications, but we mark them as non-required on the driver side for backwards compatibility. Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
-
Ezequiel Garcia authored
In order to introduce other controls, the control initialization needs to support an initial struct v4l2_ctrl_control. While here, let's cleanup the control initialization, removing unneeded fields. Signed-off-by:
-
Boris Brezillon authored
Those lists can be extracted from the dpb, let's simplify userspace life and build that list kernel-side (generic helpers will be provided for drivers that need this list). Signed-off-by:
Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Tested-by:
-
Ezequiel Garcia authored
Stateless decoders have different expectations about the start code that is prepended on H264 slices. Add a menu control to express the supported start code types (including no start code). Drivers are allowed to support only one start code type, but they can support both too. Note that this is independent of the H264 decoding mode, which specifies the granularity of the decoding operations. Either in frame-based or slice-based mode, this new control will allow to define the start code expected on H264 slices. Signed-off-by:
-
Boris Brezillon authored
Some stateless decoders don't support per-slice decoding granularity (or at least not in a way that would make them efficient or easy to use). Expose a menu to control the supported decoding modes. Drivers are allowed to support only one decoding but they can support both too. To fully specify the decoding operation, we need to introduce a start_byte_offset, to indicate where slices start. Signed-off-by:
-
Ezequiel Garcia authored
The V4L2_PIX_FMT_H264_SLICE_RAW name was originally suggested because the pixel format would represent H264 slices without any start code. However, as we will now introduce a start code menu control, give the pixel format a more meaningful name, while it's still early enough to do so. Signed-off-by:
-
Rasmus Villemoes authored
Our list_sort() utility has always supported a context argument that is passed through to the comparison routine. Now there's a use case for the similar thing for sort(). This implements sort_r by simply extending the existing sort function in the obvious way. To avoid code duplication, we want to implement sort() in terms of sort_r(). The naive way to do that is static int cmp_wrapper(const void *a, const void *b, const void *ctx) { int (*real_cmp)(const void*, const void*) = ctx; return real_cmp(a, b); } sort(..., cmp) { sort_r(..., cmp_wrapper, cmp) } but this would do two indirect calls for each comparison. Instead, do as is done for the default swap functions - that only adds a cost of a single easily predicted branch to each comparison call. Aside from introducing support for the context argument, this also serves as preparation for patches that will eliminate the indirect comparison calls in common cases. Requested-by:Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Tested-by:
-
Hans Verkuil authored
If reg_r() fails, then gspca_dev->usb_buf was left uninitialized, and some drivers used the contents of that buffer in logic. This caused several syzbot errors: https://syzkaller.appspot.com/bug?extid=397fd082ce5143e2f67d https://syzkaller.appspot.com/bug?extid=1a35278dd0ebfb3a038a https://syzkaller.appspot.com/bug?extid=06ddf1788cfd048c5e82 I analyzed the gspca drivers and zeroed the buffer where needed. Reported-and-tested-by: syzbot+1a35278dd0ebfb3a038a@syzkaller.appspotmail.com Reported-and-tested-by: syzbot+397fd082ce5143e2f67d@syzkaller.appspotmail.com Reported-and-tested-by: syzbot+06ddf1788cfd048c5e82@syzkaller.appspotmail.com Signed-off-by:
-
Ezequiel Garcia authored
Update Jacob's address and add myself as co-maintainer. Signed-off-by:
-
Hans Verkuil authored
dev->usbc_buf was passed as argument for %s, but it was not safeguarded by a terminating 0. This caused this syzbot issue: https://syzkaller.appspot.com/bug?extid=79d18aac4bf1770dd050 Reported-and-tested-by: syzbot+79d18aac4bf1770dd050@syzkaller.appspotmail.com Signed-off-by:
-
Hans Verkuil authored
In the probe() function radio->int_in_urb was not killed if an error occurred in the probe sequence. It was also missing in the disconnect. This caused this syzbot issue: https://syzkaller.appspot.com/bug?extid=2d4fc2a0c45ad8da7e99 Reported-and-tested-by: syzbot+2d4fc2a0c45ad8da7e99@syzkaller.appspotmail.com Signed-off-by:
-
Hans Verkuil authored
One typo in the function name, one missing : after :c:type. Signed-off-by:
-
Hugues Fruchet authored
Add support of several sub-devices within pipeline instead of a single one. This allows to support a CSI-2 camera sensor connected through a CSI-2 to parallel bridge. Signed-off-by:
Hugues Fruchet <hugues.fruchet@st.com> Signed-off-by:
-
Hugues Fruchet authored
Add media controller support to dcmi in order to walk within remote subdevices pipeline. Signed-off-by:
-
Hugues Fruchet authored
Add a trace of the set of supported fourcc/mbus_code which intersect between DCMI and source sub-device. Signed-off-by:
-
Hugues Fruchet authored
Rename "subdev" entity struct field to "source" to prepare for several subdev support. Move asd field on top of entity struct. Acked-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Geert Uytterhoeven authored
Fix typos. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Ezequiel Garcia authored
Some users have been having a hard time finding the hidden menus. A typically case are camera sensor drivers (e.g IMX219, OV5645, etc), which are common on embedded platforms and not really "ancillary" devices. The problem with MEDIA_SUBDRV_AUTOSELECT seems to be related to the fact that it uses the "visible" syntax to hide the menus. This is not obvious and it normally takes some time to figure out. To fix the problem, add a comment on each of hidden menus, which should clarify what option is causing menus to be hidden. Signed-off-by:
-
- 15 Aug, 2019 13 commits
-
-
Sakari Ailus authored
The ov5670 driver didn't get a MAINTAINERS entry when it was merged. Add one now. Signed-off-by:
-
Sébastien Szymanski authored
i.MX7 and i.MX6UL/L have the same CSI controller. So add i.MX6UL/L support to imx7-media-csi driver. Signed-off-by:
Sébastien Szymanski <sebastien.szymanski@armadeus.com> Reviewed-by:
Rui Miguel Silva <rmfrfs@gmail.com> Reviewed-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
-
Sébastien Szymanski authored
Document "fsl,imx6ul-csi" entry. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Ezequiel Garcia authored
Not all sensors will be able to guarantee a proper initial state. This may be either because the driver is not properly written, or (probably unlikely) because the hardware won't support it. While the right solution in the former case is to fix the sensor driver, the real world not always allows right solutions, due to lack of available documentation and support on these sensors. Let's relax this requirement, and allow the driver to support stream start, even if the sensor initial sequence wasn't the expected. Also improve the warning message to better explain the problem and provide a hint that the sensor driver needs to be fixed. Signed-off-by:
Steve Longerbeam <slongerbeam@gmail.com> Reviewed-by:
-
Steve Longerbeam authored
Add a sentence that makes it more clear when the CSI-2 transmitter must, if possible, exit LP-11 mode. That is, maintain LP-11 mode until stream on, at which point the transmitter activates the clock lane and transition to HS mode. Signed-off-by:
-
Sakari Ailus authored
The raw Bayer formats have been listed under the label of RGB formats but in fact they're quite different. The latter are readily usable as such whereas the former require quite bit of image processing before useful. Split them into RGB and raw Bayer formats. Signed-off-by:
-
Sakari Ailus authored
When the support for serial busses was introduced in V4L2, it was decided to use the existing parallel bus media bus pixel codes to describe them. While this was a practical choice at the time, it necessitates choosing which one of the many parallel mbus pixel codes to use, for on the serial busses these formats are effectively all equivalent. The practice has always been to use the pixel code that describes a bus that transfers a single sample per clock. Document this. Signed-off-by:
-
Ezequiel Garcia authored
This is mostly a port of Jacopo's fix: commit aa4bb8b8 Author: Jacopo Mondi <jacopo@jmondi.org> Date: Fri Jul 6 05:51:52 2018 -0400 media: ov5640: Re-work MIPI startup sequence In the OV5645 case, the changes are: - At set_power(1) time power up MIPI Tx/Rx and set data and clock lanes in LP11 during 'sleep' and 'idle' with MIPI clock in non-continuous mode. - At set_power(0) time power down MIPI Tx/Rx (in addition to the current power down of regulators and clock gating). - At s_stream time enable/disable the MIPI interface output. With this commit the sensor is able to enter LP-11 mode during power up, as expected by some CSI-2 controllers. Many thanks to Fabio Estevam for his help debugging this issue. Tested-by:
Jacopo Mondi <jacopo@jmondi.org> Signed-off-by:
-
Sakari Ailus authored
The streaming state should be set to the first upstream sub-device only, not everywhere, for a sub-device driver itself knows how to best control the streaming state of its own upstream sub-devices. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Sakari Ailus authored
The omap3isp driver registered subdevs without the dev field being set. Do that now. Signed-off-by:
-
Luca Weiss authored
Parse async sub-devices related to the sensor by switching the async sub-device registration function. Signed-off-by:
Luca Weiss <luca@z3ntu.xyz> Signed-off-by:
-
Sakari Ailus authored
Instead of blindly trusting getting the clock frequency succeeded end then testing it against a pre-defined value, verify reading the value succeeded. Fixes: 879347f0 ("media: ov8856: Add support for OV8856 sensor") Signed-off-by:
-
Shawn Tu authored
Add a V4L2 sub-device driver for Omnivision ov5675 image sensor. This is a camera sensor using the I2C bus for control and the CSI-2 bus for data. This driver supports following features: - manual exposure and analog/digital gain control support - vblank/hblank control support - test pattern support - media controller support - runtime PM support - support following resolutions: + 2592x1944 at 30FPS + 1296x972 at 30FPS [Sakari Ailus: Wrapped a few long lines.] [mchehab+samsung@kernel.org: fix a checkpatch warning] Signed-off-by:
Shawn Tu <shawnx.tu@intel.com> Signed-off-by:
-
- 14 Aug, 2019 8 commits
-
-
Colin Ian King authored
Currently when the call vsp1_dl_body_get fails and returns null the error return path leaks the allocation of dl. Fix this by kfree'ing dl before returning. Addresses-Coverity: ("Resource leak") Fixes: 5d7936b8 ("media: vsp1: Convert display lists to use new body pool") Signed-off-by:Colin Ian King <colin.king@canonical.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Darius Rad authored
Allow selecting the IR protocol, MCE or iMON, for a device that identifies as follows (with config id 0x7e): 15c2:ffdc SoundGraph Inc. iMON PAD Remote Controller As the driver is structured to default to iMON when both RC protocols are supported, existing users of this device (using MCE protocol) will need to manually switch to MCE (RC-6) protocol from userspace (with ir-keytable, sysfs). Signed-off-by:
Darius Rad <alpha@area49.net> Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Sean Young authored
The usb_bulk_urb will kfree'd on disconnect, so ensure the pointer is set to NULL after each free. stop stream urb killing urb buffer free tm6000: got start feed request tm6000_start_feed tm6000: got start stream request tm6000_start_stream tm6000: pipe reset tm6000: got start feed request tm6000_start_feed tm6000: got start feed request tm6000_start_feed tm6000: got start feed request tm6000_start_feed tm6000: got start feed request tm6000_start_feed tm6000: IR URB failure: status: -71, length 0 xhci_hcd 0000:00:14.0: ERROR unknown event type 37 xhci_hcd 0000:00:14.0: ERROR unknown event type 37 tm6000: error tm6000_urb_received usb 1-2: USB disconnect, device number 5 tm6000: disconnecting tm6000 #0 ================================================================== BUG: KASAN: use-after-free in dvb_fini+0x75/0x140 [tm6000_dvb] Read of size 8 at addr ffff888241044060 by task kworker/2:0/22 CPU: 2 PID: 22 Comm: kworker/2:0 Tainted: G W 5.3.0-rc4+ #1 Hardware name: LENOVO 20KHCTO1WW/20KHCTO1WW, BIOS N23ET65W (1.40 ) 07/02/2019 Workqueue: usb_hub_wq hub_event Call Trace: dump_stack+0x9a/0xf0 print_address_description.cold+0xae/0x34f __kasan_report.cold+0x75/0x93 ? tm6000_fillbuf+0x390/0x3c0 [tm6000_alsa] ? dvb_fini+0x75/0x140 [tm6000_dvb] kasan_report+0xe/0x12 dvb_fini+0x75/0x140 [tm6000_dvb] tm6000_close_extension+0x51/0x80 [tm6000] tm6000_usb_disconnect.cold+0xd4/0x105 [tm6000] usb_unbind_interface+0xe4/0x390 device_release_driver_internal+0x121/0x250 bus_remove_device+0x197/0x260 device_del+0x268/0x550 ? __device_links_no_driver+0xd0/0xd0 ? usb_remove_ep_devs+0x30/0x3b usb_disable_device+0x122/0x400 usb_disconnect+0x153/0x430 hub_event+0x800/0x1e40 ? trace_hardirqs_on_thunk+0x1a/0x20 ? hub_port_debounce+0x1f0/0x1f0 ? retint_kernel+0x10/0x10 ? lock_is_held_type+0xf1/0x130 ? hub_port_debounce+0x1f0/0x1f0 ? process_one_work+0x4ae/0xa00 process_one_work+0x4ba/0xa00 ? pwq_dec_nr_in_flight+0x160/0x160 ? do_raw_spin_lock+0x10a/0x1d0 worker_thread+0x7a/0x5c0 ? process_one_work+0xa00/0xa00 kthread+0x1d5/0x200 ? kthread_create_worker_on_cpu+0xd0/0xd0 ret_from_fork+0x3a/0x50 Allocated by task 2682: save_stack+0x1b/0x80 __kasan_kmalloc.constprop.0+0xc2/0xd0 usb_alloc_urb+0x28/0x60 tm6000_start_feed+0x10a/0x300 [tm6000_dvb] dmx_ts_feed_start_filtering+0x86/0x120 [dvb_core] dvb_dmxdev_start_feed+0x121/0x180 [dvb_core] dvb_dmxdev_filter_start+0xcb/0x540 [dvb_core] dvb_demux_do_ioctl+0x7ed/0x890 [dvb_core] dvb_usercopy+0x97/0x1f0 [dvb_core] dvb_demux_ioctl+0x11/0x20 [dvb_core] do_vfs_ioctl+0x5d8/0x9d0 ksys_ioctl+0x5e/0x90 __x64_sys_ioctl+0x3d/0x50 do_syscall_64+0x74/0xe0 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 22: save_stack+0x1b/0x80 __kasan_slab_free+0x12c/0x170 kfree+0xfd/0x3a0 xhci_giveback_urb_in_irq+0xfe/0x230 xhci_td_cleanup+0x276/0x340 xhci_irq+0x1129/0x3720 __handle_irq_event_percpu+0x6e/0x420 handle_irq_event_percpu+0x6f/0x100 handle_irq_event+0x55/0x84 handle_edge_irq+0x108/0x3b0 handle_irq+0x2e/0x40 do_IRQ+0x83/0x1a0 Cc: stable@vger.kernel.org Signed-off-by:
-
Sean Young authored
KEY_MAX is not a key but designates the highest value a linux keycode can ever have. Signed-off-by:
-
Sean Young authored
syzbot reports an error on flush_request_modules() for the second device. This workqueue was never initialised so simply remove the offending line. usb 1-1: USB disconnect, device number 2 em28xx 1-1:1.153: Disconnecting em28xx #1 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 12 at kernel/workqueue.c:3031 __flush_work.cold+0x2c/0x36 kernel/workqueue.c:3031 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.3.0-rc2+ #25 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e lib/dump_stack.c:113 panic+0x2a3/0x6da kernel/panic.c:219 __warn.cold+0x20/0x4a kernel/panic.c:576 report_bug+0x262/0x2a0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:179 [inline] fixup_bug arch/x86/kernel/traps.c:174 [inline] do_error_trap+0x12b/0x1e0 arch/x86/kernel/traps.c:272 do_invalid_op+0x32/0x40 arch/x86/kernel/traps.c:291 invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1026 RIP: 0010:__flush_work.cold+0x2c/0x36 kernel/workqueue.c:3031 Code: 9a 22 00 48 c7 c7 20 e4 c5 85 e8 d9 3a 0d 00 0f 0b 45 31 e4 e9 98 86 ff ff e8 51 9a 22 00 48 c7 c7 20 e4 c5 85 e8 be 3a 0d 00 <0f> 0b 45 31 e4 e9 7d 86 ff ff e8 36 9a 22 00 48 c7 c7 20 e4 c5 85 RSP: 0018:ffff8881da20f720 EFLAGS: 00010286 RAX: 0000000000000024 RBX: dffffc0000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8128a0fd RDI: ffffed103b441ed6 RBP: ffff8881da20f888 R08: 0000000000000024 R09: fffffbfff11acd9a R10: fffffbfff11acd99 R11: ffffffff88d66ccf R12: 0000000000000000 R13: 0000000000000001 R14: ffff8881c6685df8 R15: ffff8881d2a85b78 flush_request_modules drivers/media/usb/em28xx/em28xx-cards.c:3325 [inline] em28xx_usb_disconnect.cold+0x280/0x2a6 drivers/media/usb/em28xx/em28xx-cards.c:4023 usb_unbind_interface+0x1bd/0x8a0 drivers/usb/core/driver.c:423 __device_release_driver drivers/base/dd.c:1120 [inline] device_release_driver_internal+0x404/0x4c0 drivers/base/dd.c:1151 bus_remove_device+0x2dc/0x4a0 drivers/base/bus.c:556 device_del+0x420/0xb10 drivers/base/core.c:2288 usb_disable_device+0x211/0x690 drivers/usb/core/message.c:1237 usb_disconnect+0x284/0x8d0 drivers/usb/core/hub.c:2199 hub_port_connect drivers/usb/core/hub.c:4949 [inline] hub_port_connect_change drivers/usb/core/hub.c:5213 [inline] port_event drivers/usb/core/hub.c:5359 [inline] hub_event+0x1454/0x3640 drivers/usb/core/hub.c:5441 process_one_work+0x92b/0x1530 kernel/workqueue.c:2269 process_scheduled_works kernel/workqueue.c:2331 [inline] worker_thread+0x7ab/0xe20 kernel/workqueue.c:2417 kthread+0x318/0x420 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Kernel Offset: disabled Rebooting in 86400 seconds.. Fixes: be7fd3c3 ("media: em28xx: Hauppauge DualHD second tuner functionality) Reviewed-by:
Brad Love <brad@nextdimension.cc> Reported-by: syzbot+b7f57261c521087d89bb@syzkaller.appspotmail.com Signed-off-by:
-
Sean Young authored
The decoder is called rc-mm, not rcmm. This was renamed late in the cycle so this bug crept in. Acked-by:
Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
-
Sean Young authored
Sometimes the device sends IR data which is all space, no pulses whatsoever. Add the end of this the driver will put the rc device into idle mode when it already is in idle mode. The following will be logged: rc rc0: nonsensical timing event of duration 0 rc rc0: two consecutive events of type space Signed-off-by:
-
Sean Young authored
This code needs some explanation. Signed-off-by:
-
