linux-kernel - Re: [PATCH 2/2] USB: serial: cp210x: Workaround for occasional cp2108 hangs.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20151020075006.GB20289@localhost>
Date:	Tue, 20 Oct 2015 09:50:06 +0200
From:	Johan Hovold <johan@...nel.org>
To:	Konstantin Shkolnyy <konstantin.shkolnyy@...il.com>
Cc:	johan@...nel.org, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] USB: serial: cp210x: Workaround for occasional
 cp2108 hangs.

On Mon, Oct 19, 2015 at 05:01:40PM -0500, Konstantin Shkolnyy wrote:
> This patch can only be applied after the patch titled
> "USB: serial: cp210x: Implement 16-bit register access functions"

No need to put this in the commit message, ordering is assumed to be
correct when you submit a series of patches.

> Work around 2 cp2108 bugs:
> 
> 1) cp2108 GET_LINE_CTL returns the 16-bit value with the 2 bytes swapped.
> However, SET_LINE_CTL functions properly. When the driver tries to modify
> the register, it reads it, modifies some bits and writes back. Because
> the read bytes were swapped, this often results in an invalid value to be
> written. In turn, this causes cp2108 respond with a stall. The stall
> sometimes doesn't clear properly and cp2108 starts responding to following
> valid commands also with stalls, effectively failing.
> 
> 2) Occasionally, writing data and immediately closing the port makes cp2108
> stop responding. The device had to be unplugged to clear the error.
> The failure is induced by shutting down the device while its Tx queue still
> has unsent data. This condition is avoided by issuing PURGE command from
> the close() callback.

Two distinct fixes need to go in separate patches.

You should end up with something like the following series

 - fix hang after close (purge)
 - refactor lcr handling
 - fix cp2108 lcr handling
 - more clean ups...

Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/