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

Masahiro Yamada
2014-07-11T05:37:13Z

Hi Marek,

On Thu, 10 Jul 2014 14:37:18 +0200
Marek Vasut <marex@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@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