Interestingly (we for me at least ;-) I have been working on an SPI subsystem that was/is a copy of the I2C subsystem with changes as SPI doesnt have a protocol like I2C. I am at the stage of tidying up the structures in the head files and looking at where they are used in the core layer. To me, what I have, like I2C, doesnt tie in very well with the new driver model (although Im not overly familiar with it, I think I finally understand platform devices :-). The current I2C core layer seems to be only registering a bus type and devices so you can see them in sysfs as none of the functions seem to do anything. I wonder how much work the new kernel subsystems can do for us to cut down the size of i2c-core (and thus also spi-core). I guess there is no escaping the fact that Im going to gave to do some more homework and study the code. Any thoughts or insights would be very welcome.
Mark --- David Brownell <[EMAIL PROTECTED]> wrote: > Hmm, some of this resembles my prototype from last > month: > > > http://lists.lm-sensors.org/pipermail/lm-sensors/2005-July/013012.html > > Both ended up with new driver probe() methods > attaching to *devices* not > to busses, and used the probe signature the i2c core > already handles. > That helps eliminate one of the surprises hitting > anyone starting to use > the I2C driver stack. But not the more fundamental > one... > > What would you think about actually making I2C > probing work more like > standard driver model probing, instead? That is, > have the probe method > signature look like this: > > int probe(struct i2c_client *dev, void > *driver_data) > > In normal driver model usage, infrastructure creates > the devices, and the > device drivers just bind to them. But I2C doesn't > support that even for > the submodel where it's very appropriate: devices > that have been probed, > or which (as with platform_bus) were explicitly > declared to exist. > > I2C drivers would either continue the old school way > ... or could start > acting more like they do in other mainstream Linux > driver frameworks. > > - Dave > > > - > 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/ > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com - 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/
