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;
Date:   Sun, 4 Jun 2023 14:17:16 +0200
From:   Johan Hovold <johan@kernel.org>
To:     Corey Minyard <minyard@acm.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: <ZHyAzHVAu3DVgJG_@hovoldconsulting.com>
References: <ZEmDs0ASdnEAnpsL@minyard.net>
 <ZGtZKCvo71woGf9T@hovoldconsulting.com>
 <ZGtlnWGSc31Wdhxa@mail.minyard.net>
 <ZHnmSwGyOaSMbPBB@hovoldconsulting.com>
 <ZHodALMLTWk72Vvm@mail.minyard.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZHodALMLTWk72Vvm@mail.minyard.net>
Precedence: bulk

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

Johan