lkml.org 
[lkml]   [2006]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-08-02 22:49    [W:0.089 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site