Takashi Sakamoto wrote:
Can I request your comment for this patch about a quirk of transaction?
M-Audio Firewire 1814 and ProjectMix I/O often send no response against driver's request, even if the device handle the request.
For CMP and Isochronous Resource Management, this quirk works badly. When a request from driver is handled by the device but the device don't respond, the drivers (firewire_core/snd-firewire-lib) retry the request. Then a response for the second request brings error because the operation for connection or isochronous resource management is already done in device side.
Maybe we should change how these functions handle timeouts. Any other error code indicates that the lock transaction failed definitely, but after a timeout, we don't know if it was the request or the response that got lost.
We could try to read the register, and, if we see that the change that we tried to do actually happend, assume that our driver's transaction did this change.
Are read transactions more reliable than locks? If not, we might need to increase the number of retries for these devices.
Against this quirk, I want to merge this patch for upstream
This patch (no. 52) does not change the CMP code.
Regards, Clemens