The code for the second port was accidentally expanded into
usb_serial3.c, while the code for the third port was expanded in
usb_serial2.c.

Fixes: cd4c30fde5 ("Expand all USB serial 2 & 3 stuff (needed for Arduino IDE use)")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>

Add support for a dual serial port configuration (USB_DUAL_SERIAL),
providing a composite USB device, comprised of two serial ports.
The second serial port is called usb_serial2 (C) or SerialA (C++).

Note that no dummy C++ class is created if USB_DISABLED is defined,
unlike for the first port.

This increases binary size by ca. 1.2 KiB (720 bytes for USB buffers).

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>

Extract core USB serial functionality in a new usb_serial_port C class,
to allow creating multiple USB serial instances without duplicating all
code.

The original API is retained by creating static inline functions and
preprocessor macros using the old names, which are wrappers around the
new usb_serial_port functions and data members.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>

https://forum.pjrc.com/threads/40893-Incorrect-return-for-Serial-write()-on-Teensy-3-6?p=127732#post127732

I'm not sure if this fix has some side-effects - how will other functions react when it does not return zero anymore ?

Sometimes the PC or Mac drivers are not actually ready to begin receiving data immediately after they cause DTR or RTS to assert.  This delay allows the PC to become ready before we tell sketches the Serial device is true (ready).

https://groups.google.com/a/arduino.cc/d/msg/developers/ls3hkviFYM4/XWT2LbfzNcgJ