All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <htejun@gmail.com>
To: Mikael Pettersson <mikpe@it.uu.se>
Cc: jeff@garzik.org, kurt@roeckx.be, linux-ide@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.25-rc6] sata_promise: fix hardreset hotplug quirk
Date: Sun, 23 Mar 2008 21:07:30 +0900	[thread overview]
Message-ID: <47E64802.4040507@gmail.com> (raw)
In-Reply-To: <18406.12612.194477.944676@harpo.it.uu.se>

Mikael Pettersson wrote:
>  > Actually, this is common to many SATA controllers.  Lots of them raise
>  > PHY event or hotplug interrupt during COMRESET and they all plug PHY
>  > events from ->freeze.
> 
> Hmm, no I didn't know that. It's still undocumented, but perhaps
> shouldn't be called a "quirk" if it's as common as you say.

Yeap, it's common behavior.  "quirk" would be a bit unfair to promise. :-)

>  > > Although SATA hotplug status and control is per-port, it resides in
>  > > a single register shared by all ports. Therefore accesses to it must
>  > > be serialised: the controller's host->lock is used for that. The
>  > > interrupt handler is also adjusted so its hotplug register accesses
>  > > are inside the region protected by host->lock.
>  > 
>  > Hmmm... This is supposed to be handled by setting ap->lock appropriately
>  > and ap->lock already is initialized to &host->lock, so sticking with
>  > ap->lock is the right thing to do.
> 
> I'll check this. The code relies on the lock being shared by all ports,
> so at a minimum it will need a comment stating that requirement.

That's the default assumption all other LLDs depend on.  I agree it
needs documentation.

>  > ->freeze() is called with ap->lock held, trying to lock host->lock
>  > inside pdc_sata_enable/disable_hotplug() will result in deadlock.  Have
>  > you tested w/ SMP configuration or spinlock debugging turned on?
> 
> No, I'll do that and fix whatever damage occurs.

Thanks.

-- 
tejun

  reply	other threads:[~2008-03-23 12:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-22 14:21 [PATCH 2.6.25-rc6] sata_promise: fix hardreset hotplug quirk Mikael Pettersson
2008-03-23  3:21 ` Tejun Heo
2008-03-23 10:30   ` Mikael Pettersson
2008-03-23 12:07     ` Tejun Heo [this message]
2008-03-23 17:41 ` [PATCH 2.6.25-rc6] sata_promise: fix hardreset hotplug events, take 2 Mikael Pettersson
2008-03-24  2:19   ` Tejun Heo
2008-03-25  2:32     ` Jeff Garzik
2008-03-25  2:37       ` Tejun Heo
2008-03-25  3:32         ` Tejun Heo
2008-03-25  3:53           ` Jeff Garzik
2008-03-25  2:31   ` Jeff Garzik
2008-04-11 21:11   ` Kurt Roeckx

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=47E64802.4040507@gmail.com \
    --to=htejun@gmail.com \
    --cc=jeff@garzik.org \
    --cc=kurt@roeckx.be \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikpe@it.uu.se \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.