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 X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83766C00A89 for ; Fri, 30 Oct 2020 07:10:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1348620729 for ; Fri, 30 Oct 2020 07:10:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604041835; bh=6UZfI9KlukChYkAwmZBY+j32nu5aC1F84wLitkAFcHg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=CC+1rm0fi9ptHo2AFgEfQwsC7Kwym5F8mK/E1n83WQYwFwvZGCAD+Tlrstdf61J76 PNHBxGm83L1/1vTqHAuK+DfmkW3nrDGsapdgCj6dS3murDviR3scqb+6wQJ5CS6oLI Roqtcp9S4Htus9nsbdGa0jRXDKhHVAWXiC0TKWDs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725943AbgJ3HKd (ORCPT ); Fri, 30 Oct 2020 03:10:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:44726 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725823AbgJ3HKd (ORCPT ); Fri, 30 Oct 2020 03:10:33 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1665120723; Fri, 30 Oct 2020 07:10:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1604041832; bh=6UZfI9KlukChYkAwmZBY+j32nu5aC1F84wLitkAFcHg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=wp8/hvRE/LfhJJ1P3TNOzq9lgzVnDlBRiSdLAl6MZXbf1TkKDHk95RR2Xjzd6+IUb tgKDQcRYbI6wWvk5mHsZThQB/1uDo+V8qIpoGs4X6ScEv9ONzxbN9egoDEZGb29nxz T8j3F0UclYetTTGfjJGzHyDJSfrpyLmCI0/UquMY= Date: Fri, 30 Oct 2020 08:11:20 +0100 From: Greg KH To: Deepak R Varma Cc: outreachy-kernel@googlegroups.com, Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , David Airlie , Daniel Vetter , amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, melissa.srw@gmail.com, daniel.vetter@ffwll.ch Subject: Re: [Outreachy kernel] [PATCH] drm/amdgpu: use DEFINE_DEBUGFS_ATTRIBUTE with debugfs_create_file_unsafe() Message-ID: <20201030071120.GA1493629@kroah.com> References: <20201030032245.GA274478@my--box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201030032245.GA274478@my--box> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 30, 2020 at 08:52:45AM +0530, Deepak R Varma wrote: > Using DEFINE_DEBUGFS_ATTRIBUTE macro with debugfs_create_file_unsafe() > function in place of the debugfs_create_file() function will make the > file operation struct "reset" aware of the file's lifetime. Additional > details here: https://lists.archive.carbon60.com/linux/kernel/2369498 > > Issue reported by Coccinelle script: > scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci > > Signed-off-by: Deepak R Varma > --- > Please Note: This is a Outreachy project task patch. > > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 20 ++++++++++---------- > 1 file changed, 10 insertions(+), 10 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > index 2d125b8b15ee..f076b1ba7319 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c > @@ -1551,29 +1551,29 @@ static int amdgpu_debugfs_sclk_set(void *data, u64 val) > return 0; > } > > -DEFINE_SIMPLE_ATTRIBUTE(fops_ib_preempt, NULL, > - amdgpu_debugfs_ib_preempt, "%llu\n"); > +DEFINE_DEBUGFS_ATTRIBUTE(fops_ib_preempt, NULL, > + amdgpu_debugfs_ib_preempt, "%llu\n"); Are you sure this is ok? Do these devices need this additional "protection"? Do they have the problem that these macros were written for? Same for the other patches you just submitted here, I think you need to somehow "prove" that these changes are necessary, checkpatch isn't able to determine this all the time. thanks, greg k-h