This looks like a typo. By manipulating the antenna on a device while
monitoring the reported SNR, I was able to see the unexpected jump.
After applying this patch, the spike was no longer present.
Link: https://lore.kernel.org/linux-media/20211003001805.735092-1-logans@cottsay.net
Signed-off-by: Scott K Logan <logans@cottsay.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
While dvb_tuner_ops already has dedicated suspend and resume callbacks,
dvb_frontend_ops currently does not have them. Add those callbacks and
use them for suspend and resume. If they are not set, the old behavior
of calling sleep or init is used.
This allows dvb_frontend drivers to handle resume differently from init,
and suspend differently from sleep. No change is required for drivers
not needing this functionality.
Link: https://lore.kernel.org/linux-media/20210418001204.7453-2-kernel@tuxforce.de
Cc: Lukas Middendorf <kernel@tuxforce.de>, Antti Palosaari <crope@iki.fi>, Mauro Carvalho Chehab <mchehab@kernel.org>, Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Lukas Middendorf <kernel@tuxforce.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
I got a use-after-free report:
dvbdev: dvb_register_device: failed to create device dvb1.dvr0 (-12)
...
==================================================================
BUG: KASAN: use-after-free in dvb_dmxdev_release+0xce/0x2f0
...
Call Trace:
dump_stack_lvl+0x6c/0x8b
print_address_description.constprop.0+0x48/0x70
kasan_report.cold+0x82/0xdb
__asan_load4+0x6b/0x90
dvb_dmxdev_release+0xce/0x2f0
...
Allocated by task 7666:
kasan_save_stack+0x23/0x50
__kasan_kmalloc+0x83/0xa0
kmem_cache_alloc_trace+0x22e/0x470
dvb_register_device+0x12f/0x980
dvb_dmxdev_init+0x1f3/0x230
...
Freed by task 7666:
kasan_save_stack+0x23/0x50
kasan_set_track+0x20/0x30
kasan_set_free_info+0x24/0x40
__kasan_slab_free+0xf2/0x130
kfree+0xd1/0x5c0
dvb_register_device.cold+0x1ac/0x1fa
dvb_dmxdev_init+0x1f3/0x230
...
When dvb_register_device() in dvb_dmxdev_init() fails, dvb_dmxdev_init()
does not return a failure, and the memory pointed to by dvbdev or
dvr_dvbdev is invalid at this point. If they are used subsequently, it
will result in UFA or null-ptr-deref.
If dvb_register_device() in dvb_dmxdev_init() fails, fix the bug by making
dvb_dmxdev_init() return an error as well.
Link: https://lore.kernel.org/linux-media/20211015085741.1203283-1-wanghai38@huawei.com
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
support greyscale pix fmt input for coda9_jpeg_encoder. The hardware
supports it, so allow V4L2 Mem2Mem JPEG Encoder use it as well. Tested
on an i.MX6QP.
[hverkuil: updated the Subject line as suggested by Philipp]
Signed-off-by: Martin Weber <martin.weber@br-automation.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The driver already has logic to detect if it fails to stop properly and
report this error to the user. The driver however did not report the
unused buffers or buffers given to the hardware (if any) with an error,
the buffers where instead returned to user-space in the active state.
Build on the existing detection of the error condition and correctly
return the buffers with an error if it triggers.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Neither imx_media_mbus_fmt_to_ipu_image nor imx_media_ipu_image_to_mbus_fmt
were used anywhere.
Signed-off-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
USB control-message timeouts are specified in milliseconds and should
specifically not vary with CONFIG_HZ.
Fixes: 9cb2173e6e ("[media] media: Add stk1160 new driver (easycap replacement)")
Cc: stable@vger.kernel.org # 3.7
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
USB control-message timeouts are specified in milliseconds and should
specifically not vary with CONFIG_HZ.
Use the common control-message timeout define for the five-second
timeouts.
Fixes: 38f993ad8b ("V4L/DVB (8125): This driver adds support for the Sensoray 2255 devices.")
Cc: stable@vger.kernel.org # 2.6.27
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
USB control-message timeouts are specified in milliseconds and should
specifically not vary with CONFIG_HZ.
Fixes: d855497edb ("V4L/DVB (4228a): pvrusb2 to kernel 2.6.18")
Cc: stable@vger.kernel.org # 2.6.18
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
USB control-message timeouts are specified in milliseconds and should
specifically not vary with CONFIG_HZ.
Fixes: a6c2ba2835 ("[PATCH] v4l: 716: support for em28xx board family")
Cc: stable@vger.kernel.org # 2.6.16
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
USB control-message timeouts are specified in milliseconds and should
specifically not vary with CONFIG_HZ.
Fixes: ab33d5071d ("V4L/DVB (3376): Add cpia2 camera support")
Cc: stable@vger.kernel.org # 2.6.17
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
USB control-message timeouts are specified in milliseconds and should
specifically not vary with CONFIG_HZ.
Note that the driver was multiplying some of the timeout values with HZ
twice resulting in 3000-second timeouts with HZ=1000.
Also note that two of the timeout defines are currently unused.
Fixes: 2154be651b ("[media] redrat3: new rc-core IR transceiver device driver")
Cc: stable@vger.kernel.org # 3.0
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
USB control-message timeouts are specified in milliseconds and should
specifically not vary with CONFIG_HZ.
Fixes: 2154be651b ("[media] redrat3: new rc-core IR transceiver device driver")
Cc: stable@vger.kernel.org # 3.0
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
USB control-message timeouts are specified in milliseconds and should
specifically not vary with CONFIG_HZ.
Fixes: 66e89522af ("V4L/DVB: IR: add mceusb IR receiver driver")
Cc: stable@vger.kernel.org # 2.6.36
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The prarameter bs_size to function vpu_enc_encode
is not used. Remove it.
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
In order for the encoder to work with gstreamer
it needs to have the V4L2_CID_MPEG_VIDEO_VP8_PROFILE
ctrl. This patch adds that ctrl with only profile 0
supported.
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Acked-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The logic there is meant to be used by newer firmwares.
clean it up, in order to make compatible with the chosen
firmware version.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
It doesn't make sense to have a control for that. Besides that,
the Intel Aero implementation doesn't have, which means that
even the custom control is not used in practice, at least
outside Android.
So, get rid of it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Change some recovery logic at the driver, in order to make it
more compatible with ISP2401 Intel Aero firmware.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
As we're using Intel Aero firmware, make the code closer to the
driver for such device.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The comments are not following Kernel coding style.
Also, there are two missing comments that are found at the Intel Aero
device driver code. Add them.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Those seem to be used only on certain ISP2401 firmwares that
aren't supported by the driver. So, get rid of them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This is meant to select a platform-dependent factor between
Linux and Windows. It makes no sense to keep it on Kernel.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Now that the tests for the new ISP2401 input system were
dropped, simplify the code, making it closer to the Intel
Aero device driver.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Those tests are related to the input system, which is the same
for the chosen firmware, so both ISP2400 and ISP2401 will be
identical with that regards.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
With the ISP2401 firmware we're using, the code differences
are not that much from ISP2400. Cleanup the code in order
to make it closer to Intel Aero driver.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are two #ifdefs there which aren't defined anywhere.
So, just drop the dead code.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are several unused macros. Simplify the logic there, making
it closer to the Intel Aero driver and the corresponding firmware,
as this is what we have widely available for this device.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This is defined as 64 for the devices/firmware that were chosen.
So, evaluate the macros accordingly.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
As we're using the firmware from Intel Aero, ensure that the
logic inside sh_css as similar as possible to such driver.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There's a note at the uninit function that warns about issues
with mipi frames de-allocation. print a warning if the problem
ever happens.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Such function doesn't exist on Intel Aero driver. As we're using
its firmware, it may mean that this is not compatible with the
current file. So, drop it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are some dead code meant to suppress "C_RUN" warnings.
Drop it from sh_css.c, as it doesn't make much sense.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There's a commented dead code related to some future thing
to be implemented. As this won't happen, as it would require
a newer firmware, just drop the code.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are two versions of those functions. It turns that the
choosen firmware use the old version. So, drop the unused
ones and ensure that all devices will use the right functions.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
