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 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.

> 
> 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?