> > for free address ranges. It's hardly 'random probing' and it isn't a
quoted text
> > normal BAR or guaranteed to have been configured by anything beforehand.

quoted text
> Yes, but the drivers don't use INTCBAR. They scan through a herd-coded
> list of possible port ranges:

They can't just use INTCBAR as it may not have been configured by anything
before the device is probed. We do need to find and assign suitable ports
although this should probably be done via the PCI quirks on PCI setup.

quoted text
> The interrupt controller (INTC) provides IRQ status bits in a single
> I/O port byte. I only have the datasheet for IT8875F, which is 1
> parallel and no serial ports, so my understanding of UART IRQs is sort
> of reverse engineering. Polling the UART IIR register shows that it
> acts like a normal 16550 UART when set to SERIRQ mode, but I get no
> IRQs generated. Setting to standard PCI INTA interrupts, the IRQs are
> generated, but the UART IIR registers do not set the IRQ bits.

Weird design.

http://kr.ic-on-line.cn/IOL/viewpdf/IT8871F_200216.htm

provides a tiny bit of info on the uart side but I've not found any
complete documentation.

quoted text
> One possibility is to install custom io_serial_in/out functions. When
> the value of IIR is requested, the INTC can be checked, and modify the
> result to what it should be for a normal UART. That is a bit of a
> hack, but makes it much easier to fit into the existing code.

Seems a good starting point. The serial side code is robust for shared
IRQs.

Alan
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/