-----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?
Do we have any other options?
Niko
