Mask the IPCC mailbox IRQ on suspend for SM8550 too - #27
Merged
virtudude merged 1 commit intoAug 5, 2026
Conversation
0504 currently drops IRQF_NO_SUSPEND only when the IPCC node is "qcom,sm8750-ipcc", so SM8550 still requests the summary interrupt with IRQF_NO_SUSPEND and it is never masked across suspend. On SM8550 the ADSP charger firmware pushes an unsolicited BATTMGR_NOTIFICATION roughly half a second after suspend entry. With the mailbox irq unmasked that notification pulls the SoC straight back out, which upstream ROCKNIX identifies as the single biggest blocker to SM8550 staying asleep. Extend the existing compatible check to cover "qcom,sm8550-ipcc". Every other SoC keeps IRQF_NO_SUSPEND, so established behavior on the shared driver is unchanged. This is the same fix ROCKNIX merged in PR #3115, which removes the flag unconditionally; keeping armada's compatible gate preserves the existing caution for SM8250 and SM8650. No behavior change on current builds: every SM8550 device here runs ARMADA_SUSPEND_MODE=fake, so the system never reaches a real suspend where the flag matters. This is groundwork for when SM8550 suspend is enabled. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
Extends the existing IPCC suspend fix to cover SM8550. Ports ROCKNIX #3115 (merged).
What
0504dropsIRQF_NO_SUSPENDfrom the IPCC summary interrupt so it can be masked across suspend — but only when the node is"qcom,sm8750-ipcc". SM8550's node is"qcom,sm8550-ipcc", so it still requests the irq withIRQF_NO_SUSPENDand it is never masked.This adds SM8550 to that check. Every other SoC keeps
IRQF_NO_SUSPENDand is unaffected.Why
On SM8550 the ADSP charger firmware pushes an unsolicited
BATTMGR_NOTIFICATIONabout half a second after suspend entry. With the mailbox irq unmasked, that notification wakes the SoC straight back up — upstream identifies it as the single biggest blocker to SM8550 staying asleep.Any future SM8550 suspend work needs this regardless of what else it does, so it is worth having in place early.
Downsides
None that I can see:
ARMADA_SUSPEND_MODE=fake, so the system never reaches a real suspend where the flag applies.Testing
Built against 7.1.5 on an AYANEO Pocket EVO: 120 patches applied, 0 failed,
drivers/mailbox/qcom-ipcc.ocompiles clean.The wake behavior itself can't be verified on a shipping build, since SM8550 stays on fake suspend and the code path isn't reached. Upstream verified it on a Retroid Pocket 6.
🤖 Generated with Claude Code