linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Adam J. Richter" <adam@yggdrasil.com>
To: EdV@macrolink.com
Cc: driver@jpl.nasa.gov, dwmw2@infradead.org, linux-kernel@vger.kernel.org
Subject: RE: devfs + PCI serial card = no extra serial ports
Date: Fri, 14 Mar 2003 12:28:47 -0800	[thread overview]
Message-ID: <200303142028.MAA02437@adam.yggdrasil.com> (raw)

On Fri, 14 Mar 2003 at 11:49:54, Ed Vance wrote:
>The largest gotcha that I am aware of for the PCI/setserial command 
>combination is the inability to automatically "follow" the card when 
>its address changes due to adding or removing an unrelated PCI device. 
>Even so, the system is unlikely to crash because the driver checks the 
>LSR register for impossible values and cuts off access when the UART 
>is not present.

	I would expect that setserial should only be used in cases
where this information is not reliably determinable by the kernel
through hardware device ID facilities, such as what we have in PCI,
USB, etc.  If that is not already the case, it should be
straightforward to fix in the kernel sources, which seemed to be most
of what the "3 Serial issues up for discussion" thread was about
(thanks for the pointer).  There was tangential mention in that thread
of a "/proc/serialdev" interface, but nobody really identified any
real benefit to it over the existing "uart: unknown" system.

	Anyhow, my primary point in this discussion is just to say
that, as far as I can tell, devfs does not impede the serial driver
from doing what Ted Ts'o seemed to be describing.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."


             reply	other threads:[~2003-03-14 20:18 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-14 20:28 Adam J. Richter [this message]
2003-03-14 20:43 ` devfs + PCI serial card = no extra serial ports Russell King
  -- strict thread matches above, loose matches on Subject: below --
2003-03-15  0:54 Ed Vance
2003-03-15  0:02 Adam J. Richter
2003-03-14 19:49 Ed Vance
2003-03-14 20:07 ` Russell King
2003-03-14 19:06 Adam J. Richter
2003-03-10 18:37 Adam J. Richter
2003-03-10 17:12 Ed Vance
2003-03-08 19:48 Adam J. Richter
2003-03-10 18:25 ` Bryan Whitehead
2003-03-14 15:23   ` David Woodhouse
2003-03-08  1:30 Ed Vance
2003-03-07 23:57 Ed Vance
2003-03-08  0:59 ` Bryan Whitehead
2003-03-11  9:07 ` Theodore Ts'o
2003-03-07 23:40 Ed Vance
2003-03-08  0:15 ` Marek Michalkiewicz
2003-03-07 23:04 Ed Vance
2003-03-07 23:17 ` Bryan Whitehead
2003-03-07 22:51 Bryan Whitehead
2003-03-07 22:55 ` Bryan Whitehead
2003-03-07 23:28 ` Bryan Whitehead
2003-03-08  0:10   ` Marek Michalkiewicz
2003-03-07 23:38 ` Theodore Ts'o
2003-03-11 23:12 ` whitnl73

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=200303142028.MAA02437@adam.yggdrasil.com \
    --to=adam@yggdrasil.com \
    --cc=EdV@macrolink.com \
    --cc=driver@jpl.nasa.gov \
    --cc=dwmw2@infradead.org \
    --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;
as well as URLs for NNTP newsgroup(s).