From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org, mingo@elte.hu,
linux-kernel@vger.kernel.org, dwalker@mvista.com
Subject: Re: [PATCH] 2.6.18-rt7: PowerPC: fix breakage in threaded fasteoi type IRQ handlers
Date: Sun, 19 Nov 2006 23:11:03 +0300 [thread overview]
Message-ID: <4560BA57.40600@ru.mvista.com> (raw)
In-Reply-To: <1163966649.5826.101.camel@localhost.localdomain>
Hello.
Benjamin Herrenschmidt wrote:
>>>As fasteoi type chips never had to define their ack() method before the
>>>recent Ingo's change to handle_fasteoi_irq(), any attempt to execute handler
>>>in thread resulted in the kernel crash. So, define their ack() methods to be
>>>the same as their eoi() ones...
>>>Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
>>>---
>>>Since there was no feedback on three solutions I suggested, I'm going the way
>>>of least resistance and making the fasteoi type chips behave the way that
>>>handle_fasteoi_irq() is expecting from them...
>>Wait wait wait .... Can somebody (Ingo ?) explain me why the fasteoi
>>handler is being changed and what is the rationale for adding an ack
>>that was not necessary before ?
It's changed in the RT patch for the case of threaded IRQ. This patch is
not for the mainline kernels.
> To be more precise, I don't see in what circumstances a fasteoi type PIC
> would need an ack routine that does something different than the eoi...
> and if it always does the same thing, why not just call eoi ?
Because Ingo decided that calling mask() and ack() methods was a better
than calling mask() and eoi(). Here's the thread:
http://ozlabs.org/pipermail/linuxppc-dev/2006-October/026546.html
> Ben.
WBR, Sergei
WARNING: multiple messages have this Message-ID (diff)
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: mingo@elte.hu, linuxppc-dev@ozlabs.org,
linux-kernel@vger.kernel.org, dwalker@mvista.com
Subject: Re: [PATCH] 2.6.18-rt7: PowerPC: fix breakage in threaded fasteoi type IRQ handlers
Date: Sun, 19 Nov 2006 23:11:03 +0300 [thread overview]
Message-ID: <4560BA57.40600@ru.mvista.com> (raw)
In-Reply-To: <1163966649.5826.101.camel@localhost.localdomain>
Hello.
Benjamin Herrenschmidt wrote:
>>>As fasteoi type chips never had to define their ack() method before the
>>>recent Ingo's change to handle_fasteoi_irq(), any attempt to execute handler
>>>in thread resulted in the kernel crash. So, define their ack() methods to be
>>>the same as their eoi() ones...
>>>Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
>>>---
>>>Since there was no feedback on three solutions I suggested, I'm going the way
>>>of least resistance and making the fasteoi type chips behave the way that
>>>handle_fasteoi_irq() is expecting from them...
>>Wait wait wait .... Can somebody (Ingo ?) explain me why the fasteoi
>>handler is being changed and what is the rationale for adding an ack
>>that was not necessary before ?
It's changed in the RT patch for the case of threaded IRQ. This patch is
not for the mainline kernels.
> To be more precise, I don't see in what circumstances a fasteoi type PIC
> would need an ack routine that does something different than the eoi...
> and if it always does the same thing, why not just call eoi ?
Because Ingo decided that calling mask() and ack() methods was a better
than calling mask() and eoi(). Here's the thread:
http://ozlabs.org/pipermail/linuxppc-dev/2006-October/026546.html
> Ben.
WBR, Sergei
next prev parent reply other threads:[~2006-11-19 20:09 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-19 19:43 [PATCH] 2.6.18-rt7: PowerPC: fix breakage in threaded fasteoi type IRQ handlers Sergei Shtylyov
2006-11-19 19:43 ` Sergei Shtylyov
2006-11-19 20:00 ` Benjamin Herrenschmidt
2006-11-19 20:00 ` Benjamin Herrenschmidt
2006-11-19 20:04 ` Benjamin Herrenschmidt
2006-11-19 20:04 ` Benjamin Herrenschmidt
2006-11-19 20:11 ` Sergei Shtylyov [this message]
2006-11-19 20:11 ` Sergei Shtylyov
2006-11-19 20:06 ` Ingo Molnar
2006-11-19 20:06 ` Ingo Molnar
2006-11-19 20:19 ` Benjamin Herrenschmidt
2006-11-19 20:19 ` Benjamin Herrenschmidt
2006-11-19 20:23 ` Ingo Molnar
2006-11-19 20:23 ` Ingo Molnar
2006-11-19 20:31 ` Sergei Shtylyov
2006-11-19 20:31 ` Sergei Shtylyov
2006-11-19 20:36 ` Benjamin Herrenschmidt
2006-11-19 20:36 ` Benjamin Herrenschmidt
2006-11-19 20:42 ` Sergei Shtylyov
2006-11-19 20:42 ` Sergei Shtylyov
2006-11-19 20:45 ` Benjamin Herrenschmidt
2006-11-19 20:45 ` Benjamin Herrenschmidt
2006-11-19 20:49 ` Benjamin Herrenschmidt
2006-11-19 20:49 ` Benjamin Herrenschmidt
2006-11-20 1:16 ` Benjamin Herrenschmidt
2006-11-20 1:16 ` Benjamin Herrenschmidt
2006-11-20 10:01 ` Ingo Molnar
2006-11-20 10:01 ` Ingo Molnar
2006-11-20 15:29 ` Sergei Shtylyov
2006-11-20 15:29 ` Sergei Shtylyov
2006-11-20 16:56 ` Ingo Molnar
2006-11-20 16:56 ` Ingo Molnar
2006-11-20 17:03 ` Sergei Shtylyov
2006-11-20 17:03 ` Sergei Shtylyov
2006-11-20 17:26 ` Ingo Molnar
2006-11-20 17:26 ` Ingo Molnar
2006-11-20 17:55 ` Ingo Molnar
2006-11-20 17:55 ` Ingo Molnar
2006-11-20 18:20 ` Daniel Walker
2006-11-20 18:20 ` Daniel Walker
2006-11-20 18:29 ` Ingo Molnar
2006-11-20 18:29 ` Ingo Molnar
2006-11-20 18:30 ` Sergei Shtylyov
2006-11-20 18:30 ` Sergei Shtylyov
2006-11-20 19:10 ` Ingo Molnar
2006-11-20 19:10 ` Ingo Molnar
2006-11-20 19:11 ` Ingo Molnar
2006-11-20 19:11 ` Ingo Molnar
2006-11-20 19:18 ` Sergei Shtylyov
2006-11-20 19:18 ` Sergei Shtylyov
2006-11-20 19:24 ` Sergei Shtylyov
2006-11-20 19:24 ` Sergei Shtylyov
2006-11-20 19:23 ` Ingo Molnar
2006-11-20 20:11 ` Benjamin Herrenschmidt
2006-11-20 20:11 ` Benjamin Herrenschmidt
2006-11-20 20:09 ` Benjamin Herrenschmidt
2006-11-20 20:09 ` Benjamin Herrenschmidt
2006-11-20 16:25 ` Daniel Walker
2006-11-20 16:25 ` Daniel Walker
2006-11-20 16:42 ` Ingo Molnar
2006-11-20 17:01 ` Daniel Walker
2006-11-20 20:07 ` Benjamin Herrenschmidt
2006-11-20 20:07 ` Benjamin Herrenschmidt
2006-11-19 20:26 ` Sergei Shtylyov
2006-11-19 20:26 ` Sergei Shtylyov
2006-11-19 20:32 ` Benjamin Herrenschmidt
2006-11-19 20:32 ` Benjamin Herrenschmidt
2006-11-19 20:40 ` Sergei Shtylyov
2006-11-19 20:40 ` Sergei Shtylyov
2006-11-19 20:41 ` Benjamin Herrenschmidt
2006-11-19 20:41 ` Benjamin Herrenschmidt
2006-11-19 20:52 ` Sergei Shtylyov
2006-11-19 20:52 ` Sergei Shtylyov
2006-11-19 21:08 ` Benjamin Herrenschmidt
2006-11-19 21:08 ` Benjamin Herrenschmidt
2006-11-20 15:46 ` Sergei Shtylyov
2006-11-20 15:46 ` Sergei Shtylyov
2006-11-19 20:44 ` Sergei Shtylyov
2006-11-19 20:48 ` Benjamin Herrenschmidt
2007-05-17 13:20 ` [PATCH 2.6.21-rt2] PowerPC: revert fix for threaded fasteoi " Sergei Shtylyov
2007-05-17 13:20 ` Sergei Shtylyov
2007-07-12 16:47 ` Sergei Shtylyov
2007-07-12 16:52 ` Thomas Gleixner
2007-07-12 16:52 ` Thomas Gleixner
2007-07-13 17:19 ` Sergei Shtylyov
2007-07-13 17:19 ` Sergei Shtylyov
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=4560BA57.40600@ru.mvista.com \
--to=sshtylyov@ru.mvista.com \
--cc=benh@kernel.crashing.org \
--cc=dwalker@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mingo@elte.hu \
/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.