From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 816673F328D for ; Tue, 25 Aug 2026 12:12:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.151 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787659927; cv=none; b=Pd+Op1Ov+CgOIkhhkLjpG4vJK2fGwTQkZV6IjutI/UbXuUU5qTJ5x5qszKKz+pZAKpw8zFJLQKVP8uTgAnqGJ8jCBayOjrzhFZNV5KDrg5I2G7PIffRoDOeRqhn92CHbXcfJoX0VOB7MD1Sz77TR/CWQkFx2xgaushV+gCLzkjU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787659927; c=relaxed/simple; bh=T73vZchuwJDxSXUvOKdq69NcExOqVapI7/cu6f4fqqE=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=nre2fschLzPkaAkWeI127p+WcWIP01Di6JXZ0bpTeo845mWx4m0dPavqDQEWzywgtKdq5s43mmLtbb0HJpeNSvh2fa5+D1dWJ38VYwDtv57T0wfO/g8eS2QUvwUYcmhYfB2gptPgpgODF1FYLV2FoZoHZ6lJw4vzL8v4qWCL0mw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org; spf=pass smtp.mailfrom=mailbox.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b=FFaaq//I; arc=none smtp.client-ip=80.241.56.151 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=mailbox.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mailbox.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mailbox.org header.i=@mailbox.org header.b="FFaaq//I" Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4hTmqP2d3mz8tyc; Tue, 25 Aug 2026 14:12:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1787659921; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=T73vZchuwJDxSXUvOKdq69NcExOqVapI7/cu6f4fqqE=; b=FFaaq//IPiElRgZXUezuLs1Dbd0lcxE6CaLQqhr2iB66JOd4iVEKIiXvQBZ0WJe+UASTRz 5zlMQg6QhojVZLCgoHL0c5dr53RithEohx4cQOfN1LKzTRDOvIi0DWxvSDUtagiyObwIsA U4JrNAAcLhVY+TWSOtKD+uJgY3evbAik7XAmh7BjcSPu2qCkM9MxUoDLE3KjpZ2kMsTFYl UjW5MzJHp0GpEw5ND6JyKI4172h3hksu8BERZyqzr91Poi32YmJWo4kGj/kjuxZo/Tsnoa DO+hV4JGFQ3AHKTNOpOZXfJxRaZ7UIl7g5Z3B1G62Tm2RRRaPl6gr3SwYyLhdA== Message-ID: <488156c4065f4da218ecce730266bd5cec3a9ea6.camel@mailbox.org> Subject: Re: [PATCH v2] drm/sched: Guard against NULL dev in drm_sched_job trace event From: Philipp Stanner Reply-To: phasta@kernel.org To: Danilo Krummrich , oushixiong1025@163.com Cc: Matthew Brost , Philipp Stanner , Christian =?ISO-8859-1?Q?K=F6nig?= , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Shixiong Ou Date: Tue, 25 Aug 2026 14:11:55 +0200 In-Reply-To: References: <20260825103615.661200-1-oushixiong1025@163.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MBO-RS-ID: 2a3310547a7e1e939da X-MBO-RS-META: cw6abxtjxocj3jmrrib8a4oxudu3h3ze On Tue, 2026-08-25 at 14:02 +0200, Danilo Krummrich wrote: >=20 [=E2=80=A6] >=20 > I don't think that we should make such changes for Kunit tests only; it i= mplies > 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=E2=80=A6 >=20 > Why can't we have the Kunit test create a fake device for this? For insta= nce, > 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 =3D=3D NULL into account. So one might argue that making the print-functions all robust against NULL would be the more consistent thing. P.