vibes: harden AWINIC stop path and extend Vibe Log Info coverage#1712
Open
jplexer wants to merge 3 commits into
Open
vibes: harden AWINIC stop path and extend Vibe Log Info coverage#1712jplexer wants to merge 3 commits into
jplexer wants to merge 3 commits into
Conversation
The CONTCFG6 write result was accumulated into ret with &= before ret was ever assigned, reading an uninitialized value; the following CONTCFG7 write then overwrote ret entirely, so a failed CONTCFG6 write could never trip the assert. Assign first, then accumulate. FIRM-3361 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Joshua Jun <lets@throw.rocks>
The RAM waveform is configured with an infinite hardware loop (WAVCFG9 SEQ1 loop count = 0xF), so once vibe_ctl(true) issues GO the motor runs until a STOP sequence lands. The stop path ignored every I2C return value: a single transient I2C failure while stopping left the motor buzzing indefinitely with nothing in the logs, until the next unconditional vibe_ctl(false) - typically the user dismissing the notification (vibes_cancel). This matches the long-standing "notification vibrates endlessly until dismissed" reports. Make prv_aw862xx_play_go() report success, verify the chip actually reached standby (including after the forced-standby fallback), retry the stop once, and log an error if the motor could not be confirmed stopped. FIRM-3361 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Joshua Jun <lets@throw.rocks>
The Vibe Log Info toggle only elevated the trigger_start log, which shows a pattern started but not whether it ever ended. For the endless-notification-vibe reports the interesting question is exactly that: did the final OFF step run, and what state did the cancel path find when the user dismissed the notification. Log pattern completion and pattern clear at the same toggle-controlled level, including the live strength and dropped step count at clear time: a clear that finds the motor on with no pattern in progress is a wedged vibe. Also factor the toggle check into a VIBE_PATTERN_LOG macro. FIRM-3361 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Joshua Jun <lets@throw.rocks>
gmarull
reviewed
Jul 15, 2026
gmarull
left a comment
gmarull
left a comment
Member
There was a problem hiding this comment.
will check more in detail tomorrow
gmarull
reviewed
Jul 16, 2026
| #define AW862XX_PWR_OFF_TIME (2) /* ms */ | ||
| #define AW862XX_PWR_ON_TIME (8) /* ms */ | ||
| #define AW862XX_STOP_STANDBY_RETRIES (40) | ||
| #define AW862XX_STOP_ATTEMPTS (2) |
Member
There was a problem hiding this comment.
Unless we are 100% sure this happens, we should not add a retry (yet). I'd for now log and see if this is observed.
Member
There was a problem hiding this comment.
Did logs contain e.g. an i2c xfer error?
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
2 participants
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.
Context
FIRM-3361 (recurrence of the FIRM-1538 / FIRM-2319 "notification vibrates endlessly until dismissed" family, now seen on getafix/Android as well as obelix/iOS).
Root-cause analysis: the notification vibe path has no software repeat — only
phone_uiandalarm_popupuse repeat timers. On the AWINIC haptic drivers,vibe_ctl(true)starts an open-ended hardware drive (AW86225: RAM loop mode with SEQ1 loop count 0xF = infinite loop; AW8623X: CONT mode with max drive times), so every moment of silence depends on a timed STOP sequence over I2C. The AW86225 stop path discarded every I2C return value: one transient I2C failure while stopping leaves the motor buzzing indefinitely with nothing in the logs, until the next unconditionalvibe_ctl(false)— which is exactly what dismissing the notification does (vibes_cancel). This matches the reported symptom precisely.Changes
ret &=invibe_set_strength— a failed CONTCFG6 write could never trip the assert.prv_aw862xx_play_go()now reports success; the stop path verifies the chip reached standby (including re-checking after the forced-standby fallback, which previously fired blind), retries once, and logs an error if the motor cannot be confirmed stopped.trigger_startwith nopattern complete, then a clear reporting nonzero strength, confirms the wedge; repeatedtrigger_startlines would instead indicate a software re-trigger.Verification
getafix@dvt(AW8623X) andgetafix@dvt2(AW86225) build cleantest_vibe,test_vibe_score,test_vibe_score_info,test_vibe_intensity)FIRM-3361
🤖 Generated with Claude Code