All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Stuebner <heiko@sntech.de>
To: Daniel Stone <daniel@fooishbar.org>
Cc: dri-devel@lists.freedesktop.org,
	Daniel Stone <daniels@collabora.com>,
	andy.yan@rock-chips.com, hjc@rock-chips.com,
	cristian.ciocaltea@collabora.com, kernel@collabora.com
Subject: Re: [PATCH 06/13] drm/rockchip: Switch impossible format conditional to WARN_ON
Date: Mon, 20 Oct 2025 16:00:32 +0200	[thread overview]
Message-ID: <1938027.tdWV9SEqCh@phil> (raw)
In-Reply-To: <CAPj87rM=Zvg9HbJ71FCmbGXAe32R0B1yLwRwyS0ztEy6=aww_w@mail.gmail.com>

Am Montag, 20. Oktober 2025, 15:47:16 Mitteleuropäische Sommerzeit schrieb Daniel Stone:
> Hi,
> 
> On Mon, 20 Oct 2025 at 14:25, Heiko Stuebner <heiko@sntech.de> wrote:
> > Am Montag, 20. Oktober 2025, 15:10:31 Mitteleuropäische Sommerzeit schrieb Heiko Stuebner:
> > > Am Mittwoch, 15. Oktober 2025, 13:00:35 Mitteleuropäische Sommerzeit schrieb Daniel Stone:
> > > >     format = vop2_convert_format(fb->format->format);
> > > > -   if (format < 0)
> > > > -           return format;
> > > > +   /* We shouldn't be able to create a fb for an unsupported format */
> > > > +   WARN_ON(format < 0);
> > >
> > > What happened to Greg's
> > > "But don't add new WARN() calls please, just properly clean up and handle
> > > the error." [0]
> > >
> > > Also, switching to WARN_ON would then continue the atomic_check function
> > > where it currently does exit with a real error code?
> >
> > So while I can live with WARN_ON as something that should never ever
> > happen
> 
> Right, I'm following the clarifications from jgg and Kees in that
> thread, namely that WARN_ON is being used for 'how on earth did this
> happen, the code is somehow completely broken' situations that
> userspace should never be able to trigger under any circumstances.
> 
> > I still think atomic_check should follow its function and report
> > the error upwards like:
> >
> > if (WARN_ON(format < 0))
> >   return format;
> 
> Happy to do this if you prefer.

I do :-) .

In the same line as the rest of your series does get rid of strange
clutches that try to work around impossible situations, if the format
thing is wrong, we should not continue, but fail the check function,
as we did before.


Heiko



  reply	other threads:[~2025-10-20 14:00 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-15 11:00 [PATCH 00/13] drm/rockchip: No more post-atomic_check fixups Daniel Stone
2025-10-15 11:00 ` [PATCH 01/13] drm/rockchip: Demote normal drm_err to debug Daniel Stone
2025-10-15 11:00 ` [PATCH 02/13] drm/rockchip: Declare framebuffer width/height bounds Daniel Stone
2025-10-15 11:00 ` [PATCH 03/13] drm/rockchip: Return error code for errors Daniel Stone
2025-10-15 11:00 ` [PATCH 04/13] drm/rockchip: Rename variables for clarity Daniel Stone
2025-10-15 11:00 ` [PATCH 05/13] drm/rockchip: Use temporary variables Daniel Stone
2025-10-15 11:00 ` [PATCH 06/13] drm/rockchip: Switch impossible format conditional to WARN_ON Daniel Stone
2025-10-20 13:10   ` Heiko Stuebner
2025-10-20 13:25     ` Heiko Stuebner
2025-10-20 13:47       ` Daniel Stone
2025-10-20 14:00         ` Heiko Stuebner [this message]
2025-10-15 11:00 ` [PATCH 07/13] drm/rockchip: Switch impossible pos " Daniel Stone
2025-10-15 11:00 ` [PATCH 08/13] drm/rockchip: Fix eSmart test condition Daniel Stone
2025-11-12  8:16   ` Andy Yan
2025-10-15 11:00 ` [PATCH 09/13] drm/rockchip: Enforce scaling workaround in plane_check Daniel Stone
2025-11-12  8:13   ` Andy Yan
2025-10-15 11:00 ` [PATCH 10/13] drm/rockchip: Enforce AFBC source alignment " Daniel Stone
2025-11-12  8:21   ` Andy Yan
2025-11-12  8:34     ` Andy Yan
2025-11-12  9:42       ` Andy Yan
2025-10-15 11:00 ` [PATCH 11/13] drm/rockchip: Enforce AFBC transform stride align " Daniel Stone
2025-10-15 11:00 ` [PATCH 12/13] drm/rockchip: Use drm_is_afbc helper function Daniel Stone
2025-10-15 11:00 ` [PATCH 13/13] drm/rockchip: Simplify format_mod_supported Daniel Stone
2025-10-20 14:00 ` (subset) [PATCH 00/13] drm/rockchip: No more post-atomic_check fixups Heiko Stuebner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1938027.tdWV9SEqCh@phil \
    --to=heiko@sntech.de \
    --cc=andy.yan@rock-chips.com \
    --cc=cristian.ciocaltea@collabora.com \
    --cc=daniel@fooishbar.org \
    --cc=daniels@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hjc@rock-chips.com \
    --cc=kernel@collabora.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.