[26.04_linux-nvidia] MediaTek MT8901 SPI/I2C ACPI power-management support

[bdintakurti-nv]

Add MediaTek MT8901 SPI and I2C ACPI power-management support.

The series:

• Adds ACPI enumeration and firmware-managed clock setup for the MediaTek SPI controller, including runtime
  autosuspend and Power Wrap coordination during runtime and system sleep.
• Adds Power Wrap lifecycle handling and noirq suspend/resume support to the existing MT8901 ACPI I2C path.
• Keeps CONFIG_SPI_MT65XX=m and CONFIG_I2C_MT65XX=m. Both are already enabled for arm64, so no config change is
  required.

Dependencies (patches intentionally NOT carried here):
MediaTek Power Wrap support: #570

This PR does not build standalone until #570 lands. Both drivers include <linux/soc/mediatek/mtk-pwrap.h> and use its
exported mtk_pwrap_dev_*() APIs.

Validation:

• Validated with the required Power Wrap changes in the integration tree.
• Kernel build and S3/s2idle suspend-resume testing completed.
• validate-pr and patchscan checks completed with no errors or missing fixes.

Launchpad bug: https://bugs.launchpad.net/ubuntu/+source/linux-nvidia-bos/+bug/2167886

[nirmoy]

BaseOS Kernel Review

Warning

⚠️ Review needs attention

The mt65xx SPI ACPI path can build without Power Wrap and then fail probe; its noirq PM callbacks also issue SCMI requests after IRQs are disabled, risking suspend/resume timeouts.

Findings: Critical 0 · High 0 · Medium 2 · Low 2

🔍 Review artifacts

• 🟠 Boro review: 4 findings
• 🔵 Test plan: ready for validation

📦 Kernel deb builds — 🟢 2/2 passed

• 🟢 amd64: build report and 4 debs
• 🟢 arm64: build report and 4 debs

Note

Build reports and debs are retained for 10 days after the PR closes.

Review metadata

• Reviewed head: e8fae81dcf70
• Overall status: attention needed
• Architectures: 2/2 successful

This comment is maintained by BaseOS Reviewer and updated when the GitHub watcher publishes a newer review.

[github-actions]

PR Validation Report

Patchscan ✅ No Missing Fixes

All cherry-picked commits checked — no missing upstream fixes found.

PR Lint ✅ All checks passed

Details

Checking 2 commits...

Cherry-pick digest:
┌──────────────┬──────────────────────────────────────────────────────────────────┬────────────┬─────────┬───────────────────────────┐
│ Local        │ Referenced upstream / Patch subject                              │ Patch-ID   │ Subject │ SoB chain                 │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ e8fae81dcf70 │ [SAUCE] i2c: mt65xx: enable suspend and resume                   │ N/A        │ N/A     │ zhang, bdintaku           │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 5658c02afdc0 │ [SAUCE] spi: mt65xx: enable acpi and power management            │ N/A        │ N/A     │ dasari, bdintaku          │
└──────────────┴──────────────────────────────────────────────────────────────────┴────────────┴─────────┴───────────────────────────┘

Lint: all checks passed.

[jamieNguyenNVIDIA]

Codex reports two functional issues:

1. mtk_spi_runtime_suspend() suppresses every Power Wrap suspend error, clears power_state, and returns success. The SSPM transport can fail before sending the D3 request, so this records the device as suspended while it remains in D0. A subsequent resume may send a duplicate D0 request, and system sleep may skip D3 entirely. Proven pre-send failures need to retain the active state and be returned to runtime PM; post-send timeout ambiguity needs an explicit reconciliation strategy.
2. mtk_spi_init_clocks_acpi() unconditionally dereferences ACPI_COMPANION(dev)->handle. This fails to compile with the valid CONFIG_ACPI=n && CONFIG_COMPILE_TEST=y && CONFIG_SPI_MT65XX=m configuration. Please guard the ACPI-only implementation or use a compile-safe accessor.

Commit hygiene also needs attention:

• Bharat Dintakurti is the committer for both commits, but each carries only the MediaTek author’s Signed-off-by. Please add the committer/carrier SoB to both commits and to both branch variants.
• The SPI commit includes extensive function-entry dev_dbg() tracing and unrelated mechanical cleanup; strict checkpatch reports 26 warnings. Please remove that noise or split it from the functional ACPI/PM change.
• The exact PR heads do not build until PR 570/571 lands. Please rebase afterward and validate the resulting exact heads.

Finally, what is the concrete upstream plan for this work—owner, target trees/lists, and expected posting date? These are substantial SAUCE changes to shared MediaTek drivers and depend on a large private SSPM/Power Wrap abstraction.

Please prioritize upstreaming, ideally beginning with an RFC for the firmware and power-management architecture. Upstream may have questions about the private SCMI transport and void * client API, hard-coded physical register writes, probe-time BestPerf policy, debug sysfs ABI, and USB4 platform-bus notifier.

[dcemin-nv]

BaseOS team, could someone create the Launchpad bug for this change (one bug for #605 and #606) so the BugLink can be added and lint goes green? Same pattern as 2166301, 2166302 and 2167235. nirmoy is out and asked for the request to be made here. Thanks.

[bdintakurti-nv]

Updated with the review fixes: added carrier sign-offs, fixed the CONFIG_ACPI=n/COMPILE_TEST path, removed
temporary debug logging and unrelated cleanup, documented the new fields, and resolved checkpatch findings.

For the SSPM timeout concern, this is the same limitation discussed for USB: the shared Power Wrap transport returns -ETIMEDOUT both when a request was not sent and when it was sent but the acknowledgment timed out. The client therefore cannot safely determine the hardware state or perform rollback.

MediaTek owns the upstreaming for these changes, I will coordinate with them for this.

[jamieNguyenNVIDIA]

Summary of remaining issues

• Medium: mtk_spi_runtime_suspend() still suppresses Power Wrap suspend failures and records
  D3 even when the transport failed before sending the request.

• Validation: Both exact PR heads still fail the arm64 build because they have not been rebased
  onto the now-landed Power Wrap dependency. Rebase and fresh exact-head validation are required.

[jamieNguyenNVIDIA]

Summary of remaining issues

The new system-resume retries address the earlier gap, and targeted builds pass on both PR heads. Codex reports four remaining issues across the equivalent patches:

• Medium — SPI: ACPI probe still registers the controller when Power Wrap setup fails.
• Medium — SPI: Runtime suspend still suppresses a D3 failure, including failures before the request is sent.
• Medium — SPI: If both D0 recovery attempts fail, remove can access MMIO while the controller may still be in D3.
• Medium — I2C: If both D0 recovery attempts fail, a later suspend can skip D3 while the controller remains in D0.

The first two remain from the previous review; the last two arise from this push.

[clsotog]

I have this finding with codex:
Power-wrap probe happens after initial I2C MMIO: drivers/i2c/busses/i2c-mt65xx.c:1651 mtk_i2c_probe() calls clk_bulk_prepare_enable() and mtk_i2c_init_hw() before mtk_i2c_pwrap_probe(). On ACPI systems, pwrap is the new mechanism that confirms/control D0/D3, so the driver can touch base/pdmabase before the controller is confirmed powered. Move pwrap probe/D0 confirmation before the initial mtk_i2c_init_hw() path.

[clsotog]

It seems like this one still not addressed: SPI runtime suspend suppresses D3 failure.
I have an extra finding:
Medium: drivers/spi/spi-mt65xx.c:1430 marks ACPI SPI controllers runtime-active after pwrap probe, then enables autosuspend at :1437-1439, but never calls pm_runtime_mark_last_busy() / pm_runtime_idle() or equivalent. With no transfer after probe, nothing schedules autosuspend, so the controller can remain in D0 indefinitely. Existing pwrap usage in mt8901 does explicitly idle after enabling runtime PM. Add an idle request after successful setup/registration.

[clsotog]

I have this medium finding:
drivers/spi/spi-mt65xx.c:1684 can leave the ACPI SPI controller pinned in D0 after a transient pwrap D3 failure. When mtk_pwrap_dev_suspend() fails and the rollback mtk_spi_runtime_resume() succeeds, the callback returns -EBUSY, leaving runtime PM active. But it does not refresh last_busy, and runtime PM only retries autosuspend on -EBUSY if the next autosuspend expiration is still in the future. At this point the prior expiration has already fired, so no new suspend attempt is queued. Add pm_runtime_mark_last_busy(dev) before returning -EBUSY, or otherwise queue a later autosuspend retry.

[jamieNguyenNVIDIA]

Findings from Codex — these apply to both #605 and #606. They are conditional transport-failure paths, not reproduced regressions. The first two may be manifestations of the same unconfirmed D0 state.

• Medium (conditional): After a failed system-suspend D3 request and unsuccessful D0 recovery, a later suspend_noirq() can skip D3 while the controller may still be in D0.
• Medium (conditional): If runtime-suspend D3 and D0 rollback both fail, runtime PM reports the device suspended although it may still be in D0. The next runtime resume does retry D0 before enabling clocks.
• Medium (conditional): If D3 repeatedly fails but D0 rollback succeeds, the new pm_runtime_mark_last_busy() can keep rearming autosuspend. Each timed-out attempt may busy-poll for about 10 seconds, with roughly 100 ms between completed attempts.

I think these are possible paths, but I’m not sure how realistic they are in practice. Do you agree with these findings, and can you comment on whether any should block an ACK?

[bdintakurti-nv]

Thanks, Jamie. I updated both PRs. Failed D0 recovery now blocks a later system suspend until D0 is confirmed. A failed D3 request gets one automatic retry, not an indefinite retry loop. If both D3 and D0 fail, the next runtime resume confirms D0 before hardware access.

[jamieNguyenNVIDIA]

Acked-by: Jamie Nguyen <jamien@nvidia.com>

[clsotog]

No more findings from me.
Acked-by: Carol L Soto <csoto@nvidia.com>

[jamieNguyenNVIDIA]

Applied to Canonical resolute main-next, on top of Ubuntu-nvidia-7.0.0-1021.22:

• e5b3b6397296 NVIDIA: SAUCE: spi: mt65xx: enable ACPI and power management
• 569049bad1cf NVIDIA: SAUCE: i2c: mt65xx: enable suspend and resume

Matched to this PR by git patch-id --stable. Closing.