From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jeff Garzik <jeff@garzik.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-ide@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
Tejun Heo <tj@kernel.org>
Subject: Re: [git patches] libata fixes for .26
Date: Fri, 4 Jul 2008 10:09:04 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.1.10.0807040955100.2815@woody.linux-foundation.org> (raw)
In-Reply-To: <20080704131005.GA30768@havoc.gtf.org>
On Fri, 4 Jul 2008, Jeff Garzik wrote:
>
> The libata-sff change is longer than I'd like for 2.6.26-rc, but it's
> all printk changes/additions. No behavior changes, just improved
> diagnostics upon error, something we really need in that area.
Hmm..
Looking at the AHCI change, I think it's still potentially buggy.
I think it is potentially buggy for two separate reasons:
- if the interrupt happens because of some port that we don't handle, we
should still ACK it, in order to get rid of it. I don't think Tejun's
patch fixed anything at all, since it still did a binary 'and' with
hpriv->port_map on the bits, so it would never ACK anything that didn't
have a bit set, and the (bogus) interrupt would keep screaming.
- I also wonder if / suspect that the IRQ ACK should happen _before_ we
handle the source of the interrupt, because otherwise if one port ends
up having two events in close succession (can this happen? I think so),
then we end up perhaps getting the irq for the first one, and handle
that first event, but then the second event happens immediately
afterwards, and before we do the writel() to ACK it, so now the
_hardware_ thinks we have handled both of them, even though we never
actually reacted to the second event.
So I think the appended (TOTALLY UNTESTED!) patch - based on top of the
pull that I already did - might be a good idea.
NOTE! I _really_ didn't test it. I do not know how AHCI works at a low
level, and maybe there is some reason why the IRQ ACK writel() actually
has to happen after you've handled the event (to avoid getting a new
interrupt immediately. But based on other controllers I've worked with,
this is the correct way to not lose irq events.
[ And yes, the race for the irq ack issue is small. And yes, the
likelihood of a bogus interrupt triggering is probably small too. And
see above about my lack of specific knowledge about AHCI.
So I'm sure as heck not going to commit this patch, I'm just sending it
out as a "Are you sure you shouldn't do it like this?" RFC patch.. ]
Hmm?
Linus
---
drivers/ata/ahci.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 061817a..5cfee74 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1786,12 +1786,17 @@ static irqreturn_t ahci_interrupt(int irq, void *dev_instance)
/* sigh. 0xffffffff is a valid return from h/w */
irq_stat = readl(mmio + HOST_IRQ_STAT);
- irq_stat &= hpriv->port_map;
if (!irq_stat)
return IRQ_NONE;
spin_lock(&host->lock);
+ /* Ack _all_ sources of interrupts.. */
+ writel(irq_stat, mmio + HOST_IRQ_STAT);
+
+ /* ..but only care (and report as handled) about the ones we can handle */
+ irq_stat &= hpriv->port_map;
+
for (i = 0; i < host->n_ports; i++) {
struct ata_port *ap;
@@ -1811,9 +1816,6 @@ static irqreturn_t ahci_interrupt(int irq, void *dev_instance)
handled = 1;
}
-
- writel(irq_stat, mmio + HOST_IRQ_STAT);
-
spin_unlock(&host->lock);
VPRINTK("EXIT\n");
next prev parent reply other threads:[~2008-07-04 17:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-04 13:10 Jeff Garzik
2008-07-04 17:09 ` Linus Torvalds [this message]
2008-07-05 3:13 ` Tejun Heo
2008-07-05 3:18 ` Tejun Heo
2008-07-05 4:10 ` [PATCH #upstream-fixes] ahci: give another shot at clearing all bits in irq_stat Tejun Heo
2008-07-06 13:45 ` Jeff Garzik
2008-07-11 14:10 [git patches] libata fixes for .26 Jeff Garzik
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=alpine.LFD.1.10.0807040955100.2815@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=jeff@garzik.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@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
all inboxes | Powered by JetHome®