From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6B435C352A1 for ; Wed, 7 Dec 2022 17:03:05 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 50B4910E406; Wed, 7 Dec 2022 17:03:00 +0000 (UTC) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTPS id BA0E010E40D for ; Wed, 7 Dec 2022 17:02:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1670432578; x=1701968578; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=WoV9z6ZBbm9mUrY+haS/xZMRHerbOqBn4TTf68aUasU=; b=mxJu1Ipv6uAJYwcY6Y19Hcco37dnl21lKU29bczNckdrRyoQDqjIuxI1 P8gB5wM7bhw8QrMq+VJDZj+Y/UOfuNQzVhODQRYv2DfF9OB093dMFSeny ezhgwFTy4TFYAiXQbFA/jU6MetHt+ImGOGNpAWRQL9E/vdvSdasSr6BTt XnPT+dXgoibCOBFrWy3/wf+ulRsB9pRdw1zB6iHdRApnd1/CKlNcpv7HV zEHP2aE+onJoVHJ91kBBQnlQVjru0pJeBfLszv1O0o+0RdyLbdAq/Ojr/ irrzzhBiX5hF4JabyonSZlcDTH5EDrB7mCuyteXlYFv+YzHB7qGzImu5k g==; X-IronPort-AV: E=McAfee;i="6500,9779,10554"; a="318082079" X-IronPort-AV: E=Sophos;i="5.96,225,1665471600"; d="scan'208";a="318082079" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Dec 2022 09:02:34 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10554"; a="679203460" X-IronPort-AV: E=Sophos;i="5.96,225,1665471600"; d="scan'208";a="679203460" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.209.106.185]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Dec 2022 09:02:34 -0800 Date: Wed, 07 Dec 2022 08:50:31 -0800 Message-ID: <87r0xbcg4o.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Alan Previn In-Reply-To: <20221206092100.274195-5-alan.previn.teres.alexis@intel.com> References: <20221206092100.274195-1-alan.previn.teres.alexis@intel.com> <20221206092100.274195-5-alan.previn.teres.alexis@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/guc: Rename GuC log relay debugfs descriptively X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-gfx@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Tue, 06 Dec 2022 01:20:59 -0800, Alan Previn wrote: > > GuC log relay debugfs name for the control handle vs the actual relay > channel are vague. Fix them so it's obvious from the name. No real objection to anything here, just a couple of questions. > > Signed-off-by: Alan Previn > --- > drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 2 +- > .../drm/i915/gt/uc/intel_guc_log_debugfs.c | 22 +++++++++---------- > 2 files changed, 12 insertions(+), 12 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c > index 6e880d9f42d4..d019c60d34e8 100644 > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c > @@ -551,7 +551,7 @@ static int guc_log_relay_create(struct intel_guc_log *log) > */ > n_subbufs = intel_guc_log_relay_subbuf_count(log); > > - guc_log_relay_chan = relay_open("guc_log", > + guc_log_relay_chan = relay_open("guc_log_relay_chan", Is this a user visible name or just something internal? I.e. Is this a user visible file name? > dev_priv->drm.primary->debugfs_root, > subbuf_size, n_subbufs, > &relay_callbacks, dev_priv); > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c > index 27756640338e..feff1e606b38 100644 > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c > @@ -137,7 +137,7 @@ DEFINE_SIMPLE_ATTRIBUTE(guc_log_relay_subbuf_count_fops, > guc_log_relay_subbuf_count_get, NULL, > "%lld\n"); > > -static int guc_log_relay_open(struct inode *inode, struct file *file) > +static int guc_log_relay_ctl_open(struct inode *inode, struct file *file) Again not objecting, but what is the purpose/thinking behind adding _ctl_ to these function names? The previous names seemed fine? > { > struct intel_guc_log *log = inode->i_private; > > @@ -150,10 +150,10 @@ static int guc_log_relay_open(struct inode *inode, struct file *file) > } > > static ssize_t > -guc_log_relay_write(struct file *filp, > - const char __user *ubuf, > - size_t cnt, > - loff_t *ppos) > +guc_log_relay_ctl_write(struct file *filp, > + const char __user *ubuf, > + size_t cnt, > + loff_t *ppos) > { > struct intel_guc_log *log = filp->private_data; > int val; > @@ -175,7 +175,7 @@ guc_log_relay_write(struct file *filp, > return ret ?: cnt; > } > > -static int guc_log_relay_release(struct inode *inode, struct file *file) > +static int guc_log_relay_ctl_release(struct inode *inode, struct file *file) > { > struct intel_guc_log *log = inode->i_private; > > @@ -183,11 +183,11 @@ static int guc_log_relay_release(struct inode *inode, struct file *file) > return 0; > } > > -static const struct file_operations guc_log_relay_fops = { > +static const struct file_operations guc_log_relay_ctl_fops = { > .owner = THIS_MODULE, > - .open = guc_log_relay_open, > - .write = guc_log_relay_write, > - .release = guc_log_relay_release, > + .open = guc_log_relay_ctl_open, > + .write = guc_log_relay_ctl_write, > + .release = guc_log_relay_ctl_release, > }; > > void intel_guc_log_debugfs_register(struct intel_guc_log *log, > @@ -197,7 +197,7 @@ void intel_guc_log_debugfs_register(struct intel_guc_log *log, > { "guc_log_dump", &guc_log_dump_fops, NULL }, > { "guc_load_err_log_dump", &guc_load_err_log_dump_fops, NULL }, > { "guc_log_level", &guc_log_level_fops, NULL }, > - { "guc_log_relay", &guc_log_relay_fops, NULL }, > + { "guc_log_relay_ctl", &guc_log_relay_ctl_fops, NULL }, > { "guc_log_relay_subbuf_size", &guc_log_relay_subbuf_size_fops, NULL }, > { "guc_log_relay_subbuf_count", &guc_log_relay_subbuf_count_fops, NULL }, > }; Thanks. -- Ashutosh