On Wed, Sep 04, 2019 at 09:20:03AM +0200, Nikolaus Voss wrote: > On Fri, 30 Aug 2019, Shevchenko, Andriy wrote: > > On Fri, Aug 16, 2019 at 01:57:26PM +0200, Nikolaus Voss wrote: > > > On Wed, 14 Aug 2019, Schmauss, Erik wrote: > > > > > -----Original Message----- > > > > > From: Shevchenko, Andriy > > > > > Sent: Wednesday, August 14, 2019 11:51 AM > > > > > To: Nikolaus Voss <nikolaus.voss@xxxxxxxxxxxxxxxxxxxxx> > > > > > Cc: Rafael J. Wysocki <rjw@xxxxxxxxxxxxx>; Len Brown <lenb@xxxxxxxxxx>; > > > > > Moore, Robert <robert.moore@xxxxxxxxx>; Schmauss, Erik > > > > > <erik.schmauss@xxxxxxxxx>; Jacek Anaszewski <jacek.anaszewski@xxxxxxxxx>; > > > > > Pavel Machek <pavel@xxxxxx>; Dan Murphy <dmurphy@xxxxxx>; Thierry > > > > > Reding <thierry.reding@xxxxxxxxx>; linux-acpi@xxxxxxxxxxxxxxx; > > > > > devel@xxxxxxxxxx; linux-leds@xxxxxxxxxxxxxxx; linux-pwm@xxxxxxxxxxxxxxx > > > > > Subject: Re: [PATCH 1/3] ACPI: Resolve objects on host-directed table loads > > > > > > > > > > On Wed, May 29, 2019 at 02:18:20PM +0200, Nikolaus Voss wrote: > > > > > > If an ACPI SSDT overlay is loaded after built-in tables have been > > > > > > loaded e.g. via configfs or efivar_ssdt_load() it is necessary to > > > > > > rewalk the namespace to resolve references. Without this, relative and > > > > > > absolute paths like ^PCI0.SBUS or \_SB.PCI0.SBUS are not resolved > > > > > > correctly. > > > > > > > > > > > > Make configfs load use the same method as efivar_ssdt_load(). > > > > > > > > > > This patch brought a regression (bisect log below). > > > > > Now I'm unable to unload the table which was working before. > > > > > > > > > > Reverting (manual, due to ACPICA changes) helps. > > > > > > > > > > Please, consider to revert for this cycle, or fix. I will be glad to test any > > > > > proposed fix. > > > > > > > > We submitted a patch (d1fb5b2f623b1af5a0d2a83d205df1b61f430dc6) > > > > in response to this suggestion and I was not aware that this had been applied. > > > > > > > > Rafael, please revert at least the ACPICA portion of this patch. > > > > > > As I see it, my ACPICA change is not part of 5.3-rc1 any more. Reverting my > > > fix is part of the patch above (d1fb5b2f623b1af5a0d2a83d205df1b61f430dc6) > > > which is already applied. > > > > > > Nevertheless, what is new, is that acpi_ns_initialize_objects() is called in > > > acpi_load_table(). This is necessary to resolve the references in the newly > > > loaded table. Maybe this prevents the table from being unloaded? > > > > So, can we do something about it? It's a regression. > > > > Rafael, Nikolaus? > > can you describe how you unload the table (from userspace?). I cannot > reproduce this regression. I was not aware of any working interface for > unloading ACPI tables, I ended up in kexec'ing the kernel for my tests each > time I had to unload a table. Sure. I have connected an I²C device(s) to my board where I have compiled ACPI tables which describes them (more details if you want to know is on [1]). So, I create a folder in ConfigFS [1,2] and fill it up with SSDT (an *.aml file). After this, if I try to remove the folder in ConfigFS followed by table removal event, the actual nodes won't be removed, and this messes up with the internal representation of the ACPI device tree. [1]: https://www.kernel.org/doc/html/latest/admin-guide/acpi/ssdt-overlays.html [2]: https://htot.github.io/meta-intel-edison/1.3-ACPI-or-not.html#run-time-loading-through-configfs -- With Best Regards, Andy Shevchenko
