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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
|
|