[Xen-changelog] [xen master] serial: Fix COM1 assumption if pci_uart_config did not find the AMT card.

[patchbot@xxxxxxx]

commit 85c6f4f3803e0a0f5c57899c0bfd03b2e154ac3b
Author:     Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
AuthorDate: Fri Mar 7 10:45:04 2014 -0500
Commit:     Keir Fraser <keir@xxxxxxx>
CommitDate: Thu Mar 13 10:21:24 2014 +0000

    serial: Fix COM1 assumption if pci_uart_config did not find the AMT card.
    
    The io_base by default is set to be 0x3f8 for COM1 and 0x2f8 for COM2
    in __setup_xen. Then we call 'ns16550_init' which copies those in
    the appropriate uart, which then calls 'ns16550_parse_port_config'
    to deal with parameter parsing. If the 'amt' parameter has been
    specified we further call 'pci_uart_config code' which scans the PCI bus.
    
    If it does not find the AMT device it would overwrite the io_base with
    0x3f8 regardless whether this is COM1 or COM2 - but only if 'amt'
    parameter had been specified.
    
    The overwrite is a way to set it back to the failsafe defaults -
    except for COM2 it is bogus.
    
    Note again - if an AMT card is found, this over-write will not happen.
    
    This in theory (as I don't have a machine with two COM ports
    readily available) means that if the user specified 'com2=9600,8n1,amt'
    and the device did not have an AMT serial device, instead of using
    0x2f8 for the io_base it ends up using 0x3f8 - and we don't get the
    output on COM2. If the user had done 'com2=9600,8n1' we would never
    get in this path so this bug would never manifest itself
    (because we don't end up scanning for the AMT device).
    
    We also unconditionally reset the IRQ value - so we would never get the
    proper interrupt when falling back to the legacy 0x3f8 and 0x2f8 COM ports.
    That is OK - as we would end up using the polling mode - while
    not the best - it still would work.
    
    Lastly the clock_hz is also set to the default one (UART_CLOCK_HZ,
    which is the same for legacy COM1 and COM2 ports)- that is strictly
    not a bug, but it is redundant and not needed.
    
    This bug was introduced with the original AMT support and I cannot
    recall why it was done that way - it is a bug.
    
    Fix it by saving the original io_base before starting the
    scan of the PCI bus. If we don't find an serial PCI device (because
    we did not exit out of the loop using return) then
    assign the original io_base value back.
    
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
    [v1: Also remove the irq override spotted by Jan]
    [v2: Add more details to the commit description]
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
---
 xen/drivers/char/ns16550.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index 2fded08..d5fe689 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -612,10 +612,11 @@ static int __init
 pci_uart_config (struct ns16550 *uart, int skip_amt, int bar_idx)
 {
     uint32_t bar, bar_64 = 0, len, len_64;
-    u64 size, mask;
+    u64 size, mask, orig_base;
     unsigned int b, d, f, nextf, i;
     u16 vendor, device;
 
+    orig_base = uart->io_base;
     uart->io_base = 0;
     /* NB. Start at bus 1 to avoid AMT: a plug-in card cannot be on bus 0. */
     for ( b = skip_amt ? 1 : 0; b < 0x100; b++ )
@@ -747,9 +748,8 @@ pci_uart_config (struct ns16550 *uart, int skip_amt, int 
bar_idx)
     if ( !skip_amt )
         return -1;
 
-    uart->io_base = 0x3f8;
-    uart->irq = 0;
-    uart->clock_hz  = UART_CLOCK_HZ;
+    /* No AMT found, fallback to the defaults. */
+    uart->io_base = orig_base;
 
     return 0;
 }
--
generated by git-patchbot for /home/xen/git/xen.git#master

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog