linux-kernel - Re: [PATCH v2 0/6] ACPI fan

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJZ5v0gd3N_2W95=wuGdymy++0Mm5NLa8zKX8nhO4Lie83PBvQ@mail.gmail.com>
Date: Fri, 24 Oct 2025 10:35:16 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Armin Wolf <W_Armin@....de>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, lenb@...nel.org, linux-acpi@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/6] ACPI fan _DSM support

On Thu, Oct 23, 2025 at 10:13 PM Armin Wolf <W_Armin@....de> wrote:
>
> Am 23.10.25 um 21:22 schrieb Rafael J. Wysocki:
>
> > On Thu, Oct 23, 2025 at 11:59 AM Rafael J. Wysocki <rafael@...nel.org> wrote:
> >> On Wed, Oct 22, 2025 at 11:41 PM Armin Wolf <W_Armin@....de> wrote:
> >>> Am 08.10.25 um 01:41 schrieb Armin Wolf:
> >>>
> >>>> Microsoft has designed a _DSM interface for the ACPI fan device [1]
> >>>> that allows the OS to set fan speed trip points. The ACPI firmware
> >>>> will notify the ACPI fan device when said trip points are triggered.
> >>>>
> >>>> Unfortunately some device manufacturers (like HP) blindly assume that
> >>>> the OS will use this _DSM interface and thus only update the fan speed
> >>>> value returned by the _FST control method when sending a notification
> >>>> to the ACPI fan device. This results in stale fan speed values being
> >>>> reported by the ACPI fan driver [2].
> >>>>
> >>>> The first patch performs a simple cleanup in order to reduce the usage
> >>>> of the acpi_device struct. The second patch fixes an issue with some
> >>>> 64-bit ACPI implementations where an invalid value was reported
> >>>> instead of the standard ACPI placeholder value (0xFFFFFFFF). The third
> >>>> patch fixes an unrelated issue inside the hwmon support code while the
> >>>> next two patches add support for the ACPI fan notifications as
> >>>> specified in ACPI 11.2.3. The last patch finally adds support for the
> >>>> Microsoft _DSM interface.
> >>>>
> >>>> All patches where tested with a custom SSDT [3] and the acpi_call [4]
> >>>> kernel module and appear to work just fine.
> >>> Any thought on this?
> >> Not yet, but I'm going to get to it today.
> >>
> >>> I tested it with a custom SSDT, so i can prove that those patches work.
> >> OK
> > I've applied two first patches for 6.19 and the third one for 6.18-rc, as a fix.
>
> Please note that the third patch depends on the first patch! Otherwise you will
> get a runtime error when acpi_fan_hwmon_read() tries to cast the platform device
> to a ACPI device.

Ah, good to know, I've missed that dependency, thanks for pointing it out.

> > My understanding is that patches [4-5/6] are preparations for the last
> > one that needs a pointer to the MSFT documentation it is based on.
>
> I understand, i will send a v3 series without the first three patch and this
> issue being addressed.

Thanks!