> > + renesas_i3c_enqueue_xfer(i3c, xfer); > > + if (!wait_for_completion_timeout(&xfer->comp, XFER_TIMEOUT)) > > + renesas_i3c_dequeue_xfer(i3c, xfer); > > This may common problem, I3C spec have 100us timeout, target side may > timeout when driver wait for irq. So target side treat "repeat start" as > "start" and issue address arbitration.
Looking more at this issue, I think these are two separate problems. Chapter 5.1.2.5 mandates that the controller shall not hold SCL low for more than 100us in most situations and by no means longer than 15ms in any situation. Depending on the controller, this may be need to be handled in software. Or it may be handled in hardware which could raise an exception and release SCL on its own if the timing was violated. The above completion is for the *whole transfer*, though, including the target response time. Like I2C, it is not specified for I3C. At least, I couldn't find it and I recall no one at the I3C plugfest could point me to one as well. So, this completion timeout is more than just 5.1.2.5. It might make sense to investigate a more reasonable value. But I don't think this should be imposed on someone submitting a new driver. It is a dedicated task. And I am not even sure the result will be a subsystem-wide static value. It might be a calculated value. Maybe even a driver-specific calculated value. So, I think the best we can do until we have this investigation is to keep drivers consistent with the historically grown value. Or?
