All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Reinelt <reinelt@eunet.at>
To: Jeff Garzik <jgarzik@mandrakesoft.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Multi-function PCI devices
Date: Sat, 07 Apr 2001 13:33:25 +0200	[thread overview]
Message-ID: <3ACEFB05.C9C0AB3C@eunet.at> (raw)
In-Reply-To: <3ACECA8F.FEC9439@eunet.at> <3ACED679.7E334234@mandrakesoft.com>

Jeff Garzik wrote:
> 
> Michael Reinelt wrote:
> > basically an extension of the pci id tables; and I hope it's in the
> > queue for the official kernel.
> 
> Where is this patch available?  I haven't heard of an extension to the
> pci id tables, so I wonder if it's really in the queue for the official
> kernel.

The patches went to Jens Maurer (pci_ids.h), Theodore Y. Ts'o (serial.c
and pci_ids.h) and Tim Waugh (parport_pc.c and pci_ids.h).

Well, and 'extension' may be the wrong word. I just added entries to
pci_ids.h and to the detection tables in parport_pc.c and serial.c

> > pci_announce_device() will be called only if there's no other driver
> > claiming the device. This explains why either the parallel or the serial
> > port will be detected: The first driver loaded will see the device, the
> > next drivers won't.

> There is no need to register more than one driver per PCI device -- just
> create a PCI driver whose probe routine registers serial and parallel,
> and whose remove routine unregisters same.

This means create a new module, which does the detection and uses
serial.c and parport_pc.c? I could do this (at least try to :-), but I'd
need some help here. I'm not a kernel hacker, and don't know much about
the pci code, module dependencies, driver tables, hotplugging and all
that stuff. If someone could provide a small sample (or skeleton) code
for this, I'd try my best....

On the other hand, how should the serial and parallel driver detect the
netmos card, if it's a independant module? How could this interfere with
devfs? How should devfsd know if it should load serial.o or netmos.o?

Adding PCI entries to both serial.c and parport_pc.c was that easy....

bye, Michael

-- 
netWorks       	                                  Vox: +43 316  692396
Michael Reinelt                                   Fax: +43 316  692343
Geisslergasse 4					  GSM: +43 676 3079941
A-8045 Graz, Austria			      e-mail: reinelt@eunet.at

  parent reply	other threads:[~2001-04-07 11:34 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   ` Michael Reinelt [this message]
2001-04-07 12:16     ` Multi-function PCI devices 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=3ACEFB05.C9C0AB3C@eunet.at \
    --to=reinelt@eunet.at \
    --cc=jgarzik@mandrakesoft.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.