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 (); } -----Original Message----- From: Nikolaus Voss <n...@vosn.de> Sent: Monday, September 23, 2019 2:05 AM To: Moore, Robert <robert.mo...@intel.com> Cc: Ferry Toth <fnt...@gmail.com>; Shevchenko, Andriy <andriy.shevche...@intel.com>; Schmauss, Erik <erik.schma...@intel.com>; Rafael J. Wysocki <r...@rjwysocki.net>; Len Brown <l...@kernel.org>; Jacek Anaszewski <jacek.anaszew...@gmail.com>; Pavel Machek <pa...@ucw.cz>; Dan Murphy <dmur...@ti.com>; linux-a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org; Jan Kiszka <jan.kis...@siemens.com> 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:n...@vosn.de] > Sent: Wednesday, September 18, 2019 7:32 AM > To: Moore, Robert <robert.mo...@intel.com> > Cc: Ferry Toth <fnt...@gmail.com>; Shevchenko, Andriy > <andriy.shevche...@intel.com>; Schmauss, Erik > <erik.schma...@intel.com>; Rafael J. Wysocki <r...@rjwysocki.net>; Len > Brown <l...@kernel.org>; Jacek Anaszewski > <jacek.anaszew...@gmail.com>; Pavel Machek <pa...@ucw.cz>; Dan Murphy > <dmur...@ti.com>; linux-a...@vger.kernel.org; de...@acpica.org; > linux-kernel@vger.kernel.org; Jan Kiszka <jan.kis...@siemens.com> > 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:n...@vosn.de] >> Sent: Monday, September 16, 2019 2:47 AM >> To: Moore, Robert <robert.mo...@intel.com> >> Cc: Ferry Toth <fnt...@gmail.com>; Shevchenko, Andriy >> <andriy.shevche...@intel.com>; Schmauss, Erik >> <erik.schma...@intel.com>; Rafael J. Wysocki <r...@rjwysocki.net>; Len >> Brown <l...@kernel.org>; Jacek Anaszewski >> <jacek.anaszew...@gmail.com>; Pavel Machek <pa...@ucw.cz>; Dan Murphy >> <dmur...@ti.com>; linux-a...@vger.kernel.org; de...@acpica.org; >> linux-kernel@vger.kernel.org; Jan Kiszka <jan.kis...@siemens.com> >> 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:fnt...@gmail.com] >>> Sent: Friday, September 13, 2019 9:48 AM >>> To: Shevchenko, Andriy <andriy.shevche...@intel.com>; Moore, Robert >>> <robert.mo...@intel.com> >>> Cc: Nikolaus Voss <n...@vosn.de>; Schmauss, Erik >>> <erik.schma...@intel.com>; Rafael J. Wysocki <r...@rjwysocki.net>; >>> Len Brown <l...@kernel.org>; Jacek Anaszewski >>> <jacek.anaszew...@gmail.com>; Pavel Machek <pa...@ucw.cz>; Dan >>> Murphy <dmur...@ti.com>; linux-a...@vger.kernel.org; >>> de...@acpica.org; linux-kernel@vger.kernel.org; >>> nikolaus.v...@loewensteinmedical.de; >>> Jan Kiszka <jan.kis...@siemens.com> >>> 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:n...@vosn.de] >>>>> Sent: Friday, September 13, 2019 12:44 AM >>>>> To: Moore, Robert <robert.mo...@intel.com> >>>>> Cc: Shevchenko, Andriy <andriy.shevche...@intel.com>; Schmauss, >>>>> Erik <erik.schma...@intel.com>; Rafael J. Wysocki >>>>> <r...@rjwysocki.net>; Len Brown <l...@kernel.org>; Jacek Anaszewski >>>>> <jacek.anaszew...@gmail.com>; Pavel Machek <pa...@ucw.cz>; Dan >>>>> Murphy <dmur...@ti.com>; linux-a...@vger.kernel.org; >>>>> de...@acpica.org; linux-kernel@vger.kernel.org; Ferry Toth >>>>> <ft...@telfort.nl>; nikolaus.v...@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 <jan.kis...@siemens.com> >>>> 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 >> >