Firstly some architecture maintainers still haven't updated their
platform for arbitary tty speeds. The kernel is going to start whining
and issuing warnings on your platform if you don't keep up with the
programme (its been 6 months).
Secondly a lot of driver level code for termios methods is very very wrong
indeed. I've been trawling through and fixing the USB stuff in part but
some of it will need maintainer attention once the next changes go in.
- The termios interface says that you hand back the actual mode you set.
This means that if your driver sets a different speed, can't do the
selected parity etc you *MUST* update the passed tty->termios to reflect
your hardware. Mostly this seems to be the lack of support for mark/space
parity but if you've got a very limited specialist device you may need to
write a lot more (indeed the empeg effectively writes the entire termios)
- If your hardware has no termios features don't provide a dummy handler
just don't provide one. In that case the kernel will (as of updates) do
the right thing and preserve the previous speed and other hardware
parameters while updating the software ones.
- We now support seperate input and output speeds. Hardware that does
this wants updating accordingly
- If your hardware is initializing termios structures or copying and
editing them itself it is responsible for encoding c_ispeed/c_ospeed.
Right now there are some hacks to do it for you if you forget in most
cases, they will go away.
- The new code will add two types of helper to deal with the more horrible
bits of all this
tty_encode_baud_rate(tty, inputbaud, outputbaud)
tty_termios_encode_baudrate(termios, inputbaud, outputbaud)
and also
tty_termios_copy_hw(new, old)
which will copy all the hardware implemented bits and speed from old to
new, which may be useful if your hardware needs to copy the old state
over and implements very little.
The speed encoding routines know about Bfoo encoding, arbitary rates and
also provide error tolerances so that programs using the Bfoo style speed
setup generally get Bfoo not BOTHER responses. Please don't put hacks for
this in drivers - if a case breaks then let me know and I'll fix the
encoder centrally.
Once all this is in the kernel will then acquire correct POSIX semantics
and error the ioctl if no requested change can be made.
Next stop after that is likely to be the open/close/hangup path.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
