From: Roland Dreier <rdreier@cisco.com>
To: Stefan Roscher <ossrosch@linux.vnet.ibm.com>
Cc: TKLEIN@de.ibm.com, THEMANN@de.ibm.com, fenkes@de.ibm.com,
LKML <linux-kernel@vger.kernel.org>,
OF-EWG <ewg@lists.openfabrics.org>,
LinuxPPC-Dev <linuxppc-dev@ozlabs.org>,
raisch@de.ibm.com, Paul Mackerras <paulus@samba.org>,
general@lists.openfabrics.org
Subject: Re: [PATCH REPOST] IB/ehca: In case of lost interrupts, trigger EOI to reenable interrupts
Date: Tue, 10 Jun 2008 09:18:50 -0700 [thread overview]
Message-ID: <adaabht5klx.fsf@cisco.com> (raw)
In-Reply-To: <200806101701.47090.ossrosch@linux.vnet.ibm.com> (Stefan Roscher's message of "Tue, 10 Jun 2008 17:01:45 +0200")
> > So just to be clear: this is a workaround for a hardware/firmware bug?
> Yes it is.
OK, so paulus et al... does it seem like a good approach to call H_EOI
from driver code (given that this driver makes tons of other hcalls)?
How critical is this? Since you said "corner case testing" I suspect we
can defer this to 2.6.27 and maybe get it into -stable later?
Also, out of curiousity:
> +u64 hipz_h_eoi(int irq)
> +{
> + int value;
> + unsigned long xirr;
> +
> + iosync();
what is the iosync() required for here?
> + value = (0xff << 24) | irq;
> + xirr = value & 0xffffffff;
given that irq and value are ints, is there any possible way value could
have bits outside of the low 32 set? If you're worried about sign
extension isn't it simpler to just make value unsigned?
> + return plpar_hcall_norets(H_EOI, xirr);
> +}
ie why not:
u64 hipz_h_eoi(int irq)
{
unsigned xirr;
iosync();
xirr = (0xff << 24) | irq;
return plpar_hcall_norets(H_EOI, xirr);
}
next prev parent reply other threads:[~2008-06-10 16:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-10 14:44 [PATCH REPOST] IB/ehca: In case of lost interrupts, trigger EOI to reenable interrupts Stefan Roscher
2008-06-10 14:52 ` Roland Dreier
2008-06-10 15:01 ` Stefan Roscher
2008-06-10 16:18 ` Roland Dreier [this message]
2008-06-12 8:37 ` Paul Mackerras
2008-06-13 14:39 ` Stefan Roscher
2008-06-12 7:23 ` Benjamin Herrenschmidt
2008-06-12 9:39 ` Paul Mackerras
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=adaabht5klx.fsf@cisco.com \
--to=rdreier@cisco.com \
--cc=THEMANN@de.ibm.com \
--cc=TKLEIN@de.ibm.com \
--cc=ewg@lists.openfabrics.org \
--cc=fenkes@de.ibm.com \
--cc=general@lists.openfabrics.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=ossrosch@linux.vnet.ibm.com \
--cc=paulus@samba.org \
--cc=raisch@de.ibm.com \
/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).