- 14 Dec, 2021 34 commits
-
-
Robert Schlabbach authored
The Si2157 (A30) is functional with the ROM firmware 3.0.5, but can also be patched at runtime, e.g. to firmware 3.1.3. However, although a firmware filename for its firmware patch exists, that has only been used for the Si2177 (A30) so far (which indeed takes the binary identical firmware patch). Add support for downloading firmware patches into the Si2157 (A30), but make it optional, so that initialization can succeed with and without a firmware patch being available. Keep the use of request_firmware() for this purpose rather than firmware_request_nowarn(), so that the warning in the log makes users aware that it is possible to provide a firmware for this tuner. The firmware patch is probably also optional for other (if not all) tuners supported by the driver, but since I do not have the others available to test, they are kept mandatory for now to avoid regressions. Signed-off-by:
Robert Schlabbach <robert_s@gmx.net> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Mauro Carvalho Chehab authored
Split the firmware load code from si2157_init, in order to help to add further changes at the way firmware is handled on this device. No functional changes. Signed-off-by: -
gushengxian authored
On some places, there's a missing whitespace. Link: https://lore.kernel.org/linux-media/20210526075527.302903-1-13145886936@163.com Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, gushengxian <gushengxian@yulong.com> Signed-off-by:
gushengxian <gushengxian@yulong.com> Signed-off-by:
-
Jason Wang authored
Static variables do not need to be initialised to 0, because compiler will initialise all uninitialised statics to 0. Thus, remove the unneeded initializations. Link: https://lore.kernel.org/linux-media/20211212070918.289617-1-wangborong@cdjrlc.comSigned-off-by:
Jason Wang <wangborong@cdjrlc.com> Signed-off-by:
-
Andy Shevchenko authored
There is no evidence we need kernel.h inclusion in certain headers. Drop unneeded <linux/kernel.h> inclusion from other headers. Link: https://lore.kernel.org/linux-media/20211210120201.35635-1-andriy.shevchenko@linux.intel.comSigned-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Minghao Chi authored
return value form directly instead of taking this in another redundant variable. Link: https://lore.kernel.org/linux-media/20211210024721.425145-1-chi.minghao@zte.com.cnReported-by:
Zeal Robot <zealci@zte.com.cm> Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by:
-
chiminghao authored
return value form directly instead of taking this in another redundant variable. Link: https://lore.kernel.org/linux-media/20211209015009.409428-1-chi.minghao@zte.com.cnReported-by:
-
Niklas Söderlund authored
Use the dev_err_probe() helper, instead of open-coding the same operation. While at it retrieve the error once and use it from 'ret' instead of retrieving it twice. Link: https://lore.kernel.org/linux-media/20211208121756.3051565-1-niklas.soderlund+renesas@ragnatech.seSuggested-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Niklas S\xF6derlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Dan Carpenter authored
The configure_channels() function has a double free because configure_memdma_and_inputblock() calls free_input_block() and then it's called again in the error handling code. Link: https://lore.kernel.org/linux-media/20211208073544.GA22020@kili Fixes: c5f5d0f9 ("[media] c8sectpfe: STiH407/10 Linux DVB demux support") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by:
-
Jiasheng Jiang authored
The return value of dma_set_coherent_mask() is not always 0. To catch the exception in case that dma is not support the mask. Link: https://lore.kernel.org/linux-media/20211206022201.1639460-1-jiasheng@iscas.ac.cn Fixes: b0444f18 ("[media] coda: add i.MX6 VDOA driver") Signed-off-by:
Jiasheng Jiang <jiasheng@iscas.ac.cn> Signed-off-by:
-
Colin Ian King authored
Pointer common is being assigned a value in a for-loop and the pointer is never read afterwards. The assignment is redundant and can be removed. Link: https://lore.kernel.org/linux-media/20211205002242.202769-1-colin.i.king@gmail.comSigned-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
Colin Ian King authored
The variable i is assigned the value 0 and each time the value is never read after it has been assigned. The assignments are redundant and can be removed. Link: https://lore.kernel.org/linux-media/20211205001717.178416-1-colin.i.king@gmail.comSigned-off-by:
-
Ricardo Ribalda authored
A lot of userspace depends on a descriptive name for vdev. Without this patch, users have a hard time figuring out which camera shall they use for their video conferencing. This reverts commit e3f60e7e. Link: https://lore.kernel.org/linux-media/20211207003840.1212374-2-ribalda@chromium.org Cc: <stable@vger.kernel.org> Fixes: e3f60e7e ("media: uvcvideo: Set unique vdev name based in type") Reported-by:
Nicolas Dufresne <nicolas@ndufresne.ca> Signed-off-by:
Ricardo Ribalda <ribalda@chromium.org> Reviewed-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Mauro Carvalho Chehab authored
As the first thing this function does is to call v4l2_device_register(), it should call v4l2_device_unregister() if an error occurs, the same way as done at saa7146_vv_release(). 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. saa7146_vv_release() will be called on failure of saa7146_register_device(). 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_HEXIUM_GEMINI=m show no new warnings, and our static analyzer no longer warns about this code. Link: https://lore.kernel.org/linux-media/20211203154030.111210-1-zhou1615@umn.eduSigned-off-by:
Zhou Qingyang <zhou1615@umn.edu> Signed-off-by:
-
Christophe JAILLET authored
'ent_enum->bmap' is a bitmap. So use 'bitmap_zalloc()' to simplify code, improve the semantic and avoid some open-coded arithmetic in allocator arguments. Also change the corresponding 'kfree()' into 'bitmap_free()' to keep consistency. While at it, remove a useless 'bitmap_zero()'. Link: https://lore.kernel.org/linux-media/b11f646dda189f490c06bf671f64a2cc0af4d45c.1638397089.git.christophe.jaillet@wanadoo.frSigned-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
-
Rikard Falkeborn authored
The only usage of max96712_subdev_ops is to pass its address to v4l2_i2c_subdev_init() which takes a pointer to const struct v4l2_subdev_ops as argument. Make it const to allow the compiler to put it in read-only memory. Link: https://lore.kernel.org/linux-media/20211127094945.27985-1-rikard.falkeborn@gmail.comSigned-off-by:
Rikard Falkeborn <rikard.falkeborn@gmail.com> Reviewed-by:
-
Wang Hai authored
I got a null-ptr-deref report: BUG: kernel NULL pointer dereference, address: 0000000000000060 ... RIP: 0010:v4l2_ctrl_auto_cluster+0x57/0x270 ... Call Trace: msi001_probe+0x13b/0x24b [msi001] spi_probe+0xeb/0x130 ... do_syscall_64+0x35/0xb0 In msi001_probe(), if the creation of control for bandwidth_auto fails, there will be a null-ptr-deref issue when it is used in v4l2_ctrl_auto_cluster(). Check dev->hdl.error before v4l2_ctrl_auto_cluster() to fix this bug. Link: https://lore.kernel.org/linux-media/20211026112348.2878040-1-wanghai38@huawei.com Fixes: 93203dd6 ("[media] msi001: Mirics MSi001 silicon tuner driver") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wang Hai <wanghai38@huawei.com> Signed-off-by:
-
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:
-
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:
-
Sakari Ailus authored
Depend on VIDEO_V4L2 for the driver actually depends on it, failing to compile otherwise. 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:
-
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 6 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:
-
