From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Edwards Subject: Re: API to flush rx fifo? Date: Fri, 14 Jun 2013 15:17:09 +0000 (UTC) Message-ID: References: <51BB2C2A.9050601@hurleysoftware.com> Return-path: Received: from plane.gmane.org ([80.91.229.3]:39947 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753416Ab3FNPRd (ORCPT ); Fri, 14 Jun 2013 11:17:33 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UnVkn-0004A3-4F for linux-serial@vger.kernel.org; Fri, 14 Jun 2013 17:17:29 +0200 Received: from dsl.comtrol.com ([64.122.56.22]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Jun 2013 17:17:29 +0200 Received: from grant.b.edwards by dsl.comtrol.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Jun 2013 17:17:29 +0200 Sender: linux-serial-owner@vger.kernel.org List-Id: linux-serial@vger.kernel.org To: linux-serial@vger.kernel.org On 2013-06-14, Peter Hurley wrote: > On 06/12/2013 04:03 PM, Grant Edwards wrote: >> I see the uart_ops.flush_buffer method which is used to flush the >> UART's tx fifo (presumably when the user calls tcflush(TCOFLUSH)). >> >> How does the rx fifo get flushed when the user calls tcflush(TCIFLUSH)? > > It doesn't. Thanks. I couldn't see any mechanism to do that, and I thought I must be missing something. > If you're seeing stale i/o, it's more likely due to the flip buffers > not being flushed Probably. There is a scenario where you can get old data because the rx fifo isn't flushed, but I suspect it's not what my customer is complaining about. FWIW, here's the scenario I'm worrying about: 1) Enable either RTS/CTS or Xon/Xoff flow control for a UART driver that handles that flow control in hardware[1]. 2) Stop making read() calls on the tty device. 3) The buffers in the tty layer fill up, so the uart driver stops transferring data from the rx fifo to the tty layer. 4) The rx fifo fills up, and the flow control stops the other end from sending data. [all working OK up to this point, now you wait for an arbitrary amount of time] 5) tcflush(TCIFLUSH) is called. [data in the tty layer gets flushed, but old data in the rx fifo remains] 6) Now that there's room for more rx data in the tty layer, the uart driver resumes transferring (old) data from the rx fifo to the tty layer. 7) read() is called and returns data that was received an arbitrary amount of time before tcflush(TCIFLUSH) was called. My "old" drivers that interfaced directly with the tty layer handled this scenario, but those drivers were becoming unmaintainable because of instability of the tty API over the range of kernel versions I support. So, I converted them over to be "uart drivers" for the common serial layer which has a much more stable API (and generally requires much less code). Now I've got a customer complaining about not being able to flush data, so I'm looking closer at how the tcflush() calls are handled. [1] Because of a bug in the serial-driver layer's handling of the setting of Xon/Xoff characters by the settermios() call, it's not possible to correctly use Xon/Xoff support in a UART for the case where the user wants to use non-default Xon/Xoff characters. -- Grant Edwards grant.b.edwards Yow! I feel ... JUGULAR ... at gmail.com