Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)
Hi Jeff! > Is Martin still alive? He hasn't been active in PCI development well > over six months, maybe a year now. Ivan (alpha hacker) appeared on the > scene to fix serious PCI bridge bugs, DaveM has added some PCI DMA > stuff, and I've added a couple driver-related things. I haven't seen > code from Martin in a long long time, and only a comment or two in > recent memory. I'm buried alive in mail, graph theory and several other projects, so I'm now happy I'm able to at least keep track of kernel development and answer some bug reports, but I hope it will get better soon. If it won't, I'll probably have to pass the maintainer's sceptre to someone less busy, but I'd rather like to avoid it as I still like the PCI world very much though it's got somewhat messy these days. > > --- linux-2.4.3-orig/include/linux/pci.hWed Apr 4 19:46:49 2001 > > +++ linux/include/linux/pci.h Sat Apr 7 20:01:51 2001 > > @@ -454,6 +454,9 @@ > > void (*remove)(struct pci_dev *dev);/* Device removed (NULL if not a >hot-plug capable driver) */ > > void (*suspend)(struct pci_dev *dev); /* Device suspended */ > > void (*resume)(struct pci_dev *dev);/* Device woken up */ > > + int multifunction_quirks; /* Quirks for PCI serial+parport >cards, > > + here multiple drivers are >allowed to register > > + for the same pci id match */ > > }; This is incredibly ugly. IMHO the right solution is to add a driver for each such multi-function device which will split the device to two virtual devices as Linus has suggested, or maybe better to add a generic driver doing such splitting for multiple similar multi-function cards. Have a nice fortnight -- Martin `MJ' Mares <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://atrey.karlin.mff.cuni.cz/~mj/ bug, n: A son of a glitch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)
Gunther Mayer wrote: > More module interdependencies == More complicated == More clueless users With module autoloading, they don't have to care about module interdependencies. The primary thing people care about is what string is passed to modprobe. When that changes, things break. As long as that doesn't change, you are ok. Who cares if two or five or ten helper modules are automatically pulled in, and who cares if that list of helper modules changes... Functionally speaking, the user is completely unaware of the change. > Many users will be surprised if they must load another module (e.g."pci_multiio") > to get their parallel and serial ports working. > > Thus _must not_ happen in the stable release. Agreed. 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." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)
Gunther Mayer wrote: > Jeff Garzik wrote: > > Gunther Mayer wrote: > > > Hardware has always needed quirks (linux-2.4.3 has about 60 occurences > > > of the word "quirks", not to mention workaround, blacklist and other synonyms)! > > > > > > Please apply this little patch instead of wasting time by finger-pointing > > > and arguing. > > > > > > Martin, comments? > > > > Is Martin still alive? He hasn't been active in PCI development well > > over six months, maybe a year now. Ivan (alpha hacker) appeared on the > > scene to fix serious PCI bridge bugs, DaveM has added some PCI DMA > > stuff, and I've added a couple driver-related things. I haven't seen > > code from Martin in a long long time, and only a comment or two in > > recent memory. > > See linux/MAINTAINERS for "PCI Subsystem", the attribute is even called: > "Supported: Someone is actually paid to look after this". Who cares... action not words. :) A lot of those MAINTAINERS entries do not reflect reality [which is a bug, of course]. 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." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)
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." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)
On Sat, Apr 07, 2001 at 10:21:11PM +0200, Gunther Mayer wrote: > Many users will be surprised if they must load another module > (e.g."pci_multiio") to get their parallel and serial ports working. > > Thus _must not_ happen in the stable release. Yes, I agree. I am planning for parport_serial.c to end up as part of parport_pc.o for 2.4. Tim. */ PGP signature
Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)
Gérard Roudier wrote: > > On Sat, 7 Apr 2001, Tim Waugh wrote: > > > On Sat, Apr 07, 2001 at 08:42:35PM +0200, Gunther Mayer wrote: > > > > > Please apply this little patch instead of wasting time by > > > finger-pointing and arguing. > > > > This patch would make me happy. > > > > It would allow support for new multi-IO cards to generally be the > > addition of about two lines to two files (which is currently how it's > > done), rather than having separate mutant hybrid monstrosity drivers > > for each card (IMHO).. > > It is possible to design a single function PCI device that is able to do > everything. Your approach is just encouraging this kind of monstrosity. > Such montrosity will look like some single-IRQ capable ISA remake, thus > worse than 20 years old ISA. > > If we want to encourage that, then we want to stay stupid for life, in my > nervous opinion. If you want to discourage hardware vendors, they will stay with Windows. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)
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 PNPBIOS and ACPI will help to configure parallel ports (and others), after some issues have been resolved. Again this will be builtin to parport (and not parport_acpi.o etc) to make it failproof. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)
Jeff Garzik wrote: > > Gunther Mayer wrote: > > Hardware has always needed quirks (linux-2.4.3 has about 60 occurences > > of the word "quirks", not to mention workaround, blacklist and other synonyms)! > > > > Please apply this little patch instead of wasting time by finger-pointing > > and arguing. > > > > Martin, comments? > > Is Martin still alive? He hasn't been active in PCI development well > over six months, maybe a year now. Ivan (alpha hacker) appeared on the > scene to fix serious PCI bridge bugs, DaveM has added some PCI DMA > stuff, and I've added a couple driver-related things. I haven't seen > code from Martin in a long long time, and only a comment or two in > recent memory. See linux/MAINTAINERS for "PCI Subsystem", the attribute is even called: "Supported: Someone is actually paid to look after this". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)
Jeff Garzik wrote: > > Tim Waugh wrote: > > It would allow support for new multi-IO cards to generally be the > > addition of about two lines to two files (which is currently how it's > > done), rather than having separate mutant hybrid monstrosity drivers > > for each card (IMHO).. > > ;-) > > My point of view is that hacking the kernel so that two device drivers > can pretend they are not driving the same hardware is silly. With such > hardware there are always inter-dependencies, and you can either hack > special case code into two or more drivers, or create one central > control point from which knowledge is dispatched. Like I mentioned in a My point of view is making it easy for the average user. This is the same as making it easy for maintainers of hardware drivers ! More module interdependencies == More complicated == More clueless users Many users will be surprised if they must load another module (e.g."pci_multiio") to get their parallel and serial ports working. Thus _must not_ happen in the stable release. Regards, Gunther - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)
On Sat, 7 Apr 2001, Tim Waugh wrote: > On Sat, Apr 07, 2001 at 08:42:35PM +0200, Gunther Mayer wrote: > > > Please apply this little patch instead of wasting time by > > finger-pointing and arguing. > > This patch would make me happy. > > It would allow support for new multi-IO cards to generally be the > addition of about two lines to two files (which is currently how it's > done), rather than having separate mutant hybrid monstrosity drivers > for each card (IMHO).. It is possible to design a single function PCI device that is able to do everything. Your approach is just encouraging this kind of monstrosity. Such montrosity will look like some single-IRQ capable ISA remake, thus worse than 20 years old ISA. If we want to encourage that, then we want to stay stupid for life, in my nervous opinion. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)
On Sat, Apr 07, 2001 at 03:23:12PM -0400, Jeff Garzik wrote: > It's just ugly to keep hacking in special cases to handle hardware > that is multifunction like this. I just don't want it to be a huge chore to add support for these cards. Would everyone be happy if (say) drivers/parport/parport_serial.c had a table and a generic version of your example function, so that the table somehow described the multifunction cards out there? Tim. */ PGP signature
Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)
Tim Waugh wrote: > It would allow support for new multi-IO cards to generally be the > addition of about two lines to two files (which is currently how it's > done), rather than having separate mutant hybrid monstrosity drivers > for each card (IMHO).. ;-) My point of view is that hacking the kernel so that two device drivers can pretend they are not driving the same hardware is silly. With such hardware there are always inter-dependencies, and you can either hack special case code into two or more drivers, or create one central control point from which knowledge is dispatched. 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. It's just ugly to keep hacking in special cases to handle hardware that is multifunction like this. 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." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)
On Sat, Apr 07, 2001 at 02:53:23PM -0400, Jeff Garzik wrote: > As has been explained, the current API supports this just fine without > modification. The current API makes it much harder to support the breadth of hardware we're talking about. The hardware has quirks, and this quirk is so common that it is absolutely the norm. Tim. */ PGP signature
Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)
On Sat, Apr 07, 2001 at 08:42:35PM +0200, Gunther Mayer wrote: > Please apply this little patch instead of wasting time by > finger-pointing and arguing. This patch would make me happy. It would allow support for new multi-IO cards to generally be the addition of about two lines to two files (which is currently how it's done), rather than having separate mutant hybrid monstrosity drivers for each card (IMHO).. Tim. */ PGP signature
Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)
Gunther Mayer wrote: > Hardware has always needed quirks (linux-2.4.3 has about 60 occurences > of the word "quirks", not to mention workaround, blacklist and other synonyms)! > > Please apply this little patch instead of wasting time by finger-pointing > and arguing. > > Martin, comments? Is Martin still alive? He hasn't been active in PCI development well over six months, maybe a year now. Ivan (alpha hacker) appeared on the scene to fix serious PCI bridge bugs, DaveM has added some PCI DMA stuff, and I've added a couple driver-related things. I haven't seen code from Martin in a long long time, and only a comment or two in recent memory. > --- linux-2.4.3-orig/include/linux/pci.hWed Apr 4 19:46:49 2001 > +++ linux/include/linux/pci.h Sat Apr 7 20:01:51 2001 > @@ -454,6 +454,9 @@ > void (*remove)(struct pci_dev *dev);/* Device removed (NULL if not a >hot-plug capable driver) */ > void (*suspend)(struct pci_dev *dev); /* Device suspended */ > void (*resume)(struct pci_dev *dev);/* Device woken up */ > + int multifunction_quirks; /* Quirks for PCI serial+parport >cards, > + here multiple drivers are >allowed to register > + for the same pci id match */ > }; As has been explained, the current API supports this just fine without modification. Also, changing the API in the stable series should be frowned upon, -especially- something domain specific like this. 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." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH for Broken PCI Multi-IO in 2.4.3 (serial+parport)
Tim Waugh wrote:
>
> On Sat, Apr 07, 2001 at 04:57:29AM -0400, Jeff Garzik wrote:
>
> > 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.
>
> It is. http://people.redhat.com/twaugh/patches/> The
> 'extension' is just 'more entries', AFAIR.
>
> > > I'm afraid this is not a bug, but a design issue, and will be hard to
> > > solve. Maybe we need a flag for such devices which allows it to be
> > > claimed ba more thean one driver?
> >
> > Not so hard.
>
> *sigh* Jeff, when I spoke to you about this last year you said
> 'tough', or words to that effect. :-(
>
> > 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.
>
> *cough* modularity *cough*
>
> Wnat to show us some elegant code that does that?
Hardware has always needed quirks (linux-2.4.3 has about 60 occurences
of the word "quirks", not to mention workaround, blacklist and other synonyms)!
Please apply this little patch instead of wasting time by finger-pointing
and arguing.
Martin, comments?
Regards, Gunther
--- linux-2.4.3-orig/include/linux/pci.hWed Apr 4 19:46:49 2001
+++ linux/include/linux/pci.h Sat Apr 7 20:01:51 2001
@@ -454,6 +454,9 @@
void (*remove)(struct pci_dev *dev);/* Device removed (NULL if not a
hot-plug capable driver) */
void (*suspend)(struct pci_dev *dev); /* Device suspended */
void (*resume)(struct pci_dev *dev);/* Device woken up */
+ int multifunction_quirks; /* Quirks for PCI serial+parport cards,
+ here multiple drivers are allowed
+to register
+ for the same pci id match */
};
--- linux-2.4.3-orig/drivers/pci/pci.c Wed Apr 4 19:46:46 2001
+++ linux/drivers/pci/pci.c Sat Apr 7 19:59:47 2001
@@ -453,7 +453,7 @@
list_add_tail(&drv->node, &pci_drivers);
pci_for_each_dev(dev) {
- if (!pci_dev_driver(dev))
+ if (!pci_dev_driver(dev) || drv->multifunction_quirks)
count += pci_announce_device(drv, dev);
}
return count;
--- linux-2.4.3-orig/drivers/parport/parport_pc.c Wed Apr 4 19:46:46 2001
+++ linux/drivers/parport/parport_pc.c Sat Apr 7 20:18:37 2001
@@ -2539,6 +2539,7 @@
name: "parport_pc",
id_table: parport_pc_pci_tbl,
probe: parport_pc_pci_probe,
+ multifunction_quirks: 1,
};
static int __init parport_pc_init_superio (void)
--- linux-2.4.3-orig/drivers/char/serial.c Wed Apr 4 19:46:43 2001
+++ linux/drivers/char/serial.c Sat Apr 7 20:00:00 2001
@@ -4178,7 +4178,7 @@
for (i=0; timedia_data[i].num; i++) {
ids = timedia_data[i].ids;
for (j=0; ids[j]; j++) {
- if (pci_get_subvendor(dev) == ids[j]) {
+ if (pci_get_subdevice(dev) == ids[j]) {
board->num_ports = timedia_data[i].num;
return 0;
}
@@ -4718,6 +4718,7 @@
probe: serial_init_one,
remove:serial_remove_one,
id_table: serial_pci_tbl,
+ multifunction_quirks: 1,
};
gmdiff-lx243-pci-multi_io
