[i2c] [patch 2.6.24-rc5-git] add i2c_new_dummy() utility

[Byron Bradley]

On Dec 27, 2007 9:53 PM, David Brownell <david-b at pacbell.net> wrote:
> On Thursday 27 December 2007, Byron Bradley wrote:
> > On Dec 16, 2007 5:23 AM, David Brownell <david-b at pacbell.net> wrote:
> > > This adds a i2c_new_dummy() primitive to help work with devices
> > > that consume multiple addresses, which include many I2C eeproms
> > > and at least one RTC.
> > >
> > > Signed-off-by: David Brownell <dbrownell at users.sourceforge.net>
> >
> > For the S35390A RTC driver I called i2c_new_dummy() in the probe
> > function in a similar style to the at24 eeprom driver. This failed
> > because the probe function is called inside an i2c_attach_device()
> > which has already locked &adap->clist_lock. When you call the
> > i2c_new_dummy() function it will itself call i2c_attach_device() but
> > it will never be able to acquire &adap->clist_lock.
>
> Right ... make the s35390a driver be a new-style driver.
>
> Or, Jean has patches in his queue [1] to remove other lists
> from i2c_core which duplicate driver model core behavior.
> I think i2c_adapter.children and i2c_adapter.clist_lock have
> not yet been removed, even though they're redundant given the
> driver model's device.klist_children records.
>
> So if you're ambitious and don't want to just make that RTC
> driver be a new-style driver, you could just get rid of that
> functionality duplication.  (Me, I'd take the easier route and
> just make it be a new-style driver!)

I believe this is already a new-style driver. It uses the RTC
framework, the module init calls i2c_add_driver() and the struct
i2c_driver provides a .probe and a .remove function. Is there
something else that I'm missing?

Thanks,

-- 
Byron Bradley