mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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");

  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®