From: Al Borchers <alborchers@steinerpoint.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-usb-devel <linux-usb-devel@lists.sourceforge.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: new locking in change_termios breaks USB serial drivers
Date: Fri, 01 Oct 2004 11:24:03 -0500 [thread overview]
Message-ID: <415D84A3.6010105@steinerpoint.com> (raw)
In-Reply-To: 1096630567.21871.4.camel@localhost.localdomain
Alan Cox wrote:
> How much of a problem is this, would it make more sense to make the
> termios locking also include a semaphore to serialize driver side events
> and not the spin lock ?
Its a design decision for the tty layer. You should choose whatever is
best there and the drivers will have to adapt.
I don't know how many tty drivers have assumed that set_termios can sleep,
like the USB serial drivers have. If that is an implicit part of tty API
that other drivers depend on, then, if possible, it seems much better to keep
the API the same and continue to allow set_termios to sleep.
I think the USB serial drivers can just queue up urbs to the device
with commands to set the termios settings and return without waiting
for those urbs to complete. There are potential synchronization issues,
however. The termios settings might go into different USB queues than
the data, and so it is possible that data sent immediately after a
set_termios might get to the device before the new termios settings.
To correctly support TCSETAW/TCSETSW the USB serial drivers would have to
have two different versions of set_termios--a non sleeping one to be called
through the tty API and a sleeping one to use with TCSETAW/TCSETSW ioctls
so the ioctl would not return until the settings were guaranteed to have
taken effect. Not many USB serial drivers support TCSETAW/TCSETSW now.
-- Al
next prev parent reply other threads:[~2004-10-01 16:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-01 10:40 new locking in change_termios breaks USB serial drivers Al Borchers
2004-10-01 11:36 ` Alan Cox
2004-10-01 16:24 ` Al Borchers [this message]
2004-10-01 15:49 ` Alan Cox
2004-10-01 18:14 ` [linux-usb-devel] " Al Borchers
2004-10-02 15:08 ` Alan Cox
2004-10-02 17:19 ` Al Borchers
2004-10-01 20:15 ` Stuart MacDonald
2004-10-01 17:42 ` Greg KH
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=415D84A3.6010105@steinerpoint.com \
--to=alborchers@steinerpoint.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox