[RFC] Rework of i2c-mpc.c - Freescale i2c driver

[Jean Delvare]

Hi Jon,

On Tue, 6 Nov 2007 12:45:24 -0500, Jon Smirl wrote:
> On 11/6/07, Jean Delvare wrote:
> > I agree with Scott here, I don't want to fork the drivers. It is
> > possible (and easy) to support both methods in the same module, let's
> > just to that. See for example David Brownell's work on the lm75 driver:
> > http://lists.lm-sensors.org/pipermail/lm-sensors/2007-September/021270.html
> 
> I agree that it is easy to make make a chip driver support both new
> and old style.
> 
> But when I call i2c_new_device() on an old style chip driver it exits
> saying that it doesn't work for the old style adapters. Checks for
> is_newstyle_driver() are in the i2c_new_device code. That's what
> caused me to rewrite the rtc-pcf8563 driver for the new style. This
> probably related to probing, I have to pass the address in struct
> i2c_board_info. The old style drivers don't support having their
> address passed in.

I know that. The trick is to register two struct i2c_driver (again see
the lm75 example), one old-style, one new-style. I agree it's not very
elegant, but it works. Hopefully we can get rid of the old-style one
after some time, and it allows for a smooth transition.

> This may be complicated by the fact that the rtc drivers I'm working
> on are not probable. That's why I want to add device tree support for
> them.
> 
> If this is going to work on an old style driver, how do I get the
> address to it?

Old-style drivers probe for supported chips on all possible addresses
(for the chip in question). If the chip can't be probed, then module
parameters must be used. That's not terribly convenient, and new-style
drivers are much preferred in this case.

-- 
Jean Delvare