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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Sat, Sep 05, 2026 at 01:55:35PM +0100, Bradley Morgan wrote:
> 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!

To quote a longtime kernel developer years ago, "Kernel development is
hard, let's go shopping."

Sorry, but yes, it can be difficult to touch cross-subsystem stuff like
this, always has been.  Just be patient.

good luck!

greg k-h