public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Murthy, Arun R" <arun.r.murthy@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>,
	xaver.hugl@kde.org, harry.wentland@amd.com,
	uma.shankar@intel.com, louis.chauvet@bootlin.com,
	naveen1.kumar@intel.com, ramya.krishna.yella@intel.com,
	dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	intel-xe@lists.freedesktop.org,
	Suraj Kandpal <suraj.kandpal@intel.com>
Subject: Re: [PATCH v10 0/7] User readable error codes on atomic_ioctl failure
Date: Tue, 24 Feb 2026 11:28:41 +0200	[thread overview]
Message-ID: <f155fae0285684108e92887e963358ea0ea158e9@intel.com> (raw)
In-Reply-To: <aZ1lbnop84k4du6N@intel.com>

On Tue, 24 Feb 2026, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> Although I kinda doubt its actual usefulness to drive useful
> fallback logic because often the restrictions might be a combination
> of many things, and the kernel can only realistically report one of
> those things.

Yeah, this is my main concern as well. The drivers will have to bail out
on the first issue they hit, whatever it is. The drivers may choose to
do the checks in different orders, resulting in different failure modes
for different drivers. And finally, accidentally making the order of the
checks part of the ABI contract is a scary prospect. Imagine user space
depending on certain checks happening first in order for the fallback
logic to work properly. Is it a kernel regression to change the order of
the checks then?

BR,
Jani.


-- 
Jani Nikula, Intel

  parent reply	other threads:[~2026-02-24  9:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-23  9:15 [PATCH v10 0/7] User readable error codes on atomic_ioctl failure Arun R Murthy
2026-02-23  9:15 ` [PATCH v10 1/7] drm: Define user readable error codes for atomic ioctl Arun R Murthy
2026-02-23  9:16 ` [PATCH v10 2/7] drm/atomic: Add error_code element in atomic_state Arun R Murthy
2026-02-23  9:16 ` [PATCH v10 3/7] drm/atomic: Call complete_signaling only if prepare_signaling is done Arun R Murthy
2026-02-23  9:16 ` [PATCH v10 4/7] drm/atomic: Allocate atomic_state at the beginning of atomic_ioctl Arun R Murthy
2026-02-23  9:16 ` [PATCH v10 5/7] drm/atomic: Return user readable error in atomic_ioctl Arun R Murthy
2026-02-23  9:16 ` [PATCH v10 6/7] drm/i915/display: Error codes for async flip failures Arun R Murthy
2026-02-23  9:16 ` [PATCH v10 7/7] drm: Introduce DRM_CAP_ATOMIC_ERROR_REPORTING Arun R Murthy
2026-02-23 10:07 ` [PATCH v10 0/7] User readable error codes on atomic_ioctl failure Murthy, Arun R
2026-02-24  7:07   ` Ville Syrjälä
2026-02-24  7:16     ` Murthy, Arun R
2026-02-24  8:46       ` Ville Syrjälä
2026-02-24  8:54         ` Murthy, Arun R
2026-02-24  9:03           ` Ville Syrjälä
2026-02-24  9:28         ` Jani Nikula [this message]
2026-02-24  9:31           ` Murthy, Arun R
2026-02-24 12:07             ` Jani Nikula
2026-03-18 15:26               ` Xaver Hugl
2026-02-23 11:09 ` ✗ i915.CI.BAT: failure for User readable error codes on atomic_ioctl failure (rev9) Patchwork
2026-03-18 15:05 ` [PATCH v10 0/7] User readable error codes on atomic_ioctl failure Xaver Hugl
2026-03-23  6:07   ` Murthy, Arun R
2026-03-23 21:19     ` Xaver Hugl
2026-03-24  4:46       ` Murthy, Arun R

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=f155fae0285684108e92887e963358ea0ea158e9@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=airlied@gmail.com \
    --cc=arun.r.murthy@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=harry.wentland@amd.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=louis.chauvet@bootlin.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=naveen1.kumar@intel.com \
    --cc=ramya.krishna.yella@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=simona@ffwll.ch \
    --cc=suraj.kandpal@intel.com \
    --cc=tursulin@ursulin.net \
    --cc=tzimmermann@suse.de \
    --cc=uma.shankar@intel.com \
    --cc=ville.syrjala@linux.intel.com \
    --cc=xaver.hugl@kde.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox