[PATCH] serial: prepare for 9bit data

[PATCH] serial: prepare for 9bit data

[Jiri Prchal]

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(-)

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 */
 
-- 
1.7.9.5

[PATCH] serial: prepare for 9bit data

[Jiri Prchal]

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(-)

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 */
 
-- 
1.7.9.5

Re: [PATCH] serial: prepare for 9bit data

[Greg KH]

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

[PATCH] serial: prepare for 9bit data

[Greg KH]

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

Re: [PATCH] serial: prepare for 9bit data

[Jiří Prchal]

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

[PATCH] serial: prepare for 9bit data

[Jiří Prchal]

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

Re: [PATCH] serial: prepare for 9bit data

[Greg KH]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] serial: prepare for 9bit data

[Greg KH]

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