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

[David Brownell]

On Thursday 27 December 2007, Byron Bradley wrote:
> 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()

You mean i2c_attach_client() ...

> > > 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.
> >
> > ...
> >
> > 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.

Indeed; sorry, I skimmed over that stacktrace too quickly.


> Is there something else that I'm missing?

I'm not sure yet.  I certainly tested that updated at24 driver
with lockdep active, and it didn't report such a warning.  It's
possible lockdep on that platform isn't fully functional yet;
I'll see if that problem triggers on a different arch (after
some intentional misconfiguration to call this utility).

One thing that looks odd in your stack trace is that it shows
i2c_attach_client() calling mutex_lock_nested(), which is most
certainly not what it does in rc6-git-current ... in fact, a
nested call is made (rather curiously) only in i2c_transfer().

Do you have other I2C patches that may be causing problems?

- Dave