From: Russell King <rmk+lkml@arm.linux.org.uk>
To: linux-kernel@vger.kernel.org
Subject: Re: Outstanding fixups (was: Re: [PROBLEM] ircomm ioctls)
Date: Tue, 13 Jan 2004 17:15:45 +0000 [thread overview]
Message-ID: <20040113171544.B7256@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20040113114948.B2975@flint.arm.linux.org.uk>; from rmk+lkml@arm.linux.org.uk on Tue, Jan 13, 2004 at 11:49:48AM +0000
On Tue, Jan 13, 2004 at 11:49:48AM +0000, Russell King wrote:
> And as a follow up, there are about 30 other drivers which still
> reference TIOCM{GET,SET,BIC,BIS} most of which won't work. Some of
> them include drivers that were dumped into drivers/serial (despite
> not using the serial_core stuff.)
Ok, I've just finished giving all those drivers the once over for this
specific problem (and no others.) A general comment is that we have
a hell of a lot of unmaintained crud here. Many of these serial drivers
are still using the global IRQ macros, and therefore are unbuildable in
2.6 kernels.
Specific drivers:
- 68360serial, amiserial, serial167
These need attention - they appear to have had the global IRQ stuff
"cleaned up". IOW, the global IRQ macros have become local IRQ macros
with no regard what so ever to any SMP locking issues.
- moxa
This has a complete lack of locking what so ever.
- pcxx, epca
These seem to do something weird with the semantics of TIOCMSET/BIC/BIS.
and as such have nonstandard behaviour. The driver author needs to
look at this and resolve the issue. As the driver stood previously,
TIOCMBIC/BIS took explicit control of the modem control lines. TIOCMSET
also did this, but only when the modem control line was _set_. If it
were cleared using TIOCMSET, control over this line was returned to the
chip.
This is not how 16x50 ports work when they are in "auto RTS" mode. The
RTS signal is the logical and of the RTS setting and the hardware flow
control, when the hardware flow control is enabled.
- pc300_tty
This seems to think that TIOCMBIC/TIOCMBIS are only used to manipulate
the DTR signal. This is an invalid assumption, so it now has a #error
and comment explaining this fact - IMO the driver author needs to fix
this themselves.
The patch:
drivers/char/amiserial.c | 63 ++++-------
drivers/char/cyclades.c | 157 +++++------------------------
drivers/char/epca.c | 177 ++++++++++++++++++---------------
drivers/char/esp.c | 63 +++++------
drivers/char/ip2main.c | 196 +++++++++++++++----------------------
drivers/char/isicom.c | 72 ++++---------
drivers/char/istallion.c | 94 ++++++++++-------
drivers/char/moxa.c | 97 +++++++++---------
drivers/char/mxser.c | 67 +++++-------
drivers/char/pcxx.c | 146 ++++++++++++++++-----------
drivers/char/rio/rio_linux.c | 5
drivers/char/riscom8.c | 64 +++++-------
drivers/char/rocket.c | 59 -----------
drivers/char/serial167.c | 77 ++------------
drivers/char/sh-sci.c | 46 +++++---
drivers/char/specialix.c | 108 +++++++-------------
drivers/char/stallion.c | 75 ++++++++------
drivers/char/sx.c | 56 +++++-----
drivers/isdn/i4l/isdn_tty.c | 111 +++++++-------------
drivers/macintosh/macserial.c | 72 ++++++++-----
drivers/net/wan/pc300_tty.c | 8 +
drivers/s390/net/ctctty.c | 87 +++++-----------
drivers/sbus/char/aurora.c | 61 ++++-------
drivers/serial/68360serial.c | 98 +++++++-----------
drivers/serial/mcfserial.c | 78 +++++++-------
drivers/tc/zs.c | 68 ++++++------
drivers/usb/serial/ftdi_sio.c | 181 +++++++++++++++-------------------
net/irda/ircomm/ircomm_tty.c | 67 ++++++++++++
net/irda/ircomm/ircomm_tty_ioctl.c | 91 -----------------
29 files changed, 1106 insertions(+), 1438 deletions(-)
Because of the size of the patch, I'm going to mail it out as several
chunks, and will follow up this mail.
1 - drivers which someone has tested and say works.
2 - drivers which have been updated but are untested but should work.
3 - drivers which have been updated but are broken in some way.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
next prev parent reply other threads:[~2004-01-13 17:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-13 11:00 [PROBLEM] ircomm ioctls Jozef Vesely
2004-01-13 11:36 ` Russell King
2004-01-13 11:49 ` Outstanding fixups (was: Re: [PROBLEM] ircomm ioctls) Russell King
2004-01-13 17:15 ` Russell King [this message]
2004-01-13 17:24 ` [1/3] Serial fixups (mostly tested) Russell King
2004-01-24 6:16 ` [lkml] pseudo tty / kernel compile question Karl Tatgenhorst
2004-01-25 21:53 ` David Woodhouse
2004-01-13 17:33 ` [2/3] Russell King
2004-01-13 17:55 ` [2/3] Henrique Oliveira
2004-01-13 18:53 ` [2/3] John Stoffel
2004-01-13 22:15 ` [2/3] Paul Mackerras
2004-01-14 7:01 ` [2/3] Benjamin Herrenschmidt
2004-01-16 11:34 ` [2/3] Matthias Urlichs
2004-01-16 0:54 ` [2/3] Greg KH
2004-01-18 12:43 ` [2/3] Greg Ungerer
2004-01-18 15:42 ` [2/3] Russell King
2004-01-18 23:23 ` [2/3] Greg Ungerer
2004-01-13 17:42 ` [3/3] 2.6 broken serial drivers Russell King
2004-01-13 20:21 ` Andrew Morton
2004-01-13 21:10 ` Russell King
2004-01-18 16:16 ` Russell King
2004-01-14 12:42 ` Maciej W. Rozycki
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=20040113171544.B7256@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox