Handling of chars received while a UART is not open

Handling of chars received while a UART is not open

[Dave Martin]

Hi all,

Question:

 1) Should a UART definitely discard the RX FIFO on ->startup()?

 2) Should a UART definitely *not* discard the RX FIFO on ->startup()?
    (as in my fix).

 3) Or is there no clear answer here?


Background:

Working on a fix for an RX lockup issue with amba-pl011 [1], I came up
with the idea that the driver's attempt to clear spurious interrupts on
startup is going wrong when the interrupt is not spurious (i.e., the RX
FIFO is initially full to the interrupt trigger threshold).

I have a fix [2] based on this.  It removes the attempt to clear
spurious interrupts so that the RX FIFO will definitely get drained if
need be, in the pl011 interrupt handler.

This should mean that amba-pl011 implements (2) with my patch.

But this may have unwanted side-effects, depending on the answer to
the above question.


Now, Qemu has a facility for stuffing some input to an emulated UART
immediately on boot, and wouldn't work in case (2) above.  OTOH, that
may be a mistaken approach: it's unlikely to work reliably on hardware
due to the problem of knowing when a physical UART is actually ready to
receive input.  So maybe Qemu should be waiting for a prompt to be
transmitted before stuffing input.  In case (1) or (3), qemu probably
needs to do something like that.

(1) is also odd though.  Garbage on the wire while the UART is closed
will then be seen when a process opens the UART.  If there is a
non-trivial amount of data, an overrun error will most likely be
reported too.  User programs intended to be robust (getty, pppd etc.)
should perhaps be doing an explicit flush on startup, but this will
race against the UART driver unless the UART driver flushes the FIFO in
its ->startup().  Wire protocols are inherently realtime and need
another way to negotiate startup (DCD/DSR/DTR signalling for example)
or to recover from a bad state on one or both ends.

So I don't know what the right answer is.


Wei's proposed fix in qemu [1] attempts to detect readiness by waiting
for the emulated system to enable interrupts on the UART, but this
makes assumptions about the driver running inside the emultaion: for
a polled-mode driver, it would most likely not work.

The pl011 hardware provides no way to distinguish spurious from
non-spurious RX FIFO interrupts other than reading the FIFO to see if
there's anything in there.  Moreover, the interrupt state machine in
the hardware can get stuck if the FIFO is not drained sufficiently.


[1] [Qemu-devel] [Qemu-arm] [PATCH] pl011: do not put into fifo before enabl
https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg06446.html

[2] [RFC PATCH v2] tty: pl011: Avoid spuriously stuck-off interrupts
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-January/556897.html

Handling of chars received while a UART is not open

[Russell King - ARM Linux]

On Wed, Jan 31, 2018 at 12:06:29PM +0000, Dave Martin wrote:
> Hi all,
> 
> Question:
> 
>  1) Should a UART definitely discard the RX FIFO on ->startup()?

Yes; POSIX makes no guarantees about the configuration of the port
while it is closed, and when it is re-opened, it is permitted that
the port is reset back to a set of default parameters rather than
the previous parameter set that was configured.

You also have the CREAD flag which indicates whether we want the
receiver enabled or not, but it is not defined by POSIX whether the
receiver remains enabled when the port is closed.

Linux behaviour has always been to flush the port of received
characters at close and open time (see 8250 driver), meaning that
characters received while the TTY is closed are ignored - just like
what happens on the physical console keyboard, which is also a TTY.
Doing otherwise is likely to confuse applications and potentially
introduce buggy behaviour that would only be detected on UARTs with
differing behaviour to 8250.

Linux follows POSIX General Terminal Interface for its TTY handling.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Handling of chars received while a UART is not open

[Peter Maydell]

On 31 January 2018 at 12:06, Dave Martin <Dave.Martin@arm.com> wrote:
> Now, Qemu has a facility for stuffing some input to an emulated UART
> immediately on boot, and wouldn't work in case (2) above.  OTOH, that
> may be a mistaken approach: it's unlikely to work reliably on hardware
> due to the problem of knowing when a physical UART is actually ready to
> receive input.  So maybe Qemu should be waiting for a prompt to be
> transmitted before stuffing input.  In case (1) or (3), qemu probably
> needs to do something like that.

FWIW, there isn't a QEMU "facility" for doing this particularly:
we just don't take any trouble to stop the user from providing
input whenever the user likes. (If the user is an automatic test
script then it's that script's job to wait for suitable prompts
from the guest before feeding input into the emulated serial port
if it wants to be reliable, the same way you'd have to if you
were feeding the data to a real serial line.)

What QEMU doesn't do and probably should fix is that we allow data
into the FIFO even if UARTCR.UARTEN is 0 ("UART disabled"). This
(I think) wouldn't affect the behaviour here, though, because the
data will just get held in QEMU's input buffer until the guest
driver sets UARTEN and then immediately fill the FIFO.

thanks
-- PMM

Handling of chars received while a UART is not open

[Dave Martin]

On Wed, Jan 31, 2018 at 01:12:15PM +0000, Peter Maydell wrote:
> On 31 January 2018 at 12:06, Dave Martin <Dave.Martin@arm.com> wrote:
> > Now, Qemu has a facility for stuffing some input to an emulated UART
> > immediately on boot, and wouldn't work in case (2) above.  OTOH, that
> > may be a mistaken approach: it's unlikely to work reliably on hardware
> > due to the problem of knowing when a physical UART is actually ready to
> > receive input.  So maybe Qemu should be waiting for a prompt to be
> > transmitted before stuffing input.  In case (1) or (3), qemu probably
> > needs to do something like that.
> 
> FWIW, there isn't a QEMU "facility" for doing this particularly:
> we just don't take any trouble to stop the user from providing
> input whenever the user likes. (If the user is an automatic test
> script then it's that script's job to wait for suitable prompts
> from the guest before feeding input into the emulated serial port
> if it wants to be reliable, the same way you'd have to if you
> were feeding the data to a real serial line.)

Fair enough.  I misunderstood slightly there.

> (I think) wouldn't affect the behaviour here, though, because the
> data will just get held in QEMU's input buffer until the guest
> driver sets UARTEN and then immediately fill the FIFO.

On the Linux side, I guess we nonetheless need to cope with input
stuffed early for the SBSA UART case, but if you're saying that
qemu (or software talking to qemu) shouldn't assume that input
stuffed at boot will actually be received (unless it qemu waits for
UARTEN) then we have some flexibility in the amba-pl011 driver here.

Based on Russell's comments, I guess the fix for the SBSA UART case
would be to read and discard the contents of the RX FIFO on UART open.
It seems harmless to do that for pl011 also, so I would suggest putting
it on the common code path.  This likely minimises the chance of being
tripped up by vendor-specific quirks.

> What QEMU doesn't do and probably should fix is that we allow data
> into the FIFO even if UARTCR.UARTEN is 0 ("UART disabled"). This

That probably does makes sense, providing qemu models a pl011.
A real pl011 wouldn't receive anything while that bit is clear.

SBSA UART doesn't have this control (or most of the others): it's
just always on.


Cheers
---Dave

Handling of chars received while a UART is not open

[Dave Martin]

On Wed, Jan 31, 2018 at 12:19:31PM +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 31, 2018 at 12:06:29PM +0000, Dave Martin wrote:
> > Hi all,
> > 
> > Question:
> > 
> >  1) Should a UART definitely discard the RX FIFO on ->startup()?
> 
> Yes; POSIX makes no guarantees about the configuration of the port
> while it is closed, and when it is re-opened, it is permitted that
> the port is reset back to a set of default parameters rather than
> the previous parameter set that was configured.
> 
> You also have the CREAD flag which indicates whether we want the
> receiver enabled or not, but it is not defined by POSIX whether the
> receiver remains enabled when the port is closed.
> 
> Linux behaviour has always been to flush the port of received
> characters at close and open time (see 8250 driver), meaning that
> characters received while the TTY is closed are ignored - just like
> what happens on the physical console keyboard, which is also a TTY.
> Doing otherwise is likely to confuse applications and potentially
> introduce buggy behaviour that would only be detected on UARTs with
> differing behaviour to 8250.
> 
> Linux follows POSIX General Terminal Interface for its TTY handling.

OK, that all sounds good.

Explicitly reading the RX FIFO until empty on startup seems compatible
with this, and harmless even on hardware that can't show the lockup.

I'll cook up another patch.

Cheers
---Dave