Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753889AbcJ1J0u (ORCPT ); Fri, 28 Oct 2016 05:26:50 -0400 Received: from mail-oi0-f68.google.com ([209.85.218.68]:34394 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750748AbcJ1J0s (ORCPT ); Fri, 28 Oct 2016 05:26:48 -0400 MIME-Version: 1.0 In-Reply-To: <20161027180229.5faqrvxa2a4pos7i@pengutronix.de> References: <20161027160406.25738-1-richard.genoud@gmail.com> <20161027180229.5faqrvxa2a4pos7i@pengutronix.de> From: Richard Genoud Date: Fri, 28 Oct 2016 11:26:26 +0200 Message-ID: Subject: Re: [PATCH v6] tty/serial: at91: fix hardware handshake on Atmel platforms To: =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= Cc: Nicolas Ferre , Alexandre Belloni , Greg Kroah-Hartman , Cyrille Pitchen , "linux-serial@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "#4 . 4+" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id u9S9QtPC013938 Content-Length: 2949 Lines: 61 2016-10-27 20:02 GMT+02:00 Uwe Kleine-König : > Hello Richard, > > On Thu, Oct 27, 2016 at 06:04:06PM +0200, Richard Genoud wrote: >> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c >> index fd8aa1f4ba78..168b10cad47b 100644 >> --- a/drivers/tty/serial/atmel_serial.c >> +++ b/drivers/tty/serial/atmel_serial.c >> @@ -2132,11 +2132,29 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios, >> mode |= ATMEL_US_USMODE_RS485; >> } else if (termios->c_cflag & CRTSCTS) { >> /* RS232 with hardware handshake (RTS/CTS) */ >> - if (atmel_use_dma_rx(port) && !atmel_use_fifo(port)) { >> - dev_info(port->dev, "not enabling hardware flow control because DMA is used"); >> - termios->c_cflag &= ~CRTSCTS; >> - } else { >> + if (atmel_use_fifo(port) && >> + !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) { >> + /* >> + * with ATMEL_US_USMODE_HWHS set, the controller will >> + * be able to drive the RTS pin high/low when the RX >> + * FIFO is above RXFTHRES/below RXFTHRES2. >> + * It will also disable the transmitter when the CTS >> + * pin is high. >> + * This mode is not activated if CTS pin is a GPIO >> + * because in this case, the transmitter is always >> + * disabled (there must be an internal pull-up >> + * responsible for this behaviour). >> + * If the RTS pin is a GPIO, the controller won't be >> + * able to drive it according to the FIFO thresholds, >> + * but it will be handled by the driver. >> + */ >> mode |= ATMEL_US_USMODE_HWHS; > > You use > > !mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS) > > as indicator that the cts mode of the respective pin is used. Is this > reliable? (It's not if there are machines that don't use CTS, neither as > gpio nor using the hardware function.) Maybe this needs a dt property to > indicate that there is no (hw)handshaking available? I used that to filter-out the case where CTS is a GPIO. Now, for the machines that don't use CTS neither as GPIO nor using the hardware function, it's a whole different story, beyond the scope of this patch. And like you said, a DT property could be useful to handle this case. ( It's a little bit like if there was an RS232 cable with just TX/RX/GND, but this will be way harder to detect :) ) Anyway, patches are welcome to handle that, but I don't think it belongs in this one. >> + } else { >> + ... >> } > > Best regards > Uwe > regards, Richard