On 7/10/2026 2:57 PM, Konrad Dybcio wrote:
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
Sure. I will update the commit message accordingly and add a corresponding comment in the driver as well. Thanks, Aniket
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
The 10x multiplier was chosen as a conservative guard band to account for the gap between theoretical transfer time and actual completion time, including DMA setup, interrupt handling, and scheduling delays. Although the value is not derived from a formal worst-case latency analysis, it provides sufficient tolerance to accommodate runtime variability and helps avoid spurious timeouts across a wide range of platforms and system load conditions.
Thanks, Aniket