From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58232) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b4pCu-0004Fh-F7 for qemu-devel@nongnu.org; Mon, 23 May 2016 08:43:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b4pCq-0002ry-Ah for qemu-devel@nongnu.org; Mon, 23 May 2016 08:43:39 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:35663) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b4pCq-0002rc-60 for qemu-devel@nongnu.org; Mon, 23 May 2016 08:43:36 -0400 Received: by mail-oi0-f65.google.com with SMTP id j202so631oih.2 for ; Mon, 23 May 2016 05:43:35 -0700 (PDT) Sender: Corey Minyard Reply-To: minyard@acm.org References: <1463671442-15631-1-git-send-email-minyard@acm.org> <1463671442-15631-6-git-send-email-minyard@acm.org> <20160520115344.29b1a24d@nial.brq.redhat.com> <5740FD4B.5010205@acm.org> <20160523120125.5e797fcb@nial.brq.redhat.com> From: Corey Minyard Message-ID: <5742FAB8.2060207@acm.org> Date: Mon, 23 May 2016 07:42:32 -0500 MIME-Version: 1.0 In-Reply-To: <20160523120125.5e797fcb@nial.brq.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v5 5/6] acpi: Add IPMI table entries List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: "Michael S . Tsirkin" , Paolo Bonzini , qemu-devel@nongnu.org, cminyard@mvista.com On 05/23/2016 05:01 AM, Igor Mammedov wrote: > On Sat, 21 May 2016 19:28:59 -0500 > Corey Minyard wrote: > >> Thanks for all the comments. I didn't know about stubs, as >> there's nothing that currently uses it in hw directory, but >> it's easy enough to add. I did have two comment below: >> >> On 05/20/2016 04:53 AM, Igor Mammedov wrote: >>> On Thu, 19 May 2016 10:24:01 -0500 >>> minyard@acm.org wrote: >> . >> . >> . >>> + aml_append(dev, aml_name_decl("_STR", aml_string("ipmi_%s", >>> + info->interface_name))); >>> + aml_append(dev, aml_name_decl("_UID", aml_int(info->uuid))); >>> + aml_append(dev, aml_name_decl("_CRS", aml_ipmi_crs(info, resource))); >>> + >>> + /* >>> + * The spec seems to require these to be methods. All the examples >>> + * show them this way and it doesn't seem to work if they are not. >>> + */ >>> + method = aml_method("_IFT", 0, AML_NOTSERIALIZED); >>> + aml_append(method, aml_return(aml_int(info->interface_type))); >>> + aml_append(dev, method); >>> + method = aml_method("_SRV", 0, AML_NOTSERIALIZED); >>> + aml_append(method, aml_return(aml_int(version))); >>> + aml_append(dev, method); >>> replace these methods with aml_name_decl() as they do not contain any logic >>> except of returning static value. >> I'm not sure why, but what you ask doesn't work. These have to be >> methods, and that is show by the IPMI spec, as the comment above >> these says. > on linux these methods are evaluated by ACPICA core and named constant > is equivalent to a method without arguments that returns constant value. > > It might be worth to investigate why it doesn't work. I just tried this again and it did work. I'm not sure why it didn't work before, if it was a change in Linux or my error. However, the latest IPMI spec has the following text: Note: _IFT and _SRV, following, have been reserved in ACPI 3.0 as names for control methods defined for SPMI Just because it works in Linux doesn't mean it will work on other OSes. Wouldn't it be safer to use a method here? -corey >> -corey