Re: Trying to fix ITE-887x parallel/serial driver bugs (including unhandled IRQs)

[Alan Cox]

> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/