Re: [RFC PATCH v2] platform/x86: panasonic-laptop: add fan speed mode for newer models

[Ilpo Järvinen]

On Wed, 10 Jun 2026, Alex Yeo wrote:

> I have a CF-SR4 and Linux works out of the box. Compared to
> previous models, this one seems to have the fans running at high speed
> by default when the computer starts.
> 
> When Windows 11 is booted up, the high fan speeds persist just until the
> login screen. Once the login screen shows up, the fan spins down.
> 
> I had suspected that this might be the laptop ramping down the fans when
> the OS declares that it is Windows but this does not seem to be the
> case.
> 
> After analyzing the DSDT and SSDT of the computer, I have found the
> following:
> 
> File ssdt10.dsl under \_SB.PC00.LPCB.EC0:
> 
> Name (CEFM, Zero)
> Method (SEFM, 1, Serialized)
> {
>     CEFM = Arg0
>     REFM ()
> }
> 
> Method (REFM, 0, Serialized)
> {
>     If ((\S0IX == 0x03))
>     {
>         Local0 = 0x05
>     }
>     ElseIf ((CEFM == Zero))
>     {
>         Local0 = Zero
>     }
>     Else
>     {
>         Local0 = 0x02
>     }
> 
>     \_SB.PC00.LPCB.EC0.EC88 (0xB5, 0x79, Local0, Zero)
> }
> 
> \_SB.PC00.LPCB.EC0.CEFM would seem be the current value
> for the fan profile. On startup, this is set to 0.
> 
> Based on the code SEFM seems the be the method to set the fan
> profile and REFM is executed right after.
> 
> I don't have access to information as to what the argument officially
> means but based on testing, any number above zero makes the fans spin
> down and behave like the older models where it stops or runs at low
> speed when its cool and ramps up when the processor gets hot.
> 
> The only relevant values for CEFM seem to be just 0 and any number above
> that just gets treated the same. I personally use just 0 and 1.
> 0 seems to be the high fan speed mode and 1 makes it behave like
> Windows.
> 
> Giving 0 as an argument reverts the fan back to the way it was during
> startup where the lowest fan speed is quite high and when load is
> applied, it seems to ramp up to an even higher speed which I think would
> be its 100%.
> 
> A value of 1 seems to have its max speed capped lower than 0.
> 
> For both modes, fan management is still automatic.
> 
> fan_mode only shows up in sysfs only if \_SB.PC00.LPCB.EC0.CEFM and
> \_SB.PC00.LPCB.EC0.SEFM are both present which should mean it should not
> show up on unsupported models. I have tried not hiding it and it just
> outputs a generic error when the value is read.
> 
> I also saw that variables such as eco_mode are kept in memory, however
> for fan_mode I rely on getting and setting the value via ACPI.
> 
> Signed-off-by: Alex Yeo <alexyeo362@xxxxxxxxx>
> ---
> Thank you for taking the time to read the patch and give feedback.
> 
> I have revised the patch according to the comments.
> 
> However, for some parts I would like to clarify the following:
> 
> >Include for pr_err() is missing it seems.
> >This file seems to be lacking sysfs.h, please add the include now.
> 
> For both pr_err() and sysfs.h they should be included as both are
> referenced/used multiple times within the same file.

I know those are pre-existing problems. But they are still missing as 
direct includes and only become included indirectly through some other
header which is fragile if somebody wants to refactor those headers.

Thus, you should simply add the missing includes finally now when you add 
more code that uses stuff from those includes.

Obviously it would have been better to have the includes right from the 
beginning but we lack automatic tools to detect that and human reviewers 
are very fallible in checking them.

> >kstrtouint()?
> 
> It takes in input via sysfs
> something like:
> $ echo 1 | sudo tee "/sys/devices/LNXSYSTM:00/LNXSYBUS:00/MAT0019:00/fan_mode"
> and based on the other functions within the same file, the input
> is expected to be a string which is converted into an int via kstrtouint()
> as CEFM is an int

So what happens if you do echo -1 instead? Your changelog only talked 
about positive values.

It may well be other sysfs functions could use unsigned conversion variant 
too (I've not checked), but here you're adding new interface and it should 
be designed the best way possible. If negative numbers are not valid 
input, kstrtouint() does check that for you for free so why not use it?

Also, please leave more context visible next time when replying, I had to 
look it up from the other mail!

> >But I'm unsure whether sysfs is right place for this interface. acer-wmi
> >driver seems to have fan mode auto/turbo selection using hwmon interface
> >but this driver doesn't have hwmon as is...
> 
> I do get what you mean. My personal goal is to have this work smoothly
> with software like thermald as the vendor appears to use Intel Dynamic
> Tuning Technology with non-standard ACPI methods to control the fan.
> I will take a look into that and see if exposing the control via a
> different way works better.
> 
> To summarize, it appears the OS calls SEFM to let the EC know the OS
> has taken control of the fan. The fan then spins down until
> it stops completely (level 0). This then allows the OS to set
> the fan level from 0 to 100. If the processor gets too hot,
> the EC intervenes and ramps up the fan.

Sounds like pwm control to me. (Though, you haven't exactly described how 
that 0-100 control is done in OS but only about getting it to spin at low 
speed to match the speed user/you expected.)

> >From what I can gather, when running Windows, the vendor's driver
> together with Intel DTT work together to control the fan.
> 
> Given this, I would like to ask what is the most appropriate
> place in the kernel to expose this functionality?
> I understand that hwmon was mentioned but I also see that
> interacting with /sys/class/thermal may also be an option.

Can we somehow read how fast the fan currently spins so the information 
could be exposed through hwmon?

You may want to look more information about hwmon and pwm as to me it 
sounds pretty a good match to the fan control (based on your explanation 
about about OS controlling fan speed in 0-100 range).

-- 
 i.