public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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