On 7/25/05, Russell King <[EMAIL PROTECTED]> wrote: > On Mon, Jul 25, 2005 at 11:02:43AM -0500, Dmitry Torokhov wrote: > > On 7/25/05, Russell King <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
