From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: Re: [PATCH] staging: fbtft: fb_ra8875: replace udelays with usleep_range Date: Fri, 27 Feb 2026 12:43:24 +1000 Message-ID: In-Reply-To: <2026022515-booth-silent-f3bd@gregkh> References: <2026022515-booth-silent-f3bd@gregkh> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Overall Series Review Subject: Re: [PATCH] staging: fbtft: fb_ra8875: replace udelays with usleep= _range Author: Greg KH Patches: 5 Reviewed: 2026-02-27T12:43:24.355510 --- This mbox contains a v1 patch and its v2 respin, both by Jose A. Perez de A= zpillaga, targeting `drivers/staging/fbtft/fb_ra8875.c`. The goal is to rep= lace two `udelay(100)` calls in `write_reg8_bus8()` with a sleeping alterna= tive to avoid busy-waiting in a non-atomic context. **v1** used `usleep_range(100, 120)`. **v2** (the current revision) switche= s to `fsleep(100)`, which is the preferred modern API per reviewer feedback. The change is **correct and appropriate**. The `write_reg8_bus8()` function= is clearly in a sleepable context =E2=80=94 it calls `write_spi()` =E2=86= =92 `spi_sync()`, which itself can sleep. The existing `init_display()` fun= ction in the same file already uses `mdelay()` for longer waits, further co= nfirming non-atomic context. For 100us, `fsleep(100)` will internally call `usleep_range(100, 125)` (bas= ed on the formula `usleep_range(usecs, usecs + (usecs >> max_slack_shift))`= with `max_slack_shift=3D2`), which is a reasonable range and avoids the bu= sy-wait of `udelay()`. No functional concerns. This is a straightforward cleanup appropriate for s= taging. --- --- Generated by Claude Code Patch Reviewer