From mboxrd@z Thu Jan 1 00:00:00 1970 From: Masahiro Yamada Date: Thu, 10 Jul 2014 20:31:01 +0900 Subject: [U-Boot] [PATCH 2/6] serial: add UniPhier serial driver In-Reply-To: <201407101214.35324.marex@denx.de> References: <20140710190650.CCBF.AA925319@jp.panasonic.com> <201407101214.35324.marex@denx.de> Message-ID: <20140710203100.CCC7.AA925319@jp.panasonic.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Marek, On Thu, 10 Jul 2014 12:14:35 +0200 Marek Vasut 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. I am not sure if we need to be so careful. Is there any other UART driver using timeout check? (What would U-Boot continue to do in case console cannot display the error message?) Best Regards Masahiro Masahiro