On Mon, 26 Oct 2026, James Hilliard wrote: > On Mon, Oct 26, 2026 at 10:24 AM Raul Rangel <[email protected]> wrote: > > > > On Mon, Oct 26, 2026 at 5:16 AM Ilpo Järvinen > > <[email protected]> wrote: > >> > >> On Sat, 24 Oct 2026, James Hilliard wrote: > >> > >> > Reserve canceled transmit and receive storage until DMA and its > >> > completion > >> > callbacks have retired. Serial-core write backpressure protects a flushed > >> > TX FIFO while normal transfers continue to DMA directly from that FIFO. > >> > > >> > The series separates OMAP's locked completion processing and serializes > >> > asynchronous write wakeups with the port lock before adding the > >> > serial-core > >> > reservation helpers and applying them to 8250 TX. Flushing > >> > empties the logical queue immediately. While the old transfer owns its > >> > storage, write_room() reports zero and write-ready notifications wait for > >> > retirement. Failed termination retains the reservation until normal > >> > completion, without advancing the reset FIFO. DMA retirement releases the > >> > reservation independently of port readiness. Serial core keeps writes and > >> > wakeups gated during shutdown until successful startup or resume. > >> > > >> > RX delivers paused data before the PIO fallback and retires callbacks in > >> > process context. Track FIFO access separately from buffer retirement so > >> > PIO and the DesignWare empty-FIFO timeout handling can run once DMA has > >> > released the FIFO. On failure, retain the requested interrupt enables in > >> > the existing IER shadow and mask receive interrupts in hardware until DMA > >> > has stopped. Recovery then leaves RX on PIO until reopen. Shutdown > >> > excludes > >> > new retirement work before releasing the channels. > >> > > >> > Based on tty-next with the posted shutdown guard [0], channel > >> > configuration error handling [1], RX TTY accounting fix [2], RZ/N1 > >> > transfer-length fix [3], transmit-PM shutdown fix [4], serport > >> > write-wakeup deferral [5], DesignWare BUSY-safe fractional-divisor > >> > programming [6], and Intel MID RX DMA timeout locking [7]. The serport > >> > fix > >> > is needed before serializing the remaining write-wakeup callers with the > >> > port lock. > >> > > >> > [0] > >> > https://lore.kernel.org/r/20261021-submit-serial-8250-dma-shutdown-v1-v1-1-3d3ce383c...@gmail.com > >> > [1] > >> > https://lore.kernel.org/r/20261021-submit-serial-8250-dma-config-errors-v1-v1-1-c067587d1...@gmail.com > >> > [2] > >> > https://lore.kernel.org/r/20261021-submit-serial-8250-dma-rx-accounting-v1-v1-1-c11795914...@gmail.com > >> > [3] > >> > https://lore.kernel.org/r/20261023-submit-serial-8250-dma-tx-length-v1-v2-1-c3106ef4d...@gmail.com > >> > [4] > >> > https://lore.kernel.org/r/20261022-submit-serial-8250-tx-pm-shutdown-v1-v1-1-0e894afa3...@gmail.com > >> > [5] > >> > https://lore.kernel.org/r/20261023-submit-serport-write-wakeup-v1-v1-1-74e731163...@gmail.com > >> > [6] > >> > https://lore.kernel.org/r/20261024-submit-serial-8250-dw-divisor-v1-v2-1-032ca5338...@gmail.com > >> > [7] > >> > https://lore.kernel.org/r/20261024-submit-serial-8250-mid-rx-lock-v1-v1-1-2b9afdf86...@gmail.com > >> > > >> > Assisted-by: Codex:gpt-6-astra > >> > Signed-off-by: James Hilliard <[email protected]> > >> > --- > >> > Changes in v6: > >> > >> Hi, > > > > > >> > >> > >> > >> This series is moving way too fast with new versions. Please slow down. > > > > > > +1. I think you should have spent more time refining your patch set before > > submission, or sending individual patches that weren't interelated. > > I was doing as much validation as I could locally already but often I > was missing > issues the Sashiko review bot was flagging. Since the Sashkio reviews appeared > to be release issues I was doing respins to try and fix all those issues.
Fixing an issue sashiko finds does not mandate you to send the fixed version out right away. And yes, definitely, fix those issues as soon as you want, no matter what's the source (sashiko, human reviewer, your own mind finding flaws when given time to process the code you've read/written), they'll then be in store for the time when it's time to send the next version. We do know this is a major problem with AI review that it pushes submitters to do rapid refresh cycle on the false pretence that reviewers must always see the latest and shiniest code (despite often the corner cases sashiko find relate to a single obscure driver most reviewers would have no opinion anyway) or that humans should only be bothered when AI bot found nothing (yet they always have a huge cc lists and mailing lists with hundreths if not thousands receipients so it doesn't add up with that excuse either!). Effectively such a patch sending loop ends up only feeding the AI review bot. > Apparently not everyone is seeing those reviews posted despite them showing > up fine in lore for me.[0] > > Is everyone here seeing those reviews or are they not showing up? > > [0] > https://lore.kernel.org/all/cadvtj4onz-bnszp+kfau-7wbswljltp5jrr6nlfdchnpo3p...@mail.gmail.com/ It's quite irrelevant to me whether I can see the reviews Sashiko gives (and I could look them up from https://sashiko.dev if I'd be interested and they do appear there). When I do review the patch series I'm not basing my review on top of sashiko's nor on top of other reviewer's. Sometimes I end up reviewing something that gets updated by a later version because of that but it also makes me immune to false claims or fixations of others. But the number one cause for me reviewing an older version is sender sending versions very close to each other, often during weekend (in how many cases the part of the code I commented on had changed, I don't have an estimate for you, sorry). At reaching v6 this fast, you've clearly done something wrong given multiple people are pointing out this to you, and yet all we get in response is that "I only did it because sashiko gave me things to fix". What is missing is a clear indication that you've understood the way you've behaved so far will not maintain good appearance in the eyes of many of the community. So please consider if it is really worth the few extra days waiting would require. I suggest you never do more than two versions per week on any non-trivial series. I can understand sometimes a quick refresh (especially when at v1-v2) is warranted but to do it for many versions close to each other is something that people don't want to see. And I do know how annoying it is to wait with patches and submit prerequisite fixes first, with all the annoying delay it comes with for the main patches one wants to get upstreamed, so I'm in no different boat than you when it comes to that part. -- i.
