linux-kernel - Re: 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20100412174352.4e13113f@lxorguk.ukuu.org.uk>
Date:	Mon, 12 Apr 2010 17:43:52 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Joseph Krahn <joseph.krahn@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Trying to fix ITE-887x parallel/serial driver bugs (including 
 unhandled IRQs)

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