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

[Russell King <rmk+lkml@arm.linux.org.uk>]

On Mon, Jul 25, 2005 at 06:56:07AM +0200, Pavel Machek wrote:
> Hi!
> 
> > > This adds support for reading ADCs (etc), neccessary to operate touch
> > > screen on Sharp Zaurus sl-5500.
> > 
> > I would like to know what the diffs are between my version (attached)
> > and this version before they get applied.
> 
> Hmm, diff looks quite big (attached), and I got it from lenz for 99%
> part.

It looks like John's version is actually based on a previous revision
of this driver. 8/

> I have made quite a lot of cleanups to touchscreen part, and it seems
> to be acceptable by input people. I think it should go into
> drivers/input/touchscreen/collie_ts.c...

Err, why should my assabet touchscreen be called "collie_ts" ?
collie is just a platform which happens to use it - it's got
no relevance to the driver naming at all.

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

> > The only reason my version has not been submitted is because it lives
> > in the drivers/misc directory, and mainline kernel folk don't like
> > drivers which clutter up that directory.  In fact, I had been told
> > that drivers/misc should remain completely empty - which makes this
> > set of miscellaneous drivers homeless.
> 
> Could they simply live in arch/arm/mach-sa1100? Or is arch/arm/soc
> better place?

arch/arm/soc?  That means that (a) we end up with another directory to
accumulate crap, (b) it's not a SoC so doesn't belong in a directory
named as such, (c) it means that the MCP and UCB drivers get their
individual files scattered throughout the kernel tree, one in this
directory, one in that directory, one in another random directory.
That's far from ideal.

Anyway, summarising this, the results are that what we have here is
a complete and utter mess. ;(

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.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core