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;
Subject: Re: [PATCH v3 2/2] iommu/amd: Add basic debugfs infrastructure for
 AMD IOMMU
To:     "Mehta, Sohil" <sohil.mehta@intel.com>,
        "shunyong.yang@hxt-semitech.com" <shunyong.yang@hxt-semitech.com>,
        "gary.hook@amd.com" <gary.hook@amd.com>,
        "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>
Cc:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
References: <152302042701.47565.17954813724758433858.stgit@sosxen2.amd.com>
 <152302067362.47565.628887796165116844.stgit@sosxen2.amd.com>
 <1523664612.2747.13.camel@intel.com>
 <efa2b7a3-04a7-20b1-3651-89ebafa85c27@amd.com>
 <1524031122.4031.5.camel@hxt-semitech.com>
 <1524036520.2747.31.camel@intel.com>
 <1524040290.4031.25.camel@hxt-semitech.com>
 <1524082659.2747.37.camel@intel.com>
From:   "Hook, Gary" <ghook@amd.com>
Message-ID: <151f3396-959b-86f6-e056-58d38682d858@amd.com>
Date:   Wed, 18 Apr 2018 16:51:26 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <1524082659.2747.37.camel@intel.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Apr 2018 20:51:38.6176 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: be30bb93-16a1-402d-2850-08d5a56e2ee6
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR12MB0696
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 4/18/2018 4:16 PM, Mehta, Sohil wrote:
> On Wed, 2018-04-18 at 08:31 +0000, Yang, Shunyong wrote:
>> Maybe the original design is to call debugfs_initialized() before
>> calling debugfs_create_xxx()?
> 
> I am unaware of the original design. Someone else would probably have
> more context. However, looking at other places in the kernel where
> debugfs_create_xx() is used, the common convention seems to be to avoid
> calling debugfs_initialized().
> 
>   Sohil
> 

debugfs_initialized() was introduced in commit c0f92ba99 back in 
2.6.30-rc1. It was intended as a helper, not as a gatekeeper, which is 
why one doesn't see it used. Given that my use in this proposed patch is 
straightforward, I'm not seeing the need here. I had just seen some 
other code that used it, and copied the model.

Unless someone comes along to say, yes, use it, I'll not.

Gary