linux-kernel - Re: [PATCH v5 0/8] drm/rockchip: No more post-atomic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <176789904481.3303270.4157084512307461486.b4-ty@sntech.de>
Date: Thu,  8 Jan 2026 20:04:37 +0100
From: Heiko Stuebner <heiko@...ech.de>
To: Sandy Huang <hjc@...k-chips.com>,
	Andy Yan <andy.yan@...k-chips.com>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Maxime Ripard <mripard@...nel.org>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	David Airlie <airlied@...il.com>,
	Simona Vetter <simona@...ll.ch>,
	Chaoyi Chen <chaoyi.chen@...k-chips.com>,
	Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Cc: Heiko Stuebner <heiko@...ech.de>,
	David Laight <david.laight.linux@...il.com>,
	dri-devel@...ts.freedesktop.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-rockchip@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	Daniel Stone <daniels@...labora.com>,
	kernel@...labora.com
Subject: Re: [PATCH v5 0/8] drm/rockchip: No more post-atomic_check fixups


On Mon, 15 Dec 2025 15:09:16 +0100, Nicolas Frattaroli wrote:
> I'm taking over this series to get it across the finish line. Original
> cover letter from Daniel Stone on v1:
> 
> > Hi,
> > This series is a pretty small and consistent one for VOP2. The atomic
> > uAPI very clearly specifies that drivers should either do what userspace
> > requested (on a successful commit), or fail atomic_check if it is not
> > for any reason possible to do what userspace requested.
> >
> > VOP2 is unfortunately littered with a bunch of cases where it will apply
> > fixups after atomic_check - doing something different to what userspace
> > requested, e.g. clipping or aligning regions - or throw error messages
> > into the log when userspace does request a condition which can't be met.
> >
> > Doing something different to what was requested is bad because it
> > results in unexpected visual output which can look like artifacts.
> > Throwing errors into the log is bad because generic userspace will
> > reasonably attempt to try any configuration it can. For example,
> > throwing an error message on a plane not being aligned to a 16 pixel
> > boundary can result in 15 frames' worth of error output in the log when
> > a window is being animated across a screen.
> >
> > This series removes all post-check fixups - failing the check if the
> > configuration cannot be applied - and also demotes all messages about
> > unsupported configurations to DEBUG_KMS.
> >
> > Cheers,
> > Daniel
> 
> [...]

Applied, thanks!

[1/8] drm/rockchip: vop2: Switch impossible format conditional to WARN_ON
      commit: 78de5d28d7207f816565fa43ec44e6735c319ddf
[2/8] drm/rockchip: vop2: Switch impossible pos conditional to WARN_ON
      commit: 2f4e3f2bef45d1eb4d8204c5f204cf274e8a6ca6
[3/8] drm/rockchip: vop2: Fix Esmart test condition
      commit: f403945d240417761d404cb1ce8fa2c1ec02daf5
[4/8] drm/rockchip: vop2: Enforce scaling workaround in plane_check
      commit: dfb673c71fc0039a6495731d0c0fcefa8a97541d
[5/8] drm/rockchip: vop2: Enforce AFBC source alignment in plane_check
      commit: 8cdd4d858d7aaeb583ae2b4e5a0378936b18f0f0
[6/8] drm/rockchip: vop2: Enforce AFBC transform stride align in plane_check
      commit: 081676de4a22341a877ce81c4d5364737d167859
[7/8] drm/rockchip: vop2: Use drm_is_afbc helper function
      commit: c8c85c0a7fc2a545749da1ab8dc866de025c2314
[8/8] drm/rockchip: vop2: Simplify format_mod_supported
      commit: 28c2490458ca935b2d793ec0e6c22265855255a2

Best regards,
-- 
Heiko Stuebner <heiko@...ech.de>