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

[David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>]

On Thursday 27 December 2007, Byron Bradley wrote:
> On Dec 16, 2007 5:23 AM, David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> 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-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
> 
> 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!)

- Dave

[1] http://khali.linux-fr.org/devel/linux-2.6/jdelvare-i2c/