From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261339AbVGYQra (ORCPT ); Mon, 25 Jul 2005 12:47:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261357AbVGYQra (ORCPT ); Mon, 25 Jul 2005 12:47:30 -0400 Received: from rproxy.gmail.com ([64.233.170.200]:44701 "EHLO rproxy.gmail.com") by vger.kernel.org with ESMTP id S261339AbVGYQr2 convert rfc822-to-8bit (ORCPT ); Mon, 25 Jul 2005 12:47:28 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DoSvRugDwVex1R+rhv11PyEXlsmCUkZMllr2u5rYFnKum8GL2NGBPy9ALdAKkxhwh3F/xLIXs4evEO/S/rKxxWh0vmgkXuw1ECpkrSfGFu9QFkN5eFlXBCrrOFwVDWqRckeagmv8rYuTq4bjOYn8ZDKHHksa71TyM3a35HdovK4= Message-ID: Date: Mon, 25 Jul 2005 11:47:25 -0500 From: Dmitry Torokhov Reply-To: dtor_core@ameritech.net To: dtor_core@ameritech.net, Pavel Machek , rpurdie@rpsys.net, lenz@cs.wisc.edu, kernel list , vojtech@suse.cz Subject: Re: [patch 1/2] Touchscreen support for sharp sl-5500 In-Reply-To: <20050725171311.D7629@flint.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Content-Disposition: inline References: <20050722180109.GA1879@elf.ucw.cz> <20050724174756.A20019@flint.arm.linux.org.uk> <20050725045607.GA1851@elf.ucw.cz> <20050725165014.B7629@flint.arm.linux.org.uk> <20050725171311.D7629@flint.arm.linux.org.uk> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 7/25/05, Russell King wrote: > On Mon, Jul 25, 2005 at 11:02:43AM -0500, Dmitry Torokhov wrote: > > On 7/25/05, Russell King 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