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

[Ping-Ke Shih]

Rosen Penev <rosenp@xxxxxxxxx> wrote:
> On Tue, Nov 3, 2026 at 9:21 PM Ping-Ke Shih <pkshih@xxxxxxxxxxx> wrote:
> >
> > Rosen Penev <rosenp@xxxxxxxxx> wrote:
> > > On Tue, Nov 3, 2026 at 4:47 PM Ping-Ke Shih <pkshih@xxxxxxxxxxx> wrote:
> > > >
> > > > Rosen Penev <rosenp@xxxxxxxxx> 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.