Re: [RFC PATCH 1/1] dmaengine: introduce dmaengine_bh_wq and bh helpers

[Arnd Bergmann]

On Mon, Jan 12, 2026, at 23:20, Allen wrote:
>> >   A hardirq callback path feels like a larger API change, so I’d
>> > prefer to handle that as a separate follow‑up (e.g. explicit hardirq
>> >  callback/flag + user migration where safe). Thoughts?
>>
>> Yes, definitely keep that separate. I still think that this is
>> what we want eventually for a bigger improvement, but your
>> patch seems valuable on its own as well.
>>
>
> Thanks for the detailed feedback. I’ll respin along these lines:
>
>   - Split the series into two patches: (1) introduce the per‑channel BH API,
>     (2) switch the vchan implementation over to the WQ_BH backend if we decide
>     to keep that step. This should make the progression clearer.
>
>   - The dmaengine_*_bh_wq() helpers will be made static; only dma_chan_*_bh()
>     stays exported.

Sounds good, yes.

>   - I won’t try to move the other per‑driver tasklets onto the shared queue in
>     this series. That feels like a separate discussion, and the right context
>     (hardirq/threaded/workqueue) may vary by driver.

I'm not sure we are talking about the same thing here. I do think we should
try to have all the callbacks in each dmaengine driver go through the same
per-channel deferral mechanism. What I meant to say is that all the tasklets
that are not used for the client callbacks should be separate from those,
e.g. the pl330_dotask() handler is used for unexpected events unrelated
to a channel.

>   - I’ll keep the hardirq callback path separate. For that follow‑up, I can plan
>     to add an explicit “hardirq safe” request bit (e.g. a new dma_ctrl_flags)
>     and update vchan_cookie_complete() to invoke the callback directly when
>     requested; otherwise it stays on the tasklet path.
>
>   If you’d prefer I drop the WQ_BH conversion entirely for now and keep only the
>   tasklet‑based per‑channel API, I can do that too.

No, I think that part is fine.

     Arnd