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.
Best regards, Marek Vasut