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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <q2lff6de6f21004120834k72cfd554v188b9d2b5a01012c@mail.gmail.com>
Date:	Mon, 12 Apr 2010 11:34:18 -0400
From:	Joseph Krahn <joseph.krahn@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Trying to fix ITE-887x parallel/serial driver bugs (including 
	unhandled IRQs)

The ITE-887x parallel and serial port drivers are badly designed. I am
working on a patch to fix this, but have some questions.

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
variants of the chip have the same PCI vendor/device IDs, but may have
only serial or only parallel ports. Is it OK to have a driver in
parport_serial.c for chip that has only serial ports? Keeping a
separate driver in 8250_pci.c means having two drivers for the same
PCI device ID.

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
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?

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