From: Michael Reinelt <reinelt@eunet.at>
To: Tim Waugh <twaugh@redhat.com>
Cc: "Jeff Garzik" <jgarzik@mandrakesoft.com>,
"Gérard Roudier" <groudier@club-internet.fr>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: Multi-function PCI devices
Date: Sun, 08 Apr 2001 14:05:36 +0200 [thread overview]
Message-ID: <3AD05410.495A2BDC@eunet.at> (raw)
In-Reply-To: <3ACECA8F.FEC9439@eunet.at> <Pine.LNX.4.10.10104071043360.1085-100000@linux.local> <20010407200053.B3280@redhat.com> <3ACF6D1D.63A2A2FE@mandrakesoft.com> <20010407205204.H3280@redhat.com>
Tim Waugh wrote:
>
> On Sat, Apr 07, 2001 at 03:40:13PM -0400, Jeff Garzik wrote:
>
> > Who said you have to have a separate driver for every single multi-IO
> > card? A single driver could support all serial+parallel multi-IO cards,
> > for example.
>
> Okay, I misunderstood. I'll take a look at doing this for 2.4.
>
> First of all, parport_pc will need to export the equivalent of
> register_serial (its equivalent is probably parport_pc_probe_port).
> [It actually already does this (conditionally on parport_cs).]
>
> drivers/parport/parport_serial.c sound okay, or is a different place
> better?
Heh. These multi-I/O-cards come in a lot of different fashions. Let me
explain the NetMos chips a bit:
My card shows up with lspci like that:
lizard:~ # lspci -s 00:0c -vn
00:0c.0 Class 0780: 9710:9835 (rev 01)
Subsystem: 1000:0012
Flags: medium devsel, IRQ 11
I/O ports at 9400 [size=8]
I/O ports at 9000 [size=8]
I/O ports at 8800 [size=8]
I/O ports at 8400 [size=8]
I/O ports at 8000 [size=8]
I/O ports at 7800 [size=16]
as you can see, it's class is PCI_CLASS_COMMUNICATION_OTHER
There are 8 different chips from Netmos, they differ mainly in the
number of serial and parallel ports:
9705 -/1P
9735 2S/1P
9745 2S/-
9805 -/1P
9815 -/2P
9835 2S/1P
9845 2S/-
9855 -/2P
the chip id is the same as the PCI device ID. So there are chips with
only serial or parallel ports, and chips with both of them. A chip
without a parallel port (9845) does not really belong to
parport/parport_serial.c :-) On the other hand, a chip without a serial
port should have nothing to do whith serial.c.
At the moment there is a clean solution: serial.c contains only the
device ids of cards with serial ports, the same for parport_pc.c
to summarize the discussion, there are 3 possible solution. I wanted a
simple _and_ clean solution, this seems impossible.
The simple solution: Gunters 'multifunction quirks'
clean solution #1: a new module according to Jeffs sample code
clean solution #2: 'invisible PCI bridge' from Linus
For both clean solutions I don't know how autoloading/hotplugging would
be handled. But they look good, especially Linus' one.
The simple solution would be _very_ easy to integrate, would not break
existing configurations, and would not require any design changes.
Suggestion: multifunction quirks for 2.4, one of the clean solutions for
2.5?
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
next prev parent reply other threads:[~2001-04-08 12:07 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
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 [this message]
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=3AD05410.495A2BDC@eunet.at \
--to=reinelt@eunet.at \
--cc=groudier@club-internet.fr \
--cc=jgarzik@mandrakesoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=twaugh@redhat.com \
/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.