RE : MPC5200Lite PCI & IRQ

Well, there is not only the IDE driver; the USB driver does it as well:

In the 2.4.25, from the "drivers/usb/host/usb-ohci.c", in the 'ohci_pci_probe' function:

And in the 2.6.7, from "drivers/usb/core/hcd-pci.c", in the 'usb_hcd_pci_probe' function:

if (!dev->irq) {
	err("found OHCI device with no IRQ assigned. check BIOS settings!");
	pci_disable_device (dev);
	return -ENODEV;
}

There are probably other drivers that have the wrong assumption that IRQ 0
is an unassigned IRQ.


Bertrand


-----Message d'origine-----
De : David Woodhouse [mailto:dwmw2@infradead.org]
Envoyé : vendredi 18 juin 2004 11:29
À : Bertrand Baudet
Cc : linuxppc-embedded@lists.linuxppc.org; jgarzik@redhat.com; B.Zolnierkiewicz@elka.pw.edu.pl
Objet : Re: MPC5200Lite PCI & IRQ

On Fri, 2004-06-04 at 15:00 +0200, Bertrand Baudet wrote:

Hi,

I'm trying to plug a sata card in the PCI slot of the MPC5200Lite.

...

By default the IRQ line of the sata card is 0,

...

From the source code, it looks like a value 0 for the IRQ means the IRQ
is disabled.

From "drivers/ide/ide-probe.c", in the 'hwif_init' function:
...
if (!hwif->irq) {
   if (!(hwif->irq = ide_default_irq(hwif->io_ports[IDE_DATA_OFFSET])))
   {
      printk("%s: DISABLED, NO IRQ\n", hwif->name);
      return (hwif->present = 0);
   }
}
...

Commenting out the above code allow the PCI card to run properly.

This is a bug in the IDE driver. Zero is a perfectly valid IRQ number --
I have boxes where PCI slots get IRQ #0 too. Please fix the IDE driver
and send the patch to the IDE maintainer.

--
dwmw2


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Fri, 2004-06-18 at 12:06 +0200, Bertrand Baudet wrote:

Well, there is not only the IDE driver; the USB driver does it as well:

In the 2.4.25, from the "drivers/usb/host/usb-ohci.c", in the 'ohci_pci_probe' function:

And in the 2.6.7, from "drivers/usb/core/hcd-pci.c", in the 'usb_hcd_pci_probe' function:

if (!dev->irq) {
	err("found OHCI device with no IRQ assigned. check BIOS settings!");
	pci_disable_device (dev);
	return -ENODEV;
}

There are probably other drivers that have the wrong assumption that IRQ 0
is an unassigned IRQ.

They are broken. They need fixing. Please don't just work around their
brokenness -- send patches to the driver maintainer.


--
dwmw2


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Fri, Jun 18, 2004 at 11:20:30AM +0100, David Woodhouse wrote:

On Fri, 2004-06-18 at 12:06 +0200, Bertrand Baudet wrote:

quoted

Well, there is not only the IDE driver; the USB driver does it as well:

In the 2.4.25, from the "drivers/usb/host/usb-ohci.c", in the 'ohci_pci_probe' function:

And in the 2.6.7, from "drivers/usb/core/hcd-pci.c", in the 'usb_hcd_pci_probe' function:

if (!dev->irq) {
	err("found OHCI device with no IRQ assigned. check BIOS settings!");
	pci_disable_device (dev);
	return -ENODEV;
}

There are probably other drivers that have the wrong assumption that IRQ 0
is an unassigned IRQ.

They are broken. They need fixing. Please don't just work around their
brokenness -- send patches to the driver maintainer.

Yes, please do :)

thanks,

greg k-h

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Sad, 2004-06-26 at 15:24, David Brownell wrote:

Is there a designated "no IRQ assigned" code?  There should be one ...
that's why such code gets cut/pasted.  Unless pci_enable_device() is
(now) guaranteed to fail if the device has no IRQ assignment?

There are a lot of drivers that assume 0 means no IRQ, including some
big x86 non-PC systems. Remember however that dev->irq is an OS private
cookie. In the x86 case for example we add 16 to APIC directed
interrupts both to split IRQs out and to avoid this problem.

So if your board has an IRQ 0 and it is a problem - just change your
numbering scheme.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Greg KH wrote:

On Fri, Jun 18, 2004 at 11:20:30AM +0100, David Woodhouse wrote:

quoted

On Fri, 2004-06-18 at 12:06 +0200, Bertrand Baudet wrote:

quoted

quoted

There are probably other drivers that have the wrong assumption that IRQ 0
is an unassigned IRQ.

Is there a designated "no IRQ assigned" code?  There should be one ...
that's why such code gets cut/pasted.  Unless pci_enable_device() is
(now) guaranteed to fail if the device has no IRQ assignment?

Possibly that test should vanish, it was evidently a problem for a
while but I've not heard reports of such problems lately.  It's in
2.6 because of cut/paste from 2.4 code.  Feel free to post a patch.

- Dave


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

On Sat, 2004-06-26 at 15:02 +0100, Alan Cox wrote:

There are a lot of drivers that assume 0 means no IRQ, including some
big x86 non-PC systems. Remember however that dev->irq is an OS private
cookie. In the x86 case for example we add 16 to APIC directed
interrupts both to split IRQs out and to avoid this problem.

There aren't _that_ many drivers which have this bug; certainly not
non-ISA drivers. Even when you consider irq_t to be an OS-private
cookie, that doesn't excuse this brokenness on the part of drivers --
they need fixing.

So if your board has an IRQ 0 and it is a problem - just change your
numbering scheme.

That's a workaround, not a fix. Not really Linux style.

Personally, I think we want to stop even thinking of it as a numbering
scheme. IRQs are a tree, not a flat array.

--
dwmw2


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/