linux-kernel - Re: [PATCH V2] Change ACPI IPMI support to "default y"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5307890D.4080807@acm.org>
Date:	Fri, 21 Feb 2014 11:12:45 -0600
From:	Corey Minyard <minyard@....org>
To:	Matthew Garrett <matthew.garrett@...ula.com>
CC:	"rja@....com" <rja@....com>, "lenb@...nel.org" <lenb@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"rjw@...ysocki.net" <rjw@...ysocki.net>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: Re: [PATCH V2] Change ACPI IPMI support to "default y"

On 02/21/2014 09:51 AM, Matthew Garrett wrote:
> 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.

Thinking about this some more, I realized that it may possible to turn
off the driver if nothing at all is waiting.  I'll need to look at the
spec to see if I'm forgetting something.

>
>> 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)?

That's exactly what I would have done...

-corey

>
> 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];
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/