[PATCH] media: platform: mtk-mdp3: add WQ_PERCPU to alloc_workqueue users

[Nicolas Dufresne]

Hi,

Le mercredi 10 décembre 2025 à 16:30 +0100, Marco Crivellari a écrit :
> On Tue, Dec 9, 2025 at 9:57 PM Nicolas Dufresne <nicolas at ndufresne.ca> wrote:
> > 
> > Hi,
> > I have to admit, there is likely no review here due to the lack of knowledge, so
> > in order to help educate myself (hopefully its not just me), can you explain why
> > the new default of WQ_UNBOUND would not be a fit for this driver ? After all,
> > the author didn't care and didn't make a choice, so I feel like its worth
> > asking.
> 
> Hi Nicolas,
> 
> The fact is that "alloc_workqueue()" without WQ_UNBOUND it means per-cpu.
> So what we are doing here is just make explicit that the workqueue is per-cpu.
> 
> Currently there are no behavioral changes in alloc_workqueue(); in a
> future release
> WQ_UNBOUND will be removed and unbound will be the default. But as for now,
> it is still per-cpu.
> 
> We can of course change the current behavior and I can send the v2 with
> WQ_UNBOUND instead. Looking at the code there are not per-cpu variable and
> the workqueue does not have the WQ_BH flag, so we can convert it if it
> is better.

thanks for clarifying. This driver having no clear maintainer, it is hard to
delegate the checks needed, but from the description, it pretty much sounded as
if most driver are picking up the wrong thing, because that is what the default
do.

I don't have strong opinion, if you think this driver can be ported in one step,
that is always my preference, and making things explicit is also nice. But I'm
also fine picking this as-is for now. Let me know, your preference, available
time and safety of not breaking anything is valid argument to me.

Nicolas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20251210/559f4698/attachment.sig>