| Message ID | 1379938052-6026-1-git-send-email-jiri.prchal@aksignal.cz (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Sep 23, 2013 at 02:07:32PM +0200, Jiri Prchal wrote:
> This patch adds 9bit data possibility for serial_core. Please confirm that I did it right way at right place. I'll make atmel_serial driver for 9bit data later.
Please wrap your lines properly.
I'd rather wait to add this type of patch _after_ you have tested it and
verified that your driver works, and take that patch at the same time.
Otherwise, this is just added cruft that no one is using, and I'd have
to remove it :)
thanks,
greg k-h
Dne 27.9.2013 00:47, Greg KH napsal(a): > On Mon, Sep 23, 2013 at 02:07:32PM +0200, Jiri Prchal wrote: >> This patch adds 9bit data possibility for serial_core. Please confirm that I did it right way at right place. I'll make atmel_serial driver for 9bit data later. > > Please wrap your lines properly. > > I'd rather wait to add this type of patch _after_ you have tested it and > verified that your driver works, and take that patch at the same time. > > Otherwise, this is just added cruft that no one is using, and I'd have > to remove it :) No one is using it because it is NOT implemented. Try to search internet for "9bit serial" to see how many people like to use it. But I probably not bother to do it and I'll try some tricks with parity. As many others. Best regard Jiri
On Fri, Oct 11, 2013 at 01:59:00PM +0200, Ji?í Prchal wrote: > > > Dne 27.9.2013 00:47, Greg KH napsal(a): > >On Mon, Sep 23, 2013 at 02:07:32PM +0200, Jiri Prchal wrote: > >>This patch adds 9bit data possibility for serial_core. Please confirm that I did it right way at right place. I'll make atmel_serial driver for 9bit data later. > > > >Please wrap your lines properly. > > > >I'd rather wait to add this type of patch _after_ you have tested it and > >verified that your driver works, and take that patch at the same time. > > > >Otherwise, this is just added cruft that no one is using, and I'd have > >to remove it :) > No one is using it because it is NOT implemented. Then implement it. > Try to search internet for "9bit serial" to see how many people like to use it. Again, then implement it, I can't add code to the kernel that no one uses, that would be cruft and be deleted, right? > But I probably not bother to do it and I'll try some tricks with parity. > As many others. Why not just implement it, then it can stay, right? thanks, greg k-h
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index 0f02351..cbe83db 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -283,9 +283,13 @@ uart_update_timeout(struct uart_port *port, unsigned int cflag, case CS7: bits = 9; break; + case CS8: default: bits = 10; break; /* CS8 */ + case CS9: + bits = 11; + break; } if (cflag & CSTOPB) diff --git a/include/uapi/asm-generic/termbits.h b/include/uapi/asm-generic/termbits.h index 232b478..120650d 100644 --- a/include/uapi/asm-generic/termbits.h +++ b/include/uapi/asm-generic/termbits.h @@ -128,7 +128,7 @@ struct ktermios { #define B38400 0000017 #define EXTA B19200 #define EXTB B38400 -#define CSIZE 0000060 +#define CSIZE 004000000060 #define CS5 0000000 #define CS6 0000020 #define CS7 0000040 @@ -157,6 +157,7 @@ struct ktermios { #define B3500000 0010016 #define B4000000 0010017 #define CIBAUD 002003600000 /* input baud rate */ +#define CS9 004000000000 /* 9bit data */ #define CMSPAR 010000000000 /* mark or space (stick) parity */ #define CRTSCTS 020000000000 /* flow control */
This patch adds 9bit data possibility for serial_core. Please confirm that I did it right way at right place. I'll make atmel_serial driver for 9bit data later. Signed-off-by: Jiri Prchal <jiri.prchal@aksignal.cz> --- drivers/tty/serial/serial_core.c | 4 ++++ include/uapi/asm-generic/termbits.h | 3 ++- 2 files changed, 6 insertions(+), 1 deletion(-)