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

[Tomasz Wroblewski <tomasz.wroblewski@citrix.com>]

On 08/27/2013 08:55 AM, Jan Beulich wrote:
>>>> On 26.08.13 at 18:12, Tomasz Wroblewski<tomasz.wroblewski@citrix.com>  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.
Aha okay. I'm trying to come up with something along the above lines 
then. I think I'll split this patch into two, one for the timer list fix 
(which I think is not controversial) and other for the hang/port 
unavailable case
> Jan
>