> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Rafael J. Wysocki > Sent: Tuesday, May 30, 2017 2:42 PM > To: Moore, Robert <[email protected]>; Jan Kiszka > <[email protected]> > Cc: Mika Westerberg <[email protected]>; Rafael J. Wysocki > <[email protected]>; Len Brown <[email protected]>; Zheng, Lv > <[email protected]>; [email protected]; Linux Kernel Mailing > List <[email protected]>; [email protected] > Subject: Re: [PATCH] acpi: configfs: Unload SSDT on configfs entry > removal > > On Tue, May 30, 2017 at 11:16 PM, Moore, Robert <[email protected]> > wrote: > > > > > >> -----Original Message----- > >> From: Jan Kiszka [mailto:[email protected]] > >> Sent: Monday, May 29, 2017 5:53 AM > >> To: Mika Westerberg <[email protected]> > >> Cc: Rafael J. Wysocki <[email protected]>; Len Brown > >> <[email protected]>; Zheng, Lv <[email protected]>; > >> [email protected]; Linux Kernel Mailing List > >> <[email protected]>; [email protected]; Moore, Robert > >> <[email protected]> > >> 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 <[email protected]> > >> >> --- > >> >> > >> >> 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
