Re: [PATCH 05/16] media: v4l2-common: Fix NV15_4L4 format info block height

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Other tiled formats (MT2110T, MT2110R, NV12MT, NV12MT_16X16) incorrectly take subsampling into account in their block_w and block_h definitions, causing chroma plane under-allocation.
- [High] Formats with bpp_div > 1 (e.g., NV15, NV20, Bayer 10P) lack block_w definitions, causing integer truncation in stride calculations.
--

(Note: The format of this report is altered due to recitation restrictions.
The original patch code is not quoted inline; instead, a free-form summary
of the findings is provided.)

Commit: 04995fa68d4b9c2dd80539724de182a617de7bac
Author: Paul Kocialkowski <paulk@sys-base.io>
Subject: media: v4l2-common: Fix NV15_4L4 format info block height

This commit corrects the NV15_4L4 format info by specifying it as a 4x4
format and ensuring the block size does not take subsampling into account
for luma and chroma.

You noted in the commit message that block size should not take subsampling
into account. Does this mean other tiled formats like MT2110T, MT2110R,
NV12MT, and NV12MT_16X16 are currently incorrect?

Looking at their definitions in v4l2_format_info(), they seem to divide
their chroma block dimensions by the subsampling factor. For instance,
MT2110T defines block_w as { 16, 8, 0, 0 } and block_h as { 32, 16, 0, 0 }.

Because v4l2_format_plane_stride() and v4l2_format_plane_height() apply
these alignments to the luma width and height before dividing by hdiv and
vdiv, an unaligned dimension like width 8 and height 16 would correctly
align the luma plane to 16x32. However, for the chroma plane, it would
align the luma dimensions to 8x16 before dividing by the subsampling
factors.

Could this result in the chroma plane being allocated only half of a
macroblock's required dimensions, leading to out-of-bounds memory writes
when the hardware writes full tiles?

Related to the macroblock sizing logic, do formats with bpp_div greater
than 1 need explicit block_w definitions to prevent integer truncation
during stride calculations?

Linear packed formats like NV15, NV20, SBGGR10P, and the RAW_CRU variants
pack multiple pixels into a fractional number of bytes. For example, NV15
has a bpp_div of 4. Because they currently lack a block_w definition, they
default to an alignment of 1.

If an unaligned width is passed to v4l2_format_plane_stride(), the formula
(aligned_width / hdiv) * bpp / bpp_div truncates. Using NV15 with a width
of 2 calculates a stride of (2 * 5) / 4 = 2 bytes. However, two 10-bit
pixels require 20 bits (2.5 bytes), so the stride rounds down.

Could this allocate less memory per line than the requested pixels require,
potentially causing buffer overflows since hardware typically writes in
multiples of bpp_div blocks?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260518102451.417971-1-paulk@sys-base.io?part=5