On 7/9/26 8:28 AM, Aniket RANDIVE wrote: > Thanks Konrad for the review. > > Sorry, I missed your comments on the v2 patch and ended up posting v3. I'm > happy to post a v4 incorporating your feedback once the discussion concludes. > > On 7/6/2026 5:11 PM, Konrad Dybcio wrote: >> On 7/5/26 3:57 PM, Aniket Randive wrote: >>> The driver uses a static XFER_TIMEOUT of HZ (1 second) for all transfers >>> regardless of message length or bus frequency, causing unnecessary >>> delays on error paths. >>> >>> Compute the timeout dynamically from message length and bus frequency >>> with a 10x safety margin over the theoretical wire time and a 300ms >>> floor. For GPI multi-descriptor transfers, use the maximum message >>> length across all queued messages as the per-completion timeout. >> >> What's the reason for a 0.3 s floor? > > The floor accounts for I2C clock stretching. The spec allows slaves to hold > SCL low indefinitely during internal processing. A dynamically computed xfer > time alone gives no time for that. > 300ms value covers worst-case stretching while still detecting real hangs 3x > faster than the old 1s static timeout.
Please put that in the commit message and possibly in the code as a comment > > Thanks, > Aniket > >> >> Why a 10x safety margin specifically? >> >> [...] > > The multiplier covers the gap between theoretical xfer time and actual > completion time (DMA descriptor setup, interrupt latency, and scheduling > jitter on a loaded system) > Without it, short transfers would have almost no extra time before a spurious > timeout. Likewise (Should there be a constant safety margin added to account for all that? Keep in mind this driver will run on a turbofast Glymur and on a notsofast Agatti so any numbers that depend on the processor's speed must be reasonable for both) Konrad
