From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A6E68C43613 for ; Thu, 20 Jun 2019 06:49:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8025A206B7 for ; Thu, 20 Jun 2019 06:49:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726485AbfFTGtb (ORCPT ); Thu, 20 Jun 2019 02:49:31 -0400 Received: from mail.steuer-voss.de ([85.183.69.95]:60686 "EHLO mail.steuer-voss.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726262AbfFTGtb (ORCPT ); Thu, 20 Jun 2019 02:49:31 -0400 X-Virus-Scanned: Debian amavisd-new at mail.steuer-voss.de Received: by mail.steuer-voss.de (Postfix, from userid 1000) id 2BDDB4D00C; Thu, 20 Jun 2019 08:49:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.steuer-voss.de (Postfix) with ESMTP id 295AA4D000; Thu, 20 Jun 2019 08:49:28 +0200 (CEST) Date: Thu, 20 Jun 2019 08:49:28 +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: <94F2FBAB4432B54E8AACC7DFDE6C92E3B95FC28D@ORSMSX110.amr.corp.intel.com> Message-ID: References: <94F2FBAB4432B54E8AACC7DFDE6C92E3B95EFB26@ORSMSX110.amr.corp.intel.com> <94F2FBAB4432B54E8AACC7DFDE6C92E3B95F9EC6@ORSMSX110.amr.corp.intel.com> <94F2FBAB4432B54E8AACC7DFDE6C92E3B95FB0BA@ORSMSX110.amr.corp.intel.com> <94F2FBAB4432B54E8AACC7DFDE6C92E3B95FC28D@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-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Wed, 19 Jun 2019, Moore, Robert wrote: > > >> -----Original Message----- >> From: Nikolaus Voss [mailto:nv@vosn.de] >> Sent: Wednesday, June 19, 2019 2:31 AM >> 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 >> >> Hi Bob, >> >> On Tue, 18 Jun 2019, Moore, Robert wrote: >>> >>> >>>> -----Original Message----- >>>> From: Moore, Robert >>>> Sent: Tuesday, June 18, 2019 1:25 PM >>>> To: 'Nikolaus Voss' >>>> 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' > leds@vger.kernel.org>; 'Linux PWM List' >>>> ; 'Linux Kernel Mailing List' >>> kernel@vger.kernel.org> >>>> Subject: RE: [PATCH v2 1/3] ACPI: Resolve objects on host-directed >>>> table loads >>>> >>>> If it is in fact the AcpiLoadTable interface that is incorrect, that >>>> of course is different. I'll check that out next. >>>> >>> [Moore, Robert] >>> >>> Yes, this is the issue, not specifically the Load() operator, but the >>> AcpiLoadTable interface only. >> >> thanks for checking this out. So what is the conclusion? Is my fix of >> AcpiLoadTable() sufficient or do we need a different solution? >> >> Niko >> > > > Your change is in the correct area. We want to do something like this, however: > > diff --git a/source/components/executer/exconfig.c b/source/components/executer/exconfig.c > index 84a058ada..eba1a6d28 100644 > --- a/source/components/executer/exconfig.c > +++ b/source/components/executer/exconfig.c > @@ -342,10 +342,9 @@ AcpiExLoadTableOp ( > return_ACPI_STATUS (Status); > } > > - /* Complete the initialization/resolution of package objects */ > + /* Complete the initialization/resolution of new objects */ > > - Status = AcpiNsWalkNamespace (ACPI_TYPE_PACKAGE, ACPI_ROOT_OBJECT, > - ACPI_UINT32_MAX, 0, AcpiNsInitOnePackage, NULL, NULL, NULL); > + AcpiNsInitializeObjects (); > > /* Parameter Data (optional) */ > > @@ -620,10 +619,11 @@ AcpiExLoadOp ( > return_ACPI_STATUS (Status); > } > > - /* Complete the initialization/resolution of package objects */ > + /* Complete the initialization/resolution of new objects */ > > - Status = AcpiNsWalkNamespace (ACPI_TYPE_PACKAGE, ACPI_ROOT_OBJECT, > - ACPI_UINT32_MAX, 0, AcpiNsInitOnePackage, NULL, NULL, NULL); > + AcpiExExitInterpreter (); > + AcpiNsInitializeObjects (); > + AcpiExEnterInterpreter (); > > /* Store the DdbHandle into the Target operand */ > > diff --git a/source/components/tables/tbxfload.c b/source/components/tables/tbxfload.c > index 217d54bf0..1e17db6c8 100644 > --- a/source/components/tables/tbxfload.c > +++ b/source/components/tables/tbxfload.c > @@ -479,6 +479,13 @@ AcpiLoadTable ( > ACPI_INFO (("Host-directed Dynamic ACPI Table Load:")); > Status = AcpiTbInstallAndLoadTable (ACPI_PTR_TO_PHYSADDR (Table), > ACPI_TABLE_ORIGIN_EXTERNAL_VIRTUAL, FALSE, &TableIndex); > + if (ACPI_SUCCESS (Status)) > + { > + /* Complete the initialization/resolution of new objects */ > + > + AcpiNsInitializeObjects (); > + } > + > return_ACPI_STATUS (Status); > } Ok, I see your are taking this up (I was a bit unsure after your previous post). Thanks, Niko