public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian Gerst <bgerst@didntduck.org>
To: "Gérard Roudier" <groudier@club-internet.fr>
Cc: Michael Reinelt <reinelt@eunet.at>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Multi-function PCI devices
Date: Sat, 07 Apr 2001 09:24:53 -0400	[thread overview]
Message-ID: <3ACF1525.88BCA48B@didntduck.org> (raw)
In-Reply-To: <Pine.LNX.4.10.10104071043360.1085-100000@linux.local>

Gérard Roudier wrote:
> 
> On Sat, 7 Apr 2001, Michael Reinelt wrote:
> 
> > Hi there,
> >
> > I've got a problem with my communication card: It's a PCI card with a
> > NetMos chip, and it provides two serial and one parallel port. It's not
> > officially supported by the linux kernel, so I wrote my own patch and
> > sent it to the parallel, serial and pci maintainer. The patch itself is
> > basically an extension of the pci id tables; and I hope it's in the
> > queue for the official kernel.
> >
> > The patch worked great for me with kernel 2.4.1 and .2, but no longer
> > with 2.4.3. The parallel port still works, but the serial port will not
> > be detected. I had a quite long debugging session last night (adding
> > printk's to the pci code takes some time, for you have to reboot to load
> > the new kernel), and I think I found the reason:
> >
> > The card shows up on the PCI bus as one device. For the card provides
> > both serial and parallel ports, it will be driven by two subsystems, the
> > serial and the parallel driver.
> 
> Given your description, this board is certainly not a multi-fonction PCI
> device. Multi-function PCI devices provide separate resources for each
> function in a way that allows each function to be driven by separate
> software drivers. A single function PCI device that provides several
> functionnalities commonly handled by separate sub-systems, is nothing but
> a bag of shit we should not want to support in any O/S in my opinion.
> Let me claim that ingenieers that want O/Ses to support such hardware are
> either morons or bastards.

Unfortunately, Windoze supports this configuration, and that's enough
for most hardware designers.  This is also an issue with the joystick
ports on many PCI sound cards.  We're not in a position to get up on the
soap box and decree this hardware "a bag of shit" though, yet.

PS.  I have run into this issue before with joystick ports on many PCI
sound cards.  The only one that I found that did it right (seperate PCI
function for the game port) was the SBLive.

-- 

						Brian Gerst

  reply	other threads:[~2001-04-07 13:31 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
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 [this message]
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=3ACF1525.88BCA48B@didntduck.org \
    --to=bgerst@didntduck.org \
    --cc=groudier@club-internet.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reinelt@eunet.at \
    /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