From: David Newall <davidn@davidnewall.com>
To: Greg KH <greg@kroah.com>
Cc: linux-usb@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Handshaking on USB serial devices
Date: Fri, 15 Feb 2008 15:49:34 +1030 [thread overview]
Message-ID: <47B520E6.5030809@davidnewall.com> (raw)
In-Reply-To: <20080214204744.GB17277@kroah.com>
Greg KH wrote:
> On Thu, Feb 14, 2008 at 07:55:44PM +1030, David Newall wrote:
>
>> The current 2.6 driver maintains it's own buffer. I think that's a bad
>> thing: usbserial already buffers writes, and the extra buffer copy seems
>> unnecessary, however it does solve the putchar problem. Buffered (i.e.
>> by the 2.6 series pl2303 driver) data is written as soon as practicable,
>> regardless of CTS/DTR. The same general workaround, but placed in
>> pl2303_send seems correct to me; that is, stop submitting write urbs
>> when the remote end lowers CTS/DTR, and trigger the resume from the
>> interrupt callback (specifically in update_line_status.)
>>
>
> Where does the usbserial core buffer writes on 2.6? The serial_write()
> function just passes the data straight down to the usb-serial child
> driver directly, no copying or buffering happens that I can see.
>
You're right. I haven't examined the 2.6 stack as closely as the 2.4.
I noticed the buffer in 2.6 pl2303, but didn't check 2.6 usb-serial. I
think I prefer the buffer in usb-serial, because its centralised rather
than in each driver, but I'm not going to step up to the plate and
propose changing that!
>> To make it clear: Even aside from the buffer in 2.6's pl2303.c, there's
>> a race: An in-flight write URB can fill all hardware buffers, making
>> unsafe what previously appeared to be a safe write. I think it's
>> essential to delay submission of the URB on a stop-transmit condition.
>>
>
> It's up to the individual driver to know when their buffers are filled
> up. The big problem is, a lot of these cheap usb-serial devices (like
> the pl2303) don't have a way to report the uart queue filled-state back
> to the host, so things can easily get over-run as you have found out.
>
My understanding of the problem has developed over the last couple of
days; going from wrist-deep to elbow-deep into the guts of things does
that. There is a problem, and the solution I've been developing
addresses it, but maybe there's a simpler answer. Hope to have a patch
together soon.
next prev parent reply other threads:[~2008-02-15 5:19 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-13 14:45 Handshaking on USB serial devices David Newall
2008-02-14 5:02 ` Greg KH
2008-02-14 9:25 ` David Newall
2008-02-14 12:10 ` Alan Cox
2008-02-14 16:16 ` Gene Heskett
2008-02-14 16:31 ` Alan Cox
2008-02-14 17:55 ` Gene Heskett
2008-02-14 19:37 ` Alan Cox
2008-02-14 20:04 ` Gene Heskett
2008-02-14 20:52 ` Greg KH
2008-02-14 21:32 ` Gene Heskett
2008-02-15 5:08 ` David Newall
2008-02-14 22:39 ` Krzysztof Halasa
2008-02-14 23:09 ` Gene Heskett
2008-02-14 18:04 ` David Newall
2008-02-14 18:53 ` David Brownell
2008-02-14 19:36 ` Alan Cox
2008-02-21 15:22 ` David Newall
2008-02-21 15:15 ` Alan Cox
2008-02-21 19:35 ` David Newall
2008-02-21 20:58 ` Greg KH
2008-02-14 20:47 ` Greg KH
2008-02-15 5:19 ` David Newall [this message]
2008-02-14 11:55 ` Alan Cox
[not found] <9Wr5Z-7cw-1@gated-at.bofh.it>
[not found] ` <9WSJ4-222-21@gated-at.bofh.it>
[not found] ` <9WTlN-2T0-7@gated-at.bofh.it>
[not found] ` <9WTYn-3Zb-29@gated-at.bofh.it>
2008-02-15 12:00 ` Bodo Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47B520E6.5030809@davidnewall.com \
--to=davidn@davidnewall.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.