Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp6295664rwl; Tue, 4 Apr 2023 10:21:01 -0700 (PDT) X-Google-Smtp-Source: AKy350YpsL44t3oyBjXQHcBy0lDr8HxUtqHbC6uzHHbXHR7aKHGOKh5ZQhk9P1xb+bwkwbs2xYAv X-Received: by 2002:aa7:cb47:0:b0:502:4182:648a with SMTP id w7-20020aa7cb47000000b005024182648amr49394edt.9.1680628860811; Tue, 04 Apr 2023 10:21:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680628860; cv=none; d=google.com; s=arc-20160816; b=kHGS1KsJ1Syuom7JFdxcewjdfTeBB2mJ9olln+FUicufozpSGJyZJ9nKEg+5cieeOU ew758Kvtmlun/uI8ingLe4EfhDwGfAoh94Q9l8UEBheN3eZwJxIy9DfvOBDQq8da82z8 JZW/zW7cGZFK6SRTIfWf7mz6bO/pqyUkD1U+278/L7Coi3amolCjWG1yBgYFOENVqEoj GJNfBeXt/ujeseOIO9aPFPYbORmZoe1ae2H4/jn2H+hE/JOpQKg6aSYYnoXPirtcSUj+ SUR3CJW7qiX6+0aom/+nGkQndhYHGk2fwsp8X3srBj74huvYfi90bJXLKPoC65xZzgql cy8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=gVf34TiuNO+nKIfTQFq53HMC/QM244aBg4rTjX9/mc0=; b=WPXbJF5smW1gsXlMN22ZHvf0mWmB+jcwipYq2i0q59uvnyv/GY1XNlbK8RVQClD3oe w+fshUcuLWayEl2dXZgpphgbxmeHVGsGH2/pG+BRJJkU+73PXbqasZp2JExC792O6kt4 e2UAIlp86LgdcSKJbEn8T/eYf0J2muBEdbragGOVDxZJK6Y84qhz/essmtVkvclYOAxR /6Zm+YI6DKXE63hvdbRCRywHzIOTayX+FuIIXZYx/pZiwLuKrTNujzPBcpSeCiEfgVSQ QRhkppuYZgi7WpxFzP+xNHoV14I4Cbf2XDaPmYCQW+WKSszrTgldnkimaLw2x9k9CmZG IySQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=eQ816N22; 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=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b12-20020a05640202cc00b00501db82b63csi2670142edx.172.2023.04.04.10.20.36; Tue, 04 Apr 2023 10:21:00 -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=@intel.com header.s=Intel header.b=eQ816N22; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235926AbjDDRTK (ORCPT + 99 others); Tue, 4 Apr 2023 13:19:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44568 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235966AbjDDRTC (ORCPT ); Tue, 4 Apr 2023 13:19:02 -0400 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E1AEE4ED5; Tue, 4 Apr 2023 10:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1680628723; x=1712164723; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Efgn0wgG6M3dPrOoOF4i+0f2G3SonPMACefzAUfo3bY=; b=eQ816N22jGlonHOa0mgO/tr3XhTJCpLzj6AZBZR1Ywsw0BQi/KWLgBgJ WUSF4ypWKWwiRFzwh2PHlvQl7WwkxDxSJqe9S+4DQuz0Jp/hy9DLDbQIv buCsNwrlr68psQerSRiiQN2731IKnRqijIbKQYpLd6eNTpdeqmPEWOcM1 j2XZ4o4GQzdK6MhGE/DStifScQ4RCsWlwun3g3lOVculDmMrF/QsntCIS GJ2xj1dkCj9ysSlLTXLVEt6E8mGOIUw4YUMYFIWuBDM2AUOyRDO1NRoHO +R31qVSGSLDFzP9AFGohTcSwGyXXLtVH6eDq+JagiL0TT8YRFzdOwHxcB g==; X-IronPort-AV: E=McAfee;i="6600,9927,10670"; a="330847141" X-IronPort-AV: E=Sophos;i="5.98,318,1673942400"; d="scan'208";a="330847141" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Apr 2023 10:18:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10670"; a="1016186296" X-IronPort-AV: E=Sophos;i="5.98,318,1673942400"; d="scan'208";a="1016186296" Received: from rajatkha-mobl.gar.corp.intel.com (HELO [10.215.121.35]) ([10.215.121.35]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Apr 2023 10:18:41 -0700 Message-ID: Date: Tue, 4 Apr 2023 22:48:38 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [PATCH] usb: typec: intel_pmc_mux: Expose IOM port status to debugfs To: Greg KH Cc: heikki.krogerus@linux.intel.com, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org References: <20230330104821.773053-1-rajat.khandelwal@linux.intel.com> Content-Language: en-US From: Rajat Khandelwal In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE autolearn=unavailable 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 Hi, On 3/30/2023 4:31 PM, Greg KH wrote: > On Thu, Mar 30, 2023 at 04:18:21PM +0530, Rajat Khandelwal wrote: >> IOM status has a crucial role during debugging to check the >> current state of the type-C port. >> There are ways to fetch the status, but all those require the >> IOM port status offset, which could change with platform. >> >> Make a debugfs directory for intel_pmc_mux and expose the status >> under it per port basis. >> >> Signed-off-by: Rajat Khandelwal >> Reviewed-by: Heikki Krogerus >> --- >> drivers/usb/typec/mux/intel_pmc_mux.c | 44 +++++++++++++++++++++++++++ >> 1 file changed, 44 insertions(+) >> >> diff --git a/drivers/usb/typec/mux/intel_pmc_mux.c b/drivers/usb/typec/mux/intel_pmc_mux.c >> index 34e4188a40ff..c99d20888f5d 100644 >> --- a/drivers/usb/typec/mux/intel_pmc_mux.c >> +++ b/drivers/usb/typec/mux/intel_pmc_mux.c >> @@ -15,6 +15,7 @@ >> #include >> #include >> #include >> +#include >> >> #include >> >> @@ -145,6 +146,8 @@ struct pmc_usb { >> u32 iom_port_status_offset; >> }; >> >> +static struct dentry *pmc_mux_debugfs_root; > Why not just look up the dentry and delete it when you want it with a > call to debugfs_lookup_and_remove() instead? That way you don't have to > keep it around (hint, pass it back from your call to > pmc_mux_debugfs_init() or better yet, don't even have a > pmc_mux_debugfs_init() function as it only contains one line and is > only called in one place. > > This will save you the storage space of this variable if debugfs is not > enabled in your kernel. A small amount, yes, but it's nicer, right? I see. Yes, though a small amount, you're anyways right. 1. Though a single-line function, I explicitly defined it to make it more readable. ATM, maintaining a small different framework within the file for another function (debugfs) somehow presents a more 'organized' code to me, if that makes sense? :) 2. About the suggestion of not keeping the debugfs_root static throughout the execution, I can change it as per your suggestion, but I'd like to keep it this way, if that's ok? This way, it would fit nice in the future if more variables are to be added. Let me know your thoughts. Thanks Rajat > > thanks, > > greg k-h