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

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On 7/25/05, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> On Mon, Jul 25, 2005 at 11:02:43AM -0500, Dmitry Torokhov wrote:
> > On 7/25/05, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> > > On Mon, Jul 25, 2005 at 10:16:05AM -0500, Dmitry Torokhov wrote:
> > > > If the problem is that you have a single piece of hardware you need to
> > > > bind several drivers to - I guess you will have to create a new
> > > > sub-device bus for that. Or just register sub-devices on the same bus
> > > > the parent device is registered on - I am not sure what is best in
> > > > this particular case - I am not familiar with the arch.
> > >
> > > That is exactly the problem - these kinds of devices do _not_ fit
> > > well into the device model.  A struct device for every different
> > > possible sub-unit is completely overkill.
> > >
> > > For instance, you may logically use one ADC and some GPIO lines
> > > on the device for X and something else for Y and they logically
> > > end up in different drivers.
> > >
> > > The problem is that the parent doesn't actually know how many
> > > devices to create nor what to call them, and they're logically
> > > indistinguishable from each other so there's no logical naming
> > > system.
> > >
> >
> > Then we should probably not try to force them into driver model. Have
> > parent device register struct device and when sub-drivers register
> > they could attach class devices (like input devices) directly to the
> > "main" device thus hiding presence of sub-sections of the chip from
> > sysfs completely. My point is that we should not be using
> > class_interface here - its purpose is diferent.
> 
> If you look at _my_ version, you'll notice that it doesn't use the
> class interface stuff.  A previous version of it did, and this seems
> to be what the collie stuff is based upon.
>

I was only commenting on something that was posted on LKML for
inclusion into input subtree that I am interested in. I don't track
ARM development that closely. Where can we see your version, please?
 
> What I suggest is that the collie folk need to update their driver
> to my version so that we don't have two different forks of the same
> driver in existance.  Then we can start discussing whether things
> should be using kthreads or not.

Do you have any reason why, generally speaking, threads should not be
used? They seem to clean up code in drivers quite a bit.

-- 
Dmitry