All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Patrick Mochel <mochel@osdl.org>, Greg KH <greg@kroah.com>,
	linux-kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] call drv->shutdown at rmmod
Date: 15 Aug 2003 09:28:31 -0600	[thread overview]
Message-ID: <m1oeyrx7mo.fsf@frodo.biederman.org> (raw)
In-Reply-To: <1060937467.13316.39.camel@gaston>

Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:

> > You're assuming that a driver can always bring a device out a shutdown
> > state. That's one of the things we talked about at OLS, and the other half
> > of the justification behind such a feature, not just making sure the
> > device is queisced. Your argument against my suggestion are some of the
> > same arguments for a feature like you're introducing. 
> 
> There is a problem of semantics here. Is shutdown() supposed to shutdown
> the hardware device (ie. low power) or just the driver ? If yes, then
> it's duplicate of the PM callbacks. My understanding of the shutdown()
> callback is that it was more than "stop driver activity, put device into
> idle state" to prepare for a shutdown/reboot (though we do also sleep
> IDE drives in this case, but this is because of that nasty cache flush
> issue).
> 
> The problem with kexec is just that. What it needs isn't low power devices,
> it needs device back in "idle" state, but if possible powered up (or at
> least in whatever state the driver found them on boot). The most important
> thing is to actually stop pending bus mastering activities.
> 
> On PPC, we have a name for that which comes from Open Firmware (since we
> need to ask the firmware to stop bus mastering & idle devices the same way
> when we take over it and before we get control of the system memory) and
> it's called "quiesce".

Even if kexec is not brought into the picture the devices need to be quiesed on
reboot.  On x86 and probably other architectures there are 2 ways a reboot can go.
1) The firmware when it regains control toggles the motherboard reset
   line resetting all of the devices, so nothing we do really makes a difference.
2) The firmware when it regains control tweaks a few things and
   pretends it was never out of control, and restarts the boot
   process.

When the firmware does not toggle the motherboard reset line during a
reboot the firmware case is exactly equivalent to the kexec one.

So shutdown needs to quiese things.

Eric

  reply	other threads:[~2003-08-15 16:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-14  7:06 [PATCH] call drv->shutdown at rmmod Eric W. Biederman
2003-08-14  7:54 ` Christoph Hellwig
2003-08-14  8:06   ` Russell King
2003-08-14 15:50     ` Eric W. Biederman
2003-08-14 16:07       ` Russell King
2003-08-14 17:26         ` Eric W. Biederman
2003-08-17 22:26           ` [PATCH] don't call device_shutdown on halt Eric W. Biederman
2003-08-14 16:40     ` [PATCH] call drv->shutdown at rmmod Russell King
2003-08-14 16:02 ` Patrick Mochel
2003-08-14 16:26   ` Eric W. Biederman
2003-08-14 16:41     ` Patrick Mochel
2003-08-14 17:41       ` Eric W. Biederman
2003-08-15  8:51       ` Benjamin Herrenschmidt
2003-08-15 15:28         ` Eric W. Biederman [this message]
2003-08-15 16:01           ` Benjamin Herrenschmidt
2003-08-15 16:30         ` Patrick Mochel
2003-08-14 16:47     ` Randy.Dunlap

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=m1oeyrx7mo.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=benh@kernel.crashing.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@osdl.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 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.