Messages in this thread | | | Date | Mon, 1 Aug 2005 00:49:59 +0200 | From | Pavel Machek <> | Subject | Re: [patch] ucb1x00: touchscreen cleanups |
| |
Hi!
> > As this isn't the only chip of this sort (i.e. a > > multi-function chip not on the CPU bus) maybe we > > should store the bus driver in a common place. If > > needed we could have a very simple bus driver > > subsystem (this might already be in the kernel, I > > haven't looked at the bus stuff) in which you register > > a bus driver and client drivers register with the bus > > driver. Just an idea :-). > > This was the idea with the drivers/soc suggestion although I think that > name is perhaps misleading. > > How about drivers/mfd where mfd = Multi Functional Devices? > > I think it would be acceptable (and in keeping with the other drivers > e.g. pcmcia) to seeing the arch and platform specific modules with the > main driver as long as the naming reflected it (like the existing mcp > and ucb code does) i.e.: > > mcp-core.c > mcp-sa1100.c > ucb1x00-code.c > ucb1x00-assabet.c > ucb1x00-collie.c > > If code can be separated out into subsystems, I'm not so sure where they > should go though. The existing policy would suggest > drivers/input/touchscreen and sound/xxx for these... > > ucb1x00-ts.c > ucb1x00-audio.c > > Opinions/Comments?
drivers/mfd sounds good, and yes, touchscreen and audio should go where they belong. Pavel -- if you have sharp zaurus hardware you don't need... you know my address - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |