On Tue, 23 Jul 2019 at 12:55, Mark Balançian <mbala...@gmail.com> wrote: > > On Jul 23, 2019, at 8:17 AM, Ezequiel Garcia <ezequ...@vanguardiasur.com.ar> > wrote: > > > On Tue, 23 Jul 2019 at 12:02, Mark Balançian <mbala...@gmail.com> wrote: > > > I see. I guess then my issue would be help in seeing how > tw686x_memcpy_dma_free alone does any required interrupt handling, since > there are also functions tw686x_irq and tw686x_audio_irq for interrupt > handling as well? However, in my analysis, they were called after > tw686x_memcpy_dma_free. > > > What are you trying to do? and what is exactly not working? > > PS: Don't drop linux-media from the Cc list, and please don't top-post. > > Thanks, > Eze > > > I don’t know what top-posting is, but I take it that it means I should write > my email below the previous? Anyways, I’m working with a linux driver > verification team to detect race conditions in the kernel. Using our tool, we > detected a possible race condition with the tw686x driver.
Can you describe how is this race condition possible ? E.g. what are the possible code paths and what would be the problem? Also, is the tool open source? > Even if there’s the slightest thing I’d like to please patch it as I really > need this for my enrolled program. > Sure, if there's anything to patch, let's patch it! > In any case, if interrupt handing isn’t given dedicated functions that are > called before tw686x_memcpy_dma_free, I wouldn’t mind writing them and > including them in a patch. > I can't understand what you mean. Can you describe what is the issue you are seeing in the driver? Thanks, Ezequiel
