Repository navigation
hwmon: macsmc: Unlock fan control on firmware that keeps fans in system mode - #512
Merged
RyanTheTide merged 1 commit intoOct 27, 2026
Conversation
…em mode On the M4 Pro MacBook Pro (J616s) both fans start in mode 3, the firmware's own fan policy, and the SMC refuses the manual mode write of the fan_control path with an error, so fan control from Linux did nothing. Public reports for M4 describe the same refusal and the Ftst key that releases the fans to the OS. When userspace first asks for a target on a fan whose mode write is refused while it reads mode 3, set Ftst, wait for the fan to leave system mode and ask again. When the last manual fan goes back to auto, clear Ftst and wait for every fan to return to mode 3. Firmware that takes the mode write directly keeps the mode 0 restore; firmware that refuses it without an Ftst key gets the error as before. Hand every manual fan back on unbind or remove, at shutdown and before suspend, and whenever a write in the sequence fails. Targets are now clamped to the fan's minimum and maximum instead of refused, so a target can never go below the minimum. Everything stays behind the existing fan_control parameter; without it nothing is written. The new KUnit suite models locked and legacy firmware. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Contributor
Author
|
Final head for batching: bc03706 (t-3207 batch1). The J616s hardware test runs in the batch1 boot through reports/j616s-sensors-20261027/fan-ftst-test.sh (sha256 9e892ecc...), called by artifacts/m4pro-mesa-tip-20261026/batch1-fantest.sh. Results will be posted here. |
RyanTheTide
marked this pull request as ready for review
October 27, 2026 14:14
erikwb
pushed a commit
to erikwb/linux
that referenced
this pull request
Oct 28, 2026
…ora-silicon#518, aurora-silicon#516, aurora-silicon#519 and aurora-silicon#451 This is the tree of the J616s test kernel 7.3.0-aurora-j616s-batch5, built from these parents: - wip/j616s-batch1-20261027 (e1a25b5): the J616s bring-up series - integration/aurora 647f084 (includes aurora-silicon#498, aurora-silicon#512, aurora-silicon#523 and DJ's G17 merges) - aurora-silicon#518 ad14f2d: 25G83 tiler growth fix (Jonathan Goyvaerts) - aurora-silicon#516 31340ab: T6040 two-lane DP pin D beside USB3 - aurora-silicon#519 d769aaf: tipd reconcile of firmware-entered J616s DP Alt Mode - aurora-silicon#451 0d43a7f: J616s external displays (František Balázsy) Resolution notes: - aurora-silicon#451's display code supersedes the older aurora-silicon#451 copy carried by batch1, including its desktop 26.6 adaptive sync. Batch1's callback guard, ProMotion presentation timestamps, minRR=0 restore and swap watchdog stay. - The display gate finds a Type-C route's PHY by its typecN name, so aurora-silicon#451's dcpext0 route@0 is not enabled on a tether whose ATC0 PHY is disabled. - aurora-silicon#516's pin D and aurora-silicon#519's tipd reconcile are kept as in the J616s series. Batch2's selftest fixture reconcile for the G17 owner and CLPC fixtures is part of this tree. Tested on the J616s with the follow-up commits: boots with 0 WARN, external display at 1920x1080@180 through DP Alt Mode, 20/20 mode switches and 15/15 DPMS cycles with no new kernel errors. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Makes the existing
fan_controlpath work on the J616s (M4 Pro MacBook Pro 16). The firmware keeps both fans in its own mode 3 and refuses the driver's manual-mode write with-EIO.Behaviour:
Ftst, waits for the fan to leave mode 3, then asks for manual mode again. It gives up after 10 s.Ftstgoes back to 0 and the driver waits for every fan to return to mode 3.Ftstkey still gets the error, and nothing else is written..shutdown), before suspend, and whenever any write in the sequence fails.-EINVAL, and 0 means auto.fan_control=1nothing is written. There are no new parameters.Tests:
macsmc-hwmon-fan(6 cases) on a model of locked and legacy firmware. With macsmc-parser and macsmc-hwmon that is 17/17 passing on arm64 qemu.reports/j616s-sensors-20261027/NEO-REBOOT-REQUEST.md. The Neo has no fan nodes, so the new code writes nothing there.The J616s test kernel also carries #511 (GPU zones at 101 C). That PR's gpubench/CTS comparison is pending with the measurement agent.
🤖 Generated with Claude Code