From: Philipp Stanner <phasta@mailbox.org>
To: Danilo Krummrich <dakr@kernel.org>, oushixiong1025@163.com
Cc: "Matthew Brost" <matthew.brost@intel.com>,
"Philipp Stanner" <phasta@kernel.org>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>,
"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>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
"Shixiong Ou" <oushixiong@kylinos.cn>
Subject: Re: [PATCH v2] drm/sched: Guard against NULL dev in drm_sched_job trace event
Date: Tue, 25 Aug 2026 14:11:55 +0200 [thread overview]
Message-ID: <488156c4065f4da218ecce730266bd5cec3a9ea6.camel@mailbox.org> (raw)
In-Reply-To: <DKY0CX15JCPZ.2P2HLLYE9O28I@kernel.org>
On Tue, 2026-08-25 at 14:02 +0200, Danilo Krummrich wrote:
>
[…]
>
> I don't think that we should make such changes for Kunit tests only; it implies
> that a NULL dev now would be a valid value for the scheduler.
Strictly speaking we don't allow for the device pointer to be NULL, so
you might be right. However, it actually is only used for creating
debug prints, so…
>
> Why can't we have the Kunit test create a fake device for this? For instance,
> this is where struct faux_device becomes useful.
Wouldn't that be the same result as printing "NULL device"?
Many DRM print helpers do the latter already. __drm_dev_vprintk() takes
dev == NULL into account.
So one might argue that making the print-functions all robust against
NULL would be the more consistent thing.
P.
next prev parent reply other threads:[~2026-08-25 12:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 10:36 [PATCH v2] drm/sched: Guard against NULL dev in drm_sched_job trace event oushixiong1025
2026-08-25 12:02 ` Danilo Krummrich
2026-08-25 12:11 ` Philipp Stanner [this message]
2026-08-25 22:54 ` Danilo Krummrich
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=488156c4065f4da218ecce730266bd5cec3a9ea6.camel@mailbox.org \
--to=phasta@mailbox.org \
--cc=airlied@gmail.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthew.brost@intel.com \
--cc=mripard@kernel.org \
--cc=oushixiong1025@163.com \
--cc=oushixiong@kylinos.cn \
--cc=phasta@kernel.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/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;
as well as URLs for NNTP newsgroup(s).