Re: [PATCH v3] ACPI: glue: Reduce debug noise from acpi_device_notify()

"Rafael J. Wysocki (Intel)" <[email protected]>
Newsgroups org.kernel.vger.linux-acpi,org.kernel.vger.linux-kernel
Message-ID <CAJZ5v0gqEuKu774XH3NZdG-bwKkPUAUjPKZF2L0opp9LOON3CQ@mail.gmail.com>
On Fri, Sep 4, 2026 at 10:12 PM Rafael J. Wysocki <[email protected]> wrote:
>
> From: "Rafael J. Wysocki" <[email protected]>
>
> When debug is enabled in the ACPI glue code that handles binding
> devices to ACPI companions, acpi_device_notify() produces a lot of
> message noise related to devices that have no ACPI companions.
>
> Reduce that noise by checking the most obvious case, ACPI device
> objects, directly and returning from acpi_device_notify() in that
> case without printing any debug messages.  Also avoid printing a
> debug message when there is no matching ACPI companion lookup
> method for the given device, which is the case for the vast
> majority of devices.
>
> Additionally, make the debug messages that get printed more informative
> and adjust the "success" debug message for devices whose ACPI companions
> have no ACPI handles (for example, they are fixed event buttons).
>
> Signed-off-by: Rafael J. Wysocki <[email protected]>
> ---
>
> v2 -> v3:
>    * Do not change pr_fmt() definition (Sashiko)
>    * adjust the "success" debug message for devices whose ACPI companions
>      have no ACPI handles
>    * Update changelog
>
> v1 -> v2:
>    * Do not return early from acpi_device_notify() for devices
>      without a bus type (Sashiko)
>    * Do not print messages for devices without matching ACPI bus
>      type definition (the vast majority)
>    * Update changelog
>
> ---
>  drivers/acpi/glue.c |   27 +++++++++++++++------------
>  1 file changed, 15 insertions(+), 12 deletions(-)
>
> --- a/drivers/acpi/glue.c
> +++ b/drivers/acpi/glue.c
> @@ -354,22 +354,27 @@ void acpi_device_notify(struct device *d
>         struct acpi_device *adev;
>         int ret;
>
> +       /* ACPI devices have no ACPI companions. */
> +       if (dev->bus == &acpi_bus_type)
> +               return;
> +
>         ret = acpi_bind_one(dev, NULL);
>         if (ret) {
>                 struct acpi_bus_type *type = acpi_get_bus_type(dev);
>
>                 if (!type)
> -                       goto err;
> +                       return;
>
>                 adev = type->find_companion(dev);
>                 if (!adev) {
>                         dev_dbg(dev, "ACPI companion not found\n");
> -                       goto err;
> +                       return;
>                 }
>                 ret = acpi_bind_one(dev, adev);
> -               if (ret)
> -                       goto err;
> -
> +               if (ret) {
> +                       dev_dbg(dev, "Binding to ACPI companion failed\n");
> +                       return;
> +               }
>                 if (type->setup) {
>                         type->setup(dev);
>                         goto done;
> @@ -389,13 +394,11 @@ void acpi_device_notify(struct device *d
>                 adev->handler->bind(dev);
>
>  done:
> -       acpi_handle_debug(ACPI_HANDLE(dev), "Bound to device %s\n",
> -                         dev_name(dev));
> -
> -       return;
> -
> -err:
> -       dev_dbg(dev, "No ACPI support\n");
> +       if (adev->handle)
> +               acpi_handle_debug(adev->handle, "Bound to device %s\n",
> +                                 dev_name(dev));
> +       else
> +               dev_dbg(dev, "Bound to ACPI device %s\n", dev_name(&adev->dev));

Self review: This isn't particularly nice and it kind of works around
a broader issue which is that the acpi_handle_debug() message is
somewhat misleading because it suggests that an ACPI namespace object
has been bound to a "physical" device, which is not what really
happens.

In fact, the "physical" device is bound to an ACPI device object
attached to the ACPI namespace object represented by the handle (or
namespace path).

So scratch this one and there will be a v4 (which will consist of 2 patches).
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.