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:   Mon, 22 May 2023 07:52:45 -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: <ZGtlnWGSc31Wdhxa@mail.minyard.net>
Reply-To: minyard@acm.org
References: <ZEmDs0ASdnEAnpsL@minyard.net>
 <ZGtZKCvo71woGf9T@hovoldconsulting.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZGtZKCvo71woGf9T@hovoldconsulting.com>
Precedence: bulk

On Mon, May 22, 2023 at 01:59:36PM +0200, Johan Hovold wrote:
> Hi Corey,
> 
> and sorry about the late reply on this.

Not a problem, thanks for replying.

> 
> On Wed, Apr 26, 2023 at 03:04:03PM -0500, Corey Minyard wrote:
> > I have a development board with a CP2105 on it, and I was trying to send
> > a break to it to do a sysrq.  And it wasn't working.
> > 
> > I have verified that the target driver works by setting a really slow
> > baud rate and sending something with a lot of zero bits.  It got breaks
> > just fine.
> > 
> > If I use TCSBRK, it seems to just send a short time with zeros, not
> > even a full character's worth.  It receives a valid character with the
> > top few bits set.  If I use TCSBRKP with a longer time, like 2.5
> > seconds, it waits the whole time, then at the very end it gets the
> > character as with the shorter break.
> > 
> > I can't find a programming manual for the chip, and I'm not sure what's
> > going on.
> 
> 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.

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.

Thank you,

-corey