Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp1806086ybn; Thu, 26 Sep 2019 02:29:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqxnqzAfSSyN/V+1r242R24JqPLWyd+hKQu+nyr35LtqLLTnAHRBo9ZxYj7cCgOReHjM4z3p X-Received: by 2002:a17:906:f846:: with SMTP id ks6mr2196369ejb.192.1569490148754; Thu, 26 Sep 2019 02:29:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569490148; cv=none; d=google.com; s=arc-20160816; b=Q/L5WtflDC67hI8GVybl8aH3RD4k5/ZPOTuEz17KUZQP6Hvt0OaWll8f5UhnOWNXmm SVYMpQoTpta7XpZAOE9xT5JpO5EZ+PiyzEG688qYo6nex8sivCzKFkcwceiDG/6KRX04 KSjNl1pudL87ta7xqfBPeyDt+gWRyexNREJNDuS02iNnUJs75IgcLOZd4lURGNT1HMI8 goUwbkua+ZngqQtpGlpC9vJu+5q8BoA0z+YmSjprG0ax2AjuS+BNxcl+g7osW/vHyaYG uK8IhgYbogEK8lENsYwmf2os3qamvP471Yos2JlHj6OuiRZsSeboM3LBYCxbxLXhREhk Dhmg== 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=fRCdJHk5ca6hYvSWWGS8xIXXxYCWVTgsYYUJFgYogMA=; b=tON6ckp2uCWmD0zF01cX8T3K6BjHpW89RlVmbZ7q+XFgs1VKZZ7IVzEynoiqbn79lR SfRwpHAPcuTFQh3ol2ULS5u7hhpY3Grb5K4zj6jpJSJxEYVCKSyMKOKdjVSB1TO4iESk kttq+S3u4+3MJTX1ldgh859IwRRU6XCwl+Hw9e+tj1Zrc7C3TLMJRj3v/lm24xwciQjK tpnoLDZHiJHI6VSNCbEY7FgP4/VBTuJTqmiYrlRZvRFO9eHVCVGAtQRBNnvgzdRuH+iW ziekqL62y6rSup8oOGUtBbEeeJHt8xKOLTg0Jd+Rbmz/Hb3ubrJpMapv7SHOzMxp2GVJ UthA== 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 f14si886508edf.102.2019.09.26.02.28.45; Thu, 26 Sep 2019 02:29:08 -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 S2389337AbfIYKSR (ORCPT + 99 others); Wed, 25 Sep 2019 06:18:17 -0400 Received: from mail.steuer-voss.de ([85.183.69.95]:41094 "EHLO mail.steuer-voss.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727141AbfIYKSQ (ORCPT ); Wed, 25 Sep 2019 06:18:16 -0400 X-Virus-Scanned: Debian amavisd-new at mail.steuer-voss.de Received: by mail.steuer-voss.de (Postfix, from userid 1000) id 7C8234D253; Wed, 25 Sep 2019 12:18:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.steuer-voss.de (Postfix) with ESMTP id 797934D179; Wed, 25 Sep 2019 12:18:11 +0200 (CEST) Date: Wed, 25 Sep 2019 12:18:11 +0200 (CEST) From: Nikolaus Voss X-X-Sender: nv@fox.voss.local To: "Moore, Robert" cc: Ferry Toth , "Shevchenko, Andriy" , "Schmauss, Erik" , "Rafael J. Wysocki" , Len Brown , Jacek Anaszewski , Pavel Machek , Dan Murphy , "linux-acpi@vger.kernel.org" , "devel@acpica.org" , "linux-kernel@vger.kernel.org" , Jan Kiszka Subject: RE: [PATCH] ACPICA: make acpi_load_table() return table index In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E3B968B639@ORSMSX110.amr.corp.intel.com> Message-ID: References: <20190906174605.GY2680@smile.fi.intel.com> <20190912080742.24642-1-nikolaus.voss@loewensteinmedical.de> <94F2FBAB4432B54E8AACC7DFDE6C92E3B9679CE8@ORSMSX110.amr.corp.intel.com> <94F2FBAB4432B54E8AACC7DFDE6C92E3B967ADF6@ORSMSX110.amr.corp.intel.com> <20190913151228.GT2680@smile.fi.intel.com> <7625fe37-1710-056d-fb9e-39c33fd962a1@gmail.com> <94F2FBAB4432B54E8AACC7DFDE6C92E3B967AEC9@ORSMSX110.amr.corp.intel.com> <94F2FBAB4432B54E8AACC7DFDE6C92E3B968327D@ORSMSX110.amr.corp.intel.com> <94F2FBAB4432B54E8AACC7DFDE6C92E3B9686438@ORSMSX110.amr.corp.intel.com> <94F2FBAB4432B54E8AACC7DFDE6C92E3B968B639@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 Tue, 24 Sep 2019, Moore, Robert wrote: > How about this: > Go back to using acpi_tb_install_and_load_table(), but then call acpi_ns_initialize_objects afterwards This is what acpi_load_table does. > > > 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 (); > } The idea was to have all drivers use the same interface for dynamically loading ACPI tables, i.e. efivar_ssdt_load() (which already used acpi_load_table()) and the acpi_configfs driver. The efivar driver doesn't provide a possibility to unload the table, so acpi_load_table() is okay for this purpose. According to Bob, acpi_tb_install_and_load_table() is not part of the external ACPICA API declared under include/acpi (though it is exported). The counterpart of acpi_load_table() - inline comment "Note1: Mainly intended to support hotplug addition of SSDTs" - seems to be acpi_unload_parent_table() - inline comment "Note: Mainly intended to support hotplug removal of SSDTs" - but it doesn't expect a table index but an acpi_handle as argument, and it is only used within ACPICA, so IMO the API can't be properly used in our case and should be improved even though unloading tables is deprecated. If changing the API is not an option, we can choose between Rafael's way (extending the API instead of changing it) or Bob's proposal (doing the same thing - hotplug-loading a SSDT - in different ways, in case of acpi_configfs using ACPICA internal API). I don't have a clear favorite, but I'm tending to Rafael's solution my favorite being the API change. Niko > > > -----Original Message----- > From: Nikolaus Voss > Sent: Monday, September 23, 2019 2:05 AM > To: Moore, Robert > Cc: Ferry Toth ; Shevchenko, Andriy ; Schmauss, Erik ; Rafael J. Wysocki ; Len Brown ; Jacek Anaszewski ; Pavel Machek ; Dan Murphy ; linux-acpi@vger.kernel.org; devel@acpica.org; linux-kernel@vger.kernel.org; Jan Kiszka > Subject: RE: [PATCH] ACPICA: make acpi_load_table() return table index > > On Thu, 19 Sep 2019, Moore, Robert wrote: >> >> >> -----Original Message----- >> From: Nikolaus Voss [mailto:nv@vosn.de] >> Sent: Wednesday, September 18, 2019 7:32 AM >> To: Moore, Robert >> Cc: Ferry Toth ; Shevchenko, Andriy >> ; Schmauss, Erik >> ; Rafael J. Wysocki ; Len >> Brown ; Jacek Anaszewski >> ; Pavel Machek ; Dan Murphy >> ; linux-acpi@vger.kernel.org; devel@acpica.org; >> linux-kernel@vger.kernel.org; Jan Kiszka >> Subject: RE: [PATCH] ACPICA: make acpi_load_table() return table index >> >> On Wed, 18 Sep 2019, Moore, Robert wrote: >>> >>> >>> -----Original Message----- >>> From: Nikolaus Voss [mailto:nv@vosn.de] >>> Sent: Monday, September 16, 2019 2:47 AM >>> To: Moore, Robert >>> Cc: Ferry Toth ; Shevchenko, Andriy >>> ; Schmauss, Erik >>> ; Rafael J. Wysocki ; Len >>> Brown ; Jacek Anaszewski >>> ; Pavel Machek ; Dan Murphy >>> ; linux-acpi@vger.kernel.org; devel@acpica.org; >>> linux-kernel@vger.kernel.org; Jan Kiszka >>> Subject: RE: [PATCH] ACPICA: make acpi_load_table() return table >>> index >>> >>> On Fri, 13 Sep 2019, Moore, Robert wrote: >>>> >>>> >>>> -----Original Message----- >>>> From: Ferry Toth [mailto:fntoth@gmail.com] >>>> Sent: Friday, September 13, 2019 9:48 AM >>>> To: Shevchenko, Andriy ; Moore, Robert >>>> >>>> Cc: Nikolaus Voss ; Schmauss, Erik >>>> ; Rafael J. Wysocki ; >>>> Len Brown ; Jacek Anaszewski >>>> ; Pavel Machek ; Dan >>>> Murphy ; linux-acpi@vger.kernel.org; >>>> devel@acpica.org; linux-kernel@vger.kernel.org; >>>> nikolaus.voss@loewensteinmedical.de; >>>> Jan Kiszka >>>> Subject: Re: [PATCH] ACPICA: make acpi_load_table() return table >>>> index >>>> >>>> Hello all, >>>> >>>> Sorry to have sent our message with cancelled e-mail address. I have correct this now. >>>> >>>> Op 13-09-19 om 17:12 schreef Shevchenko, Andriy: >>>>> On Fri, Sep 13, 2019 at 05:20:21PM +0300, Moore, Robert wrote: >>>>>> -----Original Message----- >>>>>> From: Nikolaus Voss [mailto:nv@vosn.de] >>>>>> Sent: Friday, September 13, 2019 12:44 AM >>>>>> To: Moore, Robert >>>>>> Cc: Shevchenko, Andriy ; Schmauss, >>>>>> Erik ; Rafael J. Wysocki >>>>>> ; Len Brown ; Jacek Anaszewski >>>>>> ; Pavel Machek ; Dan >>>>>> Murphy ; linux-acpi@vger.kernel.org; >>>>>> devel@acpica.org; linux-kernel@vger.kernel.org; Ferry Toth >>>>>> ; nikolaus.voss@loewensteinmedical.de >>>>>> Subject: RE: [PATCH] ACPICA: make acpi_load_table() return table >>>>>> index >>>>>> >>>>>> Bob, >>>>>> >>>>>> On Thu, 12 Sep 2019, Moore, Robert wrote: >>>>>>> The ability to unload an ACPI table (especially AML tables such >>>>>>> as >>>>>>> SSDTs) is in the process of being deprecated in ACPICA -- since >>>>>>> it is also deprecated in the current ACPI specification. This is >>>>>>> being done because of the difficulty of deleting the namespace >>>>>>> entries for the table. FYI, Windows does not properly support this function either. >>>>>> >>>>>> ok, I see it can be a problem to unload an AML table with all it's >>>>>> consequences e.g. with respect to driver unregistering in setups >>>>>> with complex dependencies. It will only work properly under >>>>>> certain conditions >>>>>> - nevertheless acpi_tb_unload_table() is still exported in ACPICA and we should get this working as it worked before. >>>>>> >>>>>> AcpiTbUnloadTable is not exported, it is an internal interface >>>>>> only >>>>>> -- as recognized by the "AcpiTb". >>>>> >>>>> In Linux it became a part of ABI when the >>>>> >>>>> commit 772bf1e2878ecfca0d1f332071c83e021dd9cf01 >>>>> Author: Jan Kiszka >>>>> Date: Fri Jun 9 20:36:31 2017 +0200 >>>>> >>>>> ACPI: configfs: Unload SSDT on configfs entry removal >>>>> >>>>> appeared in the kernel. >>>> >>>> And the commit message explains quite well why it is an important feature: >>>> >>>> "This allows to change SSDTs without rebooting the system. >>>> It also allows to destroy devices again that a dynamically loaded SSDT created. >>>> >>>> The biggest problem AFAIK is that under linux, many drivers cannot be unloaded. Also, there are many race conditions as the namespace entries "owned" by an SSDT being unloaded are deleted (out from underneath a driver). >>>> >>>> This is widely similar to the DT overlay behavior." >>>> >>>>>> I'm not sure that I want to change the interface to AcpiLoadTable >>>>>> just for something that is being deprecated. Already, we throw an >>>>>> ACPI_EXCEPTION if the Unload operator is encountered in the AML >>>>>> byte stream. The same thing with AcpiUnloadParentTable - it is being deprecated. >>>>>> >>>>>> ACPI_EXCEPTION ((AE_INFO, AE_NOT_IMPLEMENTED, >>>>>> "AML Unload operator is not supported")); >>> >>> Bob, what is your suggestion to fix the regression then? >>> >>> We could revert acpi_configfs.c to use >>> acpi_tb_install_and_load_table() instead of acpi_load_table(), >>> leaving loaded APCI objects uninitalized, but at least, unloading will work again. >>> >>> I guess my next question is: why do you want to unload a table in the >>> first place? >> >> Because it worked before and there are people who rely on it. If it's >> deprecated there should be a user notification and a reasonable >> end-of-life timeline to give these users a chance to develop an >> alternative solution. >> >> So, I still don't understand why this no longer works. We did not make >> any purposeful changes in this area - AFAIK. Bob > > It's because the acpi_configfs driver formerly used > acpi_tb_install_and_load_table() which returns the table index, but doesn't resolve the references. It now uses acpi_load_table() which resolves the references, but doesn't return the table index, so unloading doesn't work any more. > >> >> Niko >> >>> >>> >>> Do we have any other options? >>> >>> Niko >>> >>