From: ebiederm@xmission.com (Eric W. Biederman)
To: Russell King <rmk@arm.linux.org.uk>
Cc: "Adam J. Richter" <adam@yggdrasil.com>,
eblade@blackmagik.dynup.net, linux-kernel@vger.kernel.org
Subject: Re: Patch: linux-2.5.42/kernel/sys.c - warm reboot should not suspend devices
Date: 13 Oct 2002 18:03:28 -0600 [thread overview]
Message-ID: <m1smz9lwdr.fsf@frodo.biederman.org> (raw)
In-Reply-To: <20021014001552.Q23142@flint.arm.linux.org.uk>
Russell King <rmk@arm.linux.org.uk> writes:
> On Sun, Oct 13, 2002 at 04:10:01PM -0700, Adam J. Richter wrote:
> > I have no objection to replacing or supplementing the reboot
> > notifier chain with a method in struct device_driver, but let's not
> > overload these methods with ambiguous semantics. I do not want to
> > call thirty functions that primarily return memory to various memory
> > allocators, mark a bunch of inodes as invalid, and otherwise arrange
> > things so that the kernel can smoothly continue to run user level
> > programs when, in fact, we just want to pull the reset line on the
> > computer.
>
> And what about setups where you can't pull the reset line from software.
> I have several machines here like that. And one of them needs software
> to talk to the cards to put them back into a sane state before rebooting.
>
> "rebooting" in this particular case is "turn MMU off, jump to location 0"
And for x86 it is turn MMU off, jump to location 0xffff0.
> And I never said anything about needing to allocate memory to do this.
> I agree with you that suspending devices on reboot _is_ silly. However,
> that's not what I was proposing.
>
Documentation/driver-mode/devices.txt says:
> int (*remove) (struct device * dev);
>
> remove is called to dissociate a driver with a device. This may be
> called if a device is physically removed from the system, if the
> driver module is being unloaded, or during a reboot sequence.
>
> It is up to the driver to determine if the device is present or
> not. It should free any resources allocated specifically for the
> device; i.e. anything in the device's driver_data field.
>
> If the device is still present, it should quiesce the device and place
> it into a supported low-power state.
So there is a little bit that deals with a low power state.
At any rate until someone changes the kernel API again ->remove()
is the proper method to be calling in this case.
Eric
next prev parent reply other threads:[~2002-10-13 23:59 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-13 23:10 Patch: linux-2.5.42/kernel/sys.c - warm reboot should not suspend devices Adam J. Richter
2002-10-13 23:15 ` Russell King
2002-10-14 0:03 ` Eric W. Biederman [this message]
2002-10-13 23:54 ` Eric W. Biederman
-- strict thread matches above, loose matches on Subject: below --
2002-10-21 22:26 Adam J. Richter
2002-10-21 20:56 Adam J. Richter
2002-10-22 4:28 ` Eric W. Biederman
2002-10-20 7:01 Adam J. Richter
2002-10-20 9:17 ` Eric W. Biederman
2002-10-20 20:43 ` Patrick Mochel
2002-10-20 23:57 ` Eric W. Biederman
2002-10-21 17:13 ` Patrick Mochel
2002-10-17 1:50 Adam J. Richter
2002-10-17 9:08 ` Eric W. Biederman
2002-10-15 19:52 Adam J. Richter
2002-10-16 12:13 ` Eric W. Biederman
2002-10-15 18:54 Adam J. Richter
2002-10-15 2:53 Adam J. Richter
2002-10-15 16:59 ` Eric W. Biederman
2002-10-14 18:41 Adam J. Richter
2002-10-14 20:05 ` Eric W. Biederman
2002-10-15 4:55 ` Eric Blade
2002-10-16 8:01 ` Pavel Machek
2002-10-14 15:25 Adam J. Richter
2002-10-14 16:44 ` Eric W. Biederman
2002-10-14 17:48 ` Richard B. Johnson
2002-10-14 19:28 ` Eric W. Biederman
2002-10-14 20:17 ` Richard B. Johnson
2002-10-13 23:59 Adam J. Richter
2002-10-14 0:07 ` Eric W. Biederman
2002-10-14 5:38 ` Eric Blade
2002-10-14 15:28 ` Eric W. Biederman
2002-10-15 4:34 ` Eric Blade
2002-10-13 22:14 Adam J. Richter
2002-10-13 22:31 ` Russell King
2002-10-13 23:49 ` Eric W. Biederman
2002-10-15 16:35 ` Patrick Mochel
2002-10-15 20:04 ` Mikael Pettersson
2002-10-19 18:30 ` Eric W. Biederman
2002-10-20 9:47 ` Eric W. Biederman
2002-10-13 19:24 Adam J. Richter
2002-10-13 19:51 ` Eric Blade
2002-10-13 21:27 ` Eric W. Biederman
2002-10-13 22:52 ` Andries Brouwer
2002-10-14 0:30 ` Eric W. Biederman
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=m1smz9lwdr.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=adam@yggdrasil.com \
--cc=eblade@blackmagik.dynup.net \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
/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).