On Tue, Nov 08, 2022 at 11:50:19AM +0000, Tudor.Ambarus@xxxxxxxxxxxxx wrote:
> On 11/8/22 09:49, Andy Shevchenko wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > device_tx_status() may return DMA_PAUSED status when driver supports it.
>
> Yeah, but you haven't described the why. And that's because dma_cookie_status()
> currently considers just DMA_COMPLETE and DMA_IN_PROGRESS for the status of the
> cookie, so the controller drivers are forced to query the DMA_PAUSED state
> themselves.
At last without this change it's inconvenient and requires a lot of additional
(unneeded) code to be written by the caller. Moreover, it's racy. If you query
status twice in a raw, it may be well changed (for example from PAUSED to
IN_PROGRESS or COMPETE).
I will add a word summarizing this.
> Also, I noticed that Vinod prefers that you use the full paragraph in the commit
> message, and not a continuation of the patch title, so you may want to reword
> the commit message.
Yes, I will fix that.
...
> > + if (!txstate) {
> > + if (test_bit(ATC_IS_PAUSED, &atchan->status))
>
> there's a helper function that you can use instead: atc_chan_is_paused()
Will use it.
> > + return DMA_PAUSED;
> > + return DMA_ERROR;
>
> return dma_status please
Will squash the patch.
> > + }
...
> > + if (test_bit(ATC_IS_PAUSED, &atchan->status))
>
> The status may change after spin_unlock_irqrestore(). Should the residue
> be in sync with the dma status? If yes, you should check the status while
> holding the lock.
You should tell me actually. Because I'm a bit puzzled why we need a spin lock
_and_ atomic bit operations together.
> > + dma_status = DMA_PAUSED;
...
Thank you for the review.
--
With Best Regards,
Andy Shevchenko
