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
