[U-Boot] [PATCH v2] NS16550: buffer reads

[Wolfgang Denk <wd@denx.de>]

Dear Graeme Russ,

In message <CALButCKD2ucJ0ZUQJpLCP2ABYcCzO-mACa=FPWczCTVeHeoTKg@mail.gmail.com> you wrote:
>
> >> If so, could it not be possible that a Kermit/ymodem command followed by a
> >> time consuming command on the same line cause lost input?
> >
> > I don't think so.  All serial transfers use a protocol - and when the
> > transfer is complete, it does not matter any more, because no more
> > data are flowing.
> 
> My point is that the transfer turns off flow control - When the transfer
> completes, flow control will be off when the next command begins to run.

Why would any of the transfer commands actually turn off flow control?
There is no need to do that so far.  And even if they do - that's no
fundamental difference to now, where we are not reading the input
then, either.

> If the next command is one which takes a long time to execute and it is on
> the same line as the transfer command (i.e. no \r to send XOFF) and the
> user types something then that input can be lost.

I don't understand what you mean.  We're talking about a single line
of input here, right?  Re-enabling XON is not needed before we're
ready to read the next line.  And during that, no characters would be
lost because none are sent due to flow control being shut off.

> I think the solution is fairly trivial though - During the processing of
> commands entered via readline(), cause an XOFF to be sent each time (i.e.
> immediately before) the command string is dispatched a to the command
> processor just in case the previous command called getc() (and thus caused
> an XON to be sent)

This sounds like unneeded overhead to me.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Teenagers are people who express a burning desire to be different by
dressing exactly alike.
There are some strings. They're just not attached.