linux-kernel - Re: make 16C950 UARTs work

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: <20060807232032.GA13008@adamis.de>
Date:	Tue, 8 Aug 2006 01:20:32 +0200
From:	Mathias Adam <a2@...mis.de>
To:	Theodore Tso <tytso@....edu>, Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: make 16C950 UARTs work

Hello,

On 02.08.06 18:59:13, Theodore Tso wrote:
> On Wed, Aug 02, 2006 at 09:17:23PM +0100, Russell King wrote:
> > As I've said, I'm ignoring all 950 patches because I don't know what
> > works and what doesn't, and it's highly likely that applying one fix
> > for one card breaks already working fixes for other cards because
> > they have different crystals fitted, thereby requiring different
> > register settings.
> 
> Actually, this particular one is probably safe, because it doesn't
> depend on what crystal is installed, but rather works by using a
> documented feature in the Oxford 950 UART to oversample the clock
> signal.  In addition, the patch only activates UART_TCR if the user
> requests the higher baud rates, so the patch only does something if
> the user requests a baud rate that would have been previously rejected
> by the driver.  [...]

exactly, this is what the patch does. I implemented it according to
Oxford's 950 datasheet so it's not specific to the Socket BT card I have
used for testing. Furthermore, code similar to this has already been in
kernel 2.4 but got removed for some reason - perhaps there have been
other problems with 2.4's serial driver?

As far as I remember the current 2.6 serial driver uses a fixed value
for uartclk = 1843200 = 115200*16 while 2.4 was somewhat more general.
Together with 2.6's minimum divisor of 16 this gives the maximum baud
rate of 115200.

Are there any documents on why this was changed from 2.4 to 2.6?

Regards
Mathias

PS: currently I'm not subscribed to lkml so please CC me.
-
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/