Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1176780imm; Tue, 5 Jun 2018 10:12:12 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKkj5ypdUCx9YBQTx7r5UyXvEjivBCIFa9Zs8XTcPOPKcZ9yBZxqXoq9UCp8J1bj3o5pvuE X-Received: by 2002:a17:902:ab8d:: with SMTP id f13-v6mr27431837plr.81.1528218732476; Tue, 05 Jun 2018 10:12:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528218732; cv=none; d=google.com; s=arc-20160816; b=WDfIMuGFEAxD+sYMvrjOOXjjsTAhK4ybznsnbWRAuuFuXix8ChrbQk65k3P1BMPg5G i9wfKyAc7l3EcJgS6NW2EGAdhjMJ48ATZWnxP30UDonQlDL9eNrALcxVC7yK7GEMT2g/ MoakMD+MrU/EthGjD8YX/MxmOfz9BulkG8OGagJ2jIr/07lcjCL9ZyTmhLIkLalPPJic Exyz3rJU1WPNGgSfdDxWK8U7WXEHkpz4XSjRymk0vUgl3aOsjchBcIZ9H2Sayvtovsqd R6vtsMkJKXPmJXlpF42tYNK9sM3fZsuz8mlKsIPUJtlPYHlMN0bcqCDk+/Qv8fx/Axv1 BPIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=gTmCGTehcodc+DwBqtHm9TUAZ6p45wKAX04MxBf8ur4=; b=s3aKtarFc/LBzOMPK0LSlSOjbLKGMoC/xmtHplk2/O932MFhflxpF3LDqaIDeDvj+T I1IeeakkjBt/PaTaRrG2MGv4nEhyTLTni7dpmOOJizTDinuKL2UtwGtk+Fq6rulVtptc 6nTCxV+UNJHX4FqikyEnAYaF24URkBEBIaib6N7yT7Iv2J0Jo4ROXjmt1tnEDTzG1/n6 z3ZLnZe6W10i6L7TWpR8KcpIPAjEuDEDwEQlhZechjOQYsRuBFTUUgpaePFPBAmV/CCl bqkHf1r+2WiKBkVb760J3Gwc/7bS6AhO6oIPEpfvWia8CWjAv5wp1KJY55W5RMPakA4w FNZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=jTsSh408; 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 t8-v6si4934234pgq.369.2018.06.05.10.11.58; Tue, 05 Jun 2018 10:12:12 -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; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=jTsSh408; 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 S1753942AbeFERJo (ORCPT + 99 others); Tue, 5 Jun 2018 13:09:44 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:34919 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752039AbeFERJm (ORCPT ); Tue, 5 Jun 2018 13:09:42 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 34A712144B; Tue, 5 Jun 2018 13:09:42 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Tue, 05 Jun 2018 13:09:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=gTmCGTehcodc+DwBqtHm9TUAZ6p45 wKAX04MxBf8ur4=; b=jTsSh408Ma7Q1SRCCsXWCTupDy32YZ7K/Iu7jzvPXbVNG LweFYIoJmHTDq+1bQ3HKiM1/BpMp0A8BEcCVXn7CbKCa3RR+0Gu40D91LLyFOQJ4 q7d+Bddl71uianFSllrLHuEhIhXlNKTGxqjAOIMqeiAdGZL9rCHr4lphBrRnkP5s 3/tx9t0xpF7XZiucuS384pzguWt3VnLEbSFZ9mnoD7bZyzSPSkaDL9Y6QNdlJ3Dm 3UkyDK60FW+aTw284aZ84etfbI/HD6MyVFCsEtq1rFW0OVG5/4EPphXOnnAFPHRc j2mJvxWWZs4ZIlQfH6HNMUL7wCSAIpqo/rZh7tE8Q== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from localhost (lfbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.messagingengine.com (Postfix) with ESMTPA id 9B03E10262; Tue, 5 Jun 2018 13:09:41 -0400 (EDT) Date: Tue, 5 Jun 2018 19:06:24 +0200 From: Greg KH To: Gary R Hook Cc: iommu@lists.linux-foundation.org, joro@8bytes.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v8 2/2] iommu/amd: Add basic debugfs infrastructure for AMD IOMMU Message-ID: <20180605170624.GB10834@kroah.com> References: <152761784341.2654.8609366076331539902.stgit@sosgrh1.amd.com> <152761820371.2654.4551405686504157036.stgit@sosgrh1.amd.com> <20180529183917.GA10618@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 05, 2018 at 11:58:13AM -0500, Gary R Hook wrote: > On 05/29/2018 01:39 PM, Greg KH wrote: > > On Tue, May 29, 2018 at 01:23:23PM -0500, Gary R Hook wrote: > > > Implement a skeleton framework for debugfs support in the > > > AMD IOMMU. Add a hidden boolean to Kconfig that is defined > > > for the AMD IOMMU when general IOMMY DebugFS support is > > > enabled. > > > > > > Signed-off-by: Gary R Hook > > > --- > > > drivers/iommu/Kconfig | 4 ++++ > > > drivers/iommu/Makefile | 1 + > > > drivers/iommu/amd_iommu_debugfs.c | 39 +++++++++++++++++++++++++++++++++++++ > > > drivers/iommu/amd_iommu_init.c | 6 ++++-- > > > drivers/iommu/amd_iommu_proto.h | 6 ++++++ > > > drivers/iommu/amd_iommu_types.h | 5 +++++ > > > 6 files changed, 59 insertions(+), 2 deletions(-) > > > create mode 100644 drivers/iommu/amd_iommu_debugfs.c > > > > > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > > > index f9af25ac409f..ec223f6f4ad4 100644 > > > --- a/drivers/iommu/Kconfig > > > +++ b/drivers/iommu/Kconfig > > > @@ -137,6 +137,10 @@ config AMD_IOMMU > > > your BIOS for an option to enable it or if you have an IVRS ACPI > > > table. > > > +config AMD_IOMMU_DEBUGFS > > > + def_bool y > > > > Why default y? Can you not boot a box without this? If not, it should > > not be Y. > > Again, apologies for not seeing this sooner. > > Yes, the system can boot without this. The idea of a hidden option was > surfaced by Robin, and after my first approach was shot down, I tried this. > > Logic: If the over-arching IOMMU debugfs option is enabled, then > AMD_IOMMU_DEBUGFS gets defined, and AMD IOMMU code gets included. > > This issue was discussed a few weeks ago. No single approach appears to > satisfy everyone. I like this because it depends upon one switch: Do you > want DebugFS support enabled in the IOMMU driver, period? Vendor-specific > code can then choose to implement support or not, and a builder doesn't have > to worry about enabling/disabling multiple Kconfig options. > > At least, that was my line of reasoning. > > I'm not married to any approach, and I don't find clever use of Kconfig > options too terribly challenging. And I'm not defending, I'm just > explaining. The issue is, no one sets Kconfig options except a very tiny subset of kernel developers. Distros allways enable everything, as they have to do that. If you are creating something here that is so dangerous that you spam the kernel log with big warning messages, you should not be making it easy to enable, let alone be enabled by default :) Just make it an option, have it rely on the kernel debugging option, and say "DO NOT ENABLE THIS UNLESS YOU REALLY REALLY REALLY KNOW WHAT YOU ARE DOING!" thanks, greg k-h