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: <20060802204723.GE7173@flint.arm.linux.org.uk>
Date:	Wed, 2 Aug 2006 21:47:23 +0100
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Mathias Adam <a2@...mis.de>
Subject: Re: make 16C950 UARTs work

On Wed, Aug 02, 2006 at 04:31:46PM -0400, Dave Jones wrote:
> Still, leaving a patch out in the cold for 11 months, when we know it
> at least makes things work for some users strikes me as wrong.
> If we took this approach with every driver, we'd end up not supporting
> the majority of things we support today.

Define "majority".  How do we know whether what's merged works for
the majority, and this fix breaks it for one type of card.

Eg, there's another 950 setup which I received a report back in May
which had a 16MHz crystal, and the _only_ way to get that to work
reliably was to use setserial with spd_cust to specify 104 for 9600
baud, etc.  We never got to work out exactly what was going on.

However, based on my experience with dwmw2's card, registers such as
the TCR are programmed on card powerup to have some non-default state
depending on the manufacturers knowledge of the card.  This means if
we start fscking around with them in order to support these "wizzy
new features" other normal things will break.

Let me repeat what I want - I want some way that any changes which are
proposed in this area get tested against some 950-based implementation
which we call "the control implementation".  That way we get to know if
we're going forwards, backwards or sideways.

Blindly applying patches which mess around with 950 clocking registers
based upon what one random card does just isn't acceptable.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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/