- 11 Apr, 2023 15 commits
-
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl>
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Guenter Roeck <groeck@chromium.org> Signed-off-by:
-
Uwe Kleine-König authored
Exiting early in remove without releasing all acquired resources yields leaks. Note that e.g. memory allocated with devm_zalloc() is freed after .remove() returns, even if the return code was negative. While blocking_notifier_chain_unregister() won't fail and so the change is somewhat cosmetic, platform driver's .remove callbacks are about to be converted to return void. To prepare that, keep the error message but don't return early. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
- 10 Apr, 2023 25 commits
-
-
Zheng Wang authored
In rkvdec_probe, rkvdec->watchdog_work is bound with rkvdec_watchdog_func. Then rkvdec_vp9_run may be called to start the work. If we remove the module which will call rkvdec_remove to make cleanup, there may be a unfinished work. The possible sequence is as follows, which will cause a typical UAF bug. Fix it by canceling the work before cleanup in rkvdec_remove. CPU0 CPU1 |rkvdec_watchdog_func rkvdec_remove | rkvdec_v4l2_cleanup| v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //use Fixes: cd33c830 ("media: rkvdec: Add the rkvdec driver") Signed-off-by:Zheng Wang <zyytlz.wz@163.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Zheng Wang authored
In cedrus_probe, dev->watchdog_work is bound with cedrus_watchdog function. In cedrus_device_run, it will started by schedule_delayed_work. If there is an unfinished work in cedrus_remove, there may be a race condition and trigger UAF bug. CPU0 CPU1 |cedrus_watchdog cedrus_remove | v4l2_m2m_release | kfree(m2m_dev) | | | v4l2_m2m_get_curr_priv | m2m_dev //use Fix it by canceling the worker in cedrus_remove. Fixes: 7c38a551 ("media: cedrus: Add watchdog for job completion") Signed-off-by:Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by:
-
Benjamin Gaignard authored
When decoding a 10bits bitstreams VP9 driver should only expose 10bits pixel formats. To fulfill this requirement it is needed to call hantro_reset_raw_fmt() when bit depth change and to correctly set match_depth in pixel formats enumeration. Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@collabora.com> Reviewed-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by:
-
Benjamin Gaignard authored
When decoding a 10bits bitstreams HEVC driver should only expose 10bits pixel formats. To fulfill this requirement it is needed to call hantro_reset_raw_fmt() when bit depth change and to correctly set match_depth in pixel formats enumeration. Signed-off-by:
Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by:
-
Benjamin Gaignard authored
It is needed to check if the proposed pixels format is valid before updating context bit depth and other internal states. Stop using ctx->bit_depth to check format depth match and return result to the caller. Signed-off-by:
-
Benjamin Gaignard authored
In hantro_try_ctrl() we should only check the values inside control parameters and not set ctx->bit_depth. That must be done in controls set function. Create a set control function for hevc where ctx->bit_depth is set at the right time. Signed-off-by:
-
Benjamin Gaignard authored
Source and destination pixel formats fields of context structure should not be used as storage when resetting the format. Use local variables instead and let hantro_set_fmt_out() and hantro_set_fmt_cap() set them correctly later. Signed-off-by:
-
Benjamin Gaignard authored
Setting context source and destination formats should only be done in hantro_set_fmt_out() and hantro_set_fmt_cap() after check that the targeted queue is not busy. Remove these calls from hantro_reset_encoded_fmt() and hantro_reset_raw_fmt() to clean the driver. Signed-off-by:
-
Yunfei Dong authored
If lat thread can't get lat buffer, it should be that current instance don't be schedulded, the driver can't free the src buffer directly. Fixes: 7b182b8d ("media: mediatek: vcodec: Refactor get and put capture buffer flow") Signed-off-by:
Yunfei Dong <yunfei.dong@mediatek.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
-
Yunfei Dong authored
Putting core work to work queue using queue_work maybe fail, call queue_work again when the count of core work in work queue is less than core_list_cnt, making sure all the buffer in core list can be scheduled. Fixes: 365e4ba0 ("media: mtk-vcodec: Add work queue for core hardware decode") Signed-off-by:
-
Yunfei Dong authored
Remove unused lat_buf from core list, or leading to core list access NULL point. Fixes: 365e4ba0 ("media: mtk-vcodec: Add work queue for core hardware decode") Signed-off-by:
-
Yunfei Dong authored
Need to make sure core decode done before current instance is free. Fixes: 365e4ba0 ("media: mtk-vcodec: Add work queue for core hardware decode") Signed-off-by:
-
Yunfei Dong authored
Current instance will decode done when begin to wait lat buf full, move the lat_buf of current instance to the top of core list to make sure current instance's lat_buf will be used firstly. Fixes: 365e4ba0 ("media: mtk-vcodec: Add work queue for core hardware decode") Signed-off-by:
-
Yunfei Dong authored
Core Hardware decoder depends on each instance lat_buf count, calling queue_work decode again when the lat_buf count of each instance isn't zero. Fixes: 365e4ba0 ("media: mtk-vcodec: Add work queue for core hardware decode") Signed-off-by:
-
Yunfei Dong authored
Using lat_buf to share decoder information between lat and core work queue, adding params to record the buf count. Fixes: 365e4ba0 ("media: mtk-vcodec: Add work queue for core hardware decode") Signed-off-by:
-
Ming Qian authored
amphion decoder add support for the RealVideo video. RV30 and RV40 are support by amphion decoder. Signed-off-by:
Ming Qian <ming.qian@nxp.com> Signed-off-by:
-
Ming Qian authored
RealVideo, or also spelled as Real Video, is a suite of proprietary video compression formats developed by RealNetworks - the specific format changes with the version. RealVideo codecs are identified by four-character codes. RV30 and RV40 are RealNetworks' proprietary H.264-based codecs. Reviewed-by:
-
Ming Qian authored
Sorenson Spark is an implementation of H.263 for use in Flash Video and Adobe Flash files. amphion decoder can support it by insert some startcode before sequence and picture. Signed-off-by:
-
Ming Qian authored
Sorenson Spark is an implementation of H.263 for use in Flash Video and Adobe Flash files. Sorenson Spark is an incomplete implementation of H.263. It differs mostly in header structure and ranges of the coefficients. Signed-off-by:
-
Yunfei Dong authored
While the decoder can produce frames in both MM21 and MT21C formats, only MM21 is currently supported by userspace tools (like gstreamer and libyuv). In order to ensure userspace keeps working after the SCP firmware is updated to support both MM21 and MT21C formats, force the MM21 format for the capture queue. This is meant as a stopgap solution while dynamic format switching between MM21 and MT21C isn't implemented in the driver. Fixes: 7501edef ("media: mediatek: vcodec: Different codec using different capture format") Signed-off-by:
Nicolas F. R. A. Prado <nfraprado@collabora.com> Tested-by:
-
Yunfei Dong authored
Given that only the MM21 capture format is supported by userspace tools (like gstreamer and libyuv), make it the default capture format. This allows us to force the MM21 format even when a MM21 and MT21C capable firmware is available (which is needed while dynamic format switching isn't implemented in the driver), without causing the following regressions on v4l2-compliance: fail: v4l2-test-formats.cpp(478): pixelformat 3132544d (MT21) for buftype 9 not reported by ENUM_FMT test VIDIOC_G_FMT: FAIL fail: v4l2-test-formats.cpp(478): pixelformat 3132544d (MT21) for buftype 9 not reported by ENUM_FMT test VIDIOC_TRY_FMT: FAIL fail: v4l2-test-formats.cpp(478): pixelformat 3132544d (MT21) for buftype 9 not reported by ENUM_FMT test VIDIOC_S_FMT: FAIL Fixes: 7501edef ("media: mediatek: vcodec: Different codec using different capture format") Signed-off-by: -
Pin-yen Lin authored
After commit b018be06 ("media: mediatek: vcodec: Read max resolution from dec_capability"), the stateful video decoder driver never really sets its output frame size to 4K. Parse the decoder capability reported by the firmware, and update the output frame size in mtk_init_vdec_params to enable 4K frame size when available. Fixes: b018be06 ("media: mediatek: vcodec: Read max resolution from dec_capability") Signed-off-by:
Pin-yen Lin <treapking@chromium.org> Reviewed-by:
-
Yunfei Dong authored
Need to add racing control register base in device node for mt8195 support inner racing mode. Changing the max reg value from 1 to 2. Adding the description for VDEC_SYS and VDEC_MISC. Signed-off-by:
Allen-KH Cheng <allen-kh.cheng@mediatek.com> Acked-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Chen-Yu Tsai <wenst@chromium.org> Tested-by:
-
Yunfei Dong authored
mt8195 and mt8192 have different clock numbers, separate 'clock-names' according to compatible name. Signed-off-by:
-
Allen-KH Cheng authored
Because the decoder nodes already make use of the iommus property to configure the IOMMU for address translations, having a dma-ranges property makes no sense. In fact, after commit f1ad5338 ("of: Fix "dma-ranges" handling for bus controllers"), having a dma-ranges property causes IOMMU faults. Remove the dma-ranges property and update the example. Signed-off-by:
-
