From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Byron Bradley" Subject: Re: [patch 2.6.24-rc5-git] add i2c_new_dummy() utility Date: Thu, 27 Dec 2007 23:37:05 +0000 Message-ID: <57e2b00712271537v1e84b8far5d6ef17e40febfc2@mail.gmail.com> References: <20071216052308.A0FB11668D7@adsl-69-226-248-13.dsl.pltn13.pacbell.net> <200712271353.05857.david-b@pacbell.net> <57e2b00712271409n6c98f76o45116cd92b01f396@mail.gmail.com> <200712271506.43069.david-b@pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200712271506.43069.david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i2c-bounces-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org Errors-To: i2c-bounces-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org To: David Brownell Cc: timtimred-f/KTTADhmRsdnm+yROfE0A@public.gmane.org, i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org List-Id: linux-i2c@vger.kernel.org On Dec 27, 2007 11:06 PM, David Brownell wrote: > On Thursday 27 December 2007, Byron Bradley wrote: > > On Dec 27, 2007 9:53 PM, David Brownell wrote: > > > On Thursday 27 December 2007, Byron Bradley wrote: > > > > On Dec 16, 2007 5:23 AM, David Brownell 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 > > > > > > > > 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() ... Yes sorry, not sure where I got device from. > > > > 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(). I'm using the Orion git repo (http://git.kernel.org/?p=linux/kernel/git/nico/orion.git;a=summary) which is being rebased but is currently on 2.6.24-rc5. I will try the latest 2.6-git with the Orion patches and see if that fixes anything. > Do you have other I2C patches that may be causing problems? No other I2C patches. Cheers, -- Byron Bradley