On Thu, 2015-11-12 at 04:52 -0700, Jan Beulich wrote: > > > @@ -530,7 +531,8 @@ static void ns16550_setup_preirq(struct > > > /* Baud rate already set: read it out from the divisor > > > latch. */ > > > divisor = ns_read_reg(uart, UART_DLL); > > > divisor |= ns_read_reg(uart, UART_DLM) << 8; > > > - uart->baud = uart->clock_hz / (divisor << 4); > > > + if ( divisor ) > > > + uart->baud = uart->clock_hz / (divisor << 4); > > > > Will following code cope with uart->baud == BAUD_AUTO? Or should we > > pick a > > static fallback rate (115200?) and set the divisor appropriately? > > The device won't work with it left as BAUD_AUTO. Setting a guessed > baud rate alone won't help, as we'd then also have to write it into the > respective registers. And I don't think anyway we should do any > guessing here - if the command line option was wrong (regardless of > whether due to using auto or just a wrong baud rate), communication > won't work. All I think we should really care about is to not crash, the > more in a way not diagnosable over serial console.
BAUD_AUTO is the default in device-tree based situations, so it isn't necessarily the case that the command line is wrong. For the non-DT case I think it also ends up with an implicit BAUD_AUTO in some cases? That said I don't think it is worth going to the effort to distinguish implicit from explicit-auto configuration, and your argument about not writing to the registers certainly applies to the latter, so lets just worry about not crashing as you say. Is a printk worthwhile, due to the fact there might be a second console present? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
