[i2c] [patch 1/5] i2c stack can probe()

[David Brownell]

On Friday 02 March 2007 12:15 pm, Jean Delvare wrote:
> Oh, BTW...
> 
> On Thu, 15 Feb 2007 00:41:37 -0800, David Brownell wrote:
> >  static int i2c_device_match(struct device *dev, struct device_driver *drv)
> >  {
> > -	return 1;
> > +	struct i2c_client	*client = to_i2c_client(dev);
> > +	struct i2c_driver	*driver = to_i2c_driver(drv);
> > +
> > +	/* legacy i2c drivers bypass driver model probing entirely;
> > +	 * such drivers scan each i2c adapter/bus themselves.
> > +	 */
> > +	if (!driver->probe)
> > +		return 0;
> > +
> > +	/* new style drivers use the same driver matching policy as
> > +	 * platform devices or SPI:  compare device and driver names.
> > +	 */
> > +	return strcmp(client->name, drv->name) == 0;
> >  }
> 
> We still need to discuss this. I think this approach is too simplistic
> for some of our i2c drivers. Many of them support several device types, 
> and so far we have used a different client name for each of them (in
> most cases.)

If the issue is that client->name is non-constant, that could easily
be addressed by switching to a new field, initialized only by new-style
drivers.  So the device-to-driver association would be as found in
this patch (other than using that field not client->name), but the
driver could expose additional typing information in sysfs if they
really wanted to do so.

In fact I was wondering if maybe a new field should be defined for
that specific purpose.


> In order to match this model, each i2c driver should embed 
> a null-terminated list of devices it supports and this match() function
> should walk the list searching for an entry matching the client name.

That would unfortunately mean that I2C can't hotplug drivers any time soon,
since that list would need to be postprocessed by the tools creating
the "<module_name>.mod.c" files and also by "depmod".

I'm not keen on that, for several reasons.  One is that it's gratuitous
complexity ... the module loading works right now (via $MODALIAS), so
that kind of infrastructure clearly is not needed.  Another is that
waiting for such infrastructure to arrive would take time, during which
a basic mechanism (hotplug driven module loading) wouldn't work.

As it stands now, the first time I modprobed an i2c_adapter, the i2c-core
automagically modprobed the drivers for the devices that were declared
on that bus ... it Just Worked.


> I seem to remember that you objected to this approach, but I can't
> remember what you offered as an alternative for drivers supporting
> several devices.

I probably pointed out that drivers can already support multiple device
types with this scheme.  Detailed device typing info is in platform_data
with other stuff, in the more complex drivers.  All the driver binding
mechanism needs to accomplish is connecting driver A to device B; the rest
of it is up to the driver.

 
> Another (possibly related) thing to consider here is that we will need
> a way to instantiate i2c clients from user-space. The hardware
> monitoring drivers let us do that at the moment, this is very useful
> when detection doesn't work for any reason, and I don't want to lose
> the functionality in the migration. How do you plan to implement that
> in the new model (if you thought about it at all)?

I focussed on step #1 (getting standard kerne driver model support), and
now you're asking about steps #2 and #3?  Geez.  ;)

I don't see all the legacy drivers converting overnight.  As with all
such migrations, issues turn up that need to be addressed.  I won't pretend
to own a crystal ball (that works).  In the interim, I expect all of the
current solutions will continue to work.

As for instantiating a new-style client from userspace, one way would be
to write the i2c_board_info data into a per-adapter sysfs file.  That would
not be able to handle platform_data of any complexity, or IRQs, of course.

- Dave