drivers/acpi/fan.h | 47 +++++++- drivers/acpi/fan_attr.c | 2 +- drivers/acpi/fan_core.c | 254 ++++++++++++++++++++++++++++++++++++--- drivers/acpi/fan_hwmon.c | 32 ++--- 4 files changed, 302 insertions(+), 33 deletions(-)
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. [1] https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/design-guide [2] https://github.com/lm-sensors/lm-sensors/issues/506 [3] https://github.com/Wer-Wolf/acpi-fan-ssdt/blob/master/ssdt-dsm.asl [4] https://github.com/nix-community/acpi_call Changes since v1: - use acpi_evaluate_dsm_typed() during _DSM initialization - send ACPI netlink event when after handling a ACPI notification Armin Wolf (6): ACPI: fan: Use ACPI handle when retrieving _FST ACPI: fan: Workaround for 64-bit firmware bug ACPI: fan: Use platform device for devres-related actions ACPI: fan: Add basic notification support ACPI: fan: Add hwmon notification support ACPI: fan: Add support for Microsoft fan extensions drivers/acpi/fan.h | 47 +++++++- drivers/acpi/fan_attr.c | 2 +- drivers/acpi/fan_core.c | 254 ++++++++++++++++++++++++++++++++++++--- drivers/acpi/fan_hwmon.c | 32 ++--- 4 files changed, 302 insertions(+), 33 deletions(-) -- 2.39.5
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? I tested it with a custom SSDT, so i can prove that those patches work. Thanks, Armin Wolf > [1] https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/design-guide > [2] https://github.com/lm-sensors/lm-sensors/issues/506 > [3] https://github.com/Wer-Wolf/acpi-fan-ssdt/blob/master/ssdt-dsm.asl > [4] https://github.com/nix-community/acpi_call > > Changes since v1: > - use acpi_evaluate_dsm_typed() during _DSM initialization > - send ACPI netlink event when after handling a ACPI notification > > Armin Wolf (6): > ACPI: fan: Use ACPI handle when retrieving _FST > ACPI: fan: Workaround for 64-bit firmware bug > ACPI: fan: Use platform device for devres-related actions > ACPI: fan: Add basic notification support > ACPI: fan: Add hwmon notification support > ACPI: fan: Add support for Microsoft fan extensions > > drivers/acpi/fan.h | 47 +++++++- > drivers/acpi/fan_attr.c | 2 +- > drivers/acpi/fan_core.c | 254 ++++++++++++++++++++++++++++++++++++--- > drivers/acpi/fan_hwmon.c | 32 ++--- > 4 files changed, 302 insertions(+), 33 deletions(-) >
On Wed, Oct 22, 2025 at 11:41 PM Armin Wolf <W_Armin@gmx.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
On Thu, Oct 23, 2025 at 11:59 AM Rafael J. Wysocki <rafael@kernel.org> wrote: > > On Wed, Oct 22, 2025 at 11:41 PM Armin Wolf <W_Armin@gmx.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. 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.
Am 23.10.25 um 21:22 schrieb Rafael J. Wysocki: > On Thu, Oct 23, 2025 at 11:59 AM Rafael J. Wysocki <rafael@kernel.org> wrote: >> On Wed, Oct 22, 2025 at 11:41 PM Armin Wolf <W_Armin@gmx.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. > 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, Armin Wolf
On Thu, Oct 23, 2025 at 10:13 PM Armin Wolf <W_Armin@gmx.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@kernel.org> wrote: > >> On Wed, Oct 22, 2025 at 11:41 PM Armin Wolf <W_Armin@gmx.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!
© 2016 - 2026 Red Hat, Inc.