From: Sam Ravnborg <sam@ravnborg.org>
To: Sean Paul <sean@poorly.run>
Cc: Thierry Reding <thierry.reding@gmail.com>,
dri-devel@lists.freedesktop.org, Daniel Vetter <daniel@ffwll.ch>,
David Airlie <airlied@linux.ie>,
Linus Walleij <linus.walleij@linaro.org>,
Stefan Mavrodiev <stefan@olimex.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 0/19] drm/panel: drmP.h removal and DRM_DEV*
Date: Thu, 31 Jan 2019 22:03:12 +0100 [thread overview]
Message-ID: <20190131210312.GA8947@ravnborg.org> (raw)
In-Reply-To: <20190131200723.GZ114153@art_vandelay>
Hi Sean.
> Hey Sam,
> Thanks for the patchset, this will make dmesg grepping easier! One comment, and
> you're going to hate me for it: Why use DRM_DEV* instead of DRM_*?
>
> When I introduced DRM_DEV, it was to cover the case where there are multiple
> instances of the same driver (ie: dual-channel mipi, multiple crtcs, etc). I
> suppose that _could_ happen in the panel space, but it seems more unlikely than
> not.
The rationale for using DRM_DEV* are solely that if a struct device * is avalible,
then we can use this to provide more information about the origin of the logging.
I have not testet it - but from browsing the code I could not see that
DRM_ERROR and friends picked up the module name.
If DRM_ERROR is the right choice I will redo the patches - no problem.
But if we loose the module name then the DRM_DEV* variants are preferable IMO.
Note: I missed DRM_DEV_WARN(), so I left one dev_warn() in the code.
Sam
next prev parent reply other threads:[~2019-01-31 21:03 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-31 19:26 [PATCH v1 0/19] drm/panel: drmP.h removal and DRM_DEV* Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 01/19] drm/panel: drop drmP.h usage Sam Ravnborg
2019-01-31 19:26 ` Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 02/19] drm/panel: panel-innolux: drop unused variable Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 03/19] drm/panel: samsung: use DRM_DEV* Sam Ravnborg
2019-01-31 19:26 ` Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 04/19] drm/panel: arm-versatile: " Sam Ravnborg
2019-01-31 19:26 ` Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 05/19] drm/panel: truly: " Sam Ravnborg
2019-01-31 19:26 ` Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 06/19] drm/panel: sitronix: " Sam Ravnborg
2019-01-31 19:26 ` Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 07/19] drm/panel: ilitek: " Sam Ravnborg
2019-01-31 19:26 ` Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 08/19] drm/panel: innolux: " Sam Ravnborg
2019-01-31 19:26 ` Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 09/19] drm/panel: jdi: " Sam Ravnborg
2019-01-31 19:26 ` Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 10/19] drm/panel: lg: " Sam Ravnborg
2019-01-31 19:26 ` Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 11/19] drm/panel: lvds: " Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 12/19] drm/panel: olimex: " Sam Ravnborg
2019-01-31 19:26 ` Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 13/19] drm/panel: orisetech: " Sam Ravnborg
2019-01-31 19:26 ` Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 14/19] drm/panel: panasonic: " Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 15/19] drm/panel: raspberrypi: " Sam Ravnborg
2019-01-31 19:26 ` Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 16/19] drm/panel: raydium: " Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 17/19] drm/panel: seiko: " Sam Ravnborg
2019-01-31 19:26 ` Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 18/19] drm/panel: sharp: " Sam Ravnborg
2019-01-31 19:26 ` [PATCH v1 19/19] drm/panel: simple: " Sam Ravnborg
2019-01-31 19:33 ` [PATCH v1 0/19] drm/panel: drmP.h removal and DRM_DEV* Sam Ravnborg
2019-01-31 20:07 ` Sean Paul
2019-01-31 21:03 ` Sam Ravnborg [this message]
2019-01-31 21:54 ` Thierry Reding
2019-02-01 9:20 ` Sam Ravnborg
2019-02-01 10:30 ` Jani Nikula
2019-02-01 10:52 ` Andrzej Hajda
2019-02-01 11:13 ` Jani Nikula
2019-02-01 13:37 ` Sam Ravnborg
2019-02-02 1:31 ` Joe Perches
2019-02-02 1:31 ` Joe Perches
2019-02-04 18:42 ` Sam Ravnborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190131210312.GA8947@ravnborg.org \
--to=sam@ravnborg.org \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sean@poorly.run \
--cc=stefan@olimex.com \
--cc=thierry.reding@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.