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...@hitachi.com


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

Reply via email to