On Fri, Oct 9, 2009 at 22:24, Barry Song wrote: > On Sat, Oct 10, 2009 at 12:22 AM, Dmitry Torokhov wrote: >> On Fri, Oct 09, 2009 at 06:11:45AM -0400, Mike Frysinger wrote: >>> On Fri, Oct 9, 2009 at 05:18, Mike Frysinger <vapier.adi@xxxxxxxxx> wrote: >>> > we could have three modules here: ad714x, ad714x-i2c, ad714x-spi >>> >>> are you ok with this approach Dmitry ? this way people can >>> load/unload a specific bus without affecting the core or the other >>> bus, and errors with loading one bus type wouldnt affect loading of >>> the other. >> >> Yes, I think this is the most clean way. > > That will decrease the cohesion and increase coupling. It's tedious > for one driver with single feature to have three modules. To fulfill > that, ad714x need to expose data structures and export symbols to > ad714x-i2c and ad714x-spi. But those data structures and symbols are > more like local stuff. And I2C and SPI are just bottom level > communication ways, they should be the bottom level of ad714x, but > after splitting to 3 modules, it seems they become the top level of > ad714x. there should already be a clear split between the bus and the driver core, otherwise crap is being duplicated between the two interfaces. i just tested splitting things and each bus code needs to know very few things: - probe/remove for initialization - enable/disable for pm the only downside i see here is that we have to remove __devinit/__devexit markings from the common probe/remove functions and those weigh a hefty 2406/218 bytes a piece. > How about we still have one module, but let users to select which bus > should be probed according to their boards. we do that now in ad7879 and it's a bad idea -- the situation is worse than what we have now with the ad714x as it means we cant have multiple devices on different busses. -mike -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
