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]
Date:	Wed, 14 Apr 2010 13:11:40 +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)

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

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

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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ