On Fri, Jun 02, 2023 at 11:46:56AM -0500, Corey Minyard wrote: > On Fri, Jun 02, 2023 at 02:53:31PM +0200, Johan Hovold wrote: > > I just posted a patch series which does that. The USB serial drivers do > > not currently return any errors related to break signalling even though > > this has been possible since 2008. > > > > The same mechanism can be used to report that break signalling is not > > supported by a device or driver, but the USB serial drivers would be the > > first tty drivers that actually do this. If it turns out to cause any > > trouble we can still use this series to avoid the unnecessary wait. > > > > Care to give the series a try? > > > > https://lore.kernel.org/lkml/20230602124642.19076-1-johan@xxxxxxxxxx > > I have tested this series. I can verify that one of the CP2105 ports > (ttyUSB0) does not return an error on sending the break, and the other > (ttyUSB1) does. This is the only USB serial device on the system. Thanks for testing. > However, the device hooked to the remote console (ttyUSB0), the one not > returning an error on sending a break, still doesn't send a break. So > my problem isn't fixed :-(. > > # ls -l /dev/serial/by-path > total 0 > lrwxrwxrwx 1 root root 13 Jun 2 15:28 pci-0000:00:1d.0-usb-0:1.1:1.0-port0 -> ../../ttyUSB0 > lrwxrwxrwx 1 root root 13 Jun 2 15:28 pci-0000:00:1d.0-usb-0:1.1:1.1-port0 -> ../../ttyUSB1 Ok, at least that matches what you found in schematics about this being the ECI (and thus first) port. I just verified break signalling on the first port of my CP2105 using a logic analyser and everything seems to work as expected. There's also no mention of any issue with break in the errata. Could you check which firmware revision you have by enabling debugging and reconnecting the device? For example: echo func cp210x_get_fw_version +p > /sys/kernel/debug/dynamic_debug/control Johan
