From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/tiny: sharp-memory: avoid transmitting stale TX buffer data Date: Tue, 31 Mar 2026 17:34:59 +1000 Message-ID: In-Reply-To: <20260330-flickering-v1-2-5a192bf4b93d@axis.com> References: <20260330-flickering-v1-0-5a192bf4b93d@axis.com> <20260330-flickering-v1-2-5a192bf4b93d@axis.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review **Analysis:** The original code always transmitted the full `smd->tx_buffer= _size`: ```c u32 tx_buffer_size =3D smd->tx_buffer_size; // ... ret =3D sharp_memory_spi_write(smd->spi, tx_buffer, tx_buffer_size); ``` Since `tx_buffer_size =3D 1 + pitch * vdisplay` (mode byte + all lines), an= d the buffer isn't zeroed between updates, a previous full-screen update le= aves stale line entries in the buffer. When a subsequent partial update wri= tes only a few lines, the old entries are still sent, causing the panel to = overwrite correct content with stale data. The fix computes the exact transfer length: ```c u32 tx_len =3D 1 + (drm_rect_height(&clip) * pitch); ``` This is 1 byte (mode) + dirty_lines =C3=97 pitch, which is correct. Each li= ne's `pitch` already includes `SHARP_ADDR_PERIOD + hdisplay + SHARP_DUMMY_P= ERIOD` divided by 8, so the trailing dummy bits for the last transmitted li= ne are included in the transfer, satisfying the Sharp Memory LCD protocol's= requirement for a trailing dummy period. The struct field `smd->tx_buffer_size` remains used for the `devm_kzalloc` = allocation in `sharp_memory_probe()` (line 567), so it is not left dangling. **No issues.** Correct fix, good commit message with proper Fixes tag. --- Generated by Claude Code Patch Reviewer