[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] ns16550: misc minor adjustments
On 12/11/15 12:10, Ian Campbell wrote: > 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? Yes. Even if there isn't a second serial console, the system might boot and `xl dmesg` should contain a record. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |