Re: [patch 1/2] Touchscreen support for sharp sl-5500

From: Russell King
Date: Mon Jul 25 2005 - 18:09:17 EST

On Tue, Jul 26, 2005 at 12:06:59AM +0200, Pavel Machek wrote:
> > > Also it looks to me like mcp.h should go into asm/arch-sa1100, so
> > > that other drivers can use it...
> >
> > That doesn't make sense when you have other non-SA1100 devices using
> > mcp-core.c. Whether that happens or not I've no idea - I can't see
> > what everyone's using out there (just like I've absolutely zero
> > idea what collie folk are doing or not doing.)
> set_telecom_divisor relies on CONFIG_SA1100 being set (otherwise it
> breaks compilation, because struct members will not be available; at
> least in this version), so I doubt it has many non-SA1100 users...

That's not conclusive in itself - if it's only usable on SA1100
platforms, why was that ifdef added?

> > So, if the collie folk would like to clean their changes up and send
> > them to me as the driver author, I'll see about integrating them into
> > my version and we'll take it from there.
> Okay, will do. [Is there chance to pull your tree using git? It would
> help a bit...]

My git usage is limited to the final stage of my development - iow
providing an integration and test bed for merging upstream. My work
prior to that is all patch based (as per the tarball of patches I
posted previously) with scripts to manage them - I like the power to
re-order, split, merge, insert and remove patches at random, which
includes whole series of patches vs individual patches themselves.

Consequently, if I were to publish my git trees, what you'll find is
that they're indentical copies of Linus' tree except for maybe when
Linus is away, or hasn't pulled that night, or...

What you're actually seeing with the UCB stuff is the effect of me
stopping maintaining the -rmk trees - code effectively got "dropped"
from public view at that point, and I'm not going to start publishing
such a tree any time soon. It completely detracts from the task of
ensuring mainline kernels work for ARM - since the -rmk tree is/was
seen as the tree for everything ARM to be merged into, and hence
upstream merging became my problem. No, never again will I make a
fool of myself like that. Hence, I'll never again publish a kernel
tree myself, except maybe for very limited purposes.

However, if the UCB stuff is going to get worked on, I don't mind
setting up, maintaining and publishing a git tree for that that,
provided it then vanishes once merged into mainline. That falls
within the "very limited purposes" clause above.

Russell King
Linux kernel 2.6 ARM Linux -
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@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at