Re: Weird Dell SMM bug since 6.18

[Guy Boldon <gb@guyboldon.com>]

From: gb@guyboldon.com

Hi, I'm the CoolerControl maintainer, a few notes from the userspace side.

On Mon, Mar 16, 2026 at 17:55:01 -0700, Guenter Roeck wrote:
> Not really. -ENODATA seems to be the correct response if the current pwm
> value is not readable. Returning 0 or any other number would be misleading
> and trigger other problems (such as some userspace code believing that it
> can write the value back with no impact, which would be worse).

For context: thinkpad_acpi has long returned 255 as a dummy value for pwmX
when in auto mode (pwmX_enable=2), since it similarly cannot retrieve the
real PWM value during BIOS control. This was likely motivated by fancontrol
compatibility, which AFAIR requires a readable pwmX. CoolerControl reads pwmX to
confirm a channel is functional and to track data values over time, hence why we
need it readable. We can however adapt our handling for -ENODATA.

On the write concern: several drivers I'm familiar with (e.g. nct67xx, it87,
thinkpad_acpi) do not implicitly switch to manual mode on a pwmX write.
Writing pwmX having no effect when pwmX_enable != 1 is expected, normal
behavior from our perspective.

On Tue, Mar 17, 2026 at 02:29:39 +0100, Armin Wolf wrote:
> I suspect that the successful reads happen after the pwmX attribute has
> been set manually using "cat". The driver will enter manual fan control
> mode automatically in such a case to keep compatibility with legacy
> userspace applications.

That makes sense. Might be worth noting in the docs either way.

As a related point: gpd_fan returns -EOPNOTSUPP rather than -ENODATA
when in auto mode, and documents that behavior in the kernel docs. The
inconsistency between drivers, different errors for the same condition,
means userspace ends up needing per-driver handling for the same use case.
Not ideal, but at least documentation helps.

Thanks,
Guy