Am 18.07.19 um 18:46 schrieb Chris Wilson: > Quoting Sam Ravnborg (2019-07-18 17:14:58) >> drm_print.h used DRM_NAME - thus adding a dependency from >> include/drm/drm_print.h => uapi/drm/drm.h >> >> Hardcode the name "drm" to break this dependency. >> The idea is that there shall be a minimal dependency >> between include/drm/* and uapi/* >> >> Signed-off-by: Sam Ravnborg <sam@xxxxxxxxxxxx> >> Suggested-by: Daniel Vetter <daniel@xxxxxxxx> >> Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> >> Cc: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx> >> Cc: Maxime Ripard <maxime.ripard@xxxxxxxxxxx> >> Cc: Sean Paul <sean@xxxxxxxxxx> >> Cc: David Airlie <airlied@xxxxxxxx> >> Cc: Rob Clark <robdclark@xxxxxxxxx> >> Cc: Sean Paul <seanpaul@xxxxxxxxxxxx> >> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> >> Cc: Daniel Vetter <daniel@xxxxxxxx> >> --- >> include/drm/drm_print.h | 4 +--- >> 1 file changed, 1 insertion(+), 3 deletions(-) >> >> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h >> index a5d6f2f3e430..760d1bd0eaf1 100644 >> --- a/include/drm/drm_print.h >> +++ b/include/drm/drm_print.h >> @@ -32,8 +32,6 @@ >> #include <linux/device.h> >> #include <linux/debugfs.h> >> >> -#include <drm/drm.h> >> - >> /** >> * DOC: print >> * >> @@ -287,7 +285,7 @@ void drm_err(const char *format, ...); >> /* Macros to make printk easier */ >> >> #define _DRM_PRINTK(once, level, fmt, ...) \ >> - printk##once(KERN_##level "[" DRM_NAME "] " fmt, ##__VA_ARGS__) >> + printk##once(KERN_##level "[drm] " fmt, ##__VA_ARGS__) > I guess I'm th only one who > > #undef DRM_NAME > #define DRM_NAME i915 > > just so that I didn't have inane logs? > > One might suggest that instead of hardcoding it, follow the pr_fmt() > pattern and only add "[drm]" for the drm core. > > Even then it so useless (which drm driver is this message for???) that I > want to remove them all :( Yeah, agree. I mean it is nice if the core drm functions use a prefix for debug output. But I actually don't see the point for individual drivers. Christian. > -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
