Re: [Xen-devel] [PATCH] ns16550: misc minor adjustments

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel