Hi Thierry. > > I personally like the DRM_DEV_* variants better because of the > additional information that they provide. That can be useful when > grepping logs etc. > > I'm slightly on the fence about this patch. The unwritten, and > admittedly fuzzy, rules that I've been using so far are that dev_*() are > used or messages that have to do with the panel device itself, whereas > DRM_* variants are used for things that are actually related to DRM. So > typically this would mean that roughly everything in ->probe() or > ->remove() would be dev_*(), while the rest would be DRM_DEV_*(). For a rookie like me it is much simpler if one can use the same logging primitives all over or at least the rules when to use what is simple. It is simple to say that everything that exists below drivers/gpu/drm/ relates to drm. Suggested set of rules to follow: - If in drm core, use DRM_XXX where XXX represent the core functionality - If in a driver use DRM_DEV* if a struct device is available - If in a driver and no struct device, use plain DRM_ERROR/INFO If there is a need to distingush before/after one has a drm_device, the best way would be to have a set of logging primitives that take a drm_device. So we could extend the rule set: - If in a driver use DRM_DRM* if a struct drm_device is available (This rule would take precedence over a struct device) DRM_DRM*, or DRM_DDEV* or ... But you get the idea. But this is not where we are today. Shall I redo the patch-set so we go back to dev_*() in probe() / remove()? Sam _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
