[PATCH rtw-next v2] wifi: rtw89: acpi: check for _DSM function support before evaluating it

[PATCH rtw-next v2] wifi: rtw89: acpi: check for _DSM function support before evaluating it

[Rosen Penev]

When the WiFi device has no ACPI companion, or the firmware does not
implement a given rtw89 _DSM function, rtw89_acpi_evaluate_dsm() calls
acpi_evaluate_dsm() anyway. ACPI core then warns on every probe:

  ACPI: \: failed to evaluate _DSM e8c3a8d2-694b-004f-82bd-fe8607803aa7 rev:0 func:10 (0x1001)
  ACPI: \: failed to evaluate _DSM e8c3a8d2-694b-004f-82bd-fe8607803aa7 rev:0 func:6 (0x1001)

Here the handle is NULL, and acpi_evaluate_object() returns
AE_BAD_PARAMETER. All callers already treat failure as "no policy
provided by the platform", so this is only noise.

Bail out early when there is no ACPI handle, as acpi_check_dsm() would
otherwise hit the same warning while querying function 0. Then use
acpi_check_dsm() so that functions the firmware does not advertise fail
quietly at debug level, as rtw89_acpi_evaluate_method() already does.

Seen on an RTL8852BE in a desktop PCIe slot.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 v2: check handle separately. Remove Fixes.
 drivers/net/wireless/realtek/rtw89/acpi.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtw89/acpi.c b/drivers/net/wireless/realtek/rtw89/acpi.c
index ebb6cf555747..3396d42594b3 100644
--- a/drivers/net/wireless/realtek/rtw89/acpi.c
+++ b/drivers/net/wireless/realtek/rtw89/acpi.c
@@ -372,11 +372,22 @@ int rtw89_acpi_evaluate_dsm(struct rtw89_dev *rtwdev,
 			    enum rtw89_acpi_dsm_func func,
 			    struct rtw89_acpi_dsm_result *res)
 {
+	acpi_handle handle = ACPI_HANDLE(rtwdev->dev);
 	union acpi_object *obj;
 	int ret;
 
-	obj = acpi_evaluate_dsm(ACPI_HANDLE(rtwdev->dev), &rtw89_guid,
-				0, func, NULL);
+	if (!handle) {
+		rtw89_debug(rtwdev, RTW89_DBG_ACPI, "acpi dsm no handle\n");
+		return -ENODEV;
+	}
+
+	if (!acpi_check_dsm(handle, &rtw89_guid, 0, BIT(func))) {
+		rtw89_debug(rtwdev, RTW89_DBG_ACPI,
+			    "acpi dsm func %d not supported\n", func);
+		return -ENOENT;
+	}
+
+	obj = acpi_evaluate_dsm(handle, &rtw89_guid, 0, func, NULL);
 	if (!obj) {
 		rtw89_debug(rtwdev, RTW89_DBG_ACPI,
 			    "acpi dsm fail to evaluate func: %d\n", func);
-- 
2.56.0

RE: [PATCH rtw-next v2] wifi: rtw89: acpi: check for _DSM function support before evaluating it

[Ping-Ke Shih]

Rosen Penev <rosenp@gmail.com> wrote:
> When the WiFi device has no ACPI companion, or the firmware does not
> implement a given rtw89 _DSM function, rtw89_acpi_evaluate_dsm() calls
> acpi_evaluate_dsm() anyway. ACPI core then warns on every probe:
> 
>   ACPI: \: failed to evaluate _DSM e8c3a8d2-694b-004f-82bd-fe8607803aa7 rev:0 func:10 (0x1001)
>   ACPI: \: failed to evaluate _DSM e8c3a8d2-694b-004f-82bd-fe8607803aa7 rev:0 func:6 (0x1001)
> 
> Here the handle is NULL, and acpi_evaluate_object() returns
> AE_BAD_PARAMETER. All callers already treat failure as "no policy
> provided by the platform", so this is only noise.
> 
> Bail out early when there is no ACPI handle, as acpi_check_dsm() would
> otherwise hit the same warning while querying function 0. Then use
> acpi_check_dsm() so that functions the firmware does not advertise fail
> quietly at debug level, as rtw89_acpi_evaluate_method() already does.

Adding this check is fine to me. But my question in v1 is that 
acpi_check_dsm() checks func 0 to determine if BIT(func) is existing.
Is it possible func 0 not existing, but BIT(func) existing?

> 
> Seen on an RTL8852BE in a desktop PCIe slot.
> 
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
>  v2: check handle separately. Remove Fixes.
>  drivers/net/wireless/realtek/rtw89/acpi.c | 15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtw89/acpi.c b/drivers/net/wireless/realtek/rtw89/acpi.c
> index ebb6cf555747..3396d42594b3 100644
> --- a/drivers/net/wireless/realtek/rtw89/acpi.c
> +++ b/drivers/net/wireless/realtek/rtw89/acpi.c
> @@ -372,11 +372,22 @@ int rtw89_acpi_evaluate_dsm(struct rtw89_dev *rtwdev,
>                             enum rtw89_acpi_dsm_func func,
>                             struct rtw89_acpi_dsm_result *res)
>  {
> +       acpi_handle handle = ACPI_HANDLE(rtwdev->dev);
>         union acpi_object *obj;
>         int ret;
> 
> -       obj = acpi_evaluate_dsm(ACPI_HANDLE(rtwdev->dev), &rtw89_guid,
> -                               0, func, NULL);
> +       if (!handle) {
> +               rtw89_debug(rtwdev, RTW89_DBG_ACPI, "acpi dsm no handle\n");
> +               return -ENODEV;
> +       }
> +
> +       if (!acpi_check_dsm(handle, &rtw89_guid, 0, BIT(func))) {
> +               rtw89_debug(rtwdev, RTW89_DBG_ACPI,
> +                           "acpi dsm func %d not supported\n", func);
> +               return -ENOENT;
> +       }
> +
> +       obj = acpi_evaluate_dsm(handle, &rtw89_guid, 0, func, NULL);
>         if (!obj) {
>                 rtw89_debug(rtwdev, RTW89_DBG_ACPI,
>                             "acpi dsm fail to evaluate func: %d\n", func);
> --
> 2.56.0

Re: [PATCH rtw-next v2] wifi: rtw89: acpi: check for _DSM function support before evaluating it

[Rosen Penev]

On Tue, Nov 3, 2026 at 4:47 PM Ping-Ke Shih <pkshih@realtek.com> wrote:
>
> Rosen Penev <rosenp@gmail.com> wrote:
> > When the WiFi device has no ACPI companion, or the firmware does not
> > implement a given rtw89 _DSM function, rtw89_acpi_evaluate_dsm() calls
> > acpi_evaluate_dsm() anyway. ACPI core then warns on every probe:
> >
> >   ACPI: \: failed to evaluate _DSM e8c3a8d2-694b-004f-82bd-fe8607803aa7 rev:0 func:10 (0x1001)
> >   ACPI: \: failed to evaluate _DSM e8c3a8d2-694b-004f-82bd-fe8607803aa7 rev:0 func:6 (0x1001)
> >
> > Here the handle is NULL, and acpi_evaluate_object() returns
> > AE_BAD_PARAMETER. All callers already treat failure as "no policy
> > provided by the platform", so this is only noise.
> >
> > Bail out early when there is no ACPI handle, as acpi_check_dsm() would
> > otherwise hit the same warning while querying function 0. Then use
> > acpi_check_dsm() so that functions the firmware does not advertise fail
> > quietly at debug level, as rtw89_acpi_evaluate_method() already does.
>
> Adding this check is fine to me. But my question in v1 is that
> acpi_check_dsm() checks func 0 to determine if BIT(func) is existing.
> Is it possible func 0 not existing, but BIT(func) existing?
Shouldn't happen, but who knows.  I can drop the acpi_check_dsm() part.

7bf2dfccc2dd70821104d15cbab7b6fca21872be

is effectively the same as this.

Note that this specific card was taken out of a laptop and placed in a
desktop, hence the warning.
>
> >
> > Seen on an RTL8852BE in a desktop PCIe slot.
> >
> > Signed-off-by: Rosen Penev <rosenp@gmail.com>
> > ---
> >  v2: check handle separately. Remove Fixes.
> >  drivers/net/wireless/realtek/rtw89/acpi.c | 15 +++++++++++++--
> >  1 file changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtw89/acpi.c b/drivers/net/wireless/realtek/rtw89/acpi.c
> > index ebb6cf555747..3396d42594b3 100644
> > --- a/drivers/net/wireless/realtek/rtw89/acpi.c
> > +++ b/drivers/net/wireless/realtek/rtw89/acpi.c
> > @@ -372,11 +372,22 @@ int rtw89_acpi_evaluate_dsm(struct rtw89_dev *rtwdev,
> >                             enum rtw89_acpi_dsm_func func,
> >                             struct rtw89_acpi_dsm_result *res)
> >  {
> > +       acpi_handle handle = ACPI_HANDLE(rtwdev->dev);
> >         union acpi_object *obj;
> >         int ret;
> >
> > -       obj = acpi_evaluate_dsm(ACPI_HANDLE(rtwdev->dev), &rtw89_guid,
> > -                               0, func, NULL);
> > +       if (!handle) {
> > +               rtw89_debug(rtwdev, RTW89_DBG_ACPI, "acpi dsm no handle\n");
> > +               return -ENODEV;
> > +       }
> > +
> > +       if (!acpi_check_dsm(handle, &rtw89_guid, 0, BIT(func))) {
> > +               rtw89_debug(rtwdev, RTW89_DBG_ACPI,
> > +                           "acpi dsm func %d not supported\n", func);
> > +               return -ENOENT;
> > +       }
> > +
> > +       obj = acpi_evaluate_dsm(handle, &rtw89_guid, 0, func, NULL);
> >         if (!obj) {
> >                 rtw89_debug(rtwdev, RTW89_DBG_ACPI,
> >                             "acpi dsm fail to evaluate func: %d\n", func);
> > --
> > 2.56.0
>

RE: [PATCH rtw-next v2] wifi: rtw89: acpi: check for _DSM function support before evaluating it

[Ping-Ke Shih]

Rosen Penev <rosenp@gmail.com> wrote:
> On Tue, Nov 3, 2026 at 4:47 PM Ping-Ke Shih <pkshih@realtek.com> wrote:
> >
> > Rosen Penev <rosenp@gmail.com> wrote:
> > > When the WiFi device has no ACPI companion, or the firmware does not
> > > implement a given rtw89 _DSM function, rtw89_acpi_evaluate_dsm() calls
> > > acpi_evaluate_dsm() anyway. ACPI core then warns on every probe:
> > >
> > >   ACPI: \: failed to evaluate _DSM e8c3a8d2-694b-004f-82bd-fe8607803aa7 rev:0 func:10 (0x1001)
> > >   ACPI: \: failed to evaluate _DSM e8c3a8d2-694b-004f-82bd-fe8607803aa7 rev:0 func:6 (0x1001)
> > >
> > > Here the handle is NULL, and acpi_evaluate_object() returns
> > > AE_BAD_PARAMETER. All callers already treat failure as "no policy
> > > provided by the platform", so this is only noise.
> > >
> > > Bail out early when there is no ACPI handle, as acpi_check_dsm() would
> > > otherwise hit the same warning while querying function 0. Then use
> > > acpi_check_dsm() so that functions the firmware does not advertise fail
> > > quietly at debug level, as rtw89_acpi_evaluate_method() already does.
> >
> > Adding this check is fine to me. But my question in v1 is that
> > acpi_check_dsm() checks func 0 to determine if BIT(func) is existing.
> > Is it possible func 0 not existing, but BIT(func) existing?
> Shouldn't happen, but who knows.  

I don't mind taking this patch, but this is the only one point I don't know.

> I can drop the acpi_check_dsm() part.

If you drop the part, what will this patch do? almost nothing.

> 
> 7bf2dfccc2dd70821104d15cbab7b6fca21872be
> 
> is effectively the same as this.

Since rtw89_acpi_evaluate_dsm() is called at probe stage, I don't mind
acpi_check_dsm() being called on every call.

> 
> Note that this specific card was taken out of a laptop and placed in a
> desktop, hence the warning.

So, the warnings really bother you?

Re: [PATCH rtw-next v2] wifi: rtw89: acpi: check for _DSM function support before evaluating it

[Rosen Penev]

On Tue, Nov 3, 2026 at 9:21 PM Ping-Ke Shih <pkshih@realtek.com> wrote:
>
> Rosen Penev <rosenp@gmail.com> wrote:
> > On Tue, Nov 3, 2026 at 4:47 PM Ping-Ke Shih <pkshih@realtek.com> wrote:
> > >
> > > Rosen Penev <rosenp@gmail.com> wrote:
> > > > When the WiFi device has no ACPI companion, or the firmware does not
> > > > implement a given rtw89 _DSM function, rtw89_acpi_evaluate_dsm() calls
> > > > acpi_evaluate_dsm() anyway. ACPI core then warns on every probe:
> > > >
> > > >   ACPI: \: failed to evaluate _DSM e8c3a8d2-694b-004f-82bd-fe8607803aa7 rev:0 func:10 (0x1001)
> > > >   ACPI: \: failed to evaluate _DSM e8c3a8d2-694b-004f-82bd-fe8607803aa7 rev:0 func:6 (0x1001)
> > > >
> > > > Here the handle is NULL, and acpi_evaluate_object() returns
> > > > AE_BAD_PARAMETER. All callers already treat failure as "no policy
> > > > provided by the platform", so this is only noise.
> > > >
> > > > Bail out early when there is no ACPI handle, as acpi_check_dsm() would
> > > > otherwise hit the same warning while querying function 0. Then use
> > > > acpi_check_dsm() so that functions the firmware does not advertise fail
> > > > quietly at debug level, as rtw89_acpi_evaluate_method() already does.
> > >
> > > Adding this check is fine to me. But my question in v1 is that
> > > acpi_check_dsm() checks func 0 to determine if BIT(func) is existing.
> > > Is it possible func 0 not existing, but BIT(func) existing?
> > Shouldn't happen, but who knows.
>
> I don't mind taking this patch, but this is the only one point I don't know.
>
> > I can drop the acpi_check_dsm() part.
>
> If you drop the part, what will this patch do? almost nothing.
The !handle check is the big one that silences it.
>
> >
> > 7bf2dfccc2dd70821104d15cbab7b6fca21872be
> >
> > is effectively the same as this.
>
> Since rtw89_acpi_evaluate_dsm() is called at probe stage, I don't mind
> acpi_check_dsm() being called on every call.
>
> >
> > Note that this specific card was taken out of a laptop and placed in a
> > desktop, hence the warning.
>
> So, the warnings really bother you?
Yeah why not.
>
>
>

RE: [PATCH rtw-next v2] wifi: rtw89: acpi: check for _DSM function support before evaluating it

[Ping-Ke Shih]

Rosen Penev <rosenp@gmail.com> wrote:
> On Tue, Nov 3, 2026 at 9:21 PM Ping-Ke Shih <pkshih@realtek.com> wrote:
> >
> > Rosen Penev <rosenp@gmail.com> wrote:
> > > On Tue, Nov 3, 2026 at 4:47 PM Ping-Ke Shih <pkshih@realtek.com> wrote:
> > > >
> > > > Rosen Penev <rosenp@gmail.com> wrote:
> > > > > When the WiFi device has no ACPI companion, or the firmware does not
> > > > > implement a given rtw89 _DSM function, rtw89_acpi_evaluate_dsm() calls
> > > > > acpi_evaluate_dsm() anyway. ACPI core then warns on every probe:
> > > > >
> > > > >   ACPI: \: failed to evaluate _DSM e8c3a8d2-694b-004f-82bd-fe8607803aa7 rev:0 func:10 (0x1001)
> > > > >   ACPI: \: failed to evaluate _DSM e8c3a8d2-694b-004f-82bd-fe8607803aa7 rev:0 func:6 (0x1001)
> > > > >
> > > > > Here the handle is NULL, and acpi_evaluate_object() returns
> > > > > AE_BAD_PARAMETER. All callers already treat failure as "no policy
> > > > > provided by the platform", so this is only noise.
> > > > >
> > > > > Bail out early when there is no ACPI handle, as acpi_check_dsm() would
> > > > > otherwise hit the same warning while querying function 0. Then use
> > > > > acpi_check_dsm() so that functions the firmware does not advertise fail
> > > > > quietly at debug level, as rtw89_acpi_evaluate_method() already does.
> > > >
> > > > Adding this check is fine to me. But my question in v1 is that
> > > > acpi_check_dsm() checks func 0 to determine if BIT(func) is existing.
> > > > Is it possible func 0 not existing, but BIT(func) existing?
> > > Shouldn't happen, but who knows.
> >
> > I don't mind taking this patch, but this is the only one point I don't know.
> >
> > > I can drop the acpi_check_dsm() part.
> >
> > If you drop the part, what will this patch do? almost nothing.
> The !handle check is the big one that silences it.

I'm not aware of that. Let's do this only by v3.