* [PATCH] ACPI: glue: Use acpi_device_adr() in acpi_find_child_device()
@ 2021-10-27 16:59 Rafael J. Wysocki
2021-10-27 17:17 ` Andy Shevchenko
0 siblings, 1 reply; 4+ messages in thread
From: Rafael J. Wysocki @ 2021-10-27 16:59 UTC (permalink / raw)
To: Linux ACPI; +Cc: LKML, Andy Shevchenko, Hans de Goede, Mika Westerberg
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Instead of evaluating _ADR in acpi_find_child_device(), use the
observation that it has already been evaluated and the value returned
by it has been stored in the pnp.type.bus_address field of the ACPI
device object at hand.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
Note that the patch at
https://patchwork.kernel.org/project/linux-acpi/patch/2223516.ElGaqSPkdT@kreacher/
will have an effect of this, so I'm going to prioritize the current patch
over the one above.
---
drivers/acpi/glue.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
Index: linux-pm/drivers/acpi/glue.c
===================================================================
--- linux-pm.orig/drivers/acpi/glue.c
+++ linux-pm/drivers/acpi/glue.c
@@ -113,13 +113,10 @@ struct acpi_device *acpi_find_child_devi
return NULL;
list_for_each_entry(adev, &parent->children, node) {
- unsigned long long addr;
- acpi_status status;
+ acpi_bus_address addr = acpi_device_adr(adev);
int score;
- status = acpi_evaluate_integer(adev->handle, METHOD_NAME__ADR,
- NULL, &addr);
- if (ACPI_FAILURE(status) || addr != address)
+ if (!adev->pnp.type.bus_address || addr != address)
continue;
if (!ret) {
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] ACPI: glue: Use acpi_device_adr() in acpi_find_child_device()
2021-10-27 16:59 [PATCH] ACPI: glue: Use acpi_device_adr() in acpi_find_child_device() Rafael J. Wysocki
@ 2021-10-27 17:17 ` Andy Shevchenko
2021-10-27 17:23 ` Rafael J. Wysocki
0 siblings, 1 reply; 4+ messages in thread
From: Andy Shevchenko @ 2021-10-27 17:17 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux ACPI, LKML, Hans de Goede, Mika Westerberg
On Wed, Oct 27, 2021 at 06:59:06PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> Instead of evaluating _ADR in acpi_find_child_device(), use the
> observation that it has already been evaluated and the value returned
> by it has been stored in the pnp.type.bus_address field of the ACPI
> device object at hand.
...
> + acpi_bus_address addr = acpi_device_adr(adev);
> int score;
>
> - status = acpi_evaluate_integer(adev->handle, METHOD_NAME__ADR,
> - NULL, &addr);
> - if (ACPI_FAILURE(status) || addr != address)
> + if (!adev->pnp.type.bus_address || addr != address)
> continue;
I'm not sure I understand the new check, i.e. !adev->pnp.type.bus_address.
IIUC _ADR == 0 is a valid value and children may have it like this.
I believe this change will break the working things (first comes to my mind
is drivers/mfd/intel_quark_i2c_gpio.c).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] ACPI: glue: Use acpi_device_adr() in acpi_find_child_device()
2021-10-27 17:17 ` Andy Shevchenko
@ 2021-10-27 17:23 ` Rafael J. Wysocki
2021-10-27 17:35 ` Andy Shevchenko
0 siblings, 1 reply; 4+ messages in thread
From: Rafael J. Wysocki @ 2021-10-27 17:23 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Rafael J. Wysocki, Linux ACPI, LKML, Hans de Goede, Mika Westerberg
On Wed, Oct 27, 2021 at 7:17 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Wed, Oct 27, 2021 at 06:59:06PM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > Instead of evaluating _ADR in acpi_find_child_device(), use the
> > observation that it has already been evaluated and the value returned
> > by it has been stored in the pnp.type.bus_address field of the ACPI
> > device object at hand.
>
> ...
>
> > + acpi_bus_address addr = acpi_device_adr(adev);
> > int score;
> >
> > - status = acpi_evaluate_integer(adev->handle, METHOD_NAME__ADR,
> > - NULL, &addr);
> > - if (ACPI_FAILURE(status) || addr != address)
> > + if (!adev->pnp.type.bus_address || addr != address)
> > continue;
>
> I'm not sure I understand the new check, i.e. !adev->pnp.type.bus_address.
See acpi_set_pnp_ids().
adev->pnp.bus_addres is the address value and
adev->pnp.type.bus_address is a flag that is set to 1 when _ADR is
valid.
> IIUC _ADR == 0 is a valid value and children may have it like this.
That's true.
> I believe this change will break the working things (first comes to my mind
> is drivers/mfd/intel_quark_i2c_gpio.c).
I don't think so.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] ACPI: glue: Use acpi_device_adr() in acpi_find_child_device()
2021-10-27 17:23 ` Rafael J. Wysocki
@ 2021-10-27 17:35 ` Andy Shevchenko
0 siblings, 0 replies; 4+ messages in thread
From: Andy Shevchenko @ 2021-10-27 17:35 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rafael J. Wysocki, Linux ACPI, LKML, Hans de Goede, Mika Westerberg
On Wed, Oct 27, 2021 at 07:23:43PM +0200, Rafael J. Wysocki wrote:
> On Wed, Oct 27, 2021 at 7:17 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Wed, Oct 27, 2021 at 06:59:06PM +0200, Rafael J. Wysocki wrote:
...
> See acpi_set_pnp_ids().
>
> adev->pnp.bus_addres is the address value and
> adev->pnp.type.bus_address is a flag that is set to 1 when _ADR is
> valid.
>
> > IIUC _ADR == 0 is a valid value and children may have it like this.
>
> That's true.
>
> > I believe this change will break the working things (first comes to my mind
> > is drivers/mfd/intel_quark_i2c_gpio.c).
>
> I don't think so.
With your explanation I see where my logic is wrong. Thanks!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-10-27 18:35 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-27 16:59 [PATCH] ACPI: glue: Use acpi_device_adr() in acpi_find_child_device() Rafael J. Wysocki
2021-10-27 17:17 ` Andy Shevchenko
2021-10-27 17:23 ` Rafael J. Wysocki
2021-10-27 17:35 ` Andy Shevchenko
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®