From: Russ Anderson <rja@sgi.com>
To: Matthew Garrett <matthew.garrett@nebula.com>
Cc: "lenb@kernel.org" <lenb@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"minyard@acm.org" <minyard@acm.org>,
"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
rja@sgi.com
Subject: Re: [PATCH V2] Change ACPI IPMI support to "default y"
Date: Fri, 21 Feb 2014 10:53:59 -0600 [thread overview]
Message-ID: <20140221165354.GO16114@sgi.com> (raw)
In-Reply-To: <1392941592.20109.36.camel@x230>
On Fri, Feb 21, 2014 at 12:13:13AM +0000, Matthew Garrett wrote:
> On Thu, 2014-02-20 at 17:59 -0600, Russ Anderson wrote:
> > On Thu, Feb 20, 2014 at 11:09:42PM +0000, Matthew Garrett wrote:
> > > On Thu, 2014-02-20 at 16:45 -0600, Russ Anderson wrote:
> > > >
> > > > The ACPI spec requires IPMI functionality before a module loads at
> > > > boot time? And the kernel is *broken* if it does not support ACIP IPMI
> > > > functionality before module load time? Really?
> > >
> > > There's no mechanism to ensure that IPMI support will be loaded before
> > > ACPI calls attempt to access IPMI operation regions. Really.
> >
> > And no mechanism can be added to ensure that ACPI call are
> > not attempted before IPMI is initialized? A flag or lock
> > or exported symbol indicating IPMI support is ready.
>
> ACPI functions are a black box to drivers. You make an ACPI call, the
> AML code does something. We could block there, but what's the driver
> supposed to do at that point? The core could call out to a module
> loader, but if the driver is built in and IPMI isn't then you'll end up
> with a 60 second pause in boot and a driver that doesn't work.
When you say "if the driver is built in" which driver are you
talking about? I thought the issue was making sure ipmi_si
driver was loaded before power meter driver.
> > > > > ACPI 4.0 includes support for IPMI operation regions. Modular IPMI means
> > > > > that the kernel will spend a significant amount of time (potentially
> > > > > until a user manually loads a driver) failing to implement part of the
> > > > > IPMI specification. That's a problem, and the correct fix is to ensure
> > > > > that the kernel always implements IPMI support.
> > > >
> > > > The ACPI spec says ipmi_si cannot be a driver? Really?
> > > > What is the real problem you are trying to solve?
> > >
> > > The most straightforward case is that of an ACPI power meter.
> >
> > So it is just a matter of making sure ipmi_si modules loads before
> > the ACPI power meter module loads, right? module dependency issue.
>
> No, because the power meter driver has no way of knowing that a vendor
> has implemented this interface via IPMI. *Any* ACPI entry point could
> theoretically reference IPMI code, even the _INI method that's called
> during ACPI core init. If it does, and if you don't have built-in ACPI
> support, you'd fail ACPI initialisation and things would go downhill
> from there.
Again, it sounds like as long as ipmi_si driver is loaded before
power meter driver, power meter driver is fine.
--
Russ Anderson, Kernel and Performance Software Team Manager
SGI - Silicon Graphics Inc rja@sgi.com
next prev parent reply other threads:[~2014-02-21 16:54 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-18 16:28 [PATCH V2] Change ACPI IPMI support to "default y" Matthew Garrett
2014-02-18 23:26 ` Rafael J. Wysocki
2014-02-18 23:15 ` Matthew Garrett
2014-02-18 23:35 ` Rafael J. Wysocki
2014-02-18 23:25 ` Matthew Garrett
2014-02-19 0:45 ` Rafael J. Wysocki
2014-02-19 0:53 ` Corey Minyard
2014-03-12 23:00 ` Pavel Machek
2014-03-12 23:22 ` Matthew Garrett
2014-03-13 7:22 ` Pavel Machek
2014-03-13 7:24 ` Matthew Garrett
2014-03-13 8:38 ` Pavel Machek
2014-03-13 13:29 ` Corey Minyard
2014-03-16 8:53 ` Pavel Machek
2014-02-20 20:14 ` Russ Anderson
2014-02-20 20:16 ` Matthew Garrett
2014-02-20 20:40 ` Russ Anderson
2014-02-20 20:46 ` Matthew Garrett
2014-02-20 20:59 ` Russ Anderson
2014-02-20 21:00 ` Matthew Garrett
2014-02-20 21:28 ` Russ Anderson
2014-02-20 21:39 ` Matthew Garrett
2014-02-20 22:06 ` Russ Anderson
2014-02-20 22:26 ` Matthew Garrett
2014-02-20 22:45 ` Russ Anderson
2014-02-20 23:09 ` Matthew Garrett
2014-02-20 23:59 ` Russ Anderson
2014-02-21 0:13 ` Matthew Garrett
2014-02-21 16:53 ` Russ Anderson [this message]
2014-02-21 2:17 ` Zheng, Lv
2014-02-21 16:12 ` Matthew Garrett
2014-02-24 0:48 ` Zheng, Lv
2014-02-21 16:33 ` Russ Anderson
2014-02-21 13:37 ` Corey Minyard
2014-02-21 15:51 ` Matthew Garrett
2014-02-21 17:12 ` Corey Minyard
2014-02-20 21:49 ` Russ Anderson
2014-02-20 21:51 ` Matthew Garrett
2014-02-21 0:10 ` Rafael J. Wysocki
2014-02-20 23:01 ` Russ Anderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140221165354.GO16114@sgi.com \
--to=rja@sgi.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.garrett@nebula.com \
--cc=minyard@acm.org \
--cc=rjw@rjwysocki.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox