Date: Fri, 2 Oct 2009 10:53:14 +0100
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: linux-usb@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] USB: ftdi_sio: Remove tty->low_latency.
Message-ID: <20091002105314.33d54bc5@lxorguk.ukuu.org.uk>
In-Reply-To: <20091002100430.58785957@lxorguk.ukuu.org.uk>
References: <20090924154023.GA27480@localhost>
	<200909242103.48562.oliver@neukum.org>
	<20090924202107.4730f2af@lxorguk.ukuu.org.uk>
	<20090924211459.GB27963@localhost>
	<4ABD020B.4040901@gandalf.sssup.it>
	<20090929145514.GF2152@localhost>
	<20090929235232.1ae6c63b@lxorguk.ukuu.org.uk>
	<m163ayzevu.fsf@fess.ebiederm.org>
	<20091002100430.58785957@lxorguk.ukuu.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1126
Lines: 24

Having had a look through the driver someone with docs or similar needs
to explain how the ftdi_sio does hardware and software flow control. It
has throttle/unthrottle methods but these just stall the URB queuing and
don't do any flow processing of their own at all. Does the ftdi_sio do
this in hardware when the urbs run low ?

Otherwise it can certainly be simplified a lot. In particular at the
point you get throttle event you've got about 64K of cushion to react
(flow control being async anyway) and you actually *want* to pull data
after you whack the modem lines because the other end also has a latency
to respond.

So all the clever partial processing of urb stuff is overkill. Whether it
needs not to repost urbs to the device or to implement flow control in
software I don't know without docs.

With that done the driver ought to be a good deal easier to debug.

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