linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	james.bottomley@suse.de, dave.jiang@intel.com,
	linux-scsi@vger.kernel.org, jacek.danecki@intel.com,
	ed.ciechanowski@intel.com, jeffrey.d.skirvin@intel.com,
	edmund.nadolski@intel.com
Subject: Re: [RFC PATCH 4/6] isci: hardware / topology event handling
Date: Fri, 25 Mar 2011 18:07:06 -0400	[thread overview]
Message-ID: <20110325220706.GA9535@infradead.org> (raw)
In-Reply-To: <AANLkTin-HGv1V7y8Jn8kJ=ZeaPoK4LL+=Tsoz8Ej3Yjw@mail.gmail.com>

On Fri, Mar 25, 2011 at 02:39:03PM -0700, Dan Williams wrote:
> In that sense the scope of what scic_lock protects is limited to the
> core/hardware state machines (essentially a controller firmware-like
> context).  Anything that blocks or interfaces with an upper layer runs
> unlocked in the lldd layer, and we don't play any games of dropping
> the lock from the core.  Cancelling and flushing timed events is
> really the only place where the lock gets in the way.  Having a
> "timer_cancelled" flag for these few cases is the approach the core
> took over dropping the lock, del_timer_sync, and re-validating state.

If you just want to deactivate a handler and not wait for it to finish
you can simply use del_timer instead of del_timer_sync.  But it's still
up to you to make sure all timer handlers have finished before freeing
their containing structures or any other resource that they use, which
tends to be rather complicated, and hard to maintain in the long run.

  reply	other threads:[~2011-03-25 22:07 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-07  0:34 [RFC PATCH 0/6] isci: initial driver release (part1: intro and lldd) Dan Williams
2011-02-07  0:34 ` [RFC PATCH 1/6] isci: initialization Dan Williams
2011-02-17  8:22   ` Jeff Garzik
2011-02-19  0:12     ` Dan Williams
2011-02-17  8:25   ` Christoph Hellwig
2011-02-19  0:23     ` Dan Williams
2011-03-04 23:35   ` James Bottomley
2011-03-08  1:51     ` Dan Williams
2011-03-18 16:51   ` Christoph Hellwig
2011-02-07  0:34 ` [RFC PATCH 2/6] isci: task (libsas interface support) Dan Williams
2011-02-09 15:01   ` David Milburn
2011-02-14  7:14     ` Dan Williams
2011-02-16 18:48       ` David Milburn
2011-02-16 19:35         ` David Milburn
2011-02-07  0:34 ` [RFC PATCH 3/6] isci: request (core request infrastructure) Dan Williams
2011-03-18 16:41   ` Christoph Hellwig
2011-02-07  0:34 ` [RFC PATCH 4/6] isci: hardware / topology event handling Dan Williams
2011-03-18 16:18   ` Christoph Hellwig
2011-03-23  8:15     ` Dan Williams
2011-03-23  8:40       ` Christoph Hellwig
2011-03-23  9:04         ` Dan Williams
2011-03-23  9:08           ` Christoph Hellwig
2011-03-24  0:07             ` Dan Williams
2011-03-24  6:26               ` Christoph Hellwig
2011-03-25  0:57                 ` Dan Williams
2011-03-25 19:45                   ` Christoph Hellwig
2011-03-25 21:39                     ` Dan Williams
2011-03-25 22:07                       ` Christoph Hellwig [this message]
2011-03-25 22:34                         ` Dan Williams
2011-03-27 22:28                           ` Christoph Hellwig
2011-03-29  1:11                             ` Dan Williams
2011-03-30  0:37                               ` Dan Williams
2011-02-07  0:35 ` [RFC PATCH 5/6] isci: phy, port, and remote device Dan Williams
2011-02-07  0:35 ` [RFC PATCH 6/6] isci: sata support and phy settings via request_firmware() Dan Williams
2011-02-07  7:58 ` [RFC PATCH 1/6] isci: initialization jack_wang
2011-02-14  7:49   ` Dan Williams

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=20110325220706.GA9535@infradead.org \
    --to=hch@infradead.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=ed.ciechanowski@intel.com \
    --cc=edmund.nadolski@intel.com \
    --cc=jacek.danecki@intel.com \
    --cc=james.bottomley@suse.de \
    --cc=jeffrey.d.skirvin@intel.com \
    --cc=linux-scsi@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).