Received: by 2002:ac0:e34a:0:0:0:0:0 with SMTP id g10csp82369imn; Tue, 26 Jul 2022 23:39:03 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vAgwZ0/4hN+kOJO/l1wDOQ7932UZ3DRPyn8j+JxKZqaIHz2JKDfzwcC908drjJXiQAruA1 X-Received: by 2002:a17:906:d54d:b0:72f:9b43:a4bf with SMTP id cr13-20020a170906d54d00b0072f9b43a4bfmr16792875ejc.200.1658903943048; Tue, 26 Jul 2022 23:39:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658903943; cv=none; d=google.com; s=arc-20160816; b=UDeZNH5t+6dvpZLRp3kPsUvwjqZl9KCi2528Mfix2DM5j1Yfv3K1hHeGFihSwAkGsQ +CxA8Ybce1BvzsjdO+yexHNe7NK+8eODTcM+7Jnw7DIkapCdct0XiDs7m4XliINYxDk5 E01fuggmdbHoyK4/W+bfrwseRe79LpPgc/I+44QSMw7B/y9Pyvwdw+wHhFQj7exhvnmU dNqaGh4idkhV+rhql6UH8eqVNvTKoi6TvWBeh4rur5eN6+aO3QIzNwgaT9okeCVpnmQO c/DOFv/oyUdrtDvFYPm2MRCQuXEq/FSPWJytSC8N0qwAfGNrQ0WRr89BcdJXR4HJNuFT G7Nw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=dwXPWtatvOB6NNdbsoQz+3BnmLa+2LEqoFiWIOQaY64=; b=g+eLDcTugCx2d/zsmEqHV2KVd8S9TfjhSrFHG16RXCtJT8J9bzg3ix8aruwYx82l0Z z5ju+FkM+lJl39q2OdufoG1R5do2FIG1/EueeT4YZNsPF9MJSIa1EcM6ua/abKCi5R4I 5lxN8+z5y0rFS0nGTZ4E+XxJVq1wzuVgdN8eleuncdN6JX9kjuK7URyi6Ir2DE6u5Msr Mdq9Rw/YJre5XxSuW6xDYfxDM5pXwYkDbfo9BJZgK3vRYkQj2oLft0wghfH52k9rHtoS /otHdD/5CGEHmcGvd7lNzZS0hJ23otuc60FLJgWrPs/bjaewUKVGUQmf7qTDa5ZXNTMn nvhw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=PyF6gq+u; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p18-20020aa7d312000000b0043cb30af926si1069431edq.58.2022.07.26.23.38.36; Tue, 26 Jul 2022 23:39:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=PyF6gq+u; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229780AbiG0GhX (ORCPT + 99 others); Wed, 27 Jul 2022 02:37:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48040 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229468AbiG0GhU (ORCPT ); Wed, 27 Jul 2022 02:37:20 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D68F023BE7 for ; Tue, 26 Jul 2022 23:37:19 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 699896141C for ; Wed, 27 Jul 2022 06:37:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4C7DAC433D6; Wed, 27 Jul 2022 06:37:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1658903838; bh=Jnh3dRfpX0ZXk1XE00ChFXhymlExtP+glmxZcPnpX2c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PyF6gq+u4FOrLT4D8ywKtqtLxaluf/x9Pou3/YPBrdZh4yVsv9jtRsbW1u5bUt0jS Fkm5V1Pyx9ITzivx26hVqI4ak10WXWxNiNqsPOhW3WjPglOfcza5upNFS9MJicZJwJ KOLjsCXH8xqwe7Nt1ZFrWJM0CjL4PrVEgQ/jNkfY= Date: Wed, 27 Jul 2022 08:37:16 +0200 From: Greg Kroah-Hartman To: Tong Zhang Cc: Jakub Kicinski , Colin Ian King , Saurav Girepunje , Nathan Chancellor , Johan Hovold , open list , linux-staging@lists.linux.dev, Dan Carpenter Subject: Re: [PATCH v2 2/3] staging: rtl8192u: move debug files to debugfs Message-ID: References: <20220718120149.GD2338@kadam> <20220719055047.322355-3-ztong0001@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 19, 2022 at 11:30:48PM -0700, Tong Zhang wrote: > On Tue, Jul 19, 2022 at 5:53 AM Greg Kroah-Hartman > wrote: > > > > On Mon, Jul 18, 2022 at 10:50:37PM -0700, Tong Zhang wrote: > > > There are 4 debug files created under /proc/net/[Devname]. Devname could > > > Due to this is purely for debuging as files are created read only, > > > move this to debugfs like other NIC drivers do instead of using procfs. > > > This is also to prepare for address rmmod warn issue. > > > > Minor comments based on good debugfs usage: > > > > > --- a/drivers/staging/rtl8192u/r8192U.h > > > +++ b/drivers/staging/rtl8192u/r8192U.h > > > @@ -1061,6 +1061,9 @@ typedef struct r8192_priv { > > > struct delayed_work gpio_change_rf_wq; > > > struct delayed_work initialgain_operate_wq; > > > struct workqueue_struct *priv_wq; > > > + > > > + /* debugfs */ > > > + struct dentry *debugfs_dir; > > > > Why do you need to save this dentry? Can't you just look it up when you > > want to remove the files? > > > > > +void rtl8192_debugfs_init(struct net_device *dev) > > > { > > > - struct proc_dir_entry *dir; > > > + struct dentry *dir; > > > + struct r8192_priv *priv = (struct r8192_priv *)ieee80211_priv(dev); > > > > No need to cast this. Same for later on in this file. > > > > > - if (!rtl8192_proc) > > > + dir = debugfs_create_dir(dev->name, NULL); > > > + if (IS_ERR(dir)) > > > return; > > > > I'm reading this code and your comment again. > Adding this check will avoid calling into debugfs_create_file() and 4 > function calls and doing checks from there, probably will save a > couple of CPU cycles and avoid branch prediction penalty if there is > any. > I don't think the compiler can optimize for this case though it's not > performance critical. Anyho I personally feel it is better to keep > this. It's not an optimization issue, it's a "we never care about the results of a call to debugfs_*() issue". That's all, debugfs is intended to be easy to use, and you should never care about the return values of if it worked or not, so your code should not check it and do anything different based on it. Yes, it's not like "normal" kernel code, but debugfs is not normal at all, and should never expect to work as it's only for debugging. thanks, greg k-h