[U-Boot] [PATCH 2/6] serial: add UniPhier serial driver

Marek Vasut marex at denx.de
Thu Jul 10 14:37:18 CEST 2014


On Thursday, July 10, 2014 at 01:31:01 PM, Masahiro Yamada wrote:
> Hi Marek,

Hi!

> On Thu, 10 Jul 2014 12:14:35 +0200
> 
> Marek Vasut <marex at denx.de> wrote:
> > > > > +static void uniphier_serial_putc(struct uniphier_serial *port,
> > > > > const char c) +{
> > > > > +	if (c == '\n')
> > > > > +		uniphier_serial_putc(port, '\r');
> > > > > +
> > > > > +	while (!(readb(&port->lsr) & UART_LSR_THRE))
> > > > > +		;
> > > > 
> > > > I think in this function, you can avoid such completely unbounded
> > > > loop.
> > > > 
> > > > [...]
> > > 
> > > Why?
> > > Could you give me more detailed explanation?
> > 
> > In case the LSR_THRE bit would never get cleared, this loop would keep
> > spinning forever. On the other hand, if there was some kind of a
> > timeout, U-Boot would be able to continue doing at least something when
> > exiting this loop by timing out. Though you're right that something
> > would most likely have gone really bonkers if this LSR_THRE never got
> > cleared.
> 
> I guess you mentioned the case where the flow control with CTS/RTS
> results in the dead lock.

Either that or plain hardware failure.

> I am not sure if we need to be so careful.
> 
> Is there any other UART driver using timeout check?

I don't know. If you feel this is not needed, then please just ignore my 
suggestion. I'm just pushing the usual "let's not do unbounded loops where 
reasonable" thing here ;-)

> (What would U-Boot continue to do in case console cannot display the error
> message?)

It can still boot kernel, even if it cannot print on console.

Best regards,
Marek Vasut


More information about the U-Boot mailing list