Received: by 10.192.165.156 with SMTP id m28csp354939imm; Tue, 17 Apr 2018 11:15:18 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/eAQsGbGT1hG2UCrlM9fufrgtBSUrWJU6KKiZLnRZYuH0v6HvLy0JzQd+u7QOFzwrk9oXb X-Received: by 10.98.194.195 with SMTP id w64mr2891059pfk.83.1523988918476; Tue, 17 Apr 2018 11:15:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523988918; cv=none; d=google.com; s=arc-20160816; b=rbV0h6bDJRplGNn5snJ2gYtY5e2S3fr8QZ9QGWcPLEP6n4RS1/zZs4mJmZN2GWahn1 Iy7m7YJ1hLIhFBLDdXtZvXf1TmSnfqf8GSUyH/lIkeA+a6U/gtWuE8kGDZlF5/X72eMD v6isi+ZdWJmxI8l78LSMQ8LRvKrWLZitusYIXh8wbfDC2aQPB3m/TLxfGSHjN10ZKu8Q ++FxRxAwTyxk7LGruOcU/tWC8nP7x+Z5t3yz8pgTuiyVgvFYzLi0sPyIY+kN1ESAAtbV LK9f4gFDmv7lw//ed+FDCPwThq/YD4MnGBSJQ0uSI/vDfBu/fzYbQ26L79LA/9jiIhsy T2xA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=HjZFtIxQWA00nyBumhMeHMji3Nx6X0leFzl1RFjthbg=; b=qGufs/R790OLVtBcl/jF0cPnHMVa0IukmUwlBjyJ/1mnviKioeVd1icCBYm1I0Vmv3 TP6Zb9bODJ18TSA5UvfIDx7oPmXIV+GVaY3vi97pFwvykuUvBYtdr4PUFDiolUgSNJ1M ledcYw8TUwP5HwK2QJCANVVHI/2BAC7YxljEFmBv1295YuPaUJm+ksSalDHO4ew8EMFq hFgJ3a/IdyjCPOWuQzSZBV5EawHj6X41RV89NdXu9EirSON+vqPihv/viB3G0ivWWrC6 UY7GDpShs7yo56yGi1IF6NGFJX13U42FMDvplI07FoyDj4S83jEyHn1xphNkbcYRiQuu DvUg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f9-v6si14589959pli.50.2018.04.17.11.15.03; Tue, 17 Apr 2018 11:15:18 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752812AbeDQSNz (ORCPT + 99 others); Tue, 17 Apr 2018 14:13:55 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:46630 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751232AbeDQSNz (ORCPT ); Tue, 17 Apr 2018 14:13:55 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8CD2D1435; Tue, 17 Apr 2018 11:13:54 -0700 (PDT) Received: from [10.1.210.88] (e110467-lin.cambridge.arm.com [10.1.210.88]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C324F3F587; Tue, 17 Apr 2018 11:13:53 -0700 (PDT) Subject: Re: [PATCH v3 1/2] iommu - Enable debugfs exposure of the IOMMU To: "Hook, Gary" , Gary R Hook , iommu@lists.linux-foundation.org Cc: linux-kernel@vger.kernel.org References: <152302042701.47565.17954813724758433858.stgit@sosxen2.amd.com> <152302066417.47565.4017200105445420643.stgit@sosxen2.amd.com> <9123cd44-e01f-bff6-8441-792acbde10bc@amd.com> From: Robin Murphy Message-ID: Date: Tue, 17 Apr 2018 19:13:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <9123cd44-e01f-bff6-8441-792acbde10bc@amd.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17/04/18 18:46, Hook, Gary wrote: > On 4/6/2018 9:17 AM, Gary R Hook wrote: >> Provide base enablement for using debugfs to expose internal data of >> an IOMMU driver. When called, create the /sys/kernel/debug/iommu >> directory.  Emit a strong warning at boot time to indicate that this >> feature is enabled. >> >> This patch adds a top-level function that will create the (above) >> directory, under which a driver may create a hw-specific directory for >> its use. The function >> >>     iommu_debugfs_setup() >> >> returns a pointer to the new dentry structure created for >> /sys/kernel/debug/iommu, or NULL in the event of a failure. An IOMMU >> driver should call this function first, and then create a directory >> beneath it. A driver implementation might look something like: >> >> static struct dentry *my_debugfs; >> >>     struct dentry *d_top; >>     if (!my_debugfs) { >>         d_top = iommu_debugfs_setup(); >>         if (d_top) >>             my_debugfs = debugfs_create_dir("vendor", d_top); >>     } >> >> Since the IOMMU driver can not be removed from the running system, this >> patch only provides an "on" function. >> >> Signed-off-by: Gary R Hook >> --- >>   drivers/iommu/Kconfig         |   11 ++++++++ >>   drivers/iommu/Makefile        |    1 + >>   drivers/iommu/iommu-debugfs.c |   58 >> +++++++++++++++++++++++++++++++++++++++++ >>   include/linux/iommu.h         |    4 +++ >>   4 files changed, 74 insertions(+) >>   create mode 100644 drivers/iommu/iommu-debugfs.c >> >> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig >> index f3a21343e636..c1e39dabfec2 100644 >> --- a/drivers/iommu/Kconfig >> +++ b/drivers/iommu/Kconfig >> @@ -60,6 +60,17 @@ config IOMMU_IO_PGTABLE_ARMV7S_SELFTEST >>   endmenu >> +config IOMMU_DEBUG >> +    bool "Enable IOMMU internals in DebugFS" >> +    depends on DEBUG_FS >> +    default n >> +    help >> +      Allows exposure of IOMMU device internals. This option enables >> +      the use of debugfs by IOMMU drivers as required. Devices can, >> +      at initialization time, cause the IOMMU code to create a top-level >> +      debug/iommu directory, and then populate a subdirectory with >> +      entries as required. > > I should explicitly ask about this: > > Joerg had suggested IOMMU_DEBUGFS, but here I've changed to IOMMU_DEBUG. > I'm not seeing a lot of CONFIG options that use DEBUGFS for debugfs > options, so I chose to follow an implied convention. > > Question: should this indeed be IOMMU_DEBUGFS? >                                 ^^^^^^^^^^^^^ Personally I'd say yes, since there is at least some precedent for *_DEBUGFS already, and it does help make the intent that much clearer (*_DEBUG often just means lots of dmesg spam rather than an actual debugfs interface). Robin.