Re: [PATCH v6 0/5] serial: 8250: serialize DMA cancellation with buffer reuse

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 6861 bytes --]

On Mon, 26 Oct 2026, James Hilliard wrote:

> On Mon, Oct 26, 2026 at 10:24 AM Raul Rangel <rrangel@chromium.org> wrote:
> >
> > On Mon, Oct 26, 2026 at 5:16 AM Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> 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-3d3ce383c614@gmail.com
> >> > [1] https://lore.kernel.org/r/20261021-submit-serial-8250-dma-config-errors-v1-v1-1-c067587d1ef2@gmail.com
> >> > [2] https://lore.kernel.org/r/20261021-submit-serial-8250-dma-rx-accounting-v1-v1-1-c11795914ab4@gmail.com
> >> > [3] https://lore.kernel.org/r/20261023-submit-serial-8250-dma-tx-length-v1-v2-1-c3106ef4d2df@gmail.com
> >> > [4] https://lore.kernel.org/r/20261022-submit-serial-8250-tx-pm-shutdown-v1-v1-1-0e894afa3bb8@gmail.com
> >> > [5] https://lore.kernel.org/r/20261023-submit-serport-write-wakeup-v1-v1-1-74e7311638a2@gmail.com
> >> > [6] https://lore.kernel.org/r/20261024-submit-serial-8250-dw-divisor-v1-v2-1-032ca5338359@gmail.com
> >> > [7] https://lore.kernel.org/r/20261024-submit-serial-8250-mid-rx-lock-v1-v1-1-2b9afdf869d7@gmail.com
> >> >
> >> > Assisted-by: Codex:gpt-6-astra
> >> > Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
> >> > ---
> >> > 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-7wBSWLjLTP5jrr6nLfdCHNPo3pS6w@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.