Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] The cursor plane's blend mode property is created supporting only COVERAGE, but the default atomic state initialization sets it to PREMULTI, causing atomic commits to fail. --
commit 8e0ec23e99807ff97fec9437ae15ac650e658045 Author: Icenowy Zheng <[email protected]> drm/verisilicon: set blend mode for the cursor plane This commit adds a fixed COVERAGE blend mode property for the cursor plane, as blend mode properties are now required to expose pixel formats with alpha. > diff --git a/drivers/gpu/drm/verisilicon/vs_cursor_plane.c > b/drivers/gpu/drm/verisilicon/vs_cursor_plane.c > index fa4f601dd0c87..36e3664373fa1 100644 > --- a/drivers/gpu/drm/verisilicon/vs_cursor_plane.c > +++ b/drivers/gpu/drm/verisilicon/vs_cursor_plane.c [ ... ] > @@ -268,5 +269,7 @@ struct drm_plane *vs_cursor_plane_init(struct drm_device > *drm_dev, > > drm_plane_helper_add(plane, &vs_cursor_plane_helper_funcs); > > + drm_plane_create_blend_mode_property(plane, > + BIT(DRM_MODE_BLEND_COVERAGE)); [Severity: High] Will this cause atomic commits to fail during state restoration? Looking at the plane setup, vs_cursor_plane_funcs uses the default drm_atomic_helper_plane_reset() hook, which unconditionally initializes the plane state's pixel_blend_mode to DRM_MODE_BLEND_PREMULTI. Because this property is created supporting only DRM_MODE_BLEND_COVERAGE, there is a mismatch with the initial state. When userspace queries the initial state, it reads PREMULTI. If it attempts to write this state back during an atomic commit (for instance, during a VT switch in a compositor), the commit will fail with -EINVAL since PREMULTI is not in the supported blend mode enum list. > return plane; > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
