Received: by 2002:ac0:8c9a:0:0:0:0:0 with SMTP id r26csp197897ima; Fri, 1 Feb 2019 01:49:24 -0800 (PST) X-Google-Smtp-Source: ALg8bN4uUf1BKk8bEdlBMXnw6qaslfTQfKGm7WielEdVVjhNE1k+ez95F1SJkIxLV9kH7ZRFg9o+ X-Received: by 2002:a62:47d9:: with SMTP id p86mr37696118pfi.95.1549014564576; Fri, 01 Feb 2019 01:49:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549014564; cv=none; d=google.com; s=arc-20160816; b=NKfC1DveXWyiUWqjOp1i3cuAintifs+Bxdy+A8Lrv6knbtA7OTjAu/hj44r+Ip1FPo /S2C9I8nurmtkonzZuCPpJL7t9DjbeoHArQhE1g00B42/Sb+b8lP6Nam8PrSMT18LjLV vCQX3O+ptEZq/L6ICJXaZHHladfb4xZ8CieRi8V5/Z0vgHQ26xRjJ9wsFLtOd/qoIn/H rtqW1YF3DyRa26H9HTKE46uNAXzrBXFil4r7/k69YuB2Hm/lbU+3cW0tOpSfTdAVVlar +wM7MEFru91K06qOYpijvcwOm/43eoQlysVrbJYIQequwAua1G0WcPguBlc3a9cOddXx AiYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Xb9EPCjGFcM+3LAtX4f87f6qoKkr7bfwbAiPNILLxSw=; b=vXJ2wxIekbbLsySzowtF92Wu/xzP7o/LN4CC8twMcU2hnFGPZsCMo/6yTtP3rQxH6P fe87S0R2v2HCzuPQ7l58bz7y9R1fVRtp17YyPqQLy41gxEjtGjH1EUaUDs39ZyVHGWDQ N17txjJDOgu/DUNGa+a1P0gdxIvvfBePMsWt0e0Ja3b6NS7xty4AemyeFPM8V2ZT89K0 G5Po2Iv2Ze07h3+JLMvLDfBo128d80FgMbXDNDYdhWSdMGmviizwoulZ1I/0HY9wBOSS IT5BLb011tMPoIWFIGhNb0tqxlo62v9Z7HmwZjw7yd8U+zIq4uDH8QIVn3RwO6q8RkHy Uscw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s17si6686057pgi.513.2019.02.01.01.48.35; Fri, 01 Feb 2019 01:49:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729114AbfBAJUq (ORCPT + 99 others); Fri, 1 Feb 2019 04:20:46 -0500 Received: from asavdk4.altibox.net ([109.247.116.15]:50125 "EHLO asavdk4.altibox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726450AbfBAJUp (ORCPT ); Fri, 1 Feb 2019 04:20:45 -0500 Received: from ravnborg.org (unknown [158.248.194.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by asavdk4.altibox.net (Postfix) with ESMTPS id 433A280380; Fri, 1 Feb 2019 10:20:40 +0100 (CET) Date: Fri, 1 Feb 2019 10:20:37 +0100 From: Sam Ravnborg To: Thierry Reding Cc: Sean Paul , dri-devel@lists.freedesktop.org, Daniel Vetter , David Airlie , Linus Walleij , Stefan Mavrodiev , linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 0/19] drm/panel: drmP.h removal and DRM_DEV* Message-ID: <20190201092037.GA9251@ravnborg.org> References: <20190131192619.9763-1-sam@ravnborg.org> <20190131200723.GZ114153@art_vandelay> <20190131210312.GA8947@ravnborg.org> <20190131215417.GA13156@mithrandir> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190131215417.GA13156@mithrandir> User-Agent: Mutt/1.5.21 (2010-09-15) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=UpRNyd4B c=1 sm=1 tr=0 a=UWs3HLbX/2nnQ3s7vZ42gw==:117 a=UWs3HLbX/2nnQ3s7vZ42gw==:17 a=kj9zAlcOel0A:10 a=TdsCcFLkx59YcYyte_0A:9 a=CjuIK1q_8ugA:10 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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