Re: A simpler tty driver model

[Martin Husemann <martin%duskware.de@localhost>]

On Sat, Jul 27, 2013 at 11:52:20PM -0700, Matt Thomas wrote:
> 
> I have several SoC targets that I've stalled on due to the need of writing
> a tty driver.  Sure I could cut & paste from another driver but having to
> do that 3+ times seems inordinately stupid.  So I've been thinking of 
> making that c&p'ed code into a common tty driver and exporting a small of
> h/w specific functions.

This sounds like a good idea. Minor nits...

>       int (*t_status)(void *v);
> if t_getc returns -1, call this to reason for input error.
> (framing error, parity error, etc.)

You mean t_getbuf()?
Wouldn't it be better to give that an int *error arg instead?

>       int (*t_active)(void *v, u_int signals);
> Set the following signal(s) in sigmals to active (CTS,RTS,DTR,DTS,CD,etc).

With "active" you mean "allow the hardware to use them", not "make the signal
show up on the external port"? What if hardware does not support some of
the requested signals?

>       int (*t_setmode)(void *v, u_int mode);
> contains the char width, stop bits, speed, partity (even, odd, none)
> speed is in the low 24 bits and everything else in the top 8.
> if the top 8 bits are 0, that will mean 8 bit, 1 stop, no parity.
> bits 24:25 is char size (8-[25:24]), 27:26 stop bits (1 + [27:26]/2)
> bits 31:30 are parity (3 = odd, 2 = even, 0 = none).

Why pack args here? It is not a chip, just an internal API.
Is a method to query supported speeds needed?


Martin