What
On 2026-05-03 the worst UART offenders in drivers/ufs/core/ufshcd.c, drivers/ufs/host/ufs-exynos.c, and drivers/phy/samsung/phy-gs101-ufs.c got bulk-converted from dev_info(...) to dev_dbg(...) (commit dcefb14acacf). Without that change each boot dumps ~700 KB of UART output = ~70s of throttle alone at 115200 baud, masking real boot time and the kmscon login prompt.
The worst single offender was ufs-cmd-issue in ufshcd_send_command() — fires per SCSI submission at ~110 bytes/line.
Why this is interim, not final
The instrumentation was load-bearing while we didn't know what was breaking. Once root causes were nailed down (terminator-fix, GSA mailbox shim, post-PMC misplaced writes, three cal-if walk fixes, FMPSECURITY0.DESCTYPE=0), the prints became pure noise.
dev_info → dev_dbg is silent unless dyndbg= cmdline or sysfs control re-enables them — so the data stays available for debugging while shipping defaults are quiet. But this is a quick "shut it up" sweep, not the upstream-quality state.
What needs to happen before upstream
- Keep
dev_warn / dev_err for actual error paths
- Drop
dev_info for routine link-up state (delete, don't downgrade to dev_dbg)
- Delete the dump helpers entirely, OR guard them behind a Kconfig debug option
- Audit
phy-gs101-ufs.c cdr-lock instrumentation specifically — added during dl_err 0x80000002 chase, can probably go entirely
Tracked patches affected
Affects upstream-patches/0012-ufs-phy-gs201-silence-debug-instrumentation-dev_info.patch in particular, but most of the 0001-0012 series carries some debug residue.
What
On 2026-05-03 the worst UART offenders in
drivers/ufs/core/ufshcd.c,drivers/ufs/host/ufs-exynos.c, anddrivers/phy/samsung/phy-gs101-ufs.cgot bulk-converted fromdev_info(...)todev_dbg(...)(commitdcefb14acacf). Without that change each boot dumps ~700 KB of UART output = ~70s of throttle alone at 115200 baud, masking real boot time and the kmscon login prompt.The worst single offender was
ufs-cmd-issueinufshcd_send_command()— fires per SCSI submission at ~110 bytes/line.Why this is interim, not final
The instrumentation was load-bearing while we didn't know what was breaking. Once root causes were nailed down (terminator-fix, GSA mailbox shim, post-PMC misplaced writes, three cal-if walk fixes, FMPSECURITY0.DESCTYPE=0), the prints became pure noise.
dev_info → dev_dbgis silent unlessdyndbg=cmdline or sysfs control re-enables them — so the data stays available for debugging while shipping defaults are quiet. But this is a quick "shut it up" sweep, not the upstream-quality state.What needs to happen before upstream
dev_warn/dev_errfor actual error pathsdev_infofor routine link-up state (delete, don't downgrade to dev_dbg)phy-gs101-ufs.ccdr-lock instrumentation specifically — added during dl_err 0x80000002 chase, can probably go entirelyTracked patches affected
Affects upstream-patches/0012-ufs-phy-gs201-silence-debug-instrumentation-dev_info.patch in particular, but most of the 0001-0012 series carries some debug residue.