On 8/5/2016 4:34 AM, Lars-Peter Clausen wrote: > I believe we need to invest some effort to come up with clear semantics on > what is the expected behavior when transferring a descriptor fails. > Potentially allowing clients to choose the desired behavior, e.g. either > abort all descriptors on error or continue with the next one. I agree. I was leaning towards not calling the callback when an error happens to keep the implementation simple and backwards compatible. After Dave's change, I need to call the callback with the actual error in question. Now, I have broken tx_status. If I implement DMA_ERROR into tx_status like Russell indicated, then I have the address space explosion problem like you indicated. If I report the error for the last failing cookie, is it good enough? Or another approach is tx_status is just an indication of HW accepting the request. All existing clients need to be changed to use Dave's error reporting for deciding on actual success or failure for a request that was accepted by HW. tx_status can no longer be used to check for transaction errors. It can still be used to see if HW accepts the request (like parameter checking etc. but not for the final result) I like this one better. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
