[U-Boot] [PATCH v4 2/2] NS16550: buffer reads

[Simon Glass]

Hi Wolfgang,

On Sun, Oct 16, 2011 at 1:13 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Simon Glass,
>
> In message <CAPnjgZ2Q3XtGK=5HhF0KhQo4XQDA6CAH3QFKfmgCwzNV_y0mUA at mail.gmail.com> you wrote:
>>
>> > Hmm... What about the conversation around V2 of the patch re: using XOFF/XON
>> > to control input flow? IIUC, even this V4 patch would not help much if there
>> > is a command within the pasted code that sends a lot of output, right?
>>
>> Well it will help so long as there isn't much more input. Perhaps the
>
> Don't you see that this "as long as there isn't much more input" is
> the fatal flaw of your patch?  You are not fixing the problem, you are
> just extending the point wher eit hits to some extend - it may work
> for a few more situations, but it's still guaranteed to fail for
> others.

In a similar way, the Linux kernel has a fatal flaw. Serial data
coming into the flip buffers under extreme interrupt load can be lost,
or the secondary buffers can become exhausted, or user space cannot
keep up with input under heavy load, etc., etc. This is the reality of
the world. As each problem presents itself we direct our attention to
it.

>
>> To address your question, I think we did discuss it. Wolfgang felt
>> that it should be as simple as sending XOFF when receiving the end of
>> a line and XON when waiting for characters on the new line. It
>> certainly sounds plausible.
>
> Then please let's take this approach instead, if you really need to
> support such a mode of operation.

As I said I will look at this.

>
>> I have other reasons for favouring this patch. On the main hardware
>> platform I currently use, SPI and the console UART are multiplexed, so
>> before using SPI (e.g. saveenv, reading the environment) we must read
>> in any pending characters to avoid corruption. After re-enabling the
>> UART later we must clear out any junk that has arrived. This patch
>> provides a way around that which XON/XOFF does not (since when you
>> send XOFF you may already have input characters outstanding - junk
>> will later be added and you can't tell the difference).
>
> That's an unrelated hardware issue that needs to be addressed
> independently.

Yes it is. I can't help wondering what the solution might be though,
if we are not allowed to buffer things.

Regards,
Simon

>
> 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
> Most legends have their basis in facts.
>        -- Kirk, "And The Children Shall Lead", stardate 5029.5
>