Don't read a single byte at a time from the serial port. Read
multiple (up to TTY_RD_SZ = 128) bytes with a single read(2) call. Also
write multiple bytes to the terminal (STO) with a single write(2) call.
Some BSDs (and possibly other systems too) have no mark / space parity
support, and they don't define CMSPAR. Define a dummy (zero) CMSPAR in
these cases. If the user tries to set P_MARK or P_SPACE he will get
P_EVEN or P_ODD instead.
CMSPAR is defined by bits/termios.h, and glibc has two flavours of it: a
generic one and an architecture-specific one. glibc will install the
architecture-specific one if it exists, otherwise it will install the
generic one. Only Alpha, MIPS, PPC and Sparc have their own
bits/termios.h.
The generic bits/termios.h, as well as the Alpha, PPC and Sparc flavours
do define CMSPAR. However, the MIPS flavour does not define it.
Define CMSPAR to the value from the generic value, which is also the
value known to the Linux kernel for MIPS.
Patch inspired by:
http://git.buildroot.net/buildroot/commit/?id=78cd32631e959e04b1a2f18be7b0757e21482438
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
For powerpc the termios ioctl numbers are defined with reference to the
argument-structure size. This structure must be the one expected by the
kernel (kernel termios) not the one defined by GLIBC (in
termios.h). Work around this by defining ioctl numbers with reference
to the privately defined termios2 structure.
Applies only to Linux/PowePC, and only if USE_CUSTOM_BAUD is enabled.
The powerpc[64le] arch uses different ioctls for custom baud setting: It
uses the old TCSETS*, TCGETS ioctls, not the new TCSETS*2, TCGETS2 ones.
Cross-compiles cleanly, not tested (no h/w currently available).
In all cases the pattern was tcflush(fd, TCIOFLUSH) followed by
tcsetattr(fd, TCSAFLUSH, ...). The problem was that, for some drivers,
tcflush() was apparently doing nothing, so tcsetattr() might hang
forever waiting for the output buffers to drain (possible if flow
control is enabled). Replaced tcflush(fd, TCSAFLUSH), with tcsetattr(fd,
TCSANOW) which, after a tcflush() should anyway be equivalent.
If the requested baudrate is not a custom one (i.e. does not match one
of the Bxxx macros), then the cfsetospeed_custom() and
cfsetispeed_custom() are called to configure the "nexttermios" structure
with the requested non-standard baudrate. Same thing for reading the
baudrate: If cfgetospeed() and / or cfgetispeed() return a value that is
not among the Bxxx macros, cfgetospeed_custom() and cfgetispeed_custom()
are called, to read (and decode) the non-standard baudrate from the
"nexttermios" structure.
Currently the cf[set|get][i|o]speed_custom functions are only
implemented for Linux, and work only with non-ancient kernels (>2.6). So
in effect, custom baud-rate support is currently only supported for
Linux.
