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:   Fri, 2 Jun 2023 11:46:56 -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: <ZHodALMLTWk72Vvm@mail.minyard.net>
Reply-To: minyard@acm.org
References: <ZEmDs0ASdnEAnpsL@minyard.net>
 <ZGtZKCvo71woGf9T@hovoldconsulting.com>
 <ZGtlnWGSc31Wdhxa@mail.minyard.net>
 <ZHnmSwGyOaSMbPBB@hovoldconsulting.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZHnmSwGyOaSMbPBB@hovoldconsulting.com>
Precedence: bulk

On Fri, Jun 02, 2023 at 02:53:31PM +0200, Johan Hovold wrote:
> On Mon, May 22, 2023 at 07:52:45AM -0500, Corey Minyard wrote:
> > On Mon, May 22, 2023 at 01:59:36PM +0200, Johan Hovold wrote:
> 
> > > I just verified that break works on the first port of my cp2105 but not
> > > on the second one (I seem to receive the last characters sent instead).
> > > 
> > > Apparently this is expected as the datasheet (AN571) says the following
> > > about the SET_BREAK command:
> > > 
> > > 	This command is not supported on the second CP2105 interface.
> > > 
> > > Which port are you seeing this behaviour with?
> > 
> > I'm guessing this is it.  From the schematic I think this is the
> > TXD_ECI pin, though I'm not 100% sure.  I'd have to dig through the
> > device tree and SOC manual to be sure which port is which.
> 
> It should be the second SCI interface which do not support break.
> 
> > Would it be possible to return an error in this situation instead of it
> > silently not working?  Just to avoid others having the same issue.
> 
> 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.

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

-corey

> 
> Johan