Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] drm/tegra: uninitialized swap_uv field in tegra_plane_atomic_duplicate_state --
commit 7a6701643e457b2ef09eac11050804bd4c35f58d Author: Aaron Kling <[email protected]> drm/tegra: Support swapping chroma planes The Tegra display controller supports some yuv types, but not their chroma swapped variants. For example, yuv420 is supported but yvu420 is not. This can be efficiently worked around by just passing the hardware said chroma planes backwards. Add a flag to the plane state struct and handling to both tegradc and nvdisplay paths. > diff --git a/drivers/gpu/drm/tegra/plane.h b/drivers/gpu/drm/tegra/plane.h > index e33a581e6490e..dba5f1b254e98 100644 > --- a/drivers/gpu/drm/tegra/plane.h > +++ b/drivers/gpu/drm/tegra/plane.h > @@ -49,6 +49,7 @@ struct tegra_plane_state { > struct tegra_bo_tiling tiling; > u32 format; > u32 swap; > + bool swap_uv; [Severity: Low] Does tegra_plane_atomic_duplicate_state() need to copy this new swap_uv field? In drivers/gpu/drm/tegra/plane.c:tegra_plane_atomic_duplicate_state(), the state object is allocated without zero-initializing memory, and then explicitly copies fields like format, swap, and reflect_x: copy->format = state->format; copy->swap = state->swap; copy->reflect_x = state->reflect_x; copy->reflect_y = state->reflect_y; Because a corresponding copy->swap_uv = state->swap_uv assignment is omitted, copy->swap_uv contains uninitialized heap memory. While this is partially mitigated because tegra_plane_atomic_check() recomputes swap_uv for active planes, the uninitialized memory persists if the plane is disabled (!new_plane_state->crtc), which violates the state duplication contract and could risk undefined behavior if the state is inspected later. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
