AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 18 Bitcoin

feat(core): implementation of higher granularity of TS7 backlight.

Public commit record

What the developer wrote

Authored by bleska

85/100 · Strong
feat(core): implementation of higher granularity of TS7 backlight.

Currently, it only has 32 levels (based on TPS61062 specification). The goal is to have full API logical range of 0-255 values. 1st steps is to make DMA working in linked list mode. For debugging purposes, it's has been ported to D002 (DISC2 board).
Evaluation of HAL DMA functions in the way of safe DMA suspend/resume, deinit, etc. at TS7 HW. Adding interrupt functionality for the DMA peripheral. Result - simple demo at TS7 with DML in linked list mode
Making it work as usual at TS7 with DMA in linked list mode.

[no changelog]
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit rewrites the backlight driver for the Trezor Safe hardware wallet's display boost circuit. It changes from 32 coarse brightness steps to 256 smoother steps by using a DMA-linked-list double-buffer to stream PWM pulse widths to the LED driver chip. The change is a feature implementation, not a security fix. There are some code-quality red flags—unused return values, commented-out error handlers, TODOs, and a commented-out infinite loop on a serious error—but nothing in the commit itself demonstrates an exploitable vulnerability.

Recommended action

Treat as a normal feature commit, not a security patch. If reviewing for product safety, verify that (1) HAL_DMAEx_List return codes are checked and failures fail safe (backlight off), (2) the commented-out DMA error/abort/suspend callbacks are either enabled or replaced with safe shutdown logic, (3) the DMA not-ready branch in backlight_set has a defined safe fallback instead of a silent no-op, and (4) shared state between irq-locked foreground code and the DMA IRQ callback is race-free.

Security signals we found

01

Multiple HAL API return values are stored but not checked ((void)ret), which could mask DMA initialization or runtime failures.

02

Error, abort, and suspend DMA callbacks are defined but commented out, leaving no runtime handling for DMA errors.

03

A commented-out infinite loop was intended as the fallback when DMA is not in READY state during backlight_set.

04

The driver uses irq_lock()/irq_unlock() around shared-variable updates, but the DMA callback also touches the same volatile state without explicit synchronization analysis in the diff.

05

The commit is marked [no changelog] and framed purely as a feature, with no security claims.

Risk score

Why this scored 18/100

Our methodology →
Potential impact 4/30
Exploitability 3/25
Stealth signal 3/15
Affected reach 2/15
Confidence 4/10
Evidence quality 2/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.