From: Matthew Garrett <matthew.garrett@nebula.com>
To: "minyard@acm.org" <minyard@acm.org>
CC: "rja@sgi.com" <rja@sgi.com>, "lenb@kernel.org" <lenb@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "rjw@rjwysocki.net" <rjw@rjwysocki.net>,
        "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH V2] Change ACPI IPMI support to "default y"
Thread-Topic: [PATCH V2] Change ACPI IPMI support to "default y"
Thread-Index: AQHPLMZ9xGM3QUTlOk+rIS3zgvGkBZq+l00AgAAHJxWAAAUvD4ABFuuVgAAlkQA=
Date: Fri, 21 Feb 2014 15:51:53 +0000
Message-ID: <1392997912.20109.41.camel@x230>
References: <1392740909-2079-1-git-send-email-matthew.garrett@nebula.com>
	 <20140220201458.GA7099@sgi.com> <1392927381.20109.0.camel@x230>
	 <20140220204028.GJ17949@sgi.com> <1392929163.20109.5.camel@x230>
	 <20140220205901.GM17949@sgi.com> <1392930047.20109.6.camel@x230>
	 <5307568C.3020701@acm.org>
In-Reply-To: <5307568C.3020701@acm.org>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
Content-ID: <780159190972554FB352146F7C52319F@namprd05.prod.outlook.com>
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Transfer-Encoding: 8bit

On Fri, 2014-02-21 at 07:37 -0600, Corey Minyard wrote:

> However, the basic problem is that hardware vendors produce hardware
> that sucks and then expect software to fix all the problems.  Most IPMI
> interfaces don't have interrupts, so they have to be polled.  Then they
> add important interfaces on top of it like firmware upgrade and ACPI and
> expect it to perform well.  If vendors would just have an interrupt for
> IPMI, 99% of these problems would go away.

Not going to disagree. The impact on power consumption is also pretty
awful. I should re-read the spec to figure out whether we can
legitimately get away with not doing that.

> One thing we can do is remove the default interface probing for IPMI. 
> Even though the spec has it, all modern hardware should have it
> specified in ACPI or device tree.  That should fix all the slow boot
> problems, at least.  If a user wants to add a default interface, they
> can use the interface to dynamically add it after boot time.

Something like this (untested)?

diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
index eea8464..5126230 100644
--- a/drivers/char/ipmi/Kconfig
+++ b/drivers/char/ipmi/Kconfig
@@ -52,6 +52,16 @@ config IPMI_SI
         Currently, only KCS and SMIC are supported.  If
         you are using IPMI, you should probably say "y" here.
 
+config IPMI_PROBE_DEFAULTS
+       bool 'Probe for all possible IPMI interfaces by default'
+       help
+         Modern systems will usually expose IPMI interfaces via a discoverable
+        firmware mechanism such as ACPI or DMI. Older systems do not, and so
+        the driver is forced to probe hardware manually. This may cause boot
+        delays. Say "n" here to disable this manual probing. IPMI will then
+        only be available on older systems if the "ipmi_si_intf.trydefaults=1"
+        boot argument is passed.
+
 config IPMI_WATCHDOG
        tristate 'IPMI Watchdog Timer'
        help
diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index 03f4189..82c7d56 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -1230,7 +1230,11 @@ static bool          si_tryplatform = 1;
 #ifdef CONFIG_PCI
 static bool          si_trypci = 1;
 #endif
+#ifdef CONFIG_IPMI_PROBE_DEFAULTS
 static bool          si_trydefaults = 1;
+#else
+static bool          si_trydefaults;
+#endif
 static char          *si_type[SI_MAX_PARMS];
 #define MAX_SI_TYPE_STR 30
 static char          si_type_str[MAX_SI_TYPE_STR];


-- 
Matthew Garrett <matthew.garrett@nebula.com>
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?