public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

      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