diff mbox series

[1/3] ACPI: Resolve objects on host-directed table loads

Message ID 8704391ae3004a6b4dd17975dbcc9e88bd28cf4b.1559127603.git.nikolaus.voss@loewensteinmedical.de (mailing list archive)
State Superseded, archived
Headers show
Series PWM framework: add support referencing PWMs from ACPI | expand

Commit Message

Nikolaus Voss May 29, 2019, 12:18 p.m. UTC
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().

Signed-off-by: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de>
---
 drivers/acpi/acpi_configfs.c   |  6 +-----
 drivers/acpi/acpica/tbxfload.c | 11 +++++++++++
 2 files changed, 12 insertions(+), 5 deletions(-)

Comments

Dan Murphy May 30, 2019, 2:42 p.m. UTC | #1
Nikolaus

On 5/29/19 7:18 AM, 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().
>
> Signed-off-by: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de>
> ---
>   drivers/acpi/acpi_configfs.c   |  6 +-----
>   drivers/acpi/acpica/tbxfload.c | 11 +++++++++++
>   2 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/acpi/acpi_configfs.c b/drivers/acpi/acpi_configfs.c
> index f92033661239..663f0d88f912 100644
> --- a/drivers/acpi/acpi_configfs.c
> +++ b/drivers/acpi/acpi_configfs.c
> @@ -56,11 +56,7 @@ static ssize_t acpi_table_aml_write(struct config_item *cfg,
>   	if (!table->header)
>   		return -ENOMEM;
>   
> -	ACPI_INFO(("Host-directed Dynamic ACPI Table Load:"));
> -	ret = acpi_tb_install_and_load_table(
> -			ACPI_PTR_TO_PHYSADDR(table->header),
> -			ACPI_TABLE_ORIGIN_EXTERNAL_VIRTUAL, FALSE,
> -			&table->index);
> +	ret = acpi_load_table(table->header);
>   	if (ret) {
>   		kfree(table->header);
>   		table->header = NULL;
> diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
> index 4f30f06a6f78..61f2d46e52ba 100644
> --- a/drivers/acpi/acpica/tbxfload.c
> +++ b/drivers/acpi/acpica/tbxfload.c
> @@ -297,6 +297,17 @@ acpi_status acpi_load_table(struct acpi_table_header *table)
>   	status = acpi_tb_install_and_load_table(ACPI_PTR_TO_PHYSADDR(table),
>   						ACPI_TABLE_ORIGIN_EXTERNAL_VIRTUAL,
>   						FALSE, &table_index);
> +
> +	if (!ACPI_FAILURE(status)) {
Checkpatch should complain about putting brackets around single 
statement if's.
> +		/* Complete the initialization/resolution of package objects */
> +

Extra new lines


Dan

> +		status = acpi_ns_walk_namespace(ACPI_TYPE_PACKAGE,
> +						ACPI_ROOT_OBJECT,
> +						ACPI_UINT32_MAX, 0,
> +						acpi_ns_init_one_package,
> +						NULL, NULL, NULL);
> +	}
> +
>   	return_ACPI_STATUS(status);
>   }
>
Pavel Machek May 31, 2019, 12:23 p.m. UTC | #2
Hi!

> >diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
> >index 4f30f06a6f78..61f2d46e52ba 100644
> >--- a/drivers/acpi/acpica/tbxfload.c
> >+++ b/drivers/acpi/acpica/tbxfload.c
> >@@ -297,6 +297,17 @@ acpi_status acpi_load_table(struct acpi_table_header *table)
> >  	status = acpi_tb_install_and_load_table(ACPI_PTR_TO_PHYSADDR(table),
> >  						ACPI_TABLE_ORIGIN_EXTERNAL_VIRTUAL,
> >  						FALSE, &table_index);
> >+
> >+	if (!ACPI_FAILURE(status)) {
> Checkpatch should complain about putting brackets around single statement
> if's.

With multiline statement like that and including comment -- I'd say
keep {'s. It is cleaner this way.
									Pavel
Dan Murphy May 31, 2019, 12:45 p.m. UTC | #3
Pavel

On 5/31/19 7:23 AM, Pavel Machek wrote:
> Hi!
>
>>> diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
>>> index 4f30f06a6f78..61f2d46e52ba 100644
>>> --- a/drivers/acpi/acpica/tbxfload.c
>>> +++ b/drivers/acpi/acpica/tbxfload.c
>>> @@ -297,6 +297,17 @@ acpi_status acpi_load_table(struct acpi_table_header *table)
>>>   	status = acpi_tb_install_and_load_table(ACPI_PTR_TO_PHYSADDR(table),
>>>   						ACPI_TABLE_ORIGIN_EXTERNAL_VIRTUAL,
>>>   						FALSE, &table_index);
>>> +
>>> +	if (!ACPI_FAILURE(status)) {
>> Checkpatch should complain about putting brackets around single statement
>> if's.
> With multiline statement like that and including comment -- I'd say
> keep {'s. It is cleaner this way.

Maintainers preference.  I won't nack the patch for it.

Not sure their preference as I don't usually submit to acpi.

Dan


> 									Pavel
>
>
Dan Murphy May 31, 2019, 12:46 p.m. UTC | #4
Nikolaus

On 5/30/19 9:42 AM, Dan Murphy wrote:
> Nikolaus
>
> On 5/29/19 7:18 AM, 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().
>>
>> Signed-off-by: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de>
>> ---
>>   drivers/acpi/acpi_configfs.c   |  6 +-----
>>   drivers/acpi/acpica/tbxfload.c | 11 +++++++++++
>>   2 files changed, 12 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/acpi/acpi_configfs.c b/drivers/acpi/acpi_configfs.c
>> index f92033661239..663f0d88f912 100644
>> --- a/drivers/acpi/acpi_configfs.c
>> +++ b/drivers/acpi/acpi_configfs.c
>> @@ -56,11 +56,7 @@ static ssize_t acpi_table_aml_write(struct 
>> config_item *cfg,
>>       if (!table->header)
>>           return -ENOMEM;
>>   -    ACPI_INFO(("Host-directed Dynamic ACPI Table Load:"));
>> -    ret = acpi_tb_install_and_load_table(
>> -            ACPI_PTR_TO_PHYSADDR(table->header),
>> -            ACPI_TABLE_ORIGIN_EXTERNAL_VIRTUAL, FALSE,
>> -            &table->index);
>> +    ret = acpi_load_table(table->header);
>>       if (ret) {
>>           kfree(table->header);
>>           table->header = NULL;
>> diff --git a/drivers/acpi/acpica/tbxfload.c 
>> b/drivers/acpi/acpica/tbxfload.c
>> index 4f30f06a6f78..61f2d46e52ba 100644
>> --- a/drivers/acpi/acpica/tbxfload.c
>> +++ b/drivers/acpi/acpica/tbxfload.c
>> @@ -297,6 +297,17 @@ acpi_status acpi_load_table(struct 
>> acpi_table_header *table)
>>       status = 
>> acpi_tb_install_and_load_table(ACPI_PTR_TO_PHYSADDR(table),
>>                           ACPI_TABLE_ORIGIN_EXTERNAL_VIRTUAL,
>>                           FALSE, &table_index);
>> +
>> +    if (!ACPI_FAILURE(status)) {
> Checkpatch should complain about putting brackets around single 
> statement if's.

Would ACPI_SUCCESS make more sense here?

Dan

<snip>
Nikolaus Voss June 3, 2019, 9:12 a.m. UTC | #5
Dan,

On Fri, 31 May 2019, Dan Murphy wrote:
> Nikolaus
>
> On 5/30/19 9:42 AM, Dan Murphy wrote:
>> Nikolaus
>>
>> On 5/29/19 7:18 AM, 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().
>>>
>>> Signed-off-by: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de>
>>> ---
>>>   drivers/acpi/acpi_configfs.c   |  6 +-----
>>>   drivers/acpi/acpica/tbxfload.c | 11 +++++++++++
>>>   2 files changed, 12 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/acpi/acpi_configfs.c b/drivers/acpi/acpi_configfs.c
>>> index f92033661239..663f0d88f912 100644
>>> --- a/drivers/acpi/acpi_configfs.c
>>> +++ b/drivers/acpi/acpi_configfs.c
>>> @@ -56,11 +56,7 @@ static ssize_t acpi_table_aml_write(struct
>>> config_item *cfg,
>>>       if (!table->header)
>>>           return -ENOMEM;
>>>   -    ACPI_INFO(("Host-directed Dynamic ACPI Table Load:"));
>>> -    ret = acpi_tb_install_and_load_table(
>>> -            ACPI_PTR_TO_PHYSADDR(table->header),
>>> -            ACPI_TABLE_ORIGIN_EXTERNAL_VIRTUAL, FALSE,
>>> -            &table->index);
>>> +    ret = acpi_load_table(table->header);
>>>       if (ret) {
>>>           kfree(table->header);
>>>           table->header = NULL;
>>> diff --git a/drivers/acpi/acpica/tbxfload.c
>>> b/drivers/acpi/acpica/tbxfload.c
>>> index 4f30f06a6f78..61f2d46e52ba 100644
>>> --- a/drivers/acpi/acpica/tbxfload.c
>>> +++ b/drivers/acpi/acpica/tbxfload.c
>>> @@ -297,6 +297,17 @@ acpi_status acpi_load_table(struct
>>> acpi_table_header *table)
>>>       status =
>>> acpi_tb_install_and_load_table(ACPI_PTR_TO_PHYSADDR(table),
>>>                           ACPI_TABLE_ORIGIN_EXTERNAL_VIRTUAL,
>>>                           FALSE, &table_index);
>>> +
>>> +    if (!ACPI_FAILURE(status)) {
>> Checkpatch should complain about putting brackets around single
>> statement if's.
>
> Would ACPI_SUCCESS make more sense here?

yes, changed.
Andy Shevchenko Aug. 14, 2019, 6:50 p.m. UTC | #6
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.


git bisect start
# good: [0ecfebd2b52404ae0c54a878c872bb93363ada36] Linux 5.2
git bisect good 0ecfebd2b52404ae0c54a878c872bb93363ada36
# bad: [5f9e832c137075045d15cd6899ab0505cfb2ca4b] Linus 5.3-rc1
git bisect bad 5f9e832c137075045d15cd6899ab0505cfb2ca4b
# bad: [e786741ff1b52769b044b7f4407f39cd13ee5d2d] Merge tag 'staging-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
git bisect bad e786741ff1b52769b044b7f4407f39cd13ee5d2d
# bad: [8f6ccf6159aed1f04c6d179f61f6fb2691261e84] Merge tag 'clone3-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux
git bisect bad 8f6ccf6159aed1f04c6d179f61f6fb2691261e84
# good: [ed63b9c873601ca113da5c7b1745e3946493e9f3] Merge tag 'media/v5.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
git bisect good ed63b9c873601ca113da5c7b1745e3946493e9f3
# bad: [4b4704520d97b74e045154fc3b844b73ae4e7ebd] Merge tag 'acpi-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad 4b4704520d97b74e045154fc3b844b73ae4e7ebd
# good: [e3303268f9cfa4eb7c2217df471417d4327109fd] ASoC: soc-core: don't use soc_find_component() at snd_soc_find_dai()
git bisect good e3303268f9cfa4eb7c2217df471417d4327109fd
# good: [3c53c6255d598db7084c5c3d7553d7200e857818] Merge tag 'asoc-v5.3' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
git bisect good 3c53c6255d598db7084c5c3d7553d7200e857818
# good: [4cdd5f9186bbe80306e76f11da7ecb0b9720433c] Merge tag 'sound-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
git bisect good 4cdd5f9186bbe80306e76f11da7ecb0b9720433c
# good: [13b06b78c772d64e2207e4a5a5329856fe2bf241] Merge branches 'pm-opp', 'pm-misc', 'pm-avs' and 'pm-tools'
git bisect good 13b06b78c772d64e2207e4a5a5329856fe2bf241
# good: [cf2d213e49fdf47e4c10dc629a3659e0026a54b8] Merge tag 'pm-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect good cf2d213e49fdf47e4c10dc629a3659e0026a54b8
# bad: [02a93f35f57fe5d4d1bac0ac8496884235e2fd2e] ACPICA: Update version to 20190703
git bisect bad 02a93f35f57fe5d4d1bac0ac8496884235e2fd2e
# bad: [d4ca763eed3bcc227f220beb11ff4eb2fa548755] Merge ACPI tables handling changes for v5.3.
git bisect bad d4ca763eed3bcc227f220beb11ff4eb2fa548755
# bad: [d06c47e3dd07fdf3f07e8fc45f2ce655e9b295c5] ACPI: configfs: Resolve objects on host-directed table loads
git bisect bad d06c47e3dd07fdf3f07e8fc45f2ce655e9b295c5
# good: [c78fea61f0c1f8568fbbb36ac3d1e1c85a903ae4] ACPI: tables: Allow BGRT to be overridden
git bisect good c78fea61f0c1f8568fbbb36ac3d1e1c85a903ae4
# first bad commit: [d06c47e3dd07fdf3f07e8fc45f2ce655e9b295c5] ACPI: configfs: Resolve objects on host-directed table loads
Schmauss, Erik Aug. 14, 2019, 8:27 p.m. UTC | #7
> -----Original Message-----
> From: Shevchenko, Andriy
> Sent: Wednesday, August 14, 2019 11:51 AM
> To: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de>
> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>; Len Brown <lenb@kernel.org>;
> Moore, Robert <robert.moore@intel.com>; Schmauss, Erik
> <erik.schmauss@intel.com>; Jacek Anaszewski <jacek.anaszewski@gmail.com>;
> Pavel Machek <pavel@ucw.cz>; Dan Murphy <dmurphy@ti.com>; Thierry
> Reding <thierry.reding@gmail.com>; linux-acpi@vger.kernel.org;
> devel@acpica.org; linux-leds@vger.kernel.org; linux-pwm@vger.kernel.org
> 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.

Thanks,
Erik
> 
> 
> git bisect start
> # good: [0ecfebd2b52404ae0c54a878c872bb93363ada36] Linux 5.2 git bisect
> good 0ecfebd2b52404ae0c54a878c872bb93363ada36
> # bad: [5f9e832c137075045d15cd6899ab0505cfb2ca4b] Linus 5.3-rc1 git
> bisect bad 5f9e832c137075045d15cd6899ab0505cfb2ca4b
> # bad: [e786741ff1b52769b044b7f4407f39cd13ee5d2d] Merge tag 'staging-
> 5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
> git bisect bad e786741ff1b52769b044b7f4407f39cd13ee5d2d
> # bad: [8f6ccf6159aed1f04c6d179f61f6fb2691261e84] Merge tag 'clone3-v5.3'
> of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux
> git bisect bad 8f6ccf6159aed1f04c6d179f61f6fb2691261e84
> # good: [ed63b9c873601ca113da5c7b1745e3946493e9f3] Merge tag
> 'media/v5.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-
> media
> git bisect good ed63b9c873601ca113da5c7b1745e3946493e9f3
> # bad: [4b4704520d97b74e045154fc3b844b73ae4e7ebd] Merge tag 'acpi-5.3-
> rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
> git bisect bad 4b4704520d97b74e045154fc3b844b73ae4e7ebd
> # good: [e3303268f9cfa4eb7c2217df471417d4327109fd] ASoC: soc-core: don't
> use soc_find_component() at snd_soc_find_dai() git bisect good
> e3303268f9cfa4eb7c2217df471417d4327109fd
> # good: [3c53c6255d598db7084c5c3d7553d7200e857818] Merge tag 'asoc-
> v5.3' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-
> linus git bisect good 3c53c6255d598db7084c5c3d7553d7200e857818
> # good: [4cdd5f9186bbe80306e76f11da7ecb0b9720433c] Merge tag 'sound-
> 5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
> git bisect good 4cdd5f9186bbe80306e76f11da7ecb0b9720433c
> # good: [13b06b78c772d64e2207e4a5a5329856fe2bf241] Merge branches
> 'pm-opp', 'pm-misc', 'pm-avs' and 'pm-tools'
> git bisect good 13b06b78c772d64e2207e4a5a5329856fe2bf241
> # good: [cf2d213e49fdf47e4c10dc629a3659e0026a54b8] Merge tag 'pm-5.3-
> rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
> git bisect good cf2d213e49fdf47e4c10dc629a3659e0026a54b8
> # bad: [02a93f35f57fe5d4d1bac0ac8496884235e2fd2e] ACPICA: Update
> version to 20190703 git bisect bad
> 02a93f35f57fe5d4d1bac0ac8496884235e2fd2e
> # bad: [d4ca763eed3bcc227f220beb11ff4eb2fa548755] Merge ACPI tables
> handling changes for v5.3.
> git bisect bad d4ca763eed3bcc227f220beb11ff4eb2fa548755
> # bad: [d06c47e3dd07fdf3f07e8fc45f2ce655e9b295c5] ACPI: configfs: Resolve
> objects on host-directed table loads git bisect bad
> d06c47e3dd07fdf3f07e8fc45f2ce655e9b295c5
> # good: [c78fea61f0c1f8568fbbb36ac3d1e1c85a903ae4] ACPI: tables: Allow
> BGRT to be overridden git bisect good
> c78fea61f0c1f8568fbbb36ac3d1e1c85a903ae4
> # first bad commit: [d06c47e3dd07fdf3f07e8fc45f2ce655e9b295c5] ACPI:
> configfs: Resolve objects on host-directed table loads
> 
> --
> With Best Regards,
> Andy Shevchenko
>
Nikolaus Voss Aug. 16, 2019, 11:57 a.m. UTC | #8
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@loewensteinmedical.de>
>> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>; Len Brown <lenb@kernel.org>;
>> Moore, Robert <robert.moore@intel.com>; Schmauss, Erik
>> <erik.schmauss@intel.com>; Jacek Anaszewski <jacek.anaszewski@gmail.com>;
>> Pavel Machek <pavel@ucw.cz>; Dan Murphy <dmurphy@ti.com>; Thierry
>> Reding <thierry.reding@gmail.com>; linux-acpi@vger.kernel.org;
>> devel@acpica.org; linux-leds@vger.kernel.org; linux-pwm@vger.kernel.org
>> 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?

Niko

>
> Thanks,
> Erik
>>
>>
>> git bisect start
>> # good: [0ecfebd2b52404ae0c54a878c872bb93363ada36] Linux 5.2 git bisect
>> good 0ecfebd2b52404ae0c54a878c872bb93363ada36
>> # bad: [5f9e832c137075045d15cd6899ab0505cfb2ca4b] Linus 5.3-rc1 git
>> bisect bad 5f9e832c137075045d15cd6899ab0505cfb2ca4b
>> # bad: [e786741ff1b52769b044b7f4407f39cd13ee5d2d] Merge tag 'staging-
>> 5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
>> git bisect bad e786741ff1b52769b044b7f4407f39cd13ee5d2d
>> # bad: [8f6ccf6159aed1f04c6d179f61f6fb2691261e84] Merge tag 'clone3-v5.3'
>> of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux
>> git bisect bad 8f6ccf6159aed1f04c6d179f61f6fb2691261e84
>> # good: [ed63b9c873601ca113da5c7b1745e3946493e9f3] Merge tag
>> 'media/v5.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-
>> media
>> git bisect good ed63b9c873601ca113da5c7b1745e3946493e9f3
>> # bad: [4b4704520d97b74e045154fc3b844b73ae4e7ebd] Merge tag 'acpi-5.3-
>> rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
>> git bisect bad 4b4704520d97b74e045154fc3b844b73ae4e7ebd
>> # good: [e3303268f9cfa4eb7c2217df471417d4327109fd] ASoC: soc-core: don't
>> use soc_find_component() at snd_soc_find_dai() git bisect good
>> e3303268f9cfa4eb7c2217df471417d4327109fd
>> # good: [3c53c6255d598db7084c5c3d7553d7200e857818] Merge tag 'asoc-
>> v5.3' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-
>> linus git bisect good 3c53c6255d598db7084c5c3d7553d7200e857818
>> # good: [4cdd5f9186bbe80306e76f11da7ecb0b9720433c] Merge tag 'sound-
>> 5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
>> git bisect good 4cdd5f9186bbe80306e76f11da7ecb0b9720433c
>> # good: [13b06b78c772d64e2207e4a5a5329856fe2bf241] Merge branches
>> 'pm-opp', 'pm-misc', 'pm-avs' and 'pm-tools'
>> git bisect good 13b06b78c772d64e2207e4a5a5329856fe2bf241
>> # good: [cf2d213e49fdf47e4c10dc629a3659e0026a54b8] Merge tag 'pm-5.3-
>> rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
>> git bisect good cf2d213e49fdf47e4c10dc629a3659e0026a54b8
>> # bad: [02a93f35f57fe5d4d1bac0ac8496884235e2fd2e] ACPICA: Update
>> version to 20190703 git bisect bad
>> 02a93f35f57fe5d4d1bac0ac8496884235e2fd2e
>> # bad: [d4ca763eed3bcc227f220beb11ff4eb2fa548755] Merge ACPI tables
>> handling changes for v5.3.
>> git bisect bad d4ca763eed3bcc227f220beb11ff4eb2fa548755
>> # bad: [d06c47e3dd07fdf3f07e8fc45f2ce655e9b295c5] ACPI: configfs: Resolve
>> objects on host-directed table loads git bisect bad
>> d06c47e3dd07fdf3f07e8fc45f2ce655e9b295c5
>> # good: [c78fea61f0c1f8568fbbb36ac3d1e1c85a903ae4] ACPI: tables: Allow
>> BGRT to be overridden git bisect good
>> c78fea61f0c1f8568fbbb36ac3d1e1c85a903ae4
>> # first bad commit: [d06c47e3dd07fdf3f07e8fc45f2ce655e9b295c5] ACPI:
>> configfs: Resolve objects on host-directed table loads
>>
>> --
>> With Best Regards,
>> Andy Shevchenko
>>
>
>
Andy Shevchenko Aug. 30, 2019, 2:53 p.m. UTC | #9
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@loewensteinmedical.de>
> > > Cc: Rafael J. Wysocki <rjw@rjwysocki.net>; Len Brown <lenb@kernel.org>;
> > > Moore, Robert <robert.moore@intel.com>; Schmauss, Erik
> > > <erik.schmauss@intel.com>; Jacek Anaszewski <jacek.anaszewski@gmail.com>;
> > > Pavel Machek <pavel@ucw.cz>; Dan Murphy <dmurphy@ti.com>; Thierry
> > > Reding <thierry.reding@gmail.com>; linux-acpi@vger.kernel.org;
> > > devel@acpica.org; linux-leds@vger.kernel.org; linux-pwm@vger.kernel.org
> > > 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?
Nikolaus Voss Sept. 4, 2019, 7:20 a.m. UTC | #10
Andy,

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@loewensteinmedical.de>
>>>> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>; Len Brown <lenb@kernel.org>;
>>>> Moore, Robert <robert.moore@intel.com>; Schmauss, Erik
>>>> <erik.schmauss@intel.com>; Jacek Anaszewski <jacek.anaszewski@gmail.com>;
>>>> Pavel Machek <pavel@ucw.cz>; Dan Murphy <dmurphy@ti.com>; Thierry
>>>> Reding <thierry.reding@gmail.com>; linux-acpi@vger.kernel.org;
>>>> devel@acpica.org; linux-leds@vger.kernel.org; linux-pwm@vger.kernel.org
>>>> 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.

Niko
Andy Shevchenko Sept. 6, 2019, 5:46 p.m. UTC | #11
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@loewensteinmedical.de>
> > > > > Cc: Rafael J. Wysocki <rjw@rjwysocki.net>; Len Brown <lenb@kernel.org>;
> > > > > Moore, Robert <robert.moore@intel.com>; Schmauss, Erik
> > > > > <erik.schmauss@intel.com>; Jacek Anaszewski <jacek.anaszewski@gmail.com>;
> > > > > Pavel Machek <pavel@ucw.cz>; Dan Murphy <dmurphy@ti.com>; Thierry
> > > > > Reding <thierry.reding@gmail.com>; linux-acpi@vger.kernel.org;
> > > > > devel@acpica.org; linux-leds@vger.kernel.org; linux-pwm@vger.kernel.org
> > > > > 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
Nikolaus Voss Sept. 12, 2019, 8:05 a.m. UTC | #12
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@loewensteinmedical.de>
>>>>>> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>; Len Brown <lenb@kernel.org>;
>>>>>> Moore, Robert <robert.moore@intel.com>; Schmauss, Erik
>>>>>> <erik.schmauss@intel.com>; Jacek Anaszewski <jacek.anaszewski@gmail.com>;
>>>>>> Pavel Machek <pavel@ucw.cz>; Dan Murphy <dmurphy@ti.com>; Thierry
>>>>>> Reding <thierry.reding@gmail.com>; linux-acpi@vger.kernel.org;
>>>>>> devel@acpica.org; linux-leds@vger.kernel.org; linux-pwm@vger.kernel.org
>>>>>> 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
diff mbox series

Patch

diff --git a/drivers/acpi/acpi_configfs.c b/drivers/acpi/acpi_configfs.c
index f92033661239..663f0d88f912 100644
--- a/drivers/acpi/acpi_configfs.c
+++ b/drivers/acpi/acpi_configfs.c
@@ -56,11 +56,7 @@  static ssize_t acpi_table_aml_write(struct config_item *cfg,
 	if (!table->header)
 		return -ENOMEM;
 
-	ACPI_INFO(("Host-directed Dynamic ACPI Table Load:"));
-	ret = acpi_tb_install_and_load_table(
-			ACPI_PTR_TO_PHYSADDR(table->header),
-			ACPI_TABLE_ORIGIN_EXTERNAL_VIRTUAL, FALSE,
-			&table->index);
+	ret = acpi_load_table(table->header);
 	if (ret) {
 		kfree(table->header);
 		table->header = NULL;
diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
index 4f30f06a6f78..61f2d46e52ba 100644
--- a/drivers/acpi/acpica/tbxfload.c
+++ b/drivers/acpi/acpica/tbxfload.c
@@ -297,6 +297,17 @@  acpi_status acpi_load_table(struct acpi_table_header *table)
 	status = acpi_tb_install_and_load_table(ACPI_PTR_TO_PHYSADDR(table),
 						ACPI_TABLE_ORIGIN_EXTERNAL_VIRTUAL,
 						FALSE, &table_index);
+
+	if (!ACPI_FAILURE(status)) {
+		/* Complete the initialization/resolution of package objects */
+
+		status = acpi_ns_walk_namespace(ACPI_TYPE_PACKAGE,
+						ACPI_ROOT_OBJECT,
+						ACPI_UINT32_MAX, 0,
+						acpi_ns_init_one_package,
+						NULL, NULL, NULL);
+	}
+
 	return_ACPI_STATUS(status);
 }