[i2c] Unprobable chips and new style i2c drivers

[Jean Delvare]

Hi Jon,

On Sun, 18 Nov 2007 16:55:26 -0500, Jon Smirl wrote:
> On 11/18/07, Jean Delvare <khali at linux-fr.org> wrote:
> > Hi Jon,
> >
> > On Fri, 16 Nov 2007 09:55:44 -0500, Jon Smirl wrote:
> > > How do new style drivers work with unprobable devices? Say I have an
> > > x86 kernel with all of the i2c drivers compiled in. The correct bus
> > > driver will be loaded by the platform code. How do the non-probable
> > > chip drivers get told that the device is there? With old style drivers
> > > I could use a kernel parameter to set the address.
> >
> > With new-style drivers, you have two options:
> > * Declare the devices in platform-specific files, using
> >   i2c_register_board_info().
> 
> 
> > * Call i2c_new_device().
> I am doing i2c_new_device() in my PowerPC code which can use a device
> tree to know when to load the driver.
> 
> What do you do for an rtc chip on the x86 platform? Nobody has built
> platform specific configurations for the thousands of x86 designs. The
> old solution to this was a parameter on the kernel boot command line.
> Maybe we should add an 'enable' parameter to new style drivers.

Out of curiosity, have you ever seen a RTC chip on I2C on x86?

The matter is what was being discussed in this thread:
http://lists.lm-sensors.org/pipermail/i2c/2007-November/002205.html

We could add platform-like init code for x86 that would instantiate
new-style I2C devices based on DMI data. I'm not sure how maintainable
this would be though... This would have to be limited to devices that
really cannot be probed, otherwise the list would grow very long very
quickly. The advantage would be that things just work at boot. This
could also be done in a kernel driver, after boot, however this will
break if the device is needed early in the boot process (not sure if we
have to care.)

Your proposal of adding module command-line parameters to new-style
drivers could work as well, however this would have the same drawbacks
as the legacy driver code had, for example you can't pass
device-specific parameters such as IRQ number that way. Also, this
needs specific code in all i2c chip drivers, and I'd rather avoid that.
It's everything but elegant.

That's the reason why my current idea to instantiate new-style i2c
devices from user-space is a sysfs interface. It would live on i2c
adapters (but the code behind would be generic, in i2c-core.) Something
like:

echo "lm75 0x48" > /sys/class/i2c-adapter/i2c-0/add_device

Optional device-specific data could be passed as additional parameters.
If implemented properly, this should even support chip driver
auto-loading. Let's wait for the device naming discussions to settle
first, though.

I also seem to remember that someone suggested configfs as a possible
alternative, but I didn't have the time to look into it yet.

-- 
Jean Delvare