Re: [Xen-devel] [PATCH] PCI uart: fix boot hang, and second S3 resume inactive timer list corruption

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.08.13 at 18:12, Tomasz Wroblewski <tomasz.wroblewski@xxxxxxxxxx> 
>>> wrote:
> On 08/26/2013 05:26 PM, Jan Beulich wrote:
>> My question was along the lines of "If I/O port access is disabled,
>> isn't the whole driver screwed (even if only temporarily)?" And if
>> the answer to this is "yes" (I can't see it to be "no"), dealing with
>> this likely requires more than the change you proposed.
> It could be, I only have empirical evidence of not noticing any serial 
> out hiccups during dom0 kernel init. Since this is is small driver and 
> it seems to primarily interact with the I/O only in ns16550_interrupt, 
> ns16550_poll, ns16550_tx_ready, putc, getc (and in some init functions 
> but these will only be called before dom0 boot), I thought that:
> 
> * ns16550_interrupt will be fine with IO ports disabled, it'll just exit

Ah, right, the flag being tested is a "no-interrupt-pending" one.
Good.

> * ns16550_poll will be fine with the posted patch, it'll exit
> * ns16550_getc looks like it has a potential of producing 0xFF 
> characters incorrectly, so maybe would need a port test as well

Right.

> * ns16550_putc should be fine since write to ioport will just be dropped

Ideally it would of course postpone the writes, see below.

> * ns16550_tx_ready should be fine, it will return 1 if ioports are 
> disabled which is what it needs to be returning to avoid spinning in 
> serial.c

Actually, one could probably tweak this so that at least in the non-
sync, non-log-everything case it serial.c would prefer buffering
over calling ->putc() (and hence dropping), by allowing
->tx_ready() to indicate this "disconnected" state via a special
return value.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel