From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Linux ACPI <linux-acpi@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Salil Mehta <salil.mehta@huawei.com>
Subject: Re: [PATCH v1] ACPI: scan: Avoid enumerating devices with clearly invalid _STA values
Date: Mon, 29 Apr 2024 09:29:42 +0100 [thread overview]
Message-ID: <20240429092942.00004c96@Huawei.com> (raw)
In-Reply-To: <2741433.mvXUDI8C0e@kreacher>
On Fri, 26 Apr 2024 18:56:21 +0200
"Rafael J. Wysocki" <rjw@rjwysocki.net> wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> The return value of _STA with the "present" bit unset and the "enabled"
> bit set is clearly invalid as per the ACPI specification, Section 6.3.7
> "_STA (Device Status)", so make the ACPI device enumeration code
> disregard devices with such _STA return values.
>
> Also, because this implies that status.enabled will only be set if
> status.present is set too, acpi_device_is_enabled() can be modified
> to simply return the value of the former.
>
> Link: https://uefi.org/specs/ACPI/6.5/06_Device_Configuration.html#sta-device-status
> Link: https://lore.kernel.org/linux-acpi/88179311a503493099028c12ca37d430@huawei.com/
> Suggested-by: Salil Mehta <salil.mehta@huawei.com>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Seems a sensible tidying up. Hopefully nothing was relying on
this looser behavior. One trivial thing inline.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
> drivers/acpi/bus.c | 11 +++++++++++
> drivers/acpi/scan.c | 2 +-
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> Index: linux-pm/drivers/acpi/bus.c
> ===================================================================
> --- linux-pm.orig/drivers/acpi/bus.c
> +++ linux-pm/drivers/acpi/bus.c
> @@ -112,6 +112,17 @@ int acpi_bus_get_status(struct acpi_devi
> if (ACPI_FAILURE(status))
> return -ENODEV;
>
> + if (!device->status.present && device->status.enabled) {
> + pr_info(FW_BUG "Device [%s] status [%08x]: not present and enabled\n",
> + device->pnp.bus_id, (u32)sta);
> + device->status.enabled = 0;
> + /*
> + * The status is clearly invalid, so clear the enabled bit as
> + * well to avoid attempting to use the device.
> + */
Comment seems to be in a slightly odd place. Perhaps one line earlier makes
more sense? Or was the intent to mention functional here?
> + device->status.functional = 0;
> + }
> +
> acpi_set_device_status(device, sta);
>
> if (device->status.functional && !device->status.present) {
> Index: linux-pm/drivers/acpi/scan.c
> ===================================================================
> --- linux-pm.orig/drivers/acpi/scan.c
> +++ linux-pm/drivers/acpi/scan.c
> @@ -1962,7 +1962,7 @@ bool acpi_device_is_present(const struct
>
> bool acpi_device_is_enabled(const struct acpi_device *adev)
> {
> - return adev->status.present && adev->status.enabled;
> + return adev->status.enabled;
> }
>
> static bool acpi_scan_handler_matching(struct acpi_scan_handler *handler,
>
>
>
next prev parent reply other threads:[~2024-04-29 8:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 16:56 [PATCH v1] ACPI: scan: Avoid enumerating devices with clearly invalid _STA values Rafael J. Wysocki
2024-04-28 4:17 ` Zhang, Rui
2024-04-29 16:06 ` Rafael J. Wysocki
2024-04-29 8:29 ` Jonathan Cameron [this message]
2024-04-29 16:07 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240429092942.00004c96@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=salil.mehta@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.