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

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

Johan