[m0d16l14n1]

Two fixes found on J815's first deep-sleep attempts, where the MTP (keyboard and trackpad) stopped answering AP power notices and then crashed.

1. Echo OSLOG counters on T8142. The devices pm_test step passed, the MTP logged after its resume, and the next step's prepare failed: rtkit-helper 394600000.mtp: AP power notice (idle) not answered: -62. As found for T8140 (d9b438c), an RTKit firmware holds its next OSLOG counter until the last one is echoed, and takes no AP power notice while one is outstanding. T8142 still dropped them (the no-ACK policy kept for Neo/M5 from before T8140's sleep work). They are now echoed on T8142 too, as macOS does.
2. Never stack an unanswered AP idle notice. The sleep after that sent a second idle notice, and the MTP firmware asserted (RTKit: co-processor has crashed … Invalid AP power: 8), taking the keyboard and trackpad with it until a reboot. An idle notice still unanswered when its sleep ends is now kept as pending. The next sleep checks again: if the answer has come it sends the skipped AP-on first, otherwise it refuses the sleep (-EBUSY) instead of sending another notice.

Tested on J815, with our T8142 suspend-to-RAM work in progress (not upstream; it is what makes pm_suspend_via_firmware() true there, so the helper sends idle notices at all). With both commits, the pm_test ladder devices, platform, processors and core passes (9 CPUs offline/online, Timekeeping suspended for 5.009 seconds), display, disk, keyboard and trackpad back after every step, suspend_stats success 4 / fail 0, over two boots. s2idle (lid) doesn't send idle notices and is unchanged; on the plain upstream base the OSLOG echo is the only visible change (MTP counters echoed, keyboard and trackpad fine across s2idle).

Note: #1764 (T8140 MTP start/stop) reworks rtkit-helper.c next to the second commit. The two don't overlap in logic; whichever lands second needs a small rebase, and I'll do it here if that's this one.

Part of the J815 (MacBook Air 15-inch, M5, T8142) bring-up: board results are summarised in discussion #135. Tested on a J815 with a macOS 27.0 stub (firmware 27.0) through aura Stage 2.

Assisted-by: Claude Opus 5.5

[DjDeveloperr]

Reviewed. This looks good to me.

• OSLOG echo: now on for T8142 as well as T8140. Every other SoC is unchanged.
• Pending idle notice: the logic is generic, but it only changes what happens after an idle notice that stayed unanswered through a whole sleep.
  • The next firmware sleep is refused with -EBUSY instead of stacking a second notice.
  • If the answer arrived in the meantime, the skipped AP-on goes out first.
  • On platforms whose notices are answered, idle_pending is never set, so their sleeps are unchanged.
  • The refusal happens before apple_rtkit_helper_ap_power(), so idle_unanswered stays clear and the PM_POST_SUSPEND notifier does nothing extra.

Non-blocking: once idle_pending is set while the firmware is still running, every later sleep in that boot is refused. A ratelimited (or once) variant of the "still unanswered" dev_err would keep repeated attempts, such as a lid-close loop, from flooding the log.

Since the CI run, the base has moved on rtkit.c with apple_rtkit_cold_restart(). It is independent of this change and merges cleanly, but I'll update the branch for a fresh CI run before merging.

[gig3m]

If a second T8142 board helps with the suspend-to-RAM work, I can run it on a J813 (Mac17,3, 27.0 stub): a branch, the pm_test ladder, logs back.

For reference, s2idle on this J813 today (integration/aurora 5d112b1 with #1532): about 1.7 W with the lid closed, and it stays there with the ISP powered down (#1874) and the ALS stopped (#1876). So a real sleep is what the battery needs here.

Assisted-by: Claude Fable 5.2