Re: Linking Patchwork with Sashiko?

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Thu, Jul 16, 2026 at 04:54:37PM -0400, Nicolas Dufresne wrote:
> Le mercredi 15 juillet 2026 à 23:53 -0400, Theodore Tso a écrit :
> > On Wed, Jul 15, 2026 at 11:00:54PM -0500, Nicolas Dufresne wrote:
> > > In V4L2 m2m notably, there is a "job" in the background, which allow
> > > to safely (at least this is the theory) chain up work, and
> > > synchronize against pending work. But Sashiko (and other AI) seems
> > > to not get it and state with confidence and long explanation that
> > > the drivers are racy and should do X/Y/Z more on top (and never
> > > blames the framework).
> > 
> > Is there actually a race which is allowed by the framework?  Or is
> > Sashiko's proposed race actually not possible?
> 
> Not that I'm aware of, as long as the driver follow the conventions. A typical
> occurrence of this is when Sashiko suggest that you should do an extra worker
> cancel after streamoff. The framework already ensure, through a job wait
> mechanism, that there is no more active tasks. This allow chaining this work
> across workers, and one really done with the task, the driver will call a
> function to finish the job.
> 
> Though, AI is also fed with code using the framework, but not the jobs. Venus
> and Iris from Qualcomm just leave the job running, and manually tear down and
> finish the job on streamoff. So when AI use that as example (or thinking model),
> they conclude defensive coding is needed. I bet that if Qualcomm Iris/Venus
> developer where to review other m2m they would provide similar reviews. But they
> will likely add words that show a certain level of uncertainty, very unlike
> Sashiko today.
> 
> What happens is that developers endup producing defensive code for cases that
> will never occur, but it can go as far as refactoring and putting in place extra
> mechanism that are simply duplicate of the existing framework. So we receive
> more complex code, with convincing comment that does not reflect any real-life
> scenarios.
> 
> Now its not a great mechanism, since its easy to "finish the job" and keep
> working, which can make the driver code run concurrently with a device_run()
> from another thread. And for multi-core drivers, its easy to forget that the
> framework does not protect anything concurrent inside your driver.
> 
> Sashiko is just not doing the teaching that is needed for new contributors, or
> for experienced developers handling slightly different type of HW with this
> "problematic" framework.

So I think here you need to teach Sashiko a bit. Submit a patch to
https://github.com/masoncl/review-prompts that creates
kernel/subsystem/media.md and lists all fine points of the APIs and
common pitfalls that driver writers are often fall into. That will steer
Sashiko away from suggesting hallucinated or impossible to happen
scenarios.

Thanks.

-- 
Dmitry