Claude review: drm/drm_blend: allow blend mode property without PREMULTI

[Claude Code Review Bot <claude-review@example.com>]

Overall Series Review

Subject: drm/drm_blend: allow blend mode property without PREMULTI
Author: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Patches: 3
Reviewed: 2026-05-05T08:17:26.131070

---

This is a 2-patch series to relax the DRM blend mode property creation API so that drivers whose hardware only supports COVERAGE (no PREMULTI) can expose blend mode. Patch 1 removes the PREMULTI requirement; patch 2 adds a hard enforcement that any driver exposing alpha (via alpha property or pixel formats with alpha channel) **must** also expose the blend mode property, or `drm_dev_register()` will fail.

The motivation is sound — hardware exists that only does COVERAGE blending, and the current API artificially prevents those drivers from being upstreamed. However, **patch 2 has a serious problem**: the enforcement will break multiple existing in-tree drivers that are currently working and do not call `drm_plane_create_blend_mode_property()`.

**Affected drivers found** (alpha_property set but no blend_mode_property):
- `sun4i/sun8i_ui_layer.c`
- `sun4i/sun8i_vi_layer.c`
- `atmel-hlcdc/atmel_hlcdc_plane.c`
- `stm/ltdc.c`
- `xlnx/zynqmp_kms.c`
- `logicvc/logicvc_layer.c`

None of these use the deprecated `.load` callback, so the enforcement is not bypassed. Additionally, the pixel-format alpha check (`fmt->has_alpha`) will catch even more drivers — virtually any driver that lists ARGB8888 among its supported formats but doesn't set up blend mode. This is an extremely broad net that could break many more drivers beyond the alpha_property ones listed above.

The series needs either: (a) companion patches to fix all affected in-tree drivers before the enforcement is turned on, or (b) a softer enforcement (WARN instead of error-return) with a plan to harden it later.

---

---
Generated by Claude Code Patch Reviewer