Repository navigation
power: supply: macsmc-power: optionally wake on connector insertion - #323
Open
andyhennie wants to merge 1 commit into
Open
andyhennie wants to merge 1 commit into
andyhennie wants to merge 1 commit into
Conversation
andyhennie
requested review from
chriskearney,
maralcbr and
scottjones
as code owners
November 1, 2026 17:32
andyhennie
marked this pull request as draft
November 1, 2026 17:34
During s2idle the CD321x USB-PD controllers keep their interrupt line quiet, but the SMC keeps reporting connector events over its mailbox, whose interrupt is IRQF_NO_SUSPEND. The driver already receives them and only refreshes the power supplies, which is a soft wakeup event and cannot end s2idle. A closed laptop therefore does not wake when a USB-C/Thunderbolt display or dock is attached, unlike macOS. Treat a connector insertion (event 0x7113PP05, PP = port) seen between .prepare and .complete as a hard wakeup event, like macsmc-input does for the lid and power button. The device is marked wakeup capable but left disabled, so nothing changes unless userspace writes "enabled" to its power/wakeup attribute. Removal events (0x7113PP02) never wake. Observed on a MacBook Pro 16" M1 Max (J316C, t6001): a trace on the stock kernel showed no GPIO activity from the PD controllers during s2idle while the SMC delivered 0x7113xx05 on attach; with this logic (as an out-of-tree module) a display attach with the lid closed resumed the system within 10 ms of the event, and two hours of sleep with nothing attached produced no spurious wake. The wake decision is a separate helper with a KUnit suite (macsmc-power-wake) covering insertion on each port, no wake while awake, and no wake on removal, contract-change, charger or lid events. Signed-off-by: Andy Hennie <andy@ahennie.no>
andyhennie
force-pushed
the
macsmc-wake-on-connector
branch
from
November 1, 2026 17:42
799fe80 to
485643f
Compare
andyhennie
marked this pull request as ready for review
November 1, 2026 17:45
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.
Fixes #322.
While the Mac is in s2idle the PD controllers stay quiet, but the SMC keeps reporting connector events.
macsmc-poweronly answers those with a soft wakeup. This change turns a connector insertion (0x7113PP05) between.prepareand.completeinto a hard wakeup, the same waymacsmc-inputhandles the lid.It's opt-in. The device is wakeup-capable but stays disabled until userspace enables
macsmc-power/power/wakeup, since the event can't tell a charger from a display. Removals never wake.I tested the same logic as an out-of-tree module on a J316C (M1 Max). The Mac woke within about 10 ms of the event on two ports, with no spurious wakes over 15 minutes and almost two hours asleep. The wake decision has a KUnit suite (
macsmc-power-wake). The patch builds with W=1 and passes checkpatch. I haven't run KUnit or booted the in-tree build myself because my kernel doesn't have KUnit, so I'm relying on CI for that. I've only seen this on t6001.