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 22:09:28 +0000 Message-ID: <57e2b00712271409n6c98f76o45116cd92b01f396@mail.gmail.com> References: <20071216052308.A0FB11668D7@adsl-69-226-248-13.dsl.pltn13.pacbell.net> <57e2b00712271258l6ea661ai2bfd6b9e099c71be@mail.gmail.com> <200712271353.05857.david-b@pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200712271353.05857.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 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() > > 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