On Tue, Jun 06, 2023 at 08:04:39PM +0530, Siddh Raman Pant wrote: > On Tue, 06 Jun 2023 19:35:12 +0530, Laurent Pinchart wrote: > > Hi Siddh, > > > > Thank you for the patch. > > Anytime :) > > > On Tue, Jun 06, 2023 at 04:15:16PM +0530, Siddh Raman Pant wrote: > > > Comments say macros DRM_DEBUG_* are deprecated in favor of > > > drm_dbg_*(NULL, ...), but they have broken support for it, > > > as the macro will result in `(NULL) ? (NULL)->dev : NULL`. > > > > What's the problem there ? > > (NULL)->dev is invalid C. It's a macro, so preprocessor substitutes > that text directly, there is no evaluation. GCC will throw an error > regarding dereferencing a void* pointer. > > > > /* Helper for struct drm_device based logging. */ > > > #define __drm_printk(drm, level, type, fmt, ...) \ > > > - dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__) > > > +({ \ > > > + struct device *__dev_ = __drm_dev_ptr(drm); \ > > > + if (__dev_) \ > > > + dev_##level##type(__dev_, "[drm] " fmt, ##__VA_ARGS__); \ > > > + else \ > > > + pr_##level##type("[drm] " fmt, ##__VA_ARGS__); \ > > > > If I recall correctly, dev_*() handle a NULL dev pointer just fine. Do > > we need to manually fall back to pr_*() ? > > I took drm_dev_printk (on line 261 of drm_print.c) as the reference, > wherein it uses a conditional for determining whether dev_printk or > printk should be called. > > I suppose it is to avoid printing "(NULL device *)", which dev_printk > does if it gets a NULL device pointer (refer the definition on line > 4831 of drivers/base/core.c). Though if I'm wrong, kindly let me know. You're right, it's probably best to avoid the "(NULL device *)". Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@xxxxxxxxxxxxxxxx> -- Regards, Laurent Pinchart