On Wed, 19 Nov 2025, Marco Crivellari wrote:

> On Wed, Nov 19, 2025 at 11:38 AM Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
> > [...]
> > So after refactoring, WQ_UNBOUND cannot be specified as it has been
> > removed AND the default behavior is "unbound", not "per-cpu", right?
> > So it should be other way around, e.g.:
> >
> > The refactoring is going to alter the behavior of alloc_workqueue() to be
> > unbound by default.
> 
> Yes, it makes sense. I changed that part.
> 
> This is the updated version:
> 
> This continues the effort to refactor workqueue APIs, which began with
> the introduction of new workqueues and a new alloc_workqueue flag in:
> 
> commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
> commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
> 
> The refactoring is going to alter the default behavior of
> alloc_workqueue() to be unbound by default.
> 
> With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
> any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
> must now use WQ_PERCPU. For more details see the Link tag below.
> 
> In order to keep alloc_workqueue() behavior identical, explicitly request
> WQ_PERCPU.

Fine with me, thanks.


For those system_wq changes you can follow a similar structure but alter 
it to match what is changed in the other interface.

This seems already okay:

"Replace system_wq with system_percpu_wq, keeping the same behavior."

And again you can drop the old system_wq is kept for a while thing, it's 
irrelevant to those changes as they're no longer using the system_wq.


(When sending the update, you can send all three drivers/platform/ changes 
in a single series.)

-- 
 i.