Trying to fix ITE-887x parallel/serial driver bugs (including unhandled IRQs)
in [Kernel]
|
Prev: vmalloc performance
Next: I attached a test module to reproduce this bug. Does I miss something in my code or is there a bug?
From: Alan Cox on 12 Apr 2010 12:40 > Both drivers (8250_pci.c and parport_pc.c) probe randomly for the > chips control I/O port, instead of using the standard PNP-configured > BAR, and they do so independently, stepping on the previous drivers > configuration attempt. I think the two drivers should be merged into > parport_serial.c because this is a combo chip. However, different That seems reasonable. I don't think your description is accurate entirely. The device is picked up by PCi scans and the INTCBAR is then set up by Linux having checked for free address ranges. It's hardly 'random probing' and it isn't a normal BAR or guaranteed to have been configured by anything beforehand. > The IT887x chips include an interrupt controller that maps external > IRQ inputs to serialized IRQs. Apparently, the I/O ports only present > a standard interrupt interface when wired for serialized IRQs. For > normal PCI interrupts, it needs a custom interrupt handler to > communicate directly with the interrupt-controller port. The current I guess the obvious thing to do would be to provide one. The serial code already supports several such things. What is actually needed or is the 'special' handler simply shared IRQ support in which case it ought t just work. > serial driver attempts to disable IRQs, and let the core driver revert > to polling. However, it does this incorrectly, and can produce > unhandled IRQs. (Maybe it was tested on a system with Ser. IRQ?) To > avoid extra interrupt-handler code, especially for a less common chip, > is it OK to intentionally provide polling-only support? I'd strongly prefer it worked as well as possible if the the documentation to fix it exists. What is involved ? Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 15 Apr 2010 06:40
> but all have the same PCI id. My code just lets parport_serial handle > the serial-only and parallel-only cases. Is that approach better than > having two modules that both match the same PCI id? Most distributions load each driver that matches an id anyway so I think so - puts the complexity in one place. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |