New issue by runrin on void-packages repository https://github.com/void-linux/void-packages/issues/43120 Description: ### Is this a new report? Yes ### System Info Void 6.1.21_1 x86_64 AuthenticAMD uptodate rrrmFFFFFFF ### Package(s) Affected linux6.1-6.1.21_1 ### Does a report exist for this bug with the project's home (upstream) and/or another distro? _No response_ ### Expected behaviour should be able to send commands to `/proc/acpi/ibm/fan`. for example: `echo 'level auto' > /proc/acpi/ibm/fan` ### Actual behaviour cannot send commands to `/proc/acpi/ibm/fan` because `thinkpad_acpi.fan_control=1` is not being set correctly at boot. Immediately after a reboot: ``` # cat /etc/modprobe.d/thinkpad_acpi.conf options thinkpad_acpi fan_control=1 # cat /sys/module/thinkpad_acpi/parameters/fan_control N # echo 'level auto' > /proc/acpi/ibm/fan echo: write error: invalid argument ``` ### Steps to reproduce 1. add the kernel module thinkpad-acpi by running: `modprobe thinkpad_acpi` 2. create a file in modprobe.d that contains the line `options thinkpad_acpi fan_control=1` 3. reboot 4. run `cat /sys/module/thinkpad_acpi/parameters/fan_control`. it will be incorrectly set to `N` --- running `rmmod thinkpad_acpi`, then `modprobe thinkpad_acpi` to remove and add the module fixes the issue. when re-added the module gets the parameter from any file in `/etc/modprobe.d/*` like this: ``` # cat /etc/modprobe.d/thinkpad_acpi.conf options thinkpad_acpi fan_control=1 # cat /sys/module/thinkpad_acpi/parameters/fan_control N # cat /proc/acpi/ibm/fan status: enabled speed: 3900 level: auto # rmmod thinkpad_acpi # modprobe thinkpad_acpi # cat /sys/module/thinkpad_acpi/parameters/fan_control Y # cat /proc/acpi/ibm/fan status: enabled speed: 3900 level: auto commands: level ( is 0-7, auto, disengaged, full-speed) commands: enable, disable commands: watchdog ( is 0 (off), 1-120 (seconds)) ``` adding `thinkpad_acpi.fan_control=1` to the kernel command line also fixes the problem and it will be set correctly on boot. --- i first noticed this issue with 6.1.20_1 and initially reported it [here](https://bugzilla.kernel.org/show_bug.cgi?id=217225).