Re: [PATCH v2 0/5] kthread: convert remaining users to kthread_create_worker

[Bradley Morgan <brads@mainlining.org>]

On 5 September 2026 12:19:54 BST, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>On Fri, Sep 04, 2026 at 10:13:32PM +0100, Bradley Morgan wrote:
>> On 4 September 2026 22:10:32 BST, Jakub Kicinski <kuba@kernel.org>
>wrote:
>> >On Fri, 04 Sep 2026 16:56:30 +0100 Bradley Morgan wrote:
>> >> On 4 September 2026 16:54:18 BST, Jakub Kicinski <kuba@kernel.org>
>> >wrote:
>> >> >On Fri,  4 Sep 2026 09:37:21 +0000 Bradley Morgan wrote:  
>> >> >>   media: ivtv: convert to kthread_run_worker
>> >> >>   net: encx24j600: convert to kthread_run_worker
>> >> >>   tty: sc16is7xx: convert to kthread_run_worker
>> >> >>   cpufreq: schedutil: convert to kthread_create_worker  
>> >> >
>> >> >Please send these 4 to appropriate subsystems
>> >> >  
>> >> >>   kthread: remove worker->task self assignment  
>> >> >
>> >> >Then after the next merge window when trees converge send this one
>out 
>> >> 
>> >> hi, I was hoping one person could merge it with acks from all
>subsystems
>> >
>> >Not how this works.
>> Ugh, I've seen it before happen.
>> 
>> Look, fine, I'll do a V3 soon, WITH ONLY the subsystem changes, all
>> separate, all sent over to their respective maintainers, then when all
>> thathas been merged and there's the next merge window, then whatever,
>I'll
>> send then the kthread removal
>> 
>> IMHO this is a massive annoyance though.. because what if one of the
>> driverfolks doesn't wanna respond to me!?!
>
>Then, after trying for the normal way, you can make the driver change at
>the same time.  But to circumvent the "normal way" thinking it might not
>work, is not the best thing to do.
>

Greg!

Right, okay, Ill tell you more.

For features being added, where many drivers from different subsystems get
covered at once, what they tend to do is:

A: send all patches, rely on all maintainers to merge their own crap, which is a mess

B: Have a designated merger, who merges all the changes at once, no chance of regression because it's all bundled up.


C: send drivers first, then send the feature. So then driver maintainers can merge their crap, then the main feature gets merged in merge window 

I prefer B, because it's easier that way, akpm is usually des merger hence
I CCed him.

Or tip tree?

Honestly, if I had to be honest, C is a very annoying way, because of what
I said above, if driver maintainer thinks I'm some newbie idiot or
something, then what will I do? He won't merge it!


>thanks,
>
>greg k-h

--- Thanks!
https://lore.kernel.org/all/EE579805-42F2-4C58-B752-F28779EEB717@grrlz.net/