Claude review: drm/tiny: sharp-memory: avoid transmitting stale TX buffer data

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**Analysis:** The original code always transmitted the full `smd->tx_buffer_size`:

```c
u32 tx_buffer_size = smd->tx_buffer_size;
// ...
ret = sharp_memory_spi_write(smd->spi, tx_buffer, tx_buffer_size);
```

Since `tx_buffer_size = 1 + pitch * vdisplay` (mode byte + all lines), and the buffer isn't zeroed between updates, a previous full-screen update leaves stale line entries in the buffer. When a subsequent partial update writes 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 = 1 + (drm_rect_height(&clip) * pitch);
```

This is 1 byte (mode) + dirty_lines × pitch, which is correct. Each line's `pitch` already includes `SHARP_ADDR_PERIOD + hdisplay + SHARP_DUMMY_PERIOD` divided by 8, so the trailing dummy bits for the last transmitted line 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