linux-kernel - Re: Trouble with USB serial driver (ftdi

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20090914222851.GA14235@localhost>
Date:	Tue, 15 Sep 2009 00:28:51 +0200
From:	Johan Hovold <jhovold@...il.com>
To:	Greg KH <greg@...ah.com>
Cc:	e9hack <e9hack@...glemail.com>, linux-kernel@...r.kernel.org
Subject: Re: Trouble with USB serial driver (ftdi_sio.c) on 2.6.31

On Mon, Sep 14, 2009 at 09:43:33AM -0700, Greg KH wrote:
> On Sat, Sep 12, 2009 at 02:08:31PM +0200, e9hack wrote:
> > I've some trouble with the USB serial driver (ftdi_sio.c for a FT232RL from FTDI). If the 
> > port is opened for the first time, the driver works perfectly. If the port is closed and 
> > open again, it isn't possible to read any data from port. Writing data to the port works. 
> > The FT232RL must be reconnect to get it working again. A reboot without reconnect doesn't 
> > solve this problem. 

I have a similar problem with the same chip after upgrading to 2.6.31,
although the first read after reconnecting the device (usually) works.

> {sigh}  Yes, this driver is a bit messed up in .31, sorry.  We are
> working through it and hope to have a fix in one of the upcoming
> .31-stable releases.

I've spent some time tracking down the problem and I might have some
information that could be useful:

The commit introducing the regression is
335f8514f200e63d689113d29cb7253a5c282967, which changes the way DTR/RTS
are handled on open; they used to be set prior to setting up the read
urb, now they're set after (in dtr_rts()). Depending on when the first
read callback is made, the driver may stop reading from the device.

The problem became more apparent with
557aaa7ffab639d0190b935a041b16ae44606342 which lowered the device
latency timeout to 1ms, but since setting the timeout does not take
effect until the port is closed and re-opened the driver mostly works
the first time after reconnecting the device.

My test setup opens the port and writes some bytes to a FT232RL with
rx and tx connected, and then reads the looped back data. This usually
works the first time after connecting, whereas reads never return any
data after reopening the port.

When it fails, the first read_bulk callback is made before dtr_rts
returns and port.count is incremented. In particular, the read callback
does not process the data as port.count is 0 at the time and the driver
stops reading from the device. Should the callback be made somewhat
later (as with the default 16ms latency timeout), port.count is non-zero
and all is fine.

Disabling dtr_rts() and calling set_mctrl before setting up the read
urb (as it used to be done) fixes the problem and could be used as a
temporary work-around. But I guess the read callback must be made able
to handle a port count of zero?

Let me know if I can help out with implementing or testing any fixes.

Regards,
Johan Hovold

--
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/