Re: Re: [PATCH V5.1] serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers

From: Yoshihiro YUNOMAE
Date: Wed Apr 16 2014 - 22:39:11 EST


Hi Stephen,

Thank you for your reply.

(2014/04/17 2:04), Stephen Warren wrote:
On 04/15/2014 08:08 PM, Yoshihiro YUNOMAE wrote:
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c

@@ -2275,10 +2276,9 @@ serial8250_do_set_termios(struct uart_port
*port, struct ktermios *termios,

if (up->capabilities & UART_CAP_FIFO && port->fifosize > 1) {
- fcr = uart_config[port->type].fcr;
- if ((baud < 2400 && !up->dma) || fifo_bug) {
- fcr &= ~UART_FCR_TRIGGER_MASK;
- fcr |= UART_FCR_TRIGGER_1;
+ /* NOTE: If fifo_bug is not set, a uaser can set RX_trigger. */
+ if ((baud < 2400 && !up->dma &&
+ (up->fcr == uart_config[port->type].fcr)) ||
up->fifo_bug) {
+ up->fcr &= ~UART_FCR_TRIGGER_MASK;
+ up->fcr |= UART_FCR_TRIGGER_1;
}
}

Does the "(up->fcr == uart_config[port->type].fcr)" term prevent the
user from changing the trigger level multiple times? Perhaps this is
intended?

No, this means that if a user changed FCR value before setting termios,
use the changed value because the user think changed value is always
set. But, I thought this is not straightforward and it cannot help
when the user want to use default FCR value.
Could I add FCR changed flag(user_changed_fcr) in uart_8250_port
structure and check the flag here?
Or shouldn't the driver check the user changing?

Oh, I wasn't aware that the user could change FCR directly. To be
honest, I'm not sure of the best way to resolve that kind of conflict...

OK. For simplicity, I don't implement the checking.
Even if FCR is changed here, users can change it any time, so this is
not so big problem, I think.

Thanks,
Yoshihiro YUNOMAE

--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae.ez@xxxxxxxxxxx


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/