On Fri, 6 Sep 2019, Shevchenko, Andriy wrote:
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
Thanks, I have reproduced it and the culprit is my acpi_configfs patch
that now uses acpi_load_table() to have the references resolved.
My proposal would be to have that function return the table index, which
is needed to unload the table. I'll submit a patch, Andy, could you test
it in your setup?
Erik/Robert, is it ok to change the acpi_load_table() ACPICA API
function? It has only a few uses.
Niko
