Re: Break doesn't work on a CP2105

From: Corey Minyard
Date: Sun Jun 04 2023 - 16:11:54 EST


On Sun, Jun 04, 2023 at 02:17:16PM +0200, Johan Hovold wrote:
> 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

I couldn't get that to work (didn't try too hard), so I just stuck in a dev_info():

[ 4.253869] usb 2-1.2: new full-speed USB device number 3 using ehci-pci
[ 4.342570] usb 2-1.2: New USB device found, idVendor=10c4, idProduct=ea70, bcdDevice= 1.00
[ 4.350939] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[ 4.358259] usb 2-1.2: Product: CP2105 Dual USB to UART Bridge Controller
[ 4.365052] usb 2-1.2: Manufacturer: Silicon Labs
[ 4.369765] usb 2-1.2: SerialNumber: 01070456
[ 4.374925] cp210x 2-1.2:1.0: cp210x converter detected
[ 4.381086] cp210x 2-1.2:1.0: cp210x_get_fw_version - 1.18.1
[ 4.386915] usb 2-1.2: cp210x converter now attached to ttyUSB0
[ 4.393529] cp210x 2-1.2:1.1: cp210x converter detected
[ 4.399835] cp210x 2-1.2:1.1: cp210x_get_fw_version - 1.18.1
[ 4.405657] usb 2-1.2: cp210x converter now attached to ttyUSB1

This is an embedded reference board, I guess there is some probability
that this is just broken on this board, though I'm not quite sure how.

Thanks for working on this.

-corey