lkml.org 
[lkml]   [2017]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH] acpi: configfs: Unload SSDT on configfs entry removal
Date


> -----Original Message-----
> From: rjwysocki@gmail.com [mailto:rjwysocki@gmail.com] On Behalf Of
> Rafael J. Wysocki
> Sent: Tuesday, May 30, 2017 2:42 PM
> To: Moore, Robert <robert.moore@intel.com>; Jan Kiszka
> <jan.kiszka@siemens.com>
> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>; Rafael J. Wysocki
> <rjw@rjwysocki.net>; Len Brown <lenb@kernel.org>; Zheng, Lv
> <lv.zheng@intel.com>; linux-acpi@vger.kernel.org; Linux Kernel Mailing
> List <linux-kernel@vger.kernel.org>; devel@acpica.org
> Subject: Re: [PATCH] acpi: configfs: Unload SSDT on configfs entry
> removal
>
> On Tue, May 30, 2017 at 11:16 PM, Moore, Robert <robert.moore@intel.com>
> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Jan Kiszka [mailto:jan.kiszka@siemens.com]
> >> Sent: Monday, May 29, 2017 5:53 AM
> >> To: Mika Westerberg <mika.westerberg@linux.intel.com>
> >> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>; Len Brown
> >> <lenb@kernel.org>; Zheng, Lv <lv.zheng@intel.com>;
> >> linux-acpi@vger.kernel.org; Linux Kernel Mailing List
> >> <linux-kernel@vger.kernel.org>; devel@acpica.org; Moore, Robert
> >> <robert.moore@intel.com>
> >> Subject: Re: [PATCH] acpi: configfs: Unload SSDT on configfs entry
> >> removal
> >>
> >> On 2017-05-29 14:47, Mika Westerberg wrote:
> >> > On Mon, May 29, 2017 at 01:33:29PM +0200, Jan Kiszka wrote:
> >> >> Enhance acpi_load_table to also return the table index. Use that
> >> >> index to unload the table again when the corresponding directory
> >> >> in configfs gets removed. This allows to change SSDTs without
> >> >> rebooting
> >> the system.
> >> >> It also allows to destroy devices again that a dynamically loaded
> >> >> SSDT created.
> >> >>
> >> >> This is widely similar to the DT overlay behavior.
> >> >>
> >> >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >> >> ---
> >> >>
> >> >> Can someone explain to me why an unloaded table still sticks
> >> >> around in sysfs and why we cannot release its ID and rather have
> >> >> to use a new one when loading a modified version?
> >> >
> >> > IIRC ACPICA relies the fact that SSDTs are never unloaded. Bob
> >> > (CC'd) can correct me if I got it wrong.
> >>
> >
> >
> > [Moore, Robert]
> >
> > I'm not entirely sure what the table manager code looks like at this
> time, but ACPICA does in fact support table unloading.
> >
> > It is a rather dangerous thing to do, however -- unless you are
> careful about it. Basically, all handles that reference the table to be
> unloaded will go bad.
>
> Right.
>
> Linux should handle that in theory, but the code in there is mostly very
> lightly tested AFAICS.
>
[Moore, Robert]

The load/unload functionality works with the current table interfaces. For example, the AML debugger supports both Load and Unload commands:


Load <Input Filename> Load ACPI table from a file
Unload <Namepath> Unload an ACPI table via namespace object


- load ssdt.aml
Input file ssdt.aml, Length 0x3A (58) bytes
ACPI: Host-directed Dynamic ACPI Table Load:
ACPI: SSDT 0x00000000004A1B18 00003A (v02 Intel _SSDT_01 00000001 INTL 20170303)
ACPI Exec: Table Event INSTALL, [SSDT] 004A1B18
ACPI Exec: Table Event LOAD, [SSDT] 004A1B18


- unload _T32
ACPI Exec: Table Event UNLOAD, [SSDT] 004A1B18
Parent of [_T32] (004A1028) unloaded and uninstalled



> >> OK... Is that standard-driven or just a limitation of this
> >> implementation?
> >>
> >> Is there an upper limit of tables? I'm thinking of lengthy
> >> development sessions that play with tables, loading and unloading
> modified versions.
> >>
> >
> > [Moore, Robert]
> >
> > I think that the maximum number of loaded ACPI tables is 255 at any
> given time. However, things are cleaned up after an unload such that
> repeated load/unload cycles should not consume resources.
>
> I'm not sure if this is going to work seamlessly right away, but it
> certainly can be made work.
>
> That said, the change as proposed would be an API modification forcing
> all of the OSes using ACPICA to change (or to carry out-of-the-tree
> patches), so not nice.
>
> What about adding a separate version of acpi_load_table() returning an
> index (or an error on failures) instead of the status and leaving the
> existing acpi_load_table() as is?
>
> Thanks,
> Rafael
\
 
 \ /
  Last update: 2017-05-31 16:31    [W:0.352 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site