In message: <20030606191316.GB1290_at_cicely12.cicely.de> Bernd Walter <ticso_at_cicely12.cicely.de> writes: : On Fri, Jun 06, 2003 at 12:36:54PM -0600, M. Warner Losh wrote: : > In message: <XFMail.20030606141331.jhb_at_FreeBSD.org> : > John Baldwin <jhb_at_FreeBSD.org> writes: : > : I have a small tweak to the PCI code that re-routes PCI interrupts. : > : Basically, it does two things, 1) make the comment less ia64-specific : > : and 2) if the interrupt route returns an invalid IRQ (i.e. 255), then : > : we don't change the intline. In other words, if we can't route the : > : interrupt, we just assume that the firmware knows more than we do and : > : go with the value it stuck in the register. 1) is a no-brainer, but : > : I wonder what people think about 2). Patch below: : > : > I think #2 isn't so good. #1 is a no-brainer :-) : > : > : #if ... : > ... : > : + irq = PCIB_ROUTE_INTERRUPT(pcib, dev, cfg->intpin); : > : + if (PCI_INTERRUPT_VALID(irq)) : > : + cfg->intline = irq; : > : + else : > : #endif : > : + irq = cfg->intline; : > : + resource_list_add(rl, SYS_RES_IRQ, 0, irq, irq, 1); : > : } : > : } : > : > The part I don't like is that if we can't route an interrupt, we : > assume that the interrupt that was written there before is good and : > routed. This strikes me as an unwise assumption. Also, we haven't : : Unless you find a reliable way to ask the BIOS how the board is wired, : whatelse would you do than trust the inline register? $PIR table does this for PCIBIOS. Other mechanisms do it for ACPI. Pre PCIBIOS machines you are SOL. WarnerReceived on Fri Jun 06 2003 - 10:20:05 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:10 UTC