From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: linuxppc-dev list <linuxppc-dev@ozlabs.org>
Cc: Nathan Lynch <nathanl@austin.ibm.com>
Subject: pSeries_mach_cpu_die() question
Date: Fri, 02 Jun 2006 15:16:32 +1000 [thread overview]
Message-ID: <1149225392.16202.52.camel@localhost.localdomain> (raw)
While doing some autumn cleaning of the irq stuff in general and xics
specifically, I found out that
the low level pSeriesLP_cppr_info() is exported because
pSeries_mach_cpu_die() calls it:
static void pSeries_mach_cpu_die(void)
{
local_irq_disable();
idle_task_exit();
/* Some hardware requires clearing the CPPR, while other hardware does
not
* it is safe either way
*/
pSeriesLP_cppr_info(0, 0);
rtas_stop_self();
/* Should never get here... */
BUG();
for(;;);
}
This leads to a few questions:
- We always pass "0" as the CPU. Is that right ? I seems not, but maybe
pHyp doesn't care and always assume the calling CPU ...
- xics has a xics_teardown_cpu() now, used by kexec, that does
something very similar except that it passes the proper CPU number, and
for secondary CPUs also does an EOI of any pending IPI (just in case). I
think that could be used instead of the direct call to the low level
pSeriesLP_* funciton (which I itend to unexport and rename anyway as
part of my rework). Can whoever knows that code confirm ?
- There is a comment about "some hardware....", what does it mean ? Is
it ok to do it unconditionally ? I suppose so but heh...
Cheers,
Ben.
next reply other threads:[~2006-06-02 5:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-02 5:16 Benjamin Herrenschmidt [this message]
2006-06-02 6:19 ` pSeries_mach_cpu_die() question Nathan Lynch
2006-06-02 6:26 ` Benjamin Herrenschmidt
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=1149225392.16202.52.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=nathanl@austin.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).