From: Greg KH <gregkh@suse.de>
To: Kumar Gala <kumar@kgala.com>
Cc: khali@linux-fr.org, lm-sensors@lm-sensors.org,
linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: I2C-virtual and locking?
Date: Fri, 17 Mar 2006 15:08:10 -0800 [thread overview]
Message-ID: <20060317230810.GA3192@suse.de> (raw)
In-Reply-To: <7A19BA6C-6308-4DFC-B70D-A0AE0E144B59@kgala.com>
On Fri, Mar 17, 2006 at 03:16:58PM -0600, Kumar Gala wrote:
>
> On Mar 17, 2006, at 12:54 PM, Kumar Gala wrote:
>
> >I'm looking at porting the i2c-virtual code from 2.4 to 2.6. One
> >thing I'm not clear on is the use of i2c_add_adapter_nolock() by
> >the old code. The only reference I can find related to this is:
> >
> >http://archives.andrew.net.au/lm-sensors/msg31060.html
> >
> >I can't think of a reason why locking would be in issue when adding
> >or removing of a virtual adapter. Anyone have an additional ides
> >on this?
>
> Ok, so I figured out why the _nolock() versions exist. In
> i2c_driver_register we take the core_list lock. Eventually we will
> call i2c_probe() which should call driver->attach_adapter(). For a
> virtual bus the driver's attach_adapter() will end up calling
> i2c_virt_create_adapter() which will end up calling i2c_add_adapter()
> which will never get the core_list lock.
>
> So should we integrate the concept of virtual adapters into the i2c
> core and have it such that i2c_virt_create_adapter()/
> i2c_virt_remove_adapter() expects the caller to have the core_list
> lock already?
Possibly. Jean, what do you think?
thanks,
greg k-h
prev parent reply other threads:[~2006-03-17 23:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <6CCFFBB4-CDE0-4DC0-A4D7-A3E7398B2494@kernel.crashing.org>
2006-03-17 21:16 ` I2C-virtual and locking? Kumar Gala
2006-03-17 23:08 ` Greg KH [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060317230810.GA3192@suse.de \
--to=gregkh@suse.de \
--cc=khali@linux-fr.org \
--cc=kumar@kgala.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lm-sensors@lm-sensors.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox