On 6/5/08, David Brownell <[EMAIL PROTECTED]> wrote: > On Wednesday 04 June 2008, Jon Smirl wrote: > > > Now that we've had this discussion it looks to me that the scan > > capability should be added to struct i2c_driver instead of being > > standalone. > > > > I guess what is a little strange to me is that the pre-probe() > > function is like a static driver function and probe() is an instance > > function. > > > The problem there is: how do you know which pre-probe() > function(s) to try? If you could answer that reliably > you'd be able to probe() directly. If you can't, you'd > need to load all I2C driver modules until one works... > not the desired system model. >
I see now that the adapter class should be added to the driver name alias string. The we could load all modules of a given class. But I don't think we need to go searching for the right module to load since i2c is not generally a dynamic bus. If you install a video card with an i2c bus, the driver for the video card can just load_module the right i2c driver modules. I do wonder if we could get hardware monitors to autoload. When the adapter driver for the motherboard loads, it could load module all drivers of class hardware_monitor. Then each one could do its detection thing. Unload the ones that weren't found. That would really help people who can figure out the right driver module to load. You could even get fancy and generate a uevent after the right module was found. A script in the uevent could save the info so you don't have to repeat on each boot. Of course this assume that the hardware monitor modules can reliably autodetect. -- Jon Smirl [EMAIL PROTECTED] _______________________________________________ i2c mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
