On Sun, Oct 25, 2026 at 9:10 AM Andy Shevchenko <[email protected]> wrote: > > On Sun, Oct 25, 2026 at 05:10:03AM +0000, Maciej W. Rozycki wrote: > > On Sat, 24 Oct 2026, James Hilliard wrote: > > > > > uart_write_wakeup() expects the UART port lock to be held. Several worker, > > > DMA completion and interrupt paths call it without that lock, including > > > indirect calls from uart_handle_cts_change() and the transmit helpers. > > > > Fair enough, and thank you for the cleanup and spotting the issue in the > > first place, however... > > He already issues a v6. I think the tactics against AI contributions should be > to not answer for a week or so until there will be a quiescent week.
At least with the workflow I've been using, a good signal for quiescence is simply whether or not the Sashiko reviewer found issues. I am feeding the Sashiko prompts into my local agent but it seems to sometimes miss issues that get flagged by the public Sashiko reviewer still. I've been attempting to peel off independently reviewable fixes where feasible as well to minimize the amount of patches/code during respins as well. > At least that's what I learn from this patch storm. Whenever my local branch accumulates significant refactoring/changes due to Sashiko or manual reviews I generally try and send out the new revision fairly quickly in an attempt to avoid reviewers wasting time reviewing code that is obsoleted by the new fixes/changes in my local branch. Locally I actually have far more UART related patches in an integration tree that I've held off on sending for now since they are dependent upon the prerequisite fixes I have already sent. My unposted patches actually have an even larger amount of code changes than all the UART related patches that I've posted so far, at least when measured in terms of total lines of code changed. The large amount of patches I ended up with seems to have mostly come about due to the AI agent identifying most of these bugs while iterating on and debugging new features(most of which are still largely unsent so far). The strategy I've been using is to send small isolated fixes separately and then reference them as needed in the larger series that depend on them. I figure this should make the changes easier to review than having them all in a larger series. I contributed the changes[0] to make this compatible with the Sashiko reviewer actually. I also use a custom AI agent controlled hardware in the loop test harness which makes iterating/testing changes much faster since the AI agent can autonomously test and iterate on changes far faster than is possible to do manually. This test setup also allows much more thorough testing as a lot of error handling or uncommonly hit code paths can then be tested using AI generated fault injection tests on real hardware tailored to the specific fix being validated. I manually review the final changes before sending as well of course. I'm constantly refining these patch development/review workflows as well so feel free to give me any suggestions for anything I should change to make review easier. [0] https://github.com/sashiko-dev/sashiko/pull/389 > > -- > With Best Regards, > Andy Shevchenko > >
