- 14 Dec, 2021 16 commits
-
-
Mikhail Rudenko authored
While testing Rockchip RK3399 with both ISPs enabled, a dmesg error was observed: ``` [ 15.559141] debugfs: Directory 'rkisp1' with parent '/' already present! ``` Fix it by using the device name for the debugfs subdirectory name instead of the driver name, thus preventing name collision. Link: https://lore.kernel.org/linux-media/20211010175457.438627-1-mike.rudenko@gmail.comSigned-off-by:
Mikhail Rudenko <mike.rudenko@gmail.com> Reviewed-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Evgeny Novikov authored
pt3_probe() did not free one of IO mappings in case when one of them was successful while another one failed. The patch fixed that by using functions pcim_*. Also, it simplifies error handling through switching to devm_* functions. Found by Linux Driver Verification project (linuxtesting.org). Link: https://lore.kernel.org/linux-media/20210814155742.11392-1-novikov@ispras.ruSigned-off-by:
Evgeny Novikov <novikov@ispras.ru> Co-developed-by:
Kirill Shilimanov <kirill.shilimanov@huawei.com> Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Tested-by:
Akihiro Tsukada <tskd08@gmail.com> Signed-off-by:
-
Anton Vasilyev authored
dvb_usb_device_init stores parts of properties at d->props and d->desc and uses it on dvb_usb_device_exit. Free of properties on module probe leads to use after free. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204597 The patch makes properties static instead of allocated on heap to prevent memleak and use after free. Also fixes s421_properties.devices initialization to have 2 element instead of 6 copied from p7500_properties. [mchehab: fix function call alignments] Link: https://lore.kernel.org/linux-media/20190822104147.4420-1-vasilyev@ispras.ruSigned-off-by:
Anton Vasilyev <vasilyev@ispras.ru> Fixes: 299c7007 ("media: dw2102: Fix memleak on sequence of probes") Signed-off-by:
-
Michael Tretter authored
Step 5 expects that the sensor is in LP11 mode. Use the new pre_streamon callback to signal the sensor that it should switch into LP11. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Andy Shevchenko authored
GPIO library does copy the of_node from the parent device of the GPIO chip, there is no need to repeat this in the individual drivers. Remove assignment here. For the details one may look into the of_gpio_dev_init() implementation. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Sakari Ailus authored
Depend on VIDEO_V4L2 for the driver actually depends on it, failing to compile otherwise. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
-
Benjamin Gaignard authored
G2/HEVC is broken because driver capture queue pixelformat ioctl G_FMT returns VT12 while G2/HEVC always generate NV12 frames: video1: VIDIOC_S_FMT: type=vid-out-mplane, width=2560, height=1600, format=S265 little-endian (0x35363253), field=none, colorspace=0, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0 plane 0: bytesperline=0 sizeimage=6144000 video1: VIDIOC_S_EXT_CTRLS: which=0x0, count=1, error_idx=0, request_fd=0, name=HEVC Sequence Parameter Set, id/size=0x990cf0/32 video1: VIDIOC_G_FMT: type=vid-cap-mplane, width=2560, height=1600, format=VT12 little-endian (0x32315456), field=none, colorspace=0, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0 plane 0: bytesperline=2560 sizeimage=6144000 video1: VIDIOC_ENUM_FMT: index=0, type=vid-cap-mplane, flags=0x0, pixelformat=NV12 little-endian (0x3231564e), mbus_code=0x0000, description='Y/CbCr 4:2:0' video1: VIDIOC_ENUM_FMT: error -22: index=1, type=vid-cap-mplane, flags=0x0, pixelformat=.... little-endian (0x00000000), mbus_code=0x0000, description='' video1: VIDIOC_G_FMT: type=vid-cap-mplane, width=2560, height=1600, format=VT12 little-endian (0x32315456), field=none, colorspace=0, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0 Use the postprocessor functions introduced by Hantro G2/VP9 codec series to fix the issue and remove duplicated buffer management. This allow Hantro G2/HEVC to produce NV12_4L4 and NV12. Fluster scores are 77/147 for HEVC and 129/303 for VP9 (no regression). Beauty, Jockey and ShakeNDry bitstreams from UVG (http://ultravideo.fi/) set have also been tested. Fixes: 53a3e710 ("media: hantro: Simplify postprocessor") Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@collabora.com> Reviewed-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Sean Young authored
The lirc core already introduces gaps, so there is no need for this in the driver. Signed-off-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Sean Young authored
These struct members do not serve any purpose. Signed-off-by:
-
Sean Young authored
Remove superfluous messages which add no information. Signed-off-by:
-
Sean Young authored
The usb pid/vid can be found elsewhere, the idVendor/idProduct usb sysfs files for example. Signed-off-by:
-
Sean Young authored
There is no reason to have a reset after an IR timeout. Calling ir_raw_event_handle() twice for the same interrupt has no affect. Fixes: 56b0ec30 ("[media] rc/streamzap: fix reporting response times") Signed-off-by:
-
Sean Young authored
Without this, some IR will be missing mid-stream and we might decode something which never really occurred. Signed-off-by:
-
Sean Young authored
An IR reset is only used when the IR hardware reports an error. Signed-off-by:
-
Sean Young authored
An IR reset is only used when the IR hardware reports an error. Signed-off-by:
-
Sean Young authored
Without timeout reports, it is impossible to decode many protocols since it is not known when the transmission ends. timeout reports are sent by default, but can be turned off. There is no reason to turn them off, and I cannot find any software which does this, so we can safely remove it. This makes the ioctl LIRC_SET_REC_TIMEOUT_REPORTS a no-op. Signed-off-by:
-
- 07 Dec, 2021 24 commits
-
-
Zhen Lei authored
Use DEVICE_ATTR_RO() helper macro instead of DEVICE_ATTR(), which is simpler and more readable. Due to the name of the read function of the sysfs attribute is normalized, there is a natural association. Link: https://lore.kernel.org/linux-media/20210603071009.11438-1-thunder.leizhen@huawei.comSigned-off-by:
Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by:
-
Cai Huoqing authored
use SPDX-License-Identifier instead of a verbose license text Link: https://lore.kernel.org/linux-media/20210916020006.8497-1-caihuoqing@baidu.com CC: Mauro Carvalho Chehab <mchehab@kernel.org>, <linux-media@vger.kernel.org>, <linux-kernel@vger.kernel.org> Signed-off-by:
Cai Huoqing <caihuoqing@baidu.com> Signed-off-by:
-
Krzysztof Kozlowski authored
The devices 0x187f,0x0202 and 0x187f,0x0301 are already on the list. Link: https://lore.kernel.org/linux-media/20210917092132.19576-1-krzysztof.kozlowski@canonical.comSigned-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Using stack-allocated pointers for USB message data don't work. This driver is almost OK with that, except for the I2C read logic. Fix it by using a temporary read buffer, just like on all other calls to m920x_read(). Link: https://lore.kernel.org/all/ccc99e48-de4f-045e-0fe4-61e3118e3f74@mida.se/ Reported-by: rkardell@mida.se Signed-off-by:
-
Uwe Kleine-König authored
An spi remove callback is never called with an spi_device pointer that is NULL. Also it is only called for devices that probed successfully. As cxd2880_spi_probe() always sets driver data, spi_get_drvdata() cannot be NULL. Also the return value of spi remove callbacks is ignored anyway and not freeing resources in .remove() is a bad idea. Link: https://lore.kernel.org/linux-media/20211012153945.2651412-8-u.kleine-koenig@pengutronix.de Cc: Mark Brown <broonie@kernel.org>, kernel@pengutronix.de, linux-media@vger.kernel.org, linux-spi@vger.kernel.org Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Uwe Kleine-König authored
If disabling the hardware fails the driver propagates the error code to the i2c core. However this only results in a generic error message; the device still disappears. So instead emit a message that better describes the actual problem than the i2c core's "remove failed (ESOMETHING), will be ignored" and return 0 to suppress the generic message. Link: https://lore.kernel.org/linux-media/20211026194010.109029-1-u.kleine-koenig@pengutronix.de Cc: linux-media@vger.kernel.org, kernel@pengutronix.de Signed-off-by:
-
Daniel Kamil Kozar authored
The module currently prints only "Rafael Micro r820t successfully identified" when successfully loaded, which might be misleading as the module actually supports various chip types. Link: https://lore.kernel.org/linux-media/20211119234401.271193-1-dkk089@gmail.com Cc: linux-kernel@vger.kernel.org, Daniel Kamil Kozar <dkk089@gmail.com> Signed-off-by:
Daniel Kamil Kozar <dkk089@gmail.com> Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a dev_dbg message. Fix it. Link: https://lore.kernel.org/linux-media/20211123090645.165299-1-colin.i.king@gmail.com Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
Robert Schlabbach authored
Commit e955f959 ("media: si2157: Better check for running tuner in init") completely broke the "warm" tuner detection of the si2157 driver due to a simple endian error: The Si2157 CRYSTAL_TRIM property code is 0x0402 and needs to be transmitted LSB first. However, it was inserted MSB first, causing the warm detection to always fail and spam the kernel log with tuner initialization messages each time the DVB frontend device was closed and reopened: [ 312.215682] si2157 16-0060: found a 'Silicon Labs Si2157-A30' [ 312.264334] si2157 16-0060: firmware version: 3.0.5 [ 342.248593] si2157 16-0060: found a 'Silicon Labs Si2157-A30' [ 342.295743] si2157 16-0060: firmware version: 3.0.5 [ 372.328574] si2157 16-0060: found a 'Silicon Labs Si2157-A30' [ 372.385035] si2157 16-0060: firmware version: 3.0.5 Also, the reinitializations were observed disturb _other_ tuners on multi-tuner cards such as the Hauppauge WinTV-QuadHD, leading to missed or errored packets when one of the other DVB frontend devices on that card was opened. Fix the order of the property code bytes to make the warm detection work again, also reducing the tuner initialization message in the kernel log to once per power-on, as well as fixing the interference with other tuners. Link: https://lore.kernel.org/linux-media/trinity-2a86eb9d-6264-4387-95e1-ba7b79a4050f-1638392923493@3c-app-gmx-bap03 Fixes: e955f959 ("media: si2157: Better check for running tuner in init") Reported-by:
Robert Schlabbach <robert_s@gmx.net> Signed-off-by:
-
Colin Ian King authored
Pointer tsin is being assigned a value that is never read. The assignment is redundant and can be removed. Link: https://lore.kernel.org/linux-media/20211205003745.227491-1-colin.i.king@gmail.com Cc: kernel-janitors@vger.kernel.org Signed-off-by:
Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by:
-
Akira Yokosawa authored
The beginning part of the "existing HSV/HSL formats" table (line 7742) reads: .. raw:: latex \begingroup \tiny \setlength{\tabcolsep}{2pt} However, the ending part (line 7834) reads: .. raw:: latex \normalsize Fix the imbalance by replacing the \normalsize with \endgroup. Note: Actually, the imbalance is harmless and just results in an informative message near the bottom of userspace-api.log: (\end occurred inside a group at level 1) ### semi simple group (level 1) entered at line 70696 (\begingroup) ### bottom level Link: https://lore.kernel.org/linux-media/b3eeec4d-1a34-0a1a-3097-1ddea3b5f1c8@gmail.comSigned-off-by:Akira Yokosawa <akiyks@gmail.com> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Tsuchiya Yuto authored
There are two occurrences where the variable 'asd' is dereferenced before check. Fix this issue by using the variable after the check. Link: https://lore.kernel.org/linux-media/20211122074122.GA6581@kili/ Link: https://lore.kernel.org/linux-media/20211201141904.47231-1-kitakar@gmail.comReported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Tsuchiya Yuto <kitakar@gmail.com> Signed-off-by:
-
Colin Ian King authored
Don't populate the array idx_map on the stack but instead make it static const. Also makes the object code smaller by 16 bytes. Link: https://lore.kernel.org/linux-media/20211129230626.549090-1-colin.i.king@gmail.comSigned-off-by:
-
Dafna Hirschfeld authored
In function vb2_set_plane_payload, report if the given bytesused is bigger than the buffer size, and clamp it to the buffer size. Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by:
-
Dafna Hirschfeld authored
In many places the bytesused field of struct vb2_buffer is set directly. Replace that with the function call vb2_set_plane_payload Signed-off-by:
-
Hans Verkuil authored
The cec_devnode struct has a lock meant to serialize access to the fields of this struct. This lock is taken during device node (un)registration and when opening or releasing a filehandle to the device node. When the last open filehandle is closed the cec adapter might be disabled by calling the adap_enable driver callback with the devnode.lock held. However, if during that callback a message or event arrives then the driver will call one of the cec_queue_event() variants in cec-adap.c, and those will take the same devnode.lock to walk the open filehandle list. This obviously causes a deadlock. This is quite easy to reproduce with the cec-gpio driver since that uses the cec-pin framework which generated lots of events and uses a kernel thread for the processing, so when adap_enable is called the thread is still running and can generate events. But I suspect that it might also happen with other drivers if an interrupt arrives signaling e.g. a received message before adap_enable had a chance to disable the interrupts. This patch adds a new mutex to serialize access to the fhs list. When adap_enable() is called the devnode.lock mutex is held, but not devnode.lock_fhs. The event functions in cec-adap.c will now use devnode.lock_fhs instead of devnode.lock, ensuring that it is safe to call those functions from the adap_enable callback. This specific issue only happens if the last open filehandle is closed and the physical address is invalid. This is not something that happens during normal operation, but it does happen when monitoring CEC traffic (e.g. cec-ctl --monitor) with an unconfigured CEC adapter. Signed-off-by:
-
Hans Verkuil authored
The en/disable_irq() functions keep track of the 'depth': i.e. if interrupts are disabled twice, then it needs to enable_irq() calls to enable them again. The cec-pin framework didn't take this into accound and could disable irqs multiple times, and it expected that a single enable_irq() would enable them again. Move all calls to en/disable_irq() to the kthread where it is easy to keep track of the current irq state and ensure that multiple en/disable_irq calls never happen. If interrupts where disabled twice, then they would never turn on again, leaving the CEC adapter in a dead state. Signed-off-by:
-
Hans Verkuil authored
This field is only set, but never used. Drop it. Signed-off-by:
-
Rikard Falkeborn authored
The only usage of the v4l2_m2m_ops structs is to pass their address to v4l2_m2m_init() which takes a pointer to const struct v4l2_m2m_ops as argument. Make them const to allow the compiler to put them in read-only memory. Signed-off-by:
Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by:
-
Zhou Qingyang authored
In mxb_attach(dev, info), saa7146_vv_init() is called to allocate a new memory for dev->vv_data. saa7146_vv_release() will be called on failure of mxb_probe(dev). There is a dereference of dev->vv_data in saa7146_vv_release(), which could lead to a NULL pointer dereference on failure of saa7146_vv_init(). Fix this bug by adding a check of saa7146_vv_init(). This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_VIDEO_MXB=m show no new warnings, and our static analyzer no longer warns about this code. Fixes: 03b1930e ("V4L/DVB: saa7146: fix regression of the av7110/budget-av driver") Signed-off-by:
Zhou Qingyang <zhou1615@umn.edu> Signed-off-by:
-
Zhou Qingyang authored
In hexium_attach(dev, info), saa7146_vv_init() is called to allocate a new memory for dev->vv_data. In hexium_detach(), saa7146_vv_release() will be called and there is a dereference of dev->vv_data in saa7146_vv_release(), which could lead to a NULL pointer dereference on failure of saa7146_vv_init() according to the following logic. Both hexium_attach() and hexium_detach() are callback functions of the variable 'extension', so there exists a possible call chain directly from hexium_attach() to hexium_detach(): hexium_attach(dev, info) -- fail to alloc memory to dev->vv_data | in saa7146_vv_init(). | | hexium_detach() -- a dereference of dev->vv_data in saa7146_vv_release() Fix this bug by adding a check of saa7146_vv_init(). This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_VIDEO_HEXIUM_ORION=m show no new warnings, and our static analyzer no longer warns about this code. Signed-off-by:
-
Zhou Qingyang authored
In dib8000_init(), the variable fe is not freed or passed out on the failure of dib8000_identify(&state->i2c), which could lead to a memleak. Fix this bug by adding a kfree of fe in the error path. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_DVB_DIB8000=m show no new warnings, and our static analyzer no longer warns about this code. Fixes: 77e2c0f5 ("V4L/DVB (12900): DiB8000: added support for DiBcom ISDB-T/ISDB-Tsb demodulator DiB8000") Signed-off-by:
-
Niklas Söderlund authored
There is no need to hold the group lock when unregistering the notifier, but doing so triggers a warning about a possible cyclic lock dependency. The lock warning cover the case where a subdevice is about to be bound to the notifier at the same time as it's unregistered. The locking for this scenario is handled in the v4l2-async framework so it's safe to remove the lock in the driver. This match the locking logic in the driver for when the notifier in question is registered. Signed-off-by:
-
Niklas Söderlund authored
The VIN driver have an internal concept of capture groups that covers multiple instances of the driver. This is handled using the shared media graph and a single notifier shared between all VIN instances. This design do not work well if an individual VIN where to be unbound on its own. The design could be improved up on to allow for this but would require large changes in the v4l2-async framework. To avoid the situation suppress the bind and unbind nodes in sysfs. Signed-off-by:
-
