All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Stephen Warren <swarren@nvidia.com>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Will Deacon <will.deacon@arm.com>,
	Eric Biederman <ebiederm@xmission.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] ARM: call disable_nonboot_cpus() from machine_shutdown()
Date: Thu, 3 Jan 2013 11:08:52 -0700	[thread overview]
Message-ID: <20130103180852.GA7114@obsidianresearch.com> (raw)
In-Reply-To: <20130103122100.GN2631@n2100.arm.linux.org.uk>

On Thu, Jan 03, 2013 at 12:21:00PM +0000, Russell King - ARM Linux wrote:

> This means we could have KEXEC select PM_SLEEP_SMP (and maybe PM_SLEEP) as
> required, rather than bringing in the entire suspend support just to have
> working kexec.
> 
> However, how many platforms don't have suspend support enabled?

I was looking into something similar to this for Kirkwood - my
interest was in getting kexec to work, which means it needs to call
the hibernation callbacks in the drivers prior to execing, otherwise
there is a fairly high chance DMA will corrupt the kexec target.

So this means the code needs the suspend support, however Kirkwood
doesn't have any support for ARM_CPU_SUSPEND, which blocks enabling
suspend at all for that platform. I was looking at moving the 'depends
on CPU_..' from ARCH_SUSPEND_POSSIBLE to ARM_CPU_SUSPEND, which seemed
to do the trick for kirkwood but I didn't study every possibility..

Regards,
Jason

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: jgunthorpe@obsidianresearch.com (Jason Gunthorpe)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: call disable_nonboot_cpus() from machine_shutdown()
Date: Thu, 3 Jan 2013 11:08:52 -0700	[thread overview]
Message-ID: <20130103180852.GA7114@obsidianresearch.com> (raw)
In-Reply-To: <20130103122100.GN2631@n2100.arm.linux.org.uk>

On Thu, Jan 03, 2013 at 12:21:00PM +0000, Russell King - ARM Linux wrote:

> This means we could have KEXEC select PM_SLEEP_SMP (and maybe PM_SLEEP) as
> required, rather than bringing in the entire suspend support just to have
> working kexec.
> 
> However, how many platforms don't have suspend support enabled?

I was looking into something similar to this for Kirkwood - my
interest was in getting kexec to work, which means it needs to call
the hibernation callbacks in the drivers prior to execing, otherwise
there is a fairly high chance DMA will corrupt the kexec target.

So this means the code needs the suspend support, however Kirkwood
doesn't have any support for ARM_CPU_SUSPEND, which blocks enabling
suspend at all for that platform. I was looking at moving the 'depends
on CPU_..' from ARCH_SUSPEND_POSSIBLE to ARM_CPU_SUSPEND, which seemed
to do the trick for kirkwood but I didn't study every possibility..

Regards,
Jason

  reply	other threads:[~2013-01-03 18:08 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-02 21:07 [PATCH] ARM: call disable_nonboot_cpus() from machine_shutdown() Stephen Warren
2013-01-02 21:07 ` Stephen Warren
2013-01-02 21:52 ` Russell King - ARM Linux
2013-01-02 21:52   ` Russell King - ARM Linux
2013-01-02 23:59 ` Stephen Boyd
2013-01-02 23:59   ` Stephen Boyd
2013-01-03 12:02   ` Will Deacon
2013-01-03 12:02     ` Will Deacon
2013-01-03 12:21     ` Russell King - ARM Linux
2013-01-03 12:21       ` Russell King - ARM Linux
2013-01-03 18:08       ` Jason Gunthorpe [this message]
2013-01-03 18:08         ` Jason Gunthorpe
2013-01-03 20:26       ` Stephen Warren
2013-01-03 20:26         ` Stephen Warren
2013-01-06 16:22         ` Will Deacon
2013-01-06 16:22           ` Will Deacon
2013-01-06 16:40           ` Russell King - ARM Linux
2013-01-06 16:40             ` Russell King - ARM Linux
2013-01-07  1:53             ` Eric W. Biederman
2013-01-07  1:53               ` Eric W. Biederman
2013-01-07 14:25               ` Will Deacon
2013-01-07 14:25                 ` Will Deacon
2013-01-07 14:48               ` Russell King - ARM Linux
2013-01-07 14:48                 ` Russell King - ARM Linux
2013-01-11  5:59                 ` Eric W. Biederman
2013-01-11  5:59                   ` Eric W. Biederman
2013-01-11 10:04                   ` Russell King - ARM Linux
2013-01-11 10:04                     ` Russell King - ARM Linux
2013-01-29 22:01                   ` Stephen Warren
2013-01-29 22:01                     ` Stephen Warren
2013-01-29 22:01                     ` Stephen Warren
2013-01-09  0:06               ` Stephen Warren
2013-01-09  0:06                 ` Stephen Warren
2013-01-11  6:28                 ` Eric W. Biederman
2013-01-11  6:28                   ` Eric W. Biederman
2013-01-29 22:10                   ` Stephen Warren
2013-01-29 22:10                     ` Stephen Warren
2013-01-29 22:10                     ` Stephen Warren
2013-01-03 12:03 ` Will Deacon
2013-01-03 12:03   ` Will Deacon

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=20130103180852.GA7114@obsidianresearch.com \
    --to=jgunthorpe@obsidianresearch.com \
    --cc=ebiederm@xmission.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@arm.linux.org.uk \
    --cc=sboyd@codeaurora.org \
    --cc=swarren@nvidia.com \
    --cc=swarren@wwwdotorg.org \
    --cc=will.deacon@arm.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 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.