On Tue Aug 25, 2026 at 2:11 PM CEST, Philipp Stanner wrote: > 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.
The dev_printk() primitives already do this, but that's not the point. The point is that a scheduler with a NULL device makes no sense in the first place, so we shouldn't support it -- especially not when it is just for a Kunit test that can easily satisfy the API by calling faux_device_create().
