- 11 Apr, 2023 22 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:
-
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 18 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:
-
