[PATCH v9 2/8] drm/print: Fix and add support for NULL as first argument in drm_* macros

[Siddh Raman Pant]

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.

Thanks,
Siddh