On 2014-02-26, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote: > Hi Grant, > > I know this is old but I had marked this for re-review in my mail, > and after re-looking at this problem, I realized I gave you some bad info. > > Since you were referring to uart_ops, I'll assume this is for your > serial-core mini-driver(s). Yup. Upon review of this thread, I see that you had warned me that tty->receive_room was going away, and I completely forgot about that warning and didn't do anything about it about that until my drivers actually broke 8 months later. Shame on me. >>>>> How does the rx fifo get flushed when the user calls tcflush(TCIFLUSH)? >>>> >>>> It doesn't. > > The ioctl(TCIFLUSH) does in fact flush the tty buffers. > > If you want to flush your hardware rx fifo, you can define the > .ioctl() method in your struct uart_ops and handle TCIFLUSH there. > > Note: be sure to return -ENOIOCTLCMD so that TCIFLUSH processing > still gets seen by the ldisc! > > Like this (apologies in advance for formatting; my mailer is > dain-bramaged), > > /* called with port->mutex held */ > static int xxxxxx_ioctl(struct uart_port *port, unsigned int cmd, > unsigned long arg) > { > if (cmd == TCFLSH) { > switch (arg) { > case TCIFLUSH: > case TCIOFLUSH: > spin_lock_irq(&port->lock); > xxxxxx_empty_rx_fifo(port); > spin_unlock_irq(&port->lock); > /* fall-through */ > } > } > return -ENOIOCTLCMD; > } > > Sorry, hope this isn't too late :( Great! That's certalinly simple enough. It turns out the customer's problem had nothing to do with the UART's rx fifos not getting flushed when TCIFLUSH was done, so I put that issue on the list of things to be worried about later (and that's where it still is). I'll add the above handling to my drivers just to be complete, but I don't think it's actually ever caused any problems. -- Grant Edwards grant.b.edwards Yow! I was making donuts at and now I'm on a bus! gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html