* [PATCH 1/3] ACPI: Resolve objects on host-directed table loads
2019-05-29 12:18 [PATCH 0/3] PWM framework: add support referencing PWMs from ACPI Nikolaus Voss
@ 2019-05-29 12:18 ` Nikolaus Voss
2019-05-30 14:42 ` Dan Murphy
2019-08-14 18:50 ` Andy Shevchenko
2019-05-29 12:18 ` [PATCH 2/3] PWM framework: add support referencing PWMs from ACPI Nikolaus Voss
2019-05-29 12:18 ` [PATCH 3/3] leds-pwm.c: support ACPI via firmware-node framework Nikolaus Voss
2 siblings, 2 replies; 20+ messages in thread
From: Nikolaus Voss @ 2019-05-29 12:18 UTC (permalink / raw)
To: Rafael J. Wysocki, Len Brown, Robert Moore, Erik Schmauss,
Jacek Anaszewski, Pavel Machek, Dan Murphy, Thierry Reding
Cc: Nikolaus Voss, linux-acpi, devel, linux-leds, linux-pwm
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)) {
+ /* 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);
}
--
2.17.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH 1/3] ACPI: Resolve objects on host-directed table loads
2019-05-29 12:18 ` [PATCH 1/3] ACPI: Resolve objects on host-directed table loads Nikolaus Voss
@ 2019-05-30 14:42 ` Dan Murphy
2019-05-31 12:23 ` Pavel Machek
2019-05-31 12:46 ` Dan Murphy
2019-08-14 18:50 ` Andy Shevchenko
1 sibling, 2 replies; 20+ messages in thread
From: Dan Murphy @ 2019-05-30 14:42 UTC (permalink / raw)
To: Nikolaus Voss, Rafael J. Wysocki, Len Brown, Robert Moore,
Erik Schmauss, Jacek Anaszewski, Pavel Machek, Thierry Reding
Cc: linux-acpi, devel, linux-leds, linux-pwm
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);
> }
>
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 1/3] ACPI: Resolve objects on host-directed table loads
2019-05-30 14:42 ` Dan Murphy
@ 2019-05-31 12:23 ` Pavel Machek
2019-05-31 12:45 ` Dan Murphy
2019-05-31 12:46 ` Dan Murphy
1 sibling, 1 reply; 20+ messages in thread
From: Pavel Machek @ 2019-05-31 12:23 UTC (permalink / raw)
To: Dan Murphy
Cc: Nikolaus Voss, Rafael J. Wysocki, Len Brown, Robert Moore,
Erik Schmauss, Jacek Anaszewski, Thierry Reding, linux-acpi,
devel, linux-leds, linux-pwm
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]
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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 1/3] ACPI: Resolve objects on host-directed table loads
2019-05-31 12:23 ` Pavel Machek
@ 2019-05-31 12:45 ` Dan Murphy
0 siblings, 0 replies; 20+ messages in thread
From: Dan Murphy @ 2019-05-31 12:45 UTC (permalink / raw)
To: Pavel Machek
Cc: Nikolaus Voss, Rafael J. Wysocki, Len Brown, Robert Moore,
Erik Schmauss, Jacek Anaszewski, Thierry Reding, linux-acpi,
devel, linux-leds, linux-pwm
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
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/3] ACPI: Resolve objects on host-directed table loads
2019-05-30 14:42 ` Dan Murphy
2019-05-31 12:23 ` Pavel Machek
@ 2019-05-31 12:46 ` Dan Murphy
2019-06-03 9:12 ` Nikolaus Voss
1 sibling, 1 reply; 20+ messages in thread
From: Dan Murphy @ 2019-05-31 12:46 UTC (permalink / raw)
To: Nikolaus Voss, Rafael J. Wysocki, Len Brown, Robert Moore,
Erik Schmauss, Jacek Anaszewski, Pavel Machek, Thierry Reding
Cc: linux-acpi, devel, linux-leds, linux-pwm
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>
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 1/3] ACPI: Resolve objects on host-directed table loads
2019-05-31 12:46 ` Dan Murphy
@ 2019-06-03 9:12 ` Nikolaus Voss
0 siblings, 0 replies; 20+ messages in thread
From: Nikolaus Voss @ 2019-06-03 9:12 UTC (permalink / raw)
To: Dan Murphy
Cc: Rafael J. Wysocki, Len Brown, Robert Moore, Erik Schmauss,
Jacek Anaszewski, Pavel Machek, Thierry Reding,
linux-acpi@vger.kernel.org, devel@acpica.org,
linux-leds@vger.kernel.org, linux-pwm@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/3] ACPI: Resolve objects on host-directed table loads
2019-05-29 12:18 ` [PATCH 1/3] ACPI: Resolve objects on host-directed table loads Nikolaus Voss
2019-05-30 14:42 ` Dan Murphy
@ 2019-08-14 18:50 ` Andy Shevchenko
2019-08-14 20:27 ` Schmauss, Erik
1 sibling, 1 reply; 20+ messages in thread
From: Andy Shevchenko @ 2019-08-14 18:50 UTC (permalink / raw)
To: Nikolaus Voss
Cc: Rafael J. Wysocki, Len Brown, Robert Moore, Erik Schmauss,
Jacek Anaszewski, Pavel Machek, Dan Murphy, Thierry Reding,
linux-acpi, devel, linux-leds, linux-pwm
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
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH 1/3] ACPI: Resolve objects on host-directed table loads
2019-08-14 18:50 ` Andy Shevchenko
@ 2019-08-14 20:27 ` Schmauss, Erik
2019-08-16 11:57 ` Nikolaus Voss
0 siblings, 1 reply; 20+ messages in thread
From: Schmauss, Erik @ 2019-08-14 20:27 UTC (permalink / raw)
To: Shevchenko, Andriy, Nikolaus Voss, Rafael J. Wysocki
Cc: Len Brown, Moore, Robert, Jacek Anaszewski, Pavel Machek,
Dan Murphy, Thierry Reding, linux-acpi@vger.kernel.org,
devel@acpica.org, linux-leds@vger.kernel.org,
linux-pwm@vger.kernel.org
> -----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
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: [PATCH 1/3] ACPI: Resolve objects on host-directed table loads
2019-08-14 20:27 ` Schmauss, Erik
@ 2019-08-16 11:57 ` Nikolaus Voss
2019-08-30 14:53 ` Shevchenko, Andriy
0 siblings, 1 reply; 20+ messages in thread
From: Nikolaus Voss @ 2019-08-16 11:57 UTC (permalink / raw)
To: Schmauss, Erik
Cc: Shevchenko, Andriy, Rafael J. Wysocki, Len Brown, Moore, Robert,
Jacek Anaszewski, Pavel Machek, Dan Murphy, Thierry Reding,
linux-acpi@vger.kernel.org, devel@acpica.org,
linux-leds@vger.kernel.org, linux-pwm@vger.kernel.org,
nikolaus.voss
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
>>
>
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/3] ACPI: Resolve objects on host-directed table loads
2019-08-16 11:57 ` Nikolaus Voss
@ 2019-08-30 14:53 ` Shevchenko, Andriy
2019-09-04 7:20 ` Nikolaus Voss
0 siblings, 1 reply; 20+ messages in thread
From: Shevchenko, Andriy @ 2019-08-30 14:53 UTC (permalink / raw)
To: Nikolaus Voss
Cc: Schmauss, Erik, Rafael J. Wysocki, Len Brown, Moore, Robert,
Jacek Anaszewski, Pavel Machek, Dan Murphy, Thierry Reding,
linux-acpi@vger.kernel.org, devel@acpica.org,
linux-leds@vger.kernel.org, linux-pwm@vger.kernel.org,
nikolaus.voss
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?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/3] ACPI: Resolve objects on host-directed table loads
2019-08-30 14:53 ` Shevchenko, Andriy
@ 2019-09-04 7:20 ` Nikolaus Voss
2019-09-06 17:46 ` Shevchenko, Andriy
0 siblings, 1 reply; 20+ messages in thread
From: Nikolaus Voss @ 2019-09-04 7:20 UTC (permalink / raw)
To: Shevchenko, Andriy
Cc: Schmauss, Erik, Rafael J. Wysocki, Len Brown, Moore, Robert,
Jacek Anaszewski, Pavel Machek, Dan Murphy, Thierry Reding,
linux-acpi@vger.kernel.org, devel@acpica.org,
linux-leds@vger.kernel.org, linux-pwm@vger.kernel.org
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH 1/3] ACPI: Resolve objects on host-directed table loads
2019-09-04 7:20 ` Nikolaus Voss
@ 2019-09-06 17:46 ` Shevchenko, Andriy
0 siblings, 0 replies; 20+ messages in thread
From: Shevchenko, Andriy @ 2019-09-06 17:46 UTC (permalink / raw)
To: Nikolaus Voss
Cc: Schmauss, Erik, Rafael J. Wysocki, Len Brown, Moore, Robert,
Jacek Anaszewski, Pavel Machek, Dan Murphy, Thierry Reding,
linux-acpi@vger.kernel.org, devel@acpica.org,
linux-leds@vger.kernel.org, linux-pwm@vger.kernel.org
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
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 2/3] PWM framework: add support referencing PWMs from ACPI
2019-05-29 12:18 [PATCH 0/3] PWM framework: add support referencing PWMs from ACPI Nikolaus Voss
2019-05-29 12:18 ` [PATCH 1/3] ACPI: Resolve objects on host-directed table loads Nikolaus Voss
@ 2019-05-29 12:18 ` Nikolaus Voss
2019-05-30 14:54 ` Dan Murphy
2019-05-29 12:18 ` [PATCH 3/3] leds-pwm.c: support ACPI via firmware-node framework Nikolaus Voss
2 siblings, 1 reply; 20+ messages in thread
From: Nikolaus Voss @ 2019-05-29 12:18 UTC (permalink / raw)
To: Rafael J. Wysocki, Len Brown, Robert Moore, Erik Schmauss,
Jacek Anaszewski, Pavel Machek, Dan Murphy, Thierry Reding
Cc: Nikolaus Voss, linux-acpi, devel, linux-leds, linux-pwm
In analogy to referencing a GPIO using the "gpios" property from ACPI,
support referencing a PWM using the "pwms" property.
ACPI entries must look like
Package () {"pwms", Package ()
{ <PWM device reference>, <PWM index>, <PWM period> [, <PWM flags>]}}
In contrast to the DT implementation, only _one_ PWM entry in the "pwms"
property is supported. As a consequence "pwm-names"-property and
con_id lookup aren't supported.
Support for ACPI is added via the firmware-node framework which is an
abstraction layer on top of ACPI/DT. To keep this patch clean, DT and
ACPI paths are kept separate. The firmware-node framework could be used
to unify both paths in a future patch.
To support leds-pwm driver, an additional method devm_fwnode_pwm_get()
which supports both ACPI and DT configuration is exported.
Signed-off-by: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de>
---
drivers/pwm/core.c | 112 ++++++++++++++++++++++++++++++++++++++++++++
include/linux/pwm.h | 9 ++++
2 files changed, 121 insertions(+)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 275b5f399a1a..1d788c05193e 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -6,6 +6,7 @@
* Copyright (C) 2011-2012 Avionic Design GmbH
*/
+#include <linux/acpi.h>
#include <linux/module.h>
#include <linux/pwm.h>
#include <linux/radix-tree.h>
@@ -700,6 +701,75 @@ struct pwm_device *of_pwm_get(struct device_node *np, const char *con_id)
}
EXPORT_SYMBOL_GPL(of_pwm_get);
+static struct pwm_chip *device_to_pwmchip(struct device *dev)
+{
+ struct pwm_chip *chip;
+
+ mutex_lock(&pwm_lock);
+
+ list_for_each_entry(chip, &pwm_chips, list) {
+ struct acpi_device *adev = ACPI_COMPANION(chip->dev);
+
+ if ((chip->dev == dev) || (adev && &adev->dev == dev)) {
+ mutex_unlock(&pwm_lock);
+ return chip;
+ }
+ }
+
+ mutex_unlock(&pwm_lock);
+
+ return ERR_PTR(-EPROBE_DEFER);
+}
+
+/**
+ * acpi_pwm_get() - request a PWM via parsing "pwms" property in ACPI
+ * @fwnode: firmware node to get the "pwm" property from
+ *
+ * Returns the PWM device parsed from the fwnode and index specified in the
+ * "pwms" property or a negative error-code on failure.
+ * Values parsed from the device tree are stored in the returned PWM device
+ * object.
+ *
+ * This is analogous to of_pwm_get() except con_id is not yet supported.
+ * ACPI entries must look like
+ * Package () {"pwms", Package ()
+ * { <PWM device reference>, <PWM index>, <PWM period> [, <PWM flags>]}}
+ *
+ * Returns: A pointer to the requested PWM device or an ERR_PTR()-encoded
+ * error code on failure.
+ */
+struct pwm_device *acpi_pwm_get(struct fwnode_handle *fwnode)
+{
+ struct fwnode_reference_args args;
+ struct pwm_chip *chip;
+ struct pwm_device *pwm = ERR_PTR(-ENODEV);
+ int ret;
+
+ memset(&args, 0, sizeof(args));
+ ret = __acpi_node_get_property_reference(fwnode, "pwms", 0, 3, &args);
+
+ if (!to_acpi_device_node(args.fwnode))
+ return ERR_PTR(-EINVAL);
+ if (args.nargs < 2)
+ return ERR_PTR(-EPROTO);
+
+ chip = device_to_pwmchip(&to_acpi_device_node(args.fwnode)->dev);
+ if (IS_ERR(chip))
+ return ERR_CAST(chip);
+
+ pwm = pwm_request_from_chip(chip, args.args[0], NULL);
+ if (IS_ERR(pwm))
+ return pwm;
+
+ pwm->args.period = args.args[1];
+ pwm->args.polarity = PWM_POLARITY_NORMAL;
+
+ if (args.nargs > 2 && args.args[2] & PWM_POLARITY_INVERTED)
+ pwm->args.polarity = PWM_POLARITY_INVERSED;
+
+ return pwm;
+}
+
/**
* pwm_add_table() - register PWM device consumers
* @table: array of consumers to register
@@ -763,6 +833,10 @@ struct pwm_device *pwm_get(struct device *dev, const char *con_id)
if (IS_ENABLED(CONFIG_OF) && dev && dev->of_node)
return of_pwm_get(dev->of_node, con_id);
+ /* then lookup via ACPI */
+ if (dev && is_acpi_node(dev->fwnode))
+ return acpi_pwm_get(dev->fwnode);
+
/*
* We look up the provider in the static table typically provided by
* board setup code. We first try to lookup the consumer device by
@@ -942,6 +1016,44 @@ struct pwm_device *devm_of_pwm_get(struct device *dev, struct device_node *np,
}
EXPORT_SYMBOL_GPL(devm_of_pwm_get);
+/**
+ * devm_fwnode_pwm_get() - request a resource managed PWM from firmware node
+ * @dev: device for PWM consumer
+ * @fwnode: firmware node to get the PWM from
+ * @con_id: consumer name
+ *
+ * Returns the PWM device parsed from the firmware node. See of_pwm_get() and
+ * acpi_pwm_get() for a detailed description.
+ *
+ * Returns: A pointer to the requested PWM device or an ERR_PTR()-encoded
+ * error code on failure.
+ */
+struct pwm_device *devm_fwnode_pwm_get(struct device *dev,
+ struct fwnode_handle *fwnode,
+ const char *con_id)
+{
+ struct pwm_device **ptr, *pwm = ERR_PTR(-ENODEV);
+
+ ptr = devres_alloc(devm_pwm_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+
+ if (is_of_node(fwnode))
+ pwm = of_pwm_get(to_of_node(fwnode), con_id);
+ else if (is_acpi_node(fwnode))
+ pwm = acpi_pwm_get(fwnode);
+
+ if (!IS_ERR(pwm)) {
+ *ptr = pwm;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return pwm;
+}
+EXPORT_SYMBOL_GPL(devm_fwnode_pwm_get);
+
static int devm_pwm_match(struct device *dev, void *res, void *data)
{
struct pwm_device **p = res;
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index eaa5c6e3fc9f..1a635916cdfb 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -411,6 +411,9 @@ void pwm_put(struct pwm_device *pwm);
struct pwm_device *devm_pwm_get(struct device *dev, const char *con_id);
struct pwm_device *devm_of_pwm_get(struct device *dev, struct device_node *np,
const char *con_id);
+struct pwm_device *devm_fwnode_pwm_get(struct device *dev,
+ struct fwnode_handle *fwnode,
+ const char *con_id);
void devm_pwm_put(struct device *dev, struct pwm_device *pwm);
#else
static inline struct pwm_device *pwm_request(int pwm_id, const char *label)
@@ -516,6 +519,12 @@ static inline struct pwm_device *devm_of_pwm_get(struct device *dev,
return ERR_PTR(-ENODEV);
}
+static inline struct pwm_device *devm_fwnode_pwm_get(
+ struct device *dev, struct fwnode_handle *fwnode, const char *con_id)
+{
+ return ERR_PTR(-ENODEV);
+}
+
static inline void devm_pwm_put(struct device *dev, struct pwm_device *pwm)
{
}
--
2.17.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH 2/3] PWM framework: add support referencing PWMs from ACPI
2019-05-29 12:18 ` [PATCH 2/3] PWM framework: add support referencing PWMs from ACPI Nikolaus Voss
@ 2019-05-30 14:54 ` Dan Murphy
2019-05-31 12:24 ` Pavel Machek
2019-06-03 9:27 ` Nikolaus Voss
0 siblings, 2 replies; 20+ messages in thread
From: Dan Murphy @ 2019-05-30 14:54 UTC (permalink / raw)
To: Nikolaus Voss, Rafael J. Wysocki, Len Brown, Robert Moore,
Erik Schmauss, Jacek Anaszewski, Pavel Machek, Thierry Reding
Cc: linux-acpi, devel, linux-leds, linux-pwm
Nikolaus
On 5/29/19 7:18 AM, Nikolaus Voss wrote:
> In analogy to referencing a GPIO using the "gpios" property from ACPI,
> support referencing a PWM using the "pwms" property.
>
> ACPI entries must look like
> Package () {"pwms", Package ()
> { <PWM device reference>, <PWM index>, <PWM period> [, <PWM flags>]}}
>
> In contrast to the DT implementation, only _one_ PWM entry in the "pwms"
> property is supported. As a consequence "pwm-names"-property and
> con_id lookup aren't supported.
>
> Support for ACPI is added via the firmware-node framework which is an
> abstraction layer on top of ACPI/DT. To keep this patch clean, DT and
> ACPI paths are kept separate. The firmware-node framework could be used
> to unify both paths in a future patch.
>
> To support leds-pwm driver, an additional method devm_fwnode_pwm_get()
> which supports both ACPI and DT configuration is exported.
>
> Signed-off-by: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de>
> ---
> drivers/pwm/core.c | 112 ++++++++++++++++++++++++++++++++++++++++++++
> include/linux/pwm.h | 9 ++++
> 2 files changed, 121 insertions(+)
>
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index 275b5f399a1a..1d788c05193e 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -6,6 +6,7 @@
> * Copyright (C) 2011-2012 Avionic Design GmbH
> */
>
> +#include <linux/acpi.h>
> #include <linux/module.h>
> #include <linux/pwm.h>
> #include <linux/radix-tree.h>
> @@ -700,6 +701,75 @@ struct pwm_device *of_pwm_get(struct device_node *np, const char *con_id)
> }
> EXPORT_SYMBOL_GPL(of_pwm_get);
>
> +static struct pwm_chip *device_to_pwmchip(struct device *dev)
> +{
> + struct pwm_chip *chip;
> +
> + mutex_lock(&pwm_lock);
> +
> + list_for_each_entry(chip, &pwm_chips, list) {
> + struct acpi_device *adev = ACPI_COMPANION(chip->dev);
> +
> + if ((chip->dev == dev) || (adev && &adev->dev == dev)) {
> + mutex_unlock(&pwm_lock);
> + return chip;
> + }
> + }
> +
> + mutex_unlock(&pwm_lock);
> +
> + return ERR_PTR(-EPROBE_DEFER);
> +}
> +
> +/**
> + * acpi_pwm_get() - request a PWM via parsing "pwms" property in ACPI
> + * @fwnode: firmware node to get the "pwm" property from
> + *
> + * Returns the PWM device parsed from the fwnode and index specified in the
> + * "pwms" property or a negative error-code on failure.
> + * Values parsed from the device tree are stored in the returned PWM device
> + * object.
> + *
> + * This is analogous to of_pwm_get() except con_id is not yet supported.
> + * ACPI entries must look like
> + * Package () {"pwms", Package ()
> + * { <PWM device reference>, <PWM index>, <PWM period> [, <PWM flags>]}}
> + *
> + * Returns: A pointer to the requested PWM device or an ERR_PTR()-encoded
> + * error code on failure.
> + */
> +struct pwm_device *acpi_pwm_get(struct fwnode_handle *fwnode)
static?
> +{
> + struct fwnode_reference_args args;
> + struct pwm_chip *chip;
> + struct pwm_device *pwm = ERR_PTR(-ENODEV);
> + int ret;
> +
> + memset(&args, 0, sizeof(args));
args should be zero'd out when initialized on the stack so this is
necessary.
> + ret = __acpi_node_get_property_reference(fwnode, "pwms", 0, 3, &args);
> +
> + if (!to_acpi_device_node(args.fwnode))
> + return ERR_PTR(-EINVAL);
Add new line
> + if (args.nargs < 2)
> + return ERR_PTR(-EPROTO);
> +
> + chip = device_to_pwmchip(&to_acpi_device_node(args.fwnode)->dev);
> + if (IS_ERR(chip))
> + return ERR_CAST(chip);
> +
> + pwm = pwm_request_from_chip(chip, args.args[0], NULL);
> + if (IS_ERR(pwm))
> + return pwm;
> +
> + pwm->args.period = args.args[1];
> + pwm->args.polarity = PWM_POLARITY_NORMAL;
> +
> + if (args.nargs > 2 && args.args[2] & PWM_POLARITY_INVERTED)
> + pwm->args.polarity = PWM_POLARITY_INVERSED;
> +
> + return pwm;
> +}
> +
> /**
> * pwm_add_table() - register PWM device consumers
> * @table: array of consumers to register
> @@ -763,6 +833,10 @@ struct pwm_device *pwm_get(struct device *dev, const char *con_id)
> if (IS_ENABLED(CONFIG_OF) && dev && dev->of_node)
> return of_pwm_get(dev->of_node, con_id);
>
> + /* then lookup via ACPI */
> + if (dev && is_acpi_node(dev->fwnode))
> + return acpi_pwm_get(dev->fwnode);
> +
> /*
> * We look up the provider in the static table typically provided by
> * board setup code. We first try to lookup the consumer device by
> @@ -942,6 +1016,44 @@ struct pwm_device *devm_of_pwm_get(struct device *dev, struct device_node *np,
> }
> EXPORT_SYMBOL_GPL(devm_of_pwm_get);
>
> +/**
> + * devm_fwnode_pwm_get() - request a resource managed PWM from firmware node
> + * @dev: device for PWM consumer
> + * @fwnode: firmware node to get the PWM from
> + * @con_id: consumer name
> + *
> + * Returns the PWM device parsed from the firmware node. See of_pwm_get() and
> + * acpi_pwm_get() for a detailed description.
> + *
> + * Returns: A pointer to the requested PWM device or an ERR_PTR()-encoded
> + * error code on failure.
> + */
> +struct pwm_device *devm_fwnode_pwm_get(struct device *dev,
> + struct fwnode_handle *fwnode,
> + const char *con_id)
I am wondering if it would be better just to convert the existing of_
calls to device_property calls and make it more generic.
Dan
> +{
> + struct pwm_device **ptr, *pwm = ERR_PTR(-ENODEV);
> +
> + ptr = devres_alloc(devm_pwm_release, sizeof(*ptr), GFP_KERNEL);
> + if (!ptr)
> + return ERR_PTR(-ENOMEM);
> +
> + if (is_of_node(fwnode))
> + pwm = of_pwm_get(to_of_node(fwnode), con_id);
> + else if (is_acpi_node(fwnode))
> + pwm = acpi_pwm_get(fwnode);
> +
> + if (!IS_ERR(pwm)) {
> + *ptr = pwm;
> + devres_add(dev, ptr);
> + } else {
> + devres_free(ptr);
> + }
> +
> + return pwm;
> +}
> +EXPORT_SYMBOL_GPL(devm_fwnode_pwm_get);
> +
> static int devm_pwm_match(struct device *dev, void *res, void *data)
> {
> struct pwm_device **p = res;
> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> index eaa5c6e3fc9f..1a635916cdfb 100644
> --- a/include/linux/pwm.h
> +++ b/include/linux/pwm.h
> @@ -411,6 +411,9 @@ void pwm_put(struct pwm_device *pwm);
> struct pwm_device *devm_pwm_get(struct device *dev, const char *con_id);
> struct pwm_device *devm_of_pwm_get(struct device *dev, struct device_node *np,
> const char *con_id);
> +struct pwm_device *devm_fwnode_pwm_get(struct device *dev,
> + struct fwnode_handle *fwnode,
> + const char *con_id);
> void devm_pwm_put(struct device *dev, struct pwm_device *pwm);
> #else
> static inline struct pwm_device *pwm_request(int pwm_id, const char *label)
> @@ -516,6 +519,12 @@ static inline struct pwm_device *devm_of_pwm_get(struct device *dev,
> return ERR_PTR(-ENODEV);
> }
>
> +static inline struct pwm_device *devm_fwnode_pwm_get(
> + struct device *dev, struct fwnode_handle *fwnode, const char *con_id)
> +{
> + return ERR_PTR(-ENODEV);
> +}
> +
> static inline void devm_pwm_put(struct device *dev, struct pwm_device *pwm)
> {
> }
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 2/3] PWM framework: add support referencing PWMs from ACPI
2019-05-30 14:54 ` Dan Murphy
@ 2019-05-31 12:24 ` Pavel Machek
2019-06-03 9:27 ` Nikolaus Voss
1 sibling, 0 replies; 20+ messages in thread
From: Pavel Machek @ 2019-05-31 12:24 UTC (permalink / raw)
To: Dan Murphy
Cc: Nikolaus Voss, Rafael J. Wysocki, Len Brown, Robert Moore,
Erik Schmauss, Jacek Anaszewski, Thierry Reding, linux-acpi,
devel, linux-leds, linux-pwm
[-- Attachment #1: Type: text/plain, Size: 521 bytes --]
Hi!
> >+struct pwm_device *acpi_pwm_get(struct fwnode_handle *fwnode)
> static?
> >+{
> >+ struct fwnode_reference_args args;
> >+ struct pwm_chip *chip;
> >+ struct pwm_device *pwm = ERR_PTR(-ENODEV);
> >+ int ret;
> >+
> >+ memset(&args, 0, sizeof(args));
>
> args should be zero'd out when initialized on the stack so this is
> necessary.
What?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 2/3] PWM framework: add support referencing PWMs from ACPI
2019-05-30 14:54 ` Dan Murphy
2019-05-31 12:24 ` Pavel Machek
@ 2019-06-03 9:27 ` Nikolaus Voss
1 sibling, 0 replies; 20+ messages in thread
From: Nikolaus Voss @ 2019-06-03 9:27 UTC (permalink / raw)
To: Dan Murphy
Cc: Rafael J. Wysocki, Len Brown, Robert Moore, Erik Schmauss,
Jacek Anaszewski, Pavel Machek, Thierry Reding,
linux-acpi@vger.kernel.org, devel@acpica.org,
linux-leds@vger.kernel.org, linux-pwm@vger.kernel.org
Dan,
On Thu, 30 May 2019, Dan Murphy wrote:
> Nikolaus
>
> On 5/29/19 7:18 AM, Nikolaus Voss wrote:
>> In analogy to referencing a GPIO using the "gpios" property from ACPI,
>> support referencing a PWM using the "pwms" property.
>>
>> ACPI entries must look like
>> Package () {"pwms", Package ()
>> { <PWM device reference>, <PWM index>, <PWM period> [, <PWM flags>]}}
>>
>> In contrast to the DT implementation, only _one_ PWM entry in the "pwms"
>> property is supported. As a consequence "pwm-names"-property and
>> con_id lookup aren't supported.
>>
>> Support for ACPI is added via the firmware-node framework which is an
>> abstraction layer on top of ACPI/DT. To keep this patch clean, DT and
>> ACPI paths are kept separate. The firmware-node framework could be used
>> to unify both paths in a future patch.
>>
>> To support leds-pwm driver, an additional method devm_fwnode_pwm_get()
>> which supports both ACPI and DT configuration is exported.
>>
>> Signed-off-by: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de>
>> ---
>> drivers/pwm/core.c | 112 ++++++++++++++++++++++++++++++++++++++++++++
>> include/linux/pwm.h | 9 ++++
>> 2 files changed, 121 insertions(+)
>>
>> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
>> index 275b5f399a1a..1d788c05193e 100644
>> --- a/drivers/pwm/core.c
>> +++ b/drivers/pwm/core.c
>> @@ -6,6 +6,7 @@
>> * Copyright (C) 2011-2012 Avionic Design GmbH
>> */
>>
>> +#include <linux/acpi.h>
>> #include <linux/module.h>
>> #include <linux/pwm.h>
>> #include <linux/radix-tree.h>
>> @@ -700,6 +701,75 @@ struct pwm_device *of_pwm_get(struct device_node *np, const char *con_id)
>> }
>> EXPORT_SYMBOL_GPL(of_pwm_get);
>>
>> +static struct pwm_chip *device_to_pwmchip(struct device *dev)
>> +{
>> + struct pwm_chip *chip;
>> +
>> + mutex_lock(&pwm_lock);
>> +
>> + list_for_each_entry(chip, &pwm_chips, list) {
>> + struct acpi_device *adev = ACPI_COMPANION(chip->dev);
>> +
>> + if ((chip->dev == dev) || (adev && &adev->dev == dev)) {
>> + mutex_unlock(&pwm_lock);
>> + return chip;
>> + }
>> + }
>> +
>> + mutex_unlock(&pwm_lock);
>> +
>> + return ERR_PTR(-EPROBE_DEFER);
>> +}
>> +
>> +/**
>> + * acpi_pwm_get() - request a PWM via parsing "pwms" property in ACPI
>> + * @fwnode: firmware node to get the "pwm" property from
>> + *
>> + * Returns the PWM device parsed from the fwnode and index specified in the
>> + * "pwms" property or a negative error-code on failure.
>> + * Values parsed from the device tree are stored in the returned PWM device
>> + * object.
>> + *
>> + * This is analogous to of_pwm_get() except con_id is not yet supported.
>> + * ACPI entries must look like
>> + * Package () {"pwms", Package ()
>> + * { <PWM device reference>, <PWM index>, <PWM period> [, <PWM flags>]}}
>> + *
>> + * Returns: A pointer to the requested PWM device or an ERR_PTR()-encoded
>> + * error code on failure.
>> + */
>> +struct pwm_device *acpi_pwm_get(struct fwnode_handle *fwnode)
> static?
yes, changed.
>> +{
>> + struct fwnode_reference_args args;
>> + struct pwm_chip *chip;
>> + struct pwm_device *pwm = ERR_PTR(-ENODEV);
>> + int ret;
>> +
>> + memset(&args, 0, sizeof(args));
>
> args should be zero'd out when initialized on the stack so this is
> necessary.
>
>> + ret = __acpi_node_get_property_reference(fwnode, "pwms", 0, 3, &args);
>> +
>> + if (!to_acpi_device_node(args.fwnode))
>> + return ERR_PTR(-EINVAL);
> Add new line
ok
>> + if (args.nargs < 2)
>> + return ERR_PTR(-EPROTO);
>> +
>> + chip = device_to_pwmchip(&to_acpi_device_node(args.fwnode)->dev);
>> + if (IS_ERR(chip))
>> + return ERR_CAST(chip);
>> +
>> + pwm = pwm_request_from_chip(chip, args.args[0], NULL);
>> + if (IS_ERR(pwm))
>> + return pwm;
>> +
>> + pwm->args.period = args.args[1];
>> + pwm->args.polarity = PWM_POLARITY_NORMAL;
>> +
>> + if (args.nargs > 2 && args.args[2] & PWM_POLARITY_INVERTED)
>> + pwm->args.polarity = PWM_POLARITY_INVERSED;
>> +
>> + return pwm;
>> +}
>> +
>> /**
>> * pwm_add_table() - register PWM device consumers
>> * @table: array of consumers to register
>> @@ -763,6 +833,10 @@ struct pwm_device *pwm_get(struct device *dev, const char *con_id)
>> if (IS_ENABLED(CONFIG_OF) && dev && dev->of_node)
>> return of_pwm_get(dev->of_node, con_id);
>>
>> + /* then lookup via ACPI */
>> + if (dev && is_acpi_node(dev->fwnode))
>> + return acpi_pwm_get(dev->fwnode);
>> +
>> /*
>> * We look up the provider in the static table typically provided by
>> * board setup code. We first try to lookup the consumer device by
>> @@ -942,6 +1016,44 @@ struct pwm_device *devm_of_pwm_get(struct device *dev, struct device_node *np,
>> }
>> EXPORT_SYMBOL_GPL(devm_of_pwm_get);
>>
>> +/**
>> + * devm_fwnode_pwm_get() - request a resource managed PWM from firmware node
>> + * @dev: device for PWM consumer
>> + * @fwnode: firmware node to get the PWM from
>> + * @con_id: consumer name
>> + *
>> + * Returns the PWM device parsed from the firmware node. See of_pwm_get() and
>> + * acpi_pwm_get() for a detailed description.
>> + *
>> + * Returns: A pointer to the requested PWM device or an ERR_PTR()-encoded
>> + * error code on failure.
>> + */
>> +struct pwm_device *devm_fwnode_pwm_get(struct device *dev,
>> + struct fwnode_handle *fwnode,
>> + const char *con_id)
>
> I am wondering if it would be better just to convert the existing of_
> calls to device_property calls and make it more generic.
With this first patch I wanted to keep DT and ACPI paths separate. Merging
the two paths as far as possible is reasonable but should be done in a
second step.
Nikolaus
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 3/3] leds-pwm.c: support ACPI via firmware-node framework
2019-05-29 12:18 [PATCH 0/3] PWM framework: add support referencing PWMs from ACPI Nikolaus Voss
2019-05-29 12:18 ` [PATCH 1/3] ACPI: Resolve objects on host-directed table loads Nikolaus Voss
2019-05-29 12:18 ` [PATCH 2/3] PWM framework: add support referencing PWMs from ACPI Nikolaus Voss
@ 2019-05-29 12:18 ` Nikolaus Voss
2019-05-30 15:14 ` Dan Murphy
2 siblings, 1 reply; 20+ messages in thread
From: Nikolaus Voss @ 2019-05-29 12:18 UTC (permalink / raw)
To: Rafael J. Wysocki, Len Brown, Robert Moore, Erik Schmauss,
Jacek Anaszewski, Pavel Machek, Dan Murphy, Thierry Reding
Cc: Nikolaus Voss, linux-acpi, devel, linux-leds, linux-pwm
DT specific handling is replaced by firmware-node abstration to support
ACPI specification of PWM LEDS.
Example ASL:
Device (PWML)
{
Name (_HID, "PRP0001")
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () { Package () {"compatible",
Package () {"pwm-leds"}}}})
Device (PWL0)
{
Name (_HID, "PRP0001")
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"label", "alarm-led"},
Package () {"pwms", Package ()
{\_SB_.PCI0.PWM, 0, 600000, 0}},
Package () {"linux,default-state", "off"}}})
}
}
Signed-off-by: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de>
---
drivers/leds/leds-pwm.c | 44 ++++++++++++++++++++++++-----------------
1 file changed, 26 insertions(+), 18 deletions(-)
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index af08bcdc4fd8..cc717dd6a12c 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -75,7 +75,7 @@ static inline size_t sizeof_pwm_leds_priv(int num_leds)
}
static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
- struct led_pwm *led, struct device_node *child)
+ struct led_pwm *led, struct fwnode_handle *fwnode)
{
struct led_pwm_data *led_data = &priv->leds[priv->num_leds];
struct pwm_args pargs;
@@ -88,8 +88,8 @@ static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
led_data->cdev.max_brightness = led->max_brightness;
led_data->cdev.flags = LED_CORE_SUSPENDRESUME;
- if (child)
- led_data->pwm = devm_of_pwm_get(dev, child, NULL);
+ if (fwnode)
+ led_data->pwm = devm_fwnode_pwm_get(dev, fwnode, NULL);
else
led_data->pwm = devm_pwm_get(dev, led->name);
if (IS_ERR(led_data->pwm)) {
@@ -114,7 +114,8 @@ static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
if (!led_data->period && (led->pwm_period_ns > 0))
led_data->period = led->pwm_period_ns;
- ret = devm_of_led_classdev_register(dev, child, &led_data->cdev);
+ ret = devm_of_led_classdev_register(dev, to_of_node(fwnode),
+ &led_data->cdev);
if (ret == 0) {
priv->num_leds++;
led_pwm_set(&led_data->cdev, led_data->cdev.brightness);
@@ -126,27 +127,34 @@ static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
return ret;
}
-static int led_pwm_create_of(struct device *dev, struct led_pwm_priv *priv)
+static int led_pwm_create_fwnode(struct device *dev, struct led_pwm_priv *priv)
{
- struct device_node *child;
+ struct fwnode_handle *fwnode;
struct led_pwm led;
int ret = 0;
memset(&led, 0, sizeof(led));
- for_each_child_of_node(dev->of_node, child) {
- led.name = of_get_property(child, "label", NULL) ? :
- child->name;
+ device_for_each_child_node(dev, fwnode) {
+ ret = fwnode_property_read_string(fwnode, "label", &led.name);
+ if (ret && is_of_node(fwnode))
+ led.name = to_of_node(fwnode)->name;
+ if (!led.name) {
+ fwnode_handle_put(fwnode);
+ return -EINVAL;
+ }
- led.default_trigger = of_get_property(child,
- "linux,default-trigger", NULL);
- led.active_low = of_property_read_bool(child, "active-low");
- of_property_read_u32(child, "max-brightness",
- &led.max_brightness);
+ fwnode_property_read_string(fwnode, "linux,default-trigger",
+ &led.default_trigger);
- ret = led_pwm_add(dev, priv, &led, child);
+ led.active_low = fwnode_property_read_bool(fwnode,
+ "active-low");
+ fwnode_property_read_u32(fwnode, "max-brightness",
+ &led.max_brightness);
+
+ ret = led_pwm_add(dev, priv, &led, fwnode);
if (ret) {
- of_node_put(child);
+ fwnode_handle_put(fwnode);
break;
}
}
@@ -164,7 +172,7 @@ static int led_pwm_probe(struct platform_device *pdev)
if (pdata)
count = pdata->num_leds;
else
- count = of_get_child_count(pdev->dev.of_node);
+ count = device_get_child_node_count(&pdev->dev);
if (!count)
return -EINVAL;
@@ -182,7 +190,7 @@ static int led_pwm_probe(struct platform_device *pdev)
break;
}
} else {
- ret = led_pwm_create_of(&pdev->dev, priv);
+ ret = led_pwm_create_fwnode(&pdev->dev, priv);
}
if (ret)
--
2.17.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH 3/3] leds-pwm.c: support ACPI via firmware-node framework
2019-05-29 12:18 ` [PATCH 3/3] leds-pwm.c: support ACPI via firmware-node framework Nikolaus Voss
@ 2019-05-30 15:14 ` Dan Murphy
2019-06-03 9:44 ` Nikolaus Voss
0 siblings, 1 reply; 20+ messages in thread
From: Dan Murphy @ 2019-05-30 15:14 UTC (permalink / raw)
To: Nikolaus Voss, Rafael J. Wysocki, Len Brown, Robert Moore,
Erik Schmauss, Jacek Anaszewski, Pavel Machek, Thierry Reding
Cc: linux-acpi, devel, linux-leds, linux-pwm
On 5/29/19 7:18 AM, Nikolaus Voss wrote:
> DT specific handling is replaced by firmware-node abstration to support
> ACPI specification of PWM LEDS.
>
> Example ASL:
> Device (PWML)
> {
> Name (_HID, "PRP0001")
> Name (_DSD, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () { Package () {"compatible",
> Package () {"pwm-leds"}}}})
>
> Device (PWL0)
> {
> Name (_HID, "PRP0001")
> Name (_DSD, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package () {"label", "alarm-led"},
> Package () {"pwms", Package ()
> {\_SB_.PCI0.PWM, 0, 600000, 0}},
> Package () {"linux,default-state", "off"}}})
> }
> }
>
> Signed-off-by: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de>
> ---
> drivers/leds/leds-pwm.c | 44 ++++++++++++++++++++++++-----------------
> 1 file changed, 26 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
> index af08bcdc4fd8..cc717dd6a12c 100644
> --- a/drivers/leds/leds-pwm.c
> +++ b/drivers/leds/leds-pwm.c
> @@ -75,7 +75,7 @@ static inline size_t sizeof_pwm_leds_priv(int num_leds)
> }
>
> static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
> - struct led_pwm *led, struct device_node *child)
> + struct led_pwm *led, struct fwnode_handle *fwnode)
> {
> struct led_pwm_data *led_data = &priv->leds[priv->num_leds];
> struct pwm_args pargs;
> @@ -88,8 +88,8 @@ static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
> led_data->cdev.max_brightness = led->max_brightness;
> led_data->cdev.flags = LED_CORE_SUSPENDRESUME;
>
> - if (child)
> - led_data->pwm = devm_of_pwm_get(dev, child, NULL);
> + if (fwnode)
> + led_data->pwm = devm_fwnode_pwm_get(dev, fwnode, NULL);
> else
> led_data->pwm = devm_pwm_get(dev, led->name);
> if (IS_ERR(led_data->pwm)) {
> @@ -114,7 +114,8 @@ static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
> if (!led_data->period && (led->pwm_period_ns > 0))
> led_data->period = led->pwm_period_ns;
>
> - ret = devm_of_led_classdev_register(dev, child, &led_data->cdev);
> + ret = devm_of_led_classdev_register(dev, to_of_node(fwnode),
> + &led_data->cdev);
> if (ret == 0) {
> priv->num_leds++;
> led_pwm_set(&led_data->cdev, led_data->cdev.brightness);
> @@ -126,27 +127,34 @@ static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
> return ret;
> }
>
> -static int led_pwm_create_of(struct device *dev, struct led_pwm_priv *priv)
> +static int led_pwm_create_fwnode(struct device *dev, struct led_pwm_priv *priv)
> {
> - struct device_node *child;
> + struct fwnode_handle *fwnode;
> struct led_pwm led;
> int ret = 0;
>
> memset(&led, 0, sizeof(led));
>
> - for_each_child_of_node(dev->of_node, child) {
> - led.name = of_get_property(child, "label", NULL) ? :
> - child->name;
> + device_for_each_child_node(dev, fwnode) {
> + ret = fwnode_property_read_string(fwnode, "label", &led.name);
> + if (ret && is_of_node(fwnode))
> + led.name = to_of_node(fwnode)->name;
new line
> + if (!led.name) {
> + fwnode_handle_put(fwnode);
> + return -EINVAL;
> + }
'label' is an optional parameter for device tree returning here makes it
required.
Maybe derive a default name. There is a patch series which is going to
modify how labels are created for LED class devices.
https://lore.kernel.org/patchwork/project/lkml/list/?series=391005
>
> - led.default_trigger = of_get_property(child,
> - "linux,default-trigger", NULL);
> - led.active_low = of_property_read_bool(child, "active-low");
> - of_property_read_u32(child, "max-brightness",
> - &led.max_brightness);
> + fwnode_property_read_string(fwnode, "linux,default-trigger",
> + &led.default_trigger);
>
> - ret = led_pwm_add(dev, priv, &led, child);
> + led.active_low = fwnode_property_read_bool(fwnode,
> + "active-low");
> + fwnode_property_read_u32(fwnode, "max-brightness",
> + &led.max_brightness);
> +
> + ret = led_pwm_add(dev, priv, &led, fwnode);
> if (ret) {
> - of_node_put(child);
> + fwnode_handle_put(fwnode);
> break;
> }
> }
> @@ -164,7 +172,7 @@ static int led_pwm_probe(struct platform_device *pdev)
> if (pdata)
> count = pdata->num_leds;
> else
> - count = of_get_child_count(pdev->dev.of_node);
> + count = device_get_child_node_count(&pdev->dev);
>
> if (!count)
> return -EINVAL;
> @@ -182,7 +190,7 @@ static int led_pwm_probe(struct platform_device *pdev)
> break;
> }
> } else {
> - ret = led_pwm_create_of(&pdev->dev, priv);
> + ret = led_pwm_create_fwnode(&pdev->dev, priv);
> }
>
> if (ret)
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH 3/3] leds-pwm.c: support ACPI via firmware-node framework
2019-05-30 15:14 ` Dan Murphy
@ 2019-06-03 9:44 ` Nikolaus Voss
0 siblings, 0 replies; 20+ messages in thread
From: Nikolaus Voss @ 2019-06-03 9:44 UTC (permalink / raw)
To: Dan Murphy
Cc: Rafael J. Wysocki, Len Brown, Robert Moore, Erik Schmauss,
Jacek Anaszewski, Pavel Machek, Thierry Reding,
linux-acpi@vger.kernel.org, devel@acpica.org,
linux-leds@vger.kernel.org, linux-pwm@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 4134 bytes --]
Dan,
On Thu, 30 May 2019, Dan Murphy wrote:
>
> On 5/29/19 7:18 AM, Nikolaus Voss wrote:
>> DT specific handling is replaced by firmware-node abstration to support
>> ACPI specification of PWM LEDS.
>>
>> Example ASL:
>> Device (PWML)
>> {
>> Name (_HID, "PRP0001")
>> Name (_DSD, Package () {
>> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>> Package () { Package () {"compatible",
>> Package () {"pwm-leds"}}}})
>>
>> Device (PWL0)
>> {
>> Name (_HID, "PRP0001")
>> Name (_DSD, Package () {
>> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>> Package () {
>> Package () {"label", "alarm-led"},
>> Package () {"pwms", Package ()
>> {\_SB_.PCI0.PWM, 0, 600000, 0}},
>> Package () {"linux,default-state", "off"}}})
>> }
>> }
>>
>> Signed-off-by: Nikolaus Voss <nikolaus.voss@loewensteinmedical.de>
>> ---
>> drivers/leds/leds-pwm.c | 44 ++++++++++++++++++++++++-----------------
>> 1 file changed, 26 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
>> index af08bcdc4fd8..cc717dd6a12c 100644
>> --- a/drivers/leds/leds-pwm.c
>> +++ b/drivers/leds/leds-pwm.c
>> @@ -75,7 +75,7 @@ static inline size_t sizeof_pwm_leds_priv(int num_leds)
>> }
>>
>> static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
>> - struct led_pwm *led, struct device_node *child)
>> + struct led_pwm *led, struct fwnode_handle *fwnode)
>> {
>> struct led_pwm_data *led_data = &priv->leds[priv->num_leds];
>> struct pwm_args pargs;
>> @@ -88,8 +88,8 @@ static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
>> led_data->cdev.max_brightness = led->max_brightness;
>> led_data->cdev.flags = LED_CORE_SUSPENDRESUME;
>>
>> - if (child)
>> - led_data->pwm = devm_of_pwm_get(dev, child, NULL);
>> + if (fwnode)
>> + led_data->pwm = devm_fwnode_pwm_get(dev, fwnode, NULL);
>> else
>> led_data->pwm = devm_pwm_get(dev, led->name);
>> if (IS_ERR(led_data->pwm)) {
>> @@ -114,7 +114,8 @@ static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
>> if (!led_data->period && (led->pwm_period_ns > 0))
>> led_data->period = led->pwm_period_ns;
>>
>> - ret = devm_of_led_classdev_register(dev, child, &led_data->cdev);
>> + ret = devm_of_led_classdev_register(dev, to_of_node(fwnode),
>> + &led_data->cdev);
>> if (ret == 0) {
>> priv->num_leds++;
>> led_pwm_set(&led_data->cdev, led_data->cdev.brightness);
>> @@ -126,27 +127,34 @@ static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
>> return ret;
>> }
>>
>> -static int led_pwm_create_of(struct device *dev, struct led_pwm_priv *priv)
>> +static int led_pwm_create_fwnode(struct device *dev, struct led_pwm_priv *priv)
>> {
>> - struct device_node *child;
>> + struct fwnode_handle *fwnode;
>> struct led_pwm led;
>> int ret = 0;
>>
>> memset(&led, 0, sizeof(led));
>>
>> - for_each_child_of_node(dev->of_node, child) {
>> - led.name = of_get_property(child, "label", NULL) ? :
>> - child->name;
>> + device_for_each_child_node(dev, fwnode) {
>> + ret = fwnode_property_read_string(fwnode, "label", &led.name);
>> + if (ret && is_of_node(fwnode))
>> + led.name = to_of_node(fwnode)->name;
>
> new line
ok
>
>
>> + if (!led.name) {
>> + fwnode_handle_put(fwnode);
>> + return -EINVAL;
>> + }
>
> 'label' is an optional parameter for device tree returning here makes it
> required.
>
> Maybe derive a default name. There is a patch series which is going to
> modify how labels are created for LED class devices.
>
> https://lore.kernel.org/patchwork/project/lkml/list/?series=391005
Looks interesting, thanks for the pointer. But that would be a second
step.
My patch handles name derivation the same way as the leds-gpio driver
already does. I think it should be handled consistently among drivers of
the same sub-system.
Nikolaus
^ permalink raw reply [flat|nested] 20+ messages in thread