linux-kernel - Re: [PATCH v1 0/19] drm/panel: drmP.h removal and DRM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190201092037.GA9251@ravnborg.org>
Date:   Fri, 1 Feb 2019 10:20:37 +0100
From:   Sam Ravnborg <sam@...nborg.org>
To:     Thierry Reding <thierry.reding@...il.com>
Cc:     Sean Paul <sean@...rly.run>, dri-devel@...ts.freedesktop.org,
        Daniel Vetter <daniel@...ll.ch>,
        David Airlie <airlied@...ux.ie>,
        Linus Walleij <linus.walleij@...aro.org>,
        Stefan Mavrodiev <stefan@...mex.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 0/19] drm/panel: drmP.h removal and DRM_DEV*

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