-----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

Niko

>
>
> Do we have any other options?
>
> Niko
>

Reply via email to