public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: Gunther Mayer <Gunther.Mayer@t-online.de>
Cc: no To-header on input <"unlisted-recipients:;"@havoc.gtf.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)
Date: Sat, 07 Apr 2001 17:52:28 -0400	[thread overview]
Message-ID: <3ACF8C1C.7CFF675A@mandrakesoft.com> (raw)
In-Reply-To: <3ACECA8F.FEC9439@eunet.at> <3ACED679.7E334234@mandrakesoft.com> <20010407111419.B530@redhat.com> <3ACF5F9B.AA42F1BD@t-online.de> <20010407200340.C3280@redhat.com> <3ACF6920.465635A1@mandrakesoft.com> <3ACF790B.72171236@t-online.de>

Gunther Mayer wrote:
> 
> Jeff Garzik wrote:
> >
>  Like I mentioned in a
> > previous message, the Via parport code is ugly and should go into a Via
> > superio driver.  It is simply not scalable to consider the alternative
> > -- add superio code to parport_pc.c for each ISA bridge out there.  I
> > think the same principle applies to this discussion as well.
> 
> Yes, superio will go away and replaced by user level utility:
> http://home.t-online.de/home/gunther.mayer/lssuperio-0.61.tar.bz2

The entire point of superio is -not- configuration.  That's what your
BIOS setup does, and/or user-level utilities.

The point of superio support is that you can obtain 100% accurate probe
information for legacy ISA devices, by looking at the information
exported by the ISA bridge.  There is no need for "probing" per se,
because you know whether or not the parallel port is enabled, exactly
what IRQ it's on, and exactly what DMA channel it uses.

So, a superio probe occurs first because it provides the maximum
information at the least cost.  Since ISA devices must still be
supported, the ISA probe should come after the PCI probe (which includes
PCI superio stuff).  ISA probes to ports already registered via the
superio probe fail at the request_region level, avoiding any unnecessary
hardware access at those ports.  There are tertiary benefits to such a
scheme as well, I'll be glad to elaborate on if people are interested in
the nitty gritty (read: boring) details.

	Jeff


-- 
Jeff Garzik       | Sam: "Mind if I drive?"
Building 1024     | Max: "Not if you don't mind me clawing at the dash
MandrakeSoft      |       and shrieking like a cheerleader."

  reply	other threads:[~2001-04-07 21:52 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-07  8:06 Multi-function PCI devices Michael Reinelt
2001-04-07  8:57 ` Jeff Garzik
2001-04-07 10:14   ` Tim Waugh
2001-04-07 18:42     ` PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport) Gunther Mayer
2001-04-07 18:53       ` Jeff Garzik
2001-04-07 19:06         ` Tim Waugh
2001-04-07 20:24         ` Gunther Mayer
2001-04-07 22:26           ` Jeff Garzik
2001-04-08 20:45         ` Martin Mares
2001-04-19 16:33           ` [patch, take 1] parport_serial (was Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)) Tim Waugh
2001-04-07 19:03       ` PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport) Tim Waugh
2001-04-07 16:22         ` Gérard Roudier
2001-04-07 20:47           ` Gunther Mayer
2001-04-07 19:23         ` Jeff Garzik
2001-04-07 19:31           ` Tim Waugh
2001-04-07 20:21           ` Gunther Mayer
2001-04-07 21:45             ` Tim Waugh
2001-04-07 22:29             ` Jeff Garzik
2001-04-07 20:31           ` Gunther Mayer
2001-04-07 21:52             ` Jeff Garzik [this message]
2001-04-07 11:33   ` Multi-function PCI devices Michael Reinelt
2001-04-07 12:16     ` Tim Waugh
2001-04-07 14:06       ` Michael Reinelt
2001-04-07 13:18         ` Gérard Roudier
2001-04-07 18:36           ` Michael Reinelt
2001-04-07 18:44             ` Jeff Garzik
2001-04-08 11:38               ` Michael Reinelt
2001-04-13 22:51                 ` Jeff Garzik
2001-04-14  0:34                   ` Michael Reinelt
2001-04-07 17:23       ` Jeff Garzik
2001-04-07 19:08         ` Tim Waugh
2001-04-07 19:31           ` Jeff Garzik
2001-04-08 10:25           ` Kai Henningsen
2001-04-09 13:15   ` Henning P. Schmiedehausen
2001-04-07  9:04 ` Gérard Roudier
2001-04-07 13:24   ` Brian Gerst
2001-04-07 14:03     ` Michael Reinelt
2001-04-07 13:01       ` Gérard Roudier
2001-04-07 19:14         ` Tim Waugh
2001-04-07 17:26     ` Jeff Garzik
2001-04-07 19:00   ` Tim Waugh
2001-04-07 19:40     ` Jeff Garzik
2001-04-07 19:52       ` Tim Waugh
2001-04-08 12:05         ` Michael Reinelt
2001-04-08 12:41           ` Tim Waugh
2001-04-07 21:34 ` Linus Torvalds
     [not found] ` <200104072134.OAA11307@penguin.transmeta.com>
2001-04-07 21:58   ` Jeff Garzik

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=3ACF8C1C.7CFF675A@mandrakesoft.com \
    --to=jgarzik@mandrakesoft.com \
    --cc="unlisted-recipients:;"@havoc.gtf.org \
    --cc=Gunther.Mayer@t-online.de \
    --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