On 03-11-21, 15:42, Vincent Whitchurch wrote: > The suggested timeout is not meant to take into account the overhead of > virtualization, but to be used by the virtio device as a timeout for the > transaction on the I2C bus (presumably by programming this value to the > physical I2C controller, if one exists). > > Assume that userspace (or an I2C client driver) asks for a timeout of 20 > ms for a particular transfer because it, say, knows that the particular > connected I2C peripheral either responds within 10 ms to a particular > register read or never responds, so it doesn't want to waste time > waiting unnecessarily long for the transfer to complete. > > If the virtio device end does not have any information on what timeout > is required (as in the current spec), it must assume some high value > which will never cause I2C transactions to spuriously timeout, say 10 > seconds. > > Even if the virtio driver is fixed to copy and hold all buffers to avoid > memory corruption and to time out and return to the caller after the > requested 20 ms, the next I2C transfer can not be issued until 10 > seconds have passed, since the virtio device end will still be waiting > for the hardcoded 10 second timeout and may not respond to new requests > until that transfer has timed out. Okay, so this is more about making sure the device times-out before the driver or lets say in an expected time-frame. That should be okay I guess. -- viresh _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
