request_irq（dev->irq, ....）時(shí)候，有時(shí)候發(fā)現(xiàn)dev->irq是0，驚奇？

wchtalk

request_irq（dev->irq, ....）時(shí)候，多數(shù)時(shí)間正常，但偶爾有時(shí)候發(fā)現(xiàn)dev->irq是0，中斷無法加載，驚奇？不知道大家碰到過這樣的情況？
我猜是系統(tǒng)硬件干擾等問題，軟件怎么也不會(huì)讀寫dev->irq為零？

albcamus

還有這種事？

塑料袋

BIOS初始化PCI設(shè)備的時(shí)候，有可能錯(cuò)誤的分配irq。
kernel在pcibios_init的時(shí)候，并不糾正錯(cuò)誤，只是寫dev->irq = 0。
當(dāng)你注冊(cè)了這個(gè)PCI設(shè)備的驅(qū)動(dòng)后，驅(qū)動(dòng)函數(shù)中的XXX_pci_probe應(yīng)該負(fù)責(zé)糾正這種錯(cuò)誤。
一般都是在XXX_pci_probe開頭，判斷一下vender，class.......后，就馬上pci_enable_device ，XXX_pci_probe -> pci_enable_device -> pcibios_enable_device -> pcibios_enable_irq -> pcibios_lookup_irq ( dev，1) 。
pcibios_lookup_irq ( dev，1) 的第二個(gè)參數(shù)為1時(shí)，糾正dev -> irq錯(cuò)誤



如果到了request_irq的時(shí)候，dev->irq還是0的話，那么是驅(qū)動(dòng)寫的有毛病，而不是kernel有毛病。

zx_wing

原帖由 塑料袋 于 2007-8-20 10:11 發(fā)表
BIOS初始化PCI設(shè)備的時(shí)候，有可能錯(cuò)誤的分配irq。
kernel在pcibios_init的時(shí)候，并不糾正錯(cuò)誤，只是寫dev->irq = 0。
當(dāng)你注冊(cè)了這個(gè)PCI設(shè)備的驅(qū)動(dòng)后，驅(qū)動(dòng)函數(shù)中的XXX_pci_probe應(yīng)該負(fù)責(zé)糾正這種錯(cuò)誤。
一般 ...

>>BIOS初始化PCI設(shè)備的時(shí)候，有可能錯(cuò)誤的分配irq。
是指BIOS在掃描pci總線后填寫設(shè)備的的PCI Configure Space中的interrupt line時(shí)出錯(cuò)嗎？

塑料袋

假如是2片8259A,最大irq是15.

1) BIOS寫pci設(shè)備的interrupt_line時(shí),可能寫的是個(gè)錯(cuò)的,或者沒寫.

2) init進(jìn)程遍歷一遍所有pci_dev,pci_dev -> irq  >  15 的一律pci_dev -> irq = 0,這部分pci_dev也歸結(jié)到BIOS未分配irq的那類pci_dev中.

3)init進(jìn)程遍歷一遍滿足如下條件的pci_dev
           a) BIOS未分配irq
           b) router事實(shí)上,已經(jīng)為這個(gè)pci_dev選擇好了irq.
   讀出router設(shè)置的這個(gè)irq,寫到pci_dev -> irq.


kernel做到這步就不管了,還可能剩下部分pci_dev,bios也沒有為其分配irq,router也沒有為這個(gè)pci_dev選擇irq. 但這部分pci_dev怎么處理,完全是驅(qū)動(dòng)模塊的事.

驅(qū)動(dòng)模塊里的probe函數(shù)中,要調(diào)用修改router設(shè)置的函數(shù), 如沒有修改router設(shè)置,也沒有驗(yàn)證router是否設(shè)置成功,就直接request_irq,應(yīng)該是驅(qū)動(dòng)的錯(cuò)誤.