Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Corey Minyard <tcminyard@gmail.com>
Date:   Sun, 4 Jun 2023 15:11:43 -0500
From:   Corey Minyard <minyard@acm.org>
To:     Johan Hovold <johan@kernel.org>
Cc:     Craig Shelley <craig@microtron.org.uk>,
        Linux Kernel <linux-kernel@vger.kernel.org>,
        linux-usb@vger.kernel.org
Subject: Re: Break doesn't work on a CP2105
Message-ID: <ZHzv/wbwtaLVpfaP@mail.minyard.net>
Reply-To: minyard@acm.org
References: <ZEmDs0ASdnEAnpsL@minyard.net>
 <ZGtZKCvo71woGf9T@hovoldconsulting.com>
 <ZGtlnWGSc31Wdhxa@mail.minyard.net>
 <ZHnmSwGyOaSMbPBB@hovoldconsulting.com>
 <ZHodALMLTWk72Vvm@mail.minyard.net>
 <ZHyAzHVAu3DVgJG_@hovoldconsulting.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZHyAzHVAu3DVgJG_@hovoldconsulting.com>
Precedence: bulk

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@kernel.org
> > 
> > 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