Bug 563271

Version-Release should of course read "2.6.18-*"

Created attachment 390093 [details]
Combined patch for it887x support

Patch is a rediff of following 2 commits for RHEL5.4:

commit 84f8c6fc0e3b6e48fd22c28fc3bb666a130b3994
Author: Niels de Vos <niels.devos>
Date:   Wed Aug 22 14:01:14 2007 -0700

    serial: add support for ITE 887x chips
    
    Add support for the it887x-chips (PCI) manufactured by ITE.
    
    Signed-off-by: Niels de Vos <niels.devos>
    Cc: Russell King <rmk.org.uk>
    Acked-by: Alan Cox <alan.org.uk>
    Signed-off-by: Andrew Morton <akpm>
    Signed-off-by: Linus Torvalds <torvalds>

commit e7c310c36e5fdf1b83a459e5db167bfbd86137db
Author: Niels de Vos <niels.devos>
Date:   Sun Jul 15 23:41:35 2007 -0700

    parport_pc: it887x fix
    
    The IO port range requested by parport_pc.c:sio_ite_8872_probe is too small.
    The IO-ports of ttyS1 (0x2f8) will be missconfigured by the ITE-chip.  The ITE
    starts looking for the chip a 0x2a0.  An IO-portrange of 32 will not overwrite
    the ports of ttyS1.  Therefore register 0x60 should be written with
    0xe5000000, enabling the ITE and setting IO-portsize to 32 bytes.
    
    Signed-off-by: Andrew Morton <akpm>
    Signed-off-by: Linus Torvalds <torvalds>

(I posted this to Bug #498626, but I see this is the newer entry, so I am reposting, but the last paragraph is new.)

The updated kernel code does not work for all ITE cards. My card is a 2-serial,
no-parallel version. It fails with the LSR warning and missed IRQ kernel
errors. I registered a bug report (#578616) under Fedora 12, where the kernel
already has the code from this patch.

The problem is that the updated serial/8250_pci.c and the existing
parport/parport_pc.c code do not work together, because they each program the
ioport separately. The current parport_pc.c code ignores serial-only cards, but
redefines the ioports and does not release them. If I blacklist parport_pc to
avoid this, there is no LSR warning, but the missed IRQ error remains. So, the
serial driver is somehow not correctly configured to handle the IRQ.

My card is external, but there are some of these built into the motherboard. If
so, maybe the BIOS allows the serial PNP to work, whereas something is missing
for external cards.

I found a data sheet for IT8875F and an IT887x application note. The IT887x chips optionally support SuperIO's SERIRQ interrupt routing. the parport_pc.c driver seems to assume SERIRQ, and the 8250_pci.c seems to assume standard IRQs.

The 8250_pci.c driver appears designed to only use polling, with IRQs disabled. (Can someone with a working serial port under this driver verify this?) It sets UART interrupt routing registers to zero, but this is only valid for hardware configured to use SERIRQ routing. The older ite887x patch had a custom serial interrupt handler.

The parport_pc.c driver sets SERIRQ registers to match the INTA IRQ, presumably to make SERIRQ hardware work the same as standard IRQs, but this only works when IRQ <= 15.

Normally, combo card configurations can be determined by PCI subsystem ids. Interestingly, the ITE chip has a way to write the subsystem ids, probably so that on-board chips can define these with the BIOS. From the PCI ID database,  they are never defined. One approach would be to define these early in the device initialization, with a custom id to distinguish parallel/serial combo variants. This will better fit the normal approach to handling variants, but perhaps hacking subsystem ids is a bad idea.

I have figured out how the ITE 887x chips work. They are designed for use with Serialized IRQs (SERIRQ). They behave as standard serial/parallel PCI devices when wired for SERIRQ. Otherwise, they need a custom interrupt handler to communicate with the interrupt handler at I/O base address 0. On-board use of this chip is likely always with SERIRQ motherboards.

The parallel and serial ITE drivers are both badly written. They probe for a random ioport address for the interrupt controller (needed to determine the sub-type), instead of using the existing PNP-configured port address. Next, they both assume SERIRQ mode is active. The 8250_pci.c driver then disabled interrupts and intentionally reverts to polled behavior, but devices wired for SERIRQ still have active interrupts.

I can easily fix the drivers to work without interrupts, forcing inefficient polled operation. For SERIRQ hardware, it should be fairly easy to support standard IRQ functions, but I cannot test this. It is more difficult to support interrupts with standard non-SERIRQ hardware. Maybe polling is not so bad with modern hardware?

For now, I am testing my own improved driver code, using polled operation only.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

in kernel-2.6.18-209.el5
You can download this test kernel from http://people.redhat.com/jwilson/el5

Detailed testing feedback is always welcomed.

No hardware.
Confirmed patch in kernel 2.6.18-209.el5.
Setting SanityOnly.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0017.html

I've just tested kernel-2.6.18-238.1.1.el5.i686.rpm from RHN in real hardware and the patch worked fine.

$ cat /proc/tty/driver/serial 
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:0 rx:0
1: uart:16550A port:000002F8 irq:3 tx:0 rx:0
2: uart:16550A port:000003E8 irq:169 tx:0 rx:0 CTS|DSR|CD|RI
3: uart:unknown port:000002E8 irq:3
4: uart:16550A port:00006000 irq:169 tx:1048 rx:0 RTS|CTS|DTR|RI
5: uart:16550A port:00005C00 irq:169 tx:0 rx:0
6: uart:unknown port:00000000 irq:0
7: uart:unknown port:00000000 irq:0

$ dmesg | grep ttyS
Kernel command line: ro root=/dev/VolGroup01/LogVol00 8250.nr_uarts=8 agp=off console=ttyS4,9600o8 console=tty0
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
serial8250: ttyS2 at I/O 0x3e8 (irq = 169) is a 16550A
00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:08: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
0000:06:07.0: ttyS4 at I/O 0x6000 (irq = 169) is a 16550A
0000:06:07.0: ttyS5 at I/O 0x5c00 (irq = 169) is a 16550A