Skip to content

rocknix-joypad: ratelimit the saradc read-failure message - #3250

Closed
pkilar wants to merge 1 commit into
ROCKNIX:nextfrom
pkilar:joypad-ratelimit-saradc
Closed

rocknix-joypad: ratelimit the saradc read-failure message#3250
pkilar wants to merge 1 commit into
ROCKNIX:nextfrom
pkilar:joypad-ratelimit-saradc

Conversation

@pkilar

@pkilar pkilar commented Aug 30, 2026

Copy link
Copy Markdown

Summary

  • What is the goal of this PR? Stop a failing SARADC from flooding the console.

joypad_adc_check() runs from the input polling loop. When joypad_adc_read() fails it returns 0 and the driver logs at dev_err level with no ratelimiting, so a persistent ADC failure emits one line per poll — about 8 per second — for as long as the condition lasts.

On a 1.5Mbaud serial console that is a permanent stream of identical lines. It drowns out whatever actually broke, and it adds console work to a machine that by that point is usually already in trouble.

Switches the three call sites to dev_err_ratelimited(). A genuine ADC failure still gets reported; it just stops repeating thousands of times.

Testing

  • How was this tested? Built and run on a Gusgu H7 (RK3326).
  • Test results: Before, whenever the SARADC stopped answering, the console filled with tens of thousands of identical saradc channels[N]! messages — this actively hindered debugging an unrelated interrupt storm, since the useful output scrolled away. After, the message appears at the ratelimited rate and the surrounding log stays readable.

Additional Context

  • Behaviour-only change to logging; no functional path is altered, and the continue on failure is untouched.
  • dev_err_ratelimited() is the standard helper for exactly this case and is already used widely in the kernel's input drivers.
  • This touches rocknix-joypad, which is shared across device families, so it is worth a glance from someone with other hardware — but the change is confined to three log statements.

AI Usage

Did you use AI tools to help write this code? YES — Claude Code was used to trace the log flood back to the polling loop and to draft the patch and this description.

joypad_adc_check() runs from the input polling loop. When joypad_adc_read()
fails it returns 0, and the driver logs at dev_err level with no ratelimiting -
so a persistent ADC failure emits one line per poll, about 8 per second, for as
long as the condition lasts.

On a 1.5Mbaud serial console that is a permanent stream of identical lines. It
drowns out whatever actually broke, and it adds console work to a machine that
by that point is usually already in trouble. Observed on a Gusgu H7 (RK3326)
whenever the SARADC stops answering: tens of thousands of identical messages,
which actively hindered debugging an unrelated interrupt storm.

Use dev_err_ratelimited() at all three call sites.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01985tp15STZZvPFMfnVBGnm
@pkilar pkilar closed this Sep 4, 2026
@pkilar
pkilar deleted the joypad-ratelimit-saradc branch September 4, 2026 21:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants