Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp3536091ybi; Tue, 18 Jun 2019 02:22:12 -0700 (PDT) X-Google-Smtp-Source: APXvYqxrBYQFMeKKwDBp+GAPtJA7P2NZ+n1JUVc/kpCyBLe7YctNIqT4KQT+F+dcSq6BRnEg/2fb X-Received: by 2002:a17:902:6b0c:: with SMTP id o12mr27351788plk.113.1560849732653; Tue, 18 Jun 2019 02:22:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560849732; cv=none; d=google.com; s=arc-20160816; b=JnHGqAGwmeiX9cpoUdAmHvr3WCKveMssq++QLak8nKyQzPbN1ZzfR0PasH9NbQ7WF6 srw8mTQL2Usp4EotSYOpFCAjnAkD/746Djpg48ibnmaYGbi5r3T0DiTsNh2+5KcSkotu KN6iKprvRUhl/O9rudNAyAwV7zdhoIwyUoMiuQI9ZDS0IZ4gyvgMddXKR4XBr5dUxIMx nbrLq07+aMMtvYlf40uaJVfi9P4novWtHSrQUWlY9wS6aggBRZVKhZ41aIKOybTvJuY+ /ZBWBMFz7iqqhx7bbuzb/rIh7qbVnYVas9YGhxaMm6XKfzxibS600WE0ZPF6E0dNAarf KE3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=dwod8k/2y9tJbhRFoCVsKV+l2/sc3Fnb33tz35DGud0=; b=mqHDGugtGPQWDFjENCeyENODd4VmydlZNTWdgZ+Ha6rsEf+w+BwXkeIIS5oacYNL2b BZWYWmhl9CytLOqiMvDrMfJ/zQHhoSvVNccY7GuVtNKxff/myWAuDfm8SIEYBt7MnsYR gbJ0Rh5YgILzmXIC7ErWBbuNjN0QSzlpYihBMdTsa3qgkosQcE/Pj5HqQw9ptOnzmJCn seH2G45yP/NQdttlTPgzGx692QcawidkoIFdTb8RbBR17YqqrfElzhHnUftsVKVepfCx xb24UyYgNQlaJuZM72n31hA0T91J+wCtXhCG6rvMJpNld7jGB7ZGPjuyXcExwKUilABs +LeA== ARC-Authentication-Results: i=1; mx.google.com; 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 m8si14231906pgs.457.2019.06.18.02.21.56; Tue, 18 Jun 2019 02:22: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; 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 S1729267AbfFRJVs (ORCPT + 99 others); Tue, 18 Jun 2019 05:21:48 -0400 Received: from mail.steuer-voss.de ([85.183.69.95]:58172 "EHLO mail.steuer-voss.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728810AbfFRJVs (ORCPT ); Tue, 18 Jun 2019 05:21:48 -0400 X-Virus-Scanned: Debian amavisd-new at mail.steuer-voss.de Received: by mail.steuer-voss.de (Postfix, from userid 1000) id C023A4CD7A; Tue, 18 Jun 2019 11:21:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.steuer-voss.de (Postfix) with ESMTP id BBDE9449CC; Tue, 18 Jun 2019 11:21:44 +0200 (CEST) Date: Tue, 18 Jun 2019 11:21:44 +0200 (CEST) From: Nikolaus Voss X-X-Sender: nv@fox.voss.local To: "Moore, Robert" cc: "Rafael J. Wysocki" , "Rafael J. Wysocki" , Len Brown , "Schmauss, Erik" , Jacek Anaszewski , Pavel Machek , Dan Murphy , Thierry Reding , ACPI Devel Maling List , "open list:ACPI COMPONENT ARCHITECTURE (ACPICA)" , "linux-leds@vger.kernel.org" , Linux PWM List , Linux Kernel Mailing List Subject: RE: [PATCH v2 1/3] ACPI: Resolve objects on host-directed table loads In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E3B95F9EC6@ORSMSX110.amr.corp.intel.com> Message-ID: References: <94F2FBAB4432B54E8AACC7DFDE6C92E3B95EFB26@ORSMSX110.amr.corp.intel.com> <94F2FBAB4432B54E8AACC7DFDE6C92E3B95F9EC6@ORSMSX110.amr.corp.intel.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 17 Jun 2019, Moore, Robert wrote: >> -----Original Message----- >> From: Nikolaus Voss [mailto:nv@vosn.de] >> Sent: Sunday, June 16, 2019 11:24 PM >> To: Moore, Robert >> Cc: Rafael J. Wysocki ; Rafael J. Wysocki >> ; Len Brown ; Schmauss, Erik >> ; Jacek Anaszewski >> ; Pavel Machek ; Dan Murphy >> ; Thierry Reding ; ACPI Devel >> Maling List ; open list:ACPI COMPONENT >> ARCHITECTURE (ACPICA) ; linux-leds@vger.kernel.org; >> Linux PWM List ; Linux Kernel Mailing List >> ; nikolaus.voss@loewensteinmedical.de >> Subject: RE: [PATCH v2 1/3] ACPI: Resolve objects on host-directed table >> loads >> >> Bob, >> >> On Fri, 14 Jun 2019, Moore, Robert wrote: >>> >>> >>> -----Original Message----- >>> From: Nikolaus Voss [mailto:nv@vosn.de] >>> Sent: Friday, June 14, 2019 2:26 AM >>> To: Rafael J. Wysocki >>> Cc: Rafael J. Wysocki ; Len Brown >>> ; Moore, Robert ; Schmauss, >>> Erik ; Jacek Anaszewski >>> ; Pavel Machek ; Dan Murphy >>> ; Thierry Reding ; ACPI >>> Devel Maling List ; open list:ACPI >>> COMPONENT ARCHITECTURE (ACPICA) ; >>> linux-leds@vger.kernel.org; Linux PWM List >>> ; Linux Kernel Mailing List >>> >>> Subject: Re: [PATCH v2 1/3] ACPI: Resolve objects on host-directed >>> table loads >>> >>> Hi Rafael, >>> >>> On Fri, 14 Jun 2019, Rafael J. Wysocki wrote: >>>> On Wed, Jun 12, 2019 at 10:36 AM Nikolaus Voss >>>> wrote: >>>>> >>>>> If an ACPI SSDT overlay is loaded after built-in tables have been >>>>> loaded e.g. via configfs or efivar_ssdt_load() it is necessary to >>>>> rewalk the namespace to resolve references. Without this, relative >>>>> and absolute paths like ^PCI0.SBUS or \_SB.PCI0.SBUS are not >>>>> resolved correctly. >>>>> >>>>> Make configfs load use the same method as efivar_ssdt_load(). >>>>> >>>>> Signed-off-by: Nikolaus Voss >>>> >>>> This is fine by me, so >>>> >>>> Acked-by: Rafael J. Wysocki >>>> >>>> Or if you want me to take this patch (without the other two in the >>>> series), please let me know. >>> >>> thanks. I think it would be the best if you take up this patch as it >>> is an independent topic. In retrospect it wasn't a good idea to put it >>> into this series. >>> >>> Kind regards, >>> Niko >>> >>> I would have to ask, why is additional code needed for package >>> initialization/resolution? It already happens elsewhere in acpica. Bob >> >> for built-in tables loaded via acpi_ex_load_table_op() everything is >> fine, because after acpi_tb_load_table() acpi_ns_walk_namespace() is >> called to resolve references. >> >> My fix only affects tables loaded dynamically via either acpi_configfs >> driver (for debugging purposes) or efivar_ssdt_load() (to specify a >> table on the kernel's command line). They use acpi_load_table() to load >> the table from a caller-owned buffer. To resolve the references, it is >> again necessary to rewalk the namespace, which was simply missing in >> acpi_load_table(). >> > [Moore, Robert] > > Perhaps you should call AcpiInitializeObjects after the call to > AcpiLoadTable, but I will check. My usage of acpi_load_table() is to load a SSDT which is the intended use of this method according to its description. And my expectation is that the package objects of the loaded table are initialized when this function successfully returns so it aligns with the behavior of acpi_ex_load_table_op() for built-in SSDTs. Otherwise there would be no point in having this function at all, because acpi_tb_install_and_load_table() could be called directly without any difference. Niko