[PATCH AUTOSEL 6.15 052/110] media: rkvdec: h264: Use bytesperline and buffer height as virstride

[PATCH AUTOSEL 6.15 052/110] media: rkvdec: h264: Use bytesperline and buffer height as virstride

[Sasha Levin]

From: Jonas Karlman <jonas@kwiboo.se>

[ Upstream commit d5e0aa61470c48ddc04d433a00e79cef8716377a ]

Use bytesperline and buffer height to calculate the strides configured.

This does not really change anything other than ensuring the
bytesperline that is signaled to userspace matches what is configured
in HW.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Tested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Tested-by: Christopher Obbard <chris.obbard@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

### Key Reasons for NO Backport: 1. **Not a Bug Fix**: The commit
message explicitly states "This does not really change anything other
than ensuring the bytesperline that is signaled to userspace matches
what is configured in HW." This is not fixing a functional bug but
rather improving consistency between userspace and hardware
configuration. 2. **Code Quality/Consistency Improvement**: The changes
are primarily about code correctness and consistency rather than fixing
a critical issue that affects users. This aligns with similar commits
#1, #2, and #4 which were marked as NO for backporting. 3. **Staging
Driver**: The rkvdec driver is in `drivers/staging/media/`, which
indicates it's still under development and not considered stable.
Staging drivers typically have more relaxed backporting requirements. 4.
**Specific Code Changes Analysis**: - **Before**: `hor_virstride =
(sps->bit_depth_luma_minus8 + 8) 0001-Fix-Clippy-warnings.patch
0002-Enhance-inference-prompt-to-utilize-CVEKERNELDIR-whe.patch
0003-Update-to-latest-version-of-clap.patch Cargo.lock Cargo.toml
LICENSE README.md adreno_acd_support_analysis.md
amd_display_ips_sequential_ono_backport_analysis.md
analyze_merge_commit.sh dpp_rcg_backport_analysis.md
drm_amd_display_vertical_interrupt_dcn32_dcn401_backport_analysis.md
drm_bridge_analysis.txt drm_format_helper_24bit_analysis.md
drm_imagination_register_update_analysis.md
drm_mediatek_mtk_dpi_refactoring_analysis.md
intel_ipu6_constify_analysis.md io_uring_analysis.txt ksmbd_analysis.txt
merge_commit_analysis.txt model prompt src target test_gpio_cleanup.txt
test_patch.txt verisilicon_av1_4k_analysis.md dst_fmt->width / 8;` -
**After**: `hor_virstride = dst_fmt->plane_fmt[0].bytesperline;` -
**Before**: `ver_virstride = round_up(dst_fmt->height, 16);` -
**After**: `ver_virstride = dst_fmt->height;` 5. **No Risk Indication**:
The changes don't indicate they're fixing crashes, data corruption,
security issues, or other critical problems that would warrant stable
backporting. 6. **Pattern Match with Similar Commits**: Looking at the
provided examples: - Similar commits #1, #2, #4, and #5 that make
stride/calculation improvements were marked as NO - Only commit #3 that
increased max supported height (a clear functional limitation fix) was
marked as YES 7. **No Stable Tree Mention**: The commit message contains
no indication of stable tree inclusion via Fixes: tags or explicit
stable tree requests. ### Conclusion: This commit improves code
consistency by using the actual bytesperline values from userspace
instead of calculating them from SPS parameters, but it doesn't fix a
user-impacting bug. It's a code quality improvement that follows the
pattern of other NO-backport commits in the provided examples.

 drivers/staging/media/rkvdec/rkvdec-h264.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/media/rkvdec/rkvdec-h264.c b/drivers/staging/media/rkvdec/rkvdec-h264.c
index 4fc167b42cf0c..7a1e76d423df5 100644
--- a/drivers/staging/media/rkvdec/rkvdec-h264.c
+++ b/drivers/staging/media/rkvdec/rkvdec-h264.c
@@ -896,9 +896,9 @@ static void config_registers(struct rkvdec_ctx *ctx,
 	dma_addr_t rlc_addr;
 	dma_addr_t refer_addr;
 	u32 rlc_len;
-	u32 hor_virstride = 0;
-	u32 ver_virstride = 0;
-	u32 y_virstride = 0;
+	u32 hor_virstride;
+	u32 ver_virstride;
+	u32 y_virstride;
 	u32 yuv_virstride = 0;
 	u32 offset;
 	dma_addr_t dst_addr;
@@ -909,16 +909,16 @@ static void config_registers(struct rkvdec_ctx *ctx,
 
 	f = &ctx->decoded_fmt;
 	dst_fmt = &f->fmt.pix_mp;
-	hor_virstride = (sps->bit_depth_luma_minus8 + 8) * dst_fmt->width / 8;
-	ver_virstride = round_up(dst_fmt->height, 16);
+	hor_virstride = dst_fmt->plane_fmt[0].bytesperline;
+	ver_virstride = dst_fmt->height;
 	y_virstride = hor_virstride * ver_virstride;
 
 	if (sps->chroma_format_idc == 0)
 		yuv_virstride = y_virstride;
 	else if (sps->chroma_format_idc == 1)
-		yuv_virstride += y_virstride + y_virstride / 2;
+		yuv_virstride = y_virstride + y_virstride / 2;
 	else if (sps->chroma_format_idc == 2)
-		yuv_virstride += 2 * y_virstride;
+		yuv_virstride = 2 * y_virstride;
 
 	reg = RKVDEC_Y_HOR_VIRSTRIDE(hor_virstride / 16) |
 	      RKVDEC_UV_HOR_VIRSTRIDE(hor_virstride / 16) |
-- 
2.39.5

Re: [PATCH AUTOSEL 6.15 052/110] media: rkvdec: h264: Use bytesperline and buffer height as virstride

[Greg KH]

On Sun, Jun 01, 2025 at 07:23:34PM -0400, Sasha Levin wrote:
> From: Jonas Karlman <jonas@kwiboo.se>
> 
> [ Upstream commit d5e0aa61470c48ddc04d433a00e79cef8716377a ]
> 
> Use bytesperline and buffer height to calculate the strides configured.
> 
> This does not really change anything other than ensuring the
> bytesperline that is signaled to userspace matches what is configured
> in HW.
> 
> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> Tested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> Tested-by: Christopher Obbard <chris.obbard@collabora.com>
> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
> 
> ### Key Reasons for NO Backport: 1. **Not a Bug Fix**: The commit
> message explicitly states "This does not really change anything other
> than ensuring the bytesperline that is signaled to userspace matches
> what is configured in HW." This is not fixing a functional bug but
> rather improving consistency between userspace and hardware
> configuration.

As the bot said "NO", why was this picked up?

thanks,

greg k-h

[PATCH AUTOSEL 6.15 054/110] media: rkvdec: Initialize the m2m context before the controls

[Sasha Levin]

From: Nicolas Dufresne <nicolas.dufresne@collabora.com>

[ Upstream commit d43d7db3c8a1868dcbc6cb8de90a3cdf309d6cbb ]

Setting up the control handler calls into .s_ctrl ops. While validating
the controls the ops may need to access some of the context state, which
could lead to a crash if not properly initialized.

Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

Now let me analyze the specific changes proposed in the commit: ##
Analysis **YES** This commit should be backported to stable kernel
trees. Here's my extensive analysis: ### Core Issue Analysis The commit
addresses a critical initialization order bug that can lead to crashes.
The problem occurs in the `rkvdec_open()` function at lines 822-830 in
the current code: 1. **Current problematic order:** - Line 822:
`rkvdec_init_ctrls(ctx)` is called first - Line 826-830:
`v4l2_m2m_ctx_init()` is called second 2. **The problem:** According to
the commit message and my analysis of the kernel documentation,
`v4l2_ctrl_handler_setup()` (called inside `rkvdec_init_ctrls()`) calls
`.s_ctrl` for all controls unconditionally to initialize hardware to
default values. The `.s_ctrl` handlers may need to access the m2m
context state, but if the m2m context (`ctx->fh.m2m_ctx`) isn't
initialized yet, this can cause a crash or undefined behavior. ### Code
Changes Analysis The fix is minimal and surgical: - **Lines moved:** The
initialization order is swapped - m2m context initialization moves
before control handler setup - **Error handling updated:** The error
handling paths are correctly updated to match the new initialization
order - **No functional changes:** The fix doesn't change driver
functionality, only initialization sequence ### Why This Should Be
Backported 1. **Fixes a real crash bug:** This addresses a potential
crash scenario that affects users 2. **Small and contained:** The change
is minimal - just reordering initialization and updating error paths 3.
**Low regression risk:** Moving m2m init before control init is safer
since m2m context doesn't depend on controls, but controls may depend on
m2m context 4. **Follows established patterns:** Similar commit #2 in
the historical examples shows a "YES" backport for proper initialization
order in V4L2 drivers 5. **Critical subsystem:** Media drivers crashing
can affect user applications ### Comparison with Historical Commits -
**Similar to commit #2 (YES):** Also fixes initialization order in V4L2
media driver to prevent crashes - **Similar to commit #4 (YES):** Media
driver fix that's low-risk and contained - **Unlike commits #1, #3, #5
(NO):** This actually fixes a bug rather than just cleanup/code style
improvements ### Stable Tree Criteria Met ✅ **Important bugfix:**
Prevents crashes ✅ **Minimal risk:** Simple reordering with no side
effects ✅ **Small change:** Only affects initialization sequence ✅ **No
architectural changes:** Pure bug fix ✅ **Confined to subsystem:** Only
affects rkvdec driver The fix follows the stable tree rules perfectly -
it's an important crash prevention fix with minimal regression risk,
making it an ideal backport candidate.

 drivers/staging/media/rkvdec/rkvdec.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/media/rkvdec/rkvdec.c b/drivers/staging/media/rkvdec/rkvdec.c
index f9bef5173bf25..4702df5b095b7 100644
--- a/drivers/staging/media/rkvdec/rkvdec.c
+++ b/drivers/staging/media/rkvdec/rkvdec.c
@@ -819,24 +819,24 @@ static int rkvdec_open(struct file *filp)
 	rkvdec_reset_decoded_fmt(ctx);
 	v4l2_fh_init(&ctx->fh, video_devdata(filp));
 
-	ret = rkvdec_init_ctrls(ctx);
-	if (ret)
-		goto err_free_ctx;
-
 	ctx->fh.m2m_ctx = v4l2_m2m_ctx_init(rkvdec->m2m_dev, ctx,
 					    rkvdec_queue_init);
 	if (IS_ERR(ctx->fh.m2m_ctx)) {
 		ret = PTR_ERR(ctx->fh.m2m_ctx);
-		goto err_cleanup_ctrls;
+		goto err_free_ctx;
 	}
 
+	ret = rkvdec_init_ctrls(ctx);
+	if (ret)
+		goto err_cleanup_m2m_ctx;
+
 	filp->private_data = &ctx->fh;
 	v4l2_fh_add(&ctx->fh);
 
 	return 0;
 
-err_cleanup_ctrls:
-	v4l2_ctrl_handler_free(&ctx->ctrl_hdl);
+err_cleanup_m2m_ctx:
+	v4l2_m2m_ctx_release(ctx->fh.m2m_ctx);
 
 err_free_ctx:
 	kfree(ctx);
-- 
2.39.5

Re: [PATCH AUTOSEL 6.15 054/110] media: rkvdec: Initialize the m2m context before the controls

[Nicolas Dufresne]

Le dimanche 01 juin 2025 à 19:23 -0400, Sasha Levin a écrit :
> From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> 
> [ Upstream commit d43d7db3c8a1868dcbc6cb8de90a3cdf309d6cbb ]
> 
> Setting up the control handler calls into .s_ctrl ops. While validating
> the controls the ops may need to access some of the context state, which
> could lead to a crash if not properly initialized.
> 
> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
> 
> Now let me analyze the specific changes proposed in the commit: ##
> Analysis **YES** This commit should be backported to stable kernel
> trees. Here's my extensive analysis: ### Core Issue Analysis The commit
> addresses a critical initialization order bug that can lead to crashes.

"While validating the controls the ops **may** need"

It wasn't the case yet, so its not as critical as this analyses made
it sound like. The changes that came next, removes superfluous branches
that was only there for the purpose of avoiding the crash.

It is harmless otherwise, the change is good practice and at best may
help people backportin more patches. But not worth "Fixes:" and
"CC: Stable" in my opinion. You are free to proceed.

> The problem occurs in the `rkvdec_open()` function at lines 822-830 in
> the current code: 1. **Current problematic order:** - Line 822:
> `rkvdec_init_ctrls(ctx)` is called first - Line 826-830:
> `v4l2_m2m_ctx_init()` is called second 2. **The problem:** According to
> the commit message and my analysis of the kernel documentation,
> `v4l2_ctrl_handler_setup()` (called inside `rkvdec_init_ctrls()`) calls
> `.s_ctrl` for all controls unconditionally to initialize hardware to
> default values. The `.s_ctrl` handlers may need to access the m2m
> context state, but if the m2m context (`ctx->fh.m2m_ctx`) isn't
> initialized yet, this can cause a crash or undefined behavior. ### Code
> Changes Analysis The fix is minimal and surgical: - **Lines moved:** The
> initialization order is swapped - m2m context initialization moves
> before control handler setup - **Error handling updated:** The error
> handling paths are correctly updated to match the new initialization
> order - **No functional changes:** The fix doesn't change driver
> functionality, only initialization sequence ### Why This Should Be
> Backported 1. **Fixes a real crash bug:** This addresses a potential
> crash scenario that affects users 2. **Small and contained:** The change
> is minimal - just reordering initialization and updating error paths 3.
> **Low regression risk:** Moving m2m init before control init is safer
> since m2m context doesn't depend on controls, but controls may depend on
> m2m context 4. **Follows established patterns:** Similar commit #2 in
> the historical examples shows a "YES" backport for proper initialization
> order in V4L2 drivers 5. **Critical subsystem:** Media drivers crashing
> can affect user applications ### Comparison with Historical Commits -
> **Similar to commit #2 (YES):** Also fixes initialization order in V4L2
> media driver to prevent crashes - **Similar to commit #4 (YES):** Media
> driver fix that's low-risk and contained - **Unlike commits #1, #3, #5
> (NO):** This actually fixes a bug rather than just cleanup/code style
> improvements ### Stable Tree Criteria Met ✅ **Important bugfix:**
> Prevents crashes ✅ **Minimal risk:** Simple reordering with no side
> effects ✅ **Small change:** Only affects initialization sequence ✅ **No
> architectural changes:** Pure bug fix ✅ **Confined to subsystem:** Only
> affects rkvdec driver The fix follows the stable tree rules perfectly -
> it's an important crash prevention fix with minimal regression risk,
> making it an ideal backport candidate.

Suggestion for improving the report, perhaps adding line breaks for
each items ?

best regards,
Nicolas

> 
>  drivers/staging/media/rkvdec/rkvdec.c | 14 +++++++-------
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/media/rkvdec/rkvdec.c b/drivers/staging/media/rkvdec/rkvdec.c
> index f9bef5173bf25..4702df5b095b7 100644
> --- a/drivers/staging/media/rkvdec/rkvdec.c
> +++ b/drivers/staging/media/rkvdec/rkvdec.c
> @@ -819,24 +819,24 @@ static int rkvdec_open(struct file *filp)
>  	rkvdec_reset_decoded_fmt(ctx);
>  	v4l2_fh_init(&ctx->fh, video_devdata(filp));
>  
> -	ret = rkvdec_init_ctrls(ctx);
> -	if (ret)
> -		goto err_free_ctx;
> -
>  	ctx->fh.m2m_ctx = v4l2_m2m_ctx_init(rkvdec->m2m_dev, ctx,
>  					    rkvdec_queue_init);
>  	if (IS_ERR(ctx->fh.m2m_ctx)) {
>  		ret = PTR_ERR(ctx->fh.m2m_ctx);
> -		goto err_cleanup_ctrls;
> +		goto err_free_ctx;
>  	}
>  
> +	ret = rkvdec_init_ctrls(ctx);
> +	if (ret)
> +		goto err_cleanup_m2m_ctx;
> +
>  	filp->private_data = &ctx->fh;
>  	v4l2_fh_add(&ctx->fh);
>  
>  	return 0;
>  
> -err_cleanup_ctrls:
> -	v4l2_ctrl_handler_free(&ctx->ctrl_hdl);
> +err_cleanup_m2m_ctx:
> +	v4l2_m2m_ctx_release(ctx->fh.m2m_ctx);
>  
>  err_free_ctx:
>  	kfree(ctx);