On 07/13/2016 06:18 PM, Jiang, Dave wrote: > On Wed, 2016-07-13 at 08:00 +0000, Lars-Peter Clausen wrote: >> On 07/13/2016 12:24 AM, Dave Jiang wrote: >>> Lars, >>> Here's the reworked code per your comment. Let me know if this >>> matches >>> what you are thinking. Patch 2/4 shows how the driver provides the >>> error, and patch 3,4/4 show how the errors are received by upper >>> layer. >>> The callback is an addition so people should be able to transition >>> to the new one when convenient and the old callback still remains >>> for >>> compatibility. We should be able to expand on the new callback as >>> needed since I don't know much about the slave DMA side of things. >>> If >>> you are ok with it I'll clean it up and add the proper >>> comments/docs >>> etc and resubmit. >> >> Looks OK. >> >> For the dispatching between the two callback functions there should >> be a >> helper function in the core and all drivers should be update to use >> this >> helper, so that clients can rely on that the right callback will be >> called. >> If no result is provided by the driver the helper function should >> provide a >> dummy result with no errors and no residue. >> >> What makes the whole thing slightly tricky is that some drivers store >> the >> callback on the stack and free (or recycle) the descriptor before the >> callback is called. Since this is actually required for correct >> operation we >> have to work with it. >> >> Something like this might work. > > Maybe I'm missing something. In the example below you proposed two > steps. Implement helper function and update drivers, and then change > the helper function to provide results and update the drivers again > since the new helper function require extra parameter. That would > require us to fix up all the drivers twice. Is there anything that > prevents us to go directly to step two and implement the the new helper > function with results and only touch all the drivers once? The idea is to include the new extra parameter in the first step. It's just not functional yet and every driver has to pass NULL instead of a result struct. Then once the infrastructure to handle the result parameter has been put in place it is possible to add support for result reporting to individual drivers. Drivers which have not implemented result reporting will still continue to work and they'll also continue to work with clients that want to use the result callback. The reason for the multi-step approach is to separate refactoring from implementing new features, but at the same time keep the code compilable and functional at all steps. -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
