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

[Masahiro Yamada]

Hi Marek,


On Thu, 10 Jul 2014 14:37:18 +0200
Marek Vasut <marex at denx.de> wrote:

> 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.
> 


Finally, I decided to keep this as is because:

[1] Our on-chip UART do not have the flow control feature.
    It uses only TX/RX signals.

[2] So, the eternal loop occurrs only when the hardware is broken.
   In this case, the situation is really fatal and I don't think
    it is reasonable to continue to do something.

[3] I checked some (but not all) other serial drivers but I could not find ones
    using timeout and break thing.

Best Regards
Masahiro Yamada