On Thu, Oct 13, 2011 at 10:47:17AM +0100, Russell King - ARM Linux wrote: > On Mon, Oct 10, 2011 at 12:44:08PM +0100, Mark Brown wrote: > > At the minute it seems to me that arch/arm is as good a place as any > > really - currently this code is getting dumped wherever the main device > > is. > No it isn't - we want drivers out of arch/arm (it's already been a topic > of flame for Linus, so it's something that we should try _really_ hard > to avoid.) I said it was as good a place as any, I didn't say it was a good place. Currently we don't have a good place for this code but just dumping the code somewhere else isn't really helping anything either unless there's some meaningful subsytem (or at least effort towards a subsystem) to look after it, it's bookkeeping. > As this is clearly a device driver (it has a device driver struct, it > relies upon a struct device, etc) then it needs to live outside of > arch/arm/ - and I think Arnd's suggestion of drivers/adc is probably > the right place for it to move to (even though its probably the first > to create the directory.) More stuff can come along in the future, > and then its all together to start creating a common API in there. Creating drivers/adc just seems like a sucky idea. We've already got at least one ongoing effort at creating a general purpose ADC/DAC interface in the form of the IIO subsystem (which is currently mostly targeted at higher volume devices and userspace only but the abstractions needed aren't terribly different depending on the data volumes) and does have the rather substantial advantage that there's people actually trying to make a subsystem. On the other hand it's in staging for now so it'd create pain trying to merge the in-kernel clients that go along with these devices which doesn't seem constructive. There's also the fact that ADCs and DACs are pretty much the same thing to software with the data line driven from the opposite end of the link sO if we've got a subsystem for ADCs only it seems clear we're doing something wrong. > What we *do* need to avoid is having the spmp8000 ADC callback function > data structure, the foo ADC callback function data structure, the bar > ADC callback function data structure and so forth. We need to think > *NOW* about defining a common ADC callback structure so that we don't > spawn a new problem which'll take effort to solve. The cat's already well out of the bag on that one, we've got a bunch of these things in tree already - the Cragganmore system I've got sitting here on my desk has three auxiliary ADCs I'm aware of, all of which are supported in mainline, and they're far from the only ones. I think we should just carry on as we are while the IIO work proceeds, either we'll decide that that's the way forward and we can then kick all the ADCs into there or we'll get fed up, decide that's never going to work then go and can do something else. -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
