[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150608091931.GU7557@n2100.arm.linux.org.uk>
Date: Mon, 8 Jun 2015 10:19:31 +0100
From: Russell King - ARM Linux <linux@....linux.org.uk>
To: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
Cc: Bhuvanchandra DV <bhuvanchandra.dv@...adex.com>,
devicetree@...r.kernel.org, kernel@...gutronix.de, moorray3@...pl,
gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
stefan@...er.ch, bhuvanchandra.dv@...il.com,
linux-serial@...r.kernel.org, shawn.guo@...aro.org, jslaby@...e.cz,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH V2 2/3] tty: serial: fsl_lpuart: remove RTS/CTS control
from set/get_mctrl
On Mon, Jun 08, 2015 at 08:41:13AM +0200, Uwe Kleine-König wrote:
> >From reading the commit log I would expect that you only touch the
> set_mctrl function, but not get_mctrl. Assuming your code change is
> right, can you mention this in the commit log please? The bits
> UARTMODEM_TXCTSE and UARTMODEM_RXRTSE only control the automatic mode?
And... another point. UARTMODEM_TXCTSE and UARTMODEM_RXRTSE are the
auto flow control _enable_ signals. That's not something that
get_mctrl() should ever return. get_mctrl() is about reporting the
actual current state of the CTS, DSR, DCD and RI signals _only_.
If the hardware doesn't let you read the state, then reporting that
CTS, DSR and DCD are all asserted is recommended, as that's the
state needed to make the UART do useful stuff. So that part of
this patch is the sane thing to do.
What isn't sane is to use the auto-cts enable bit to report a
ficticious current CTS state.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists